Finishing a Project

The most expensive thing any company can do is to start a project, and not complete it. Every single man-hour, every single cent spent on that project gets destroyed, as soon as the project is cancelled or abandoned.

One of the most expensive uses of anybodys time is also starting something that never gets completed. Every single hour spent in that project is destroyed when the project is abandoned - and on top of that, there is a huge opportunity cost - that time could have been used for something else.

And abandoned projects are very common - look at many peoples github, you will see projects that were started, and abandoned before they really got to a usable level.

As such, one of the most valuable things that any person or organisation can do is to figure out if a project is going to be completed. Many projects are good ideas, but there is a very low chance of them being completed - due to lack of time, attention, resources or other constraints.

The resources needed to complete any project are finite, and they cost something. If the price cannot be afforded, then it means that this project will not be completed. And all the cost of building the pointless project can be avoided by never even starting the project.

Project Inputs

A project needs:

• Time
• Resources (Money)
• Attention

Depending on what the project is about, those items are needed in different proportions. The items are also somewhat interchangeable - money can buy time (by hiring people), attention comes from having time, and some things that cost money can sometimes be replaced, given enough time. But each of those things is a direct constraint, and can be measured. An estimate of how much of those inputs each project needs can always be evaluated (and a buffer added), to really understand if a project has a realistic chance of reaching the completion state. If not, then it is best not to start the project till the inputs are available.

The Completion State

Every project is almost infinitely large. If it’s a software project, almost any feature can be added to it. So one cannot simply start a project with a vague idea of what the completion state is - it has to be well defined - and include certain things, and exclude certain things.

What is really needs to include is a completion state that will result in new information that determines the future of the project. Because a project can be infinitely large, it can also absorb infinite inputs. The decision about how much resources needs to go into a project also depend on how valuable the project will end up being - and that information is hard to get at the very beginning.

So a very useful thing to do is to define an initial completion state that also acts as advice about how much potential this project has, and thus allows a rebalancing of how much resources are being sunk into the project.

Important in defining the completion state:

• What type of information do we need to understand if this project will be successful?
• What is the minimum set of features needed that allow us get that information?

The first completion milestone should be super optimised towards the above - because they act like a checkpoint for the project, and a way to easily stop throwing resources at something that won’t work.

And sometimes, there are aspects of projects that are required, but it’s not obvious they are. For example, a side-project startup, completing the product is not enough, there needs to be a minimum of marketing to see if people will buy it. Perhaps there are enough resources to build it (the person is a coder), but not enough resources to market it (person does not enjoy marketing). In such a case, this project will end up in an incomplete state, even though the product itself is done.

Tldr

Jumping into a project is easy. Lots of excitement always. But willpower does not complete a project. Resources do. It is very, very expensive to start a project where the resources to complete that project are not available. So it’s best not to start what you can’t finish.