Why a tech project is never finished

Tech projects are difficult. They really are a problematic thing to try to deal with but primarily they are difficult to finish. And by finish I mean “be accepted by the client”.

If you’re in a company or an external contractor/supplier the same rules apply. Starting is often quite straight forward, but how do you know when something is finished?

This is where project management comes in, and whatever system you use (Agile, Lean, PRINCE, Extreme, *trust*) they all in some form have acceptance testing at the end of it.

Except that they almost all rely on one thing: knowing before you start, what the acceptance criteria are going to be.

The problem with tech projects in my experience (and especially with startup tech projects) is that without almost unlimited funds (in the startup context this is almost never the case) to do an exhaustive list of requirements, you cannot know what the acceptance criteria will be at the end.

So you are almost always going to be left with some risk around “non-completion” of a project. There will almost always be acceptance criteria that nobody had considered, that become necessary towards the end, or things that originally looked achievable that (reasons may include budget, resourcing, technology, complexity etc) become unachievable.

Now, I can hear the naysayers saying that you just need better processes, and better management and better tools and more cast iron contracts or the like, but there’s a problem. They cost money. Money that has to come from a client at some point, and money is a problem most of all in a startup context as well. As I’ve said, unlimited funds make projects much easier to deliver but a lot more expensive obviously. (Did you notice I didn’t say “better” there?)

So how do you manage the smaller projects?

It’s all about managing risk from both sides of the project. A client has to accept that the lower cost means higher risk that they may not get everything that they want, and the supplier has to accept that the project may change, and that this may mean they will have to do something different to what was initially envisaged. However, the flip side of all this is that the client needs to realise that if things change (as they often do), they either have to pay more to complete the project or accept an incomplete project as completion to the cost that they originally agreed. The supplier is often all too aware of this problem as almost every low budget project changes over time.

The problem with risk is that clients think it doesn’t apply once they’ve paid. The problem from the supplier side then is making sure that this risk is mitigated by charging more.

Can anyone see the problem? If the client doesn’t accept the risk, then the supplier will not get the budget needed to mitigate the risk. Therefore the risk falls squarely on the shoulders of the supplier of the project. How to mitigate the risk? Legal contracts, extensive proposals including enormous acceptance criteria, endless meetings… yup! That’s cost of doing business sometimes.

So basically, why do projects never finish? Because most of the time, a tech project is actually much more of the start of a process of development that can last years. The idea of a tech project being a completion event for a startup is generally wrong as almost no tech will ever be “finished” for a client.

The long road is how tech should be approached. The project approach is there to start, but it’s never the end. That doesn’t mean that the initial project should continue onto maintenance and ongoing development ad infinitum and it doesn’t mean it shouldn’t “finish” at some point but it does mean that stability of technology comes at a price, and that price is almost never easy to work out at the beginning of the initial project.

So for startups the initial project completion is the start, not the end, of a journey. In bigger companies, a lot can be learned from this approach. The mitigation of risk in larger companies is the majority of project costs as I see it, and sometimes, the smaller approach is just better. The more enjoyable tech stories are the ones where they just “had a go”.

I can’t remember the last unicorn that was created by someone putting a large project team together and doing their best to mitigate risk.