There is an idea that when we start a software project, there is an end state that could be considered finished. But up until then a project remains unfinished.  Businesses often embark on projects that are never truly finished based on their initial concept. Sometimes these are referred to as failed projects when in it may just be unfinished project that stopped being worked on.  I propose that there are only four states for a project; Not Started, Unfinished, Abandoned, and Completed.

There Are No Finished Projects Just Completed Projects

The business world has embraced the concept of a ‘Minimum Viable Product’ (MVP).  That is the smallest amount of ‘product’ that adds value to the intended consumer. Many software projects have adopted the Scrum method and use the Product Owner to drive what is important to the success of a project.  This Product Owner ultimately decides what the most important items are and ranks them in order of expected value.  As the Product Owner is the one that prioritizes the items, they control how much value is ultimately produced.

This also means that projects will probably never truly be finished.  There should always be a backlog of improvements that the consumers want or fixes to problems.  At some point, the remaining improvements will no longer add enough value to justify the cost of implementing them.  When this happens further development should be stopped.  But is it finished?  That term finished seems very final. It implies that there is nothing more to be improved, nothing more to make it more perfect. Likewise, a project may be so far from the original goals and outcomes, they are abandoned. I prefer to think of these projects as having run their course and are Completed. This is why completed projects are just abandoned or unfinished projects that are no longer consuming resources.

An Unfinished Project Is Not The Same As Successful

Just because we stop working on a project does not determine if it was successful or not. This all depends on how value is defined at the beginning of the project. According to this article 70% of projects are deemed to be failures. This reasoning seems to be faulty at it’s core. Here is one of the quotes from the article that attributes failures to the lack of requirements planning.

Solid requirements planning establishes a clear connection between the business case, project goals, and the project outcome.

Helge Scheil

There is an implicit idea with that quote that you create requirements based on project goals and outcomes. You should always know more at the end of the process than you do at the beginning. It is the height of hubris to believe you can get the ‘requirements’ correct at the beginning. The business goals and desired outcomes are the requirements. Solutions are created for these requirements, and these result in specifications. The gap between the goals and outcomes to solutions and specifications is wide.

Four Reasons For Failed Software Projects

• Business Case Changes (finances, business climate, industry changes)
• Business Goals Change / Desired Outcomes Change (different stakeholders)
• The team lacks the skills or business expertise (technology, business knowledge)
• A solution was chosen and could not be meet the goals or outcomes (technology, business process)

Any one of these could change and most agile processes can adapt and still give a product that provides value. It may not be exactly what was envisioned at the beginning of the project, but it still could provide value. If more than one changes, it is a new project. And each of these is worthy of their own article.

Celebrate The Unfinished Project

Whether a project is successful or not, resources were spent during the process of building the project. If the project ultimately creates value or does not, we need to recognize that the resources spent cannot be unspent, these are investments. One can either try and create value from what has come from the project, but we will never regain the resources that were expended. It may be that the value created will exceed the amount invested, it may not.

One thing should be certain. Learning from your successes and failures during the process of working on a project is invaluable. These hard earned lessons are assets and increase the value of organization.  Smart businesses do not throw away these lessons, the good and the bad. Celebrate the learning that occurred during the process, internalize it within yourself and your organization.

Go out and create more unfinished projects.