Project managers use percentage to evaluate task completion, is that really the healthy approach?



  • 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.




Suggested Topics

  • 2
  • 2
  • 2
  • 2
  • 2
  • 2
  • 2
  • 2
  • 2
  • 2
  • 2
  • 2
  • 2
  • 2
  • 2