Measuring Project Completion Progress


I taught my project dashboard workshop today. One of the things most people want to measure is progress towards project completion. But you can't measure project completion progress unless you have completed features: developed, integrated, and tested features. A completed feature is done enough for someone to use.

Implementing by architecture leaves all the feature integration up in the air until the end of the project, so if you must implement by architecture, you just can't measure completion until the end. That's too risky for me. But if you implement by feature, you can start measuring completion as soon as you've implemented one feature.

3 Replies to “Measuring Project Completion Progress”

  1. I think I know what you are talking about when you mean, you can be sure of measuring a project’s progress by feature. Can you clarify what you mean by architecture?

  2. Agilists embrace this philosophy in their emphasis on frequent “releases”. A key characteristic of a “release” is that it be demonstratable to an end user. To be demonstratable to end users, it must show how they would achieve something of value to them using the system. Internal architectural progress is of no value to a user. Features are.
    However, sometimes the highest risk in a software project lies in the architecture. Developers should attack such risks first. A good agilist identifies creative ways of exercising and addressing these architectural risks while still delivering value to a user early and incrementally.

  3. I absolutely agree with this. The tricky part is making sure you don’t “uncomplete” some of you “done” features when you implement later ones.
    Good automated regression testing is really important to make sure you are not going backwards.

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.