Technical Project Management - Progress Reporting
In technical projects, PMs can easily get caught up in status reporting by percentage complete. This was never discussed in any detail, in my graduate work on project management, nor in the materials from the Project Management Institute. Admittedly, it may have been there, but I don't recall seeing it. I got an A in the class in grad school and I passed my PMP. So, if it is something they deemed an important topic, they certainly do not raise it to a sufficient level of attention.
But percent complete seems to be a common method to track status on tasks. It may have been reinforced by Microsoft Project, as percent complete is prominently displayed in the interface, in the default toolbar, for example. This might make sense for construction projects and the like, as each task is more decomposable. Despite never having been involved in a major construction project, the idea seems to be that a staircase needing to be built of 10 stairs - when 4 stairs are complete, that's 40% there. This does not apply to technical projects however. It is a well known precept in computer science for example, that percent complete is independent of the number of lines of code. In my programming days, a project manager would ask for a percent complete; I would stare blankly and come up with a guess. The same applies to infrastructure projects. Unless you need to install the same patch or software on 10 different, but equal nodes in a cluster, there is very little applicability to the concept of percent complete. When configuring a server for a particular function - take an Exchange server for example - it's not done until it's tested and complete. Until email flow is validated, clicking next, next, next is irrelevant. I have heard this described by one of my first PMs at Microsoft as "the onion problem". You have no idea how long is left until you have peeled back the layers of the onion and reached its core. Because all it takes is one bad layer and the entire task goes from 99% complete to 1% complete.
We can see this clearly in progress bars in software. People joke about how little they align to reality. They seem to be going backward in some cases. And progress bars are built upon an algorithm designed to model the progress. Yet they still fail miserably. Compare that to an engineer making a value judgment on percent complete - off the cuff... and making these assessments in rapid succession as they report status on all their tasks. When Windows 7 loads now, there is no longer a progress bar... just an ever-looping indicator that the operating system is loading. Which makes more sense and aligns closer to reality.
My Project Management instructor at Microsoft Services University had it right. From a technical project management standpoint, there are three states:
- Not started.
- In progress.
- Complete.
In my experience, this is absolute truth. Most projects that are large enough to justify a project plan, rather than an agile approach, have enough lines in them that percent complete is irrelevant. The real questions are - have you started? And are you complete? Every status in the middle is irrelevant.
And even technical projects require time estimates. But the other point I have learned at Microsoft is - if we missed the mark, do not simply move the date up. Wait until you have a reason to believe something will be done by that date. Project Managers don't like to hear that. But that is their job - to push individual contributors to come up with estimates, and report on percent complete. By all means, project managers, do that. But focusing on percent complete is a waste of time in technical project management. There are three states that matter. Focus on those and let the workers get it done.