I have very limited experience in software project management roles, and I was asked this question by another engineer and I was sort of stumped.

How do I measure when a software project is complete?

The part I'm struggling with is the "measure" part. I know there are measurements such as EVM, but they are more focused on overall project performance. For instance, having a low SPI or low CPI can indicate performance/allocation issues, but it doesn't really indicate how complete a project is.

Is there a rule of thumb here to say my project is XX% complete or am I overthinking this?

  • Project completeness is a measure of Project Management and is probably outside of the domain and scope of this site. You would get the same answers if you replaced "software developement" with "IT".
    – maple_shaft
    Nov 7, 2011 at 19:26
  • 4
    @maple_shaft I disagree. The way you staff, fund, manage, and measure software projects is very different than running other types of engineering projects. This question is, IMO, on topic here under the "development methodologies", "business concerns", and "software engineering" categories - I took multiple courses in my undergraduate program on specifically how to manage software projects and processes.
    – Thomas Owens
    Nov 7, 2011 at 19:34
  • 1
    A project is complete when you can't think of any way it could be better! So really, there is no such thing! :-)
    – Dynamic
    Nov 7, 2011 at 19:39
  • I'm backing up @ThomasOwens. The concepts we're talking about here and the insights I hope will come out are important for every software developers to understand.
    – azheglov
    Nov 7, 2011 at 19:51
  • 1
    What's the scope of the project? If it covers the whole product life-cycle then the project only is complete once the last customer stopped using the software or the management cancels it.
    – Patrick
    Nov 7, 2011 at 20:20

6 Answers 6


The project is complete when there isn't anything left to do that the project sponsor is willing to pay for.

  • 1
    amazingly succinct and accurate observation. Dec 10, 2011 at 6:20
  • Unfortunately, yes. +1 for reality. The sad reality is - even if you know that the project is not finished and has still some bad flaws, if the (non-technical) sponsor sees a somehow working product, he will think that letting you work on it any more will not improve anything (because he saw that it already does what he want), so he will decide that it's finished. Dec 10, 2011 at 10:08
  • +1: It may sound cynical but it is true. Projects are really supposed to have a well-defined end, and most of the time that's when the money stops coming in. In the end it's nothing weird really, you should move on to other projects when one has ended. Of course I guess lifers have a problem with this.
    – Spoike
    Dec 10, 2011 at 17:52
  • Thanks for the comments. It is true that there is some cynicism in the answer, especially if you live in the world of waterfall methodology. However, there is also another way to look at it. If you live in the world of RAD or Agile, then you don't know exactly what the end product is supposed to be when you start out. You only find this out along the way. From a clinical, micro-economic perspective of supply and demand, it makes sense to say things are only worth what someone's willing to pay for them.
    – Joel Brown
    Dec 10, 2011 at 22:14

In a plan-driven methodology, where you have the complete requirements up-front, a complete project would satisfy all of the requirements and pass the specified unit, integration, system, and acceptance tests. In a perfect world, the project would end at the end of the plan. However, the health of the project should be tracked as part of the plan, allowing for insight into health and status so that a project that is exceeding cost/time allowed can be cancelled early.

In an iterative and incremental methodology, you often end every iteration with a potentially shippable product, which includes all of the software and associated documentation that is required. The project could end under a number of circumstances - you run out of requirements to ship, you run out of money, the customer ends the project if the cost of a future iteration is less than the earned value, or so on.

You don't want to estimate a percentage of completion, as you can only measure against known requirements, as it doesn't account for unknown requirements or defective requirements. Instead, you want to measure project completion against measurements such as completed requirements, percentage of passing tests (especially acceptance tests), and earned value - these will give a general health/status of the project, regardless of the methodology used.

Depending on your specific methodology, there are a number of measurements and metrics that you might be interested in. A few examples include earned value, velocity, requirements churn (changed requirements/unit of time), defect reports, cost (compare actual to budgeted at each phase of the project), effort, and progress (actual completed tasks vs scheduled completed tasks).


Sounds like you might be over thinking it a bit, but we programmers do have a habit of doing that.

Track a list of requirements. When you can mark of each requirement as tested and implemented, begin system testing the project.


If you have to ask the question, you don't have a project, as a project needs to be defined (think SMART Goals - Specific, Measurable, Achievable, Realistic, Time framed.).

You either have a list of requirements and/or deliverable items that must be achieved, in which case it's complete when these are done. If you don't have these, you don't know what you are building, and really don't have a project. Given your probably going to fail in this case, when the money runs out is as good a point as any to call it complete.


There is a simple rule of thumb. Define the goal of your project, express it in a number of units, see how many units you have completed so far, and compute the completion percentage.

For example, the goal of your project is to spend 400 hours writing some code. You've already spent 280 hours. Your completion percentage is 280/400 = 70%. (This paragraph is 100% sarcasm, but unfortunately this is how most project managers see progress.)

To give another example, the goal of your project is to develop some product features and deploy them to users. Let's say, you've got 10 features and you haven't deployed any of them yet. Your completion percentage is 0/10 = 0%. (This is where a typical project manager will say: "But we've coded and tested five of them; 50% or them are done!")

Moments when one of these metrics is close to zero while the other one is close to 100% are illuminating. You know what your goal is, right?

  • 1
    The problem with using percentages or ratios is that it's dependent on knowing all the requirements up front to be able to make meaningful decisions based on the numbers. If you have requirements that are stable, that's fine. In most cases, the requirements have some volitality. Seeing data that fluctuates based on known requirements is meaningless - 50% done today could be 10% done tomorrow and 75% done the next day as requirements are changed.
    – Thomas Owens
    Nov 7, 2011 at 19:52
  • @ThomasOwens: if you've delivered 5 of 10 features and it turned out the next day that only 1 of them was needed (and the other 4 weren't needed), then you've got a defective process. If you can find the root cause of this jump (from 50% to 10%), you will improve your process. The jumping percentages alert you so that you can get started on that.
    – azheglov
    Nov 7, 2011 at 20:25
  • @ThomasOwens: teams that would ever see numbers like 50-75% are doing well enough already. The most common pattern in the software industry is that this percentage (under my 2nd definition) stays close to 0% for almost the entire duration of the project as partially completed work waits for a big-bang integration at the end. (This work is "completed" under a definition of done disconnected from the goal.) My message to OP is to use something simple to avoid distractions from their goal and alert them to problems early.
    – azheglov
    Nov 7, 2011 at 20:28

You need to plan for project closure as well, possibly marking it as a milestone, that can be crossed subject to some conditions-also in your plan. Just prior to this point you will typically have a project-post-mortem and data archival activities etc.

So in a nutshell, the project ends when the plan for the same says it does! HTH.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.