100 days ago I decided to focus on becoming an AI startup. I gave myself a time limit (five months left) to demonstrate to myself that I could get something up and running.
I was getting somewhat anxious about having no income coming in, so six weeks ago I took on a part-time freelance project for a company that was switching their booking system.
I had planned for a nice ongoing earner with 1.5 days a week worth of work. Giving me plenty of time to focus on AI stuff.
What actually happened, was I got dropped into a shitstorm.
That said, I got them launched, and have backed out now. I won’t go into details to spare them the blushes, but did think I would write some generics about IT project management.
Why IT projects go bad, and what to do when they do.
Software projects can essentially have infinite scope. There is always something that can be tweaked or added. Add business management to the mix and they will demand a long list of features …
1 – You didn’t clearly agree scope with all stakeholders at the beginning, and get them to sign off on it.
All parties have a responsibility to be as clear as possible what the project is going to do. With money changing hands it’s absolutely essential.
If you are just prototyping, it’s slightly different.
You would rarely start builders on a home project without seeing some form of work blueprint.
In my early career, I ignored scope and most of the time I got away with it. But as soon as it’s something more complex, it became essential.
The work spec is essential because:
- You can protect yourself when the customer asks for more than they are paying for. As soon as the customer says, ‘well I thought I was getting X, I really need X’ … you can direct them back to the initial agreement. ALWAYS build what was initially agreed, release that, and then build the new feature afterwards.
- If done correctly, the work spec will force the thinking in the development team of HOW they are going to implement it, broadly speaking, and so the system architecture begins to form.
- New management or developers don’t know where they are without the work specification.
- Leads to increased probability that the cost is accurate
- The customer is forced to think what they actually want
Don’t mistake flowcharts for a specification. Documenting scope is a skill. Flowcharts are an essential part of the spec, but they still don’t describe what is being built.
2 – The initial scope was wildly excessive, or the customer adds ongoing scope throughout the project (and you let them)
Since software scope can be infinite, it’s easy for a customer to say they want everything. Writing a work spec helps against this, but if you don’t really think about the potential detail involved you’ll get the cost wrong.
In most cases, a good developer should identify the handful of functions that actually represent the core USP of the system.
If you are building a new product from scratch, always identify the very core of what you are trying to do and focus on that. Get those shipped and out there, and begin testing from there.
If you are halfway through a project, the BIGGEST problem I’ve always found is that management will add onto the scope rather than goto launch. They will insist feature A needs to get done with some essential feature. This becomes a habit and the product NEVER gets launched.
I worked on a project for two years and toward the end, management kept asking for more features … AND I LET THEM (at price)… I was naive … and eventually upper-upper management came into the project, the manager demanding the new features said ‘they haven’t finished’ … upper management got cold feet and pulled the project. We were so close to releasing a product that was perfectly timed to do well in the real world. Yet, it failed to launch because scope kept getting added.
3 – The developer never documented the system
This is a big one. Doesn’t seem it at the start, but eventually you need to bring other developers in… do you really want to explain repeatedly how the system works?
Documentation should be as concise as possible. You will get egos in the team who think they demonstrate their intelligence by producing a 100 page spec that no-one is ever going to have the time to read.
Documentation isn’t the initial project scope. A lot of programmers say that the code should explain itself. It’s correct, but also misses the point. Large codebases should be described (AI can help a huge amount now) … there’s always things that fellow developers need to know.
4 – You are building on a system that is shit
This is something that isn’t easily fixed. When you are working on a system that hasn’t been thought through properly; and just been cobbled together over the years… it really does become a major problem. Developers don’t want to work on it, they get stressed and they will mimic the state of the codebase by taking further shortcuts. And the problem compounds itself.
5 – You are under-resourced
There’s no way around it. If you don’t have the money to build your system then you will suffer. And if you are a technical founder, if you don’t have the time … then you are not going to get there either.
You avoid this by:
- Being very clear about what you want and don’t want
- Your scope is realistic
- Your work brief has identified how much it will REALISTICALLY cost by working out how to do it
If you are deep into a project and money has run out… it’s generally because you’ve messed up further down the line. The main thing you can do is give equity away to a decent developer and ask them to work at minimum wage for a while on it, to bring it up to the correct level.
Or, you just take out another credit card, but you get very clear about what you are doing or not doing.
6 – Poor communication (too little or too much)
The main problem with this last freelance project was that the two developers weren’t successfully communicating via emails. They were working, effectively, in different timezones … when I came in, I was able to bridge that gap and in just a few calls I had resolved blockages that had been around for quite a while.
Emails are not the best form of communication. You really need to have developers talking to one another and sharing screens so they can properly explain their problems.
So that was under communication which was the problem.
Then you can get the over communication, where you get dumped with a ton of stuff that doesn’t matter … often information that should really be in a Google Doc that can be referenced. If you add to the mental overhead of a developer, the developer will have a drop in productivity. So often you just need to keep the technician focused and protected from the business decisions going on around them.