Project Management Stack Exchange is a question and answer site for project managers. It only takes a minute to sign up.
Sign up to join this community
My concern here is that those percentage evaluations for project task progress/completion are subjective. And given that statement, is it really worth it?
Why not push for more detailed breakdown which has clear evidence of "task" or "subtask" completion which delivers either value or progress artifacts?
Keen to gauge exeprienced PM's for opinions here. How do you track progress/completiont and if you use percentage to evaluate?
Excellent question. This is one of the topics that almost caused me to give up on project management as a profession. This is a problem. I'm aware of at least three different protocols or standards in response to this.
Boolean No task is done till it is done. Every task has a definition of done and until the task reaches that state, the task is undone. This has the advantage of being objective, transparent, and empirical. You have to establish the Definition of Done, but if that is absent, the task has deeper problems. The disadvantage is that Earned Value, cost accounting and many other project management tools are going to be .... less than useful... At a minimum, you're going to have sawtooth progress; for small and moderate sized projects, I've found that these tools just aren't informative or useful. It is impossible to tell the difference between a task in progress and a task that hasn't started, and that distinction is very important.
Rule of three This is a rule of thumb. When someone starts working on a task, mark it 33% complete. When the responsible party submits the task for review/evaluation, mark it 66% complete. When the task is accepted as having met the Definition of Done, mark it 100% complete. This has the advantage of allowing you to spot tasks that haven't yet been started, and it can help to identify tasks that are slipping (you'll need to know your project, but in my environment if the duration is 50% done and the task hasn't been submitted for review, it is time for me to have a discussion with the responsible parties). EVM and cost accounting still won't work well, but it is a significant improvement over the boolean protocol. This helps me to sleep at night.
Progress Definition When you create the task and establish the Definition of Done, also create a progress metric. (in well planned projects, this goes in my Work Breakdown Structure Dictionary). This is a great opportunity to sit down with the responsible party and discuss with them how the task will be accomplished, and how it should be measured. Wonderful opportunity to capture items for the risk register. What are the stages? For example, in software, how much time do you expect to spend on researching? When do you expect to have the initial unit tests? What is the complexity of the code? Are there chunks that can be submitted to quality control early? What about the unknowns? (this is where you'll decide on critical path vs critical chain, and communicate that to your team/SME)etc. 90% of project management is communication, and this is the part where we listen to the subject matter experts and capture what we need to manage the project. The key is to do this in a respectful and humble fashion, and to convince the SME that sharing this information with you will allow them to concentrate on the task, while enabling you to communicate with management/stakeholders, and will allow you to secure the resources they need.
The third protocol is quite time intensive. For the project I've managed, the vast majority of the time I rely on the rule of three - that seems to meet the needs of my stakeholders, who don't care about EVM, but want to believe that I have a deep awareness of what is in progress, when the project will be complete, and where they can assist.
MCW's answer is a stellar one. I'll just add a few thoughts: there is nothing wrong with percentages so long as 1} people are aware of what the estimation is, ie, physical percent or duration percent; 2} folks understand the inherent biases at play; 3) and there is a cogent method for forecasting. Asking the right questions matters. For example, how much have you completed is not a great question. What do you have left is a better question. What remains tends to remove the optimism bias at play. Not alll the time but it helps. Also, get your team to estimate in ranges. Ask when will you finish. Then ask, if everything goes to $hi2, when will you finish. Getting your team to use 3-point estimates is eye opening.
Also, you get to know your team. You'll learn who sandbags and how they sandbag and then you can adjust accordingly.
For some work types, % complete isn't that meaningful. I prefer to think of, and define, a few (5? 10?) maturity levels of each major component, and then concentrate on the work to obtain the next level of maturity. At least one of these level will correspond to the component being deliverable. But each one is externally meaningful somewhere else in the project. An engineer working on a rocket nosecone doesn't need the engine to be in a finished state, but it's helpful to know how the Prototype went. So there's a dependency between Engine = Prototype and Nosecone (Concept --> Sketch).
So you could have a list like this:
Management of progress includes estimating and tracking the effort to get to the next level, and ultimately the deliverable one. And then communicating these statuses around so that decisions can be made in the whole product.
