"What is the status of the current project?"  This question haunts the dreams of project managers.  We give answers like "we are on track", "we are 60% there" or "hold on I'll go find out".  Too often, these statements translate into "the team will work ridiculous hours to make up it look like we will ship on time", "here is a number I just made up that 'feels' right", or "I will go ask the developers to make up numbers that I'll pass along, but I'll pass them along confidently".   As a whole, project teams are not very good at tracking progress in a meaningful way and, in turn, we aren't very good at managing software projects.  As the great Steve McConnell points out in his book Professional Software Development, at least 50% of software projects are late, over budget, or under scope while 25% fail outright, and one of the chief culprits is the inability to identify project challenges until it is too late.

The rate of project failure is really astounding if you think about it.  The primary purpose of a project manager is to track progress and handle the logistics that promote and impede that progress.  If we can't adequately assess project status, we aren't doing our jobs.  Yet, we get caught up with all of the other rat killing implicit with managing a software project and take our focus away from the primary initiative.  Projects are challenged and we don't figure this out until those challenges have snowballed.  The result?  Projects fail.

But hey, tracking the status of a project in a meaningful way is hard, right?  I don't buy it.

The key to managing the status of a project lies in how each individual project task, some unit of work that has a well-defined output that contributes to project completion, is managed.  A project is simply a collection of tasks.  These tasks have to be well understood so that we understand the impact the completion of an individual task has on project completion.  Unfortunately, this never seems to be the case.  Let me give you an example of what I mean. 
I've worked on projects where it was not uncommon to get three tasks for a month's worth of work.  Task 1 would be something pretty small.  It might require a couple of days to finish if I loaf, or a day to finish if I hustle.  Task 2 would be something a bit bigger, maybe requiring a week's worth of work, but it would still be fairly well understood.  Then there would be task 3, a blob of a task so poorly defined that no one could reasonably say when it could be done and often it would be impossible to say what 'done' even meant.  I could say 'this will take me a month' or 'this will take me 2 hours' and nobody would even bat an eyelash.

So a week later, I might report to management that task 1 was complete, task 2 was 90% complete, and I'm about 25% of the way through with task 3.  With task 1, one could reliably assume that a contribution to the project's overall success had been made.  It was done.  I had washed my hands of it.  The ball is now in someone else's court.

With task 2, 90% is obviously made up, but it's a number that adequately expresses that the bulk of the work has been done.  Sometimes that last 10% can really stretch out, but when I say I'm 90% done, I'm at least putting my own neck out there to say task 2 will be wrapped up soon.  If I don't deliver soon, I'll look bad and I definitely don't want that.

And now on to the albatross that is task 3.  What does 25% mean?  In Trent-speak, it means I've looked at it and maybe even created a few stub classes.  However, don't bother assuming I'm anywhere near being done, as I still have a lot of waffling room in that remaining 75%.

So it's reported up the chain that I'm almost done with 2 of my 3 tasks and that the last item should be done 'soon'.  When pressed, 'soon' is usually explained with a made up date optimistically based on the perceived quick completion of the first two items.  When this occurs, the project is already in disarray.

Experience has probably bludgeoned most of us with this scenario more than once, so it has to be more than a unique phenomenon.    So what do we do to get out of this hole?  It's simple:  put together a plan for tracking status and follow it.  Be disciplined.  Notice, I did not say run out and buy some snazzy tool.  A tool is not a solution.  A hammer doesn't do anything unless you swing it.  It's not that great project management tools don't help, it's just that a project can be managed with the best tools money can buy just as poorly as a project managed using no tools at all.

The key, as hinted in the example I gave earlier, is in how we track individual tasks.  This involves being methodical in how we break down tasks and in how we assess task completion.  Your project can be vastly improved if you just follow this set of guidelines

  • Tasks should be broken down into units of similar 'weight'.  This means that the effort required to complete tasks should be as similar as possible.  If tasks are all similar in size, the effect of completing a task will be universally understood in terms of how it affects the status of a project.
  • Tasks are either done or they are not.  The idea that a task is 'half done' should be stricken from your organization.  It's all or nothing.  A task that is not fully complete does not contribute to project completion, so quit pretending that it does.
  • Tasks should be small.  I strongly recommend that tasks be expected to require no more than a day's worth of a given team resource.  This will allow you to get a day-to-day understanding of the current status of a software project.  Additionally, breaking tasks down to a more granular level improve estimates and make sure developers are somewhat detailed in their design.
  • Tasks should always represent a unit of work.  Never break tasks into a sequence of steps.  This means no tasks like "Implement feature X - day 1" and "Implement feature X - day 2".  I've seen trolls like these before and they are utterly useless.  How does one know when the first task is complete?  It's usually when the estimated time given to that task has elapsed instead of when some meaningful work has been done.  Avoid this at all costs.
  • People should not do any work that isn't fully described in a task.  This will help the team clearly understand why a project might be challenged because you will have immediate visibility to whether new work is being introduced and what kind of work is being done.  Is a project challenged because our estimates were bad?  Is it because the problem was poorly understood?  Is it because work external to the project keeps stealing resources?  You will be able to clearly answer these questions with hard evidence.

These guidelines are simple and effective.  They just usually require a level of effort during the design and planning stages of software lifecycle that most haven't been disciplined enough to invest.  They are in too big of a hurry to lay down code for fear that every second someone isn't coding is a second the team is behind schedule.  It's just a thorny problem (affectionately coined by McConnell as WIMP, or Why Isn't Mary Programming?) we have all fallen prey to it at least once.