You or your company is heavily investing in an IT product, the success of which is very important to the business projections. Cash is burning, the development is slow, and you are finding many unexpected things to consider You are in new territory and losing sleep – where should you be looking?
Firstly, if you think you are off track you are probably right. Some years ago, I picked this up from the construction industry, and it has proven highly accurate for our company.
“If you are 15% or more through a project the percentage cost overrun will persist”.
If you are comfortable with the project, then you’ll be needing to consider more investment rather quickly. In the 30 years I have been on both sides of the fence, I have help create some great IT products and have also experienced managing a start-up company. I have also been involved in some failures and those experiences are also helpful. These days I really like to avoid those failures – it is so hard on everyone involved. While IT complexity increases at some exponential, I like to think the issues that projects may hit remain the same underneath.
In this blog I consider what an investor who has engaged a software development company like us, should be asking if they are concerned. In writing this blog I needed to graphically illustrate a concept which was simple to capture in the diagram below.
Let me explain the two dimensions:
- Direction: This comes from thinking about the market of users. It is a quest to “understand their pain” as put by Allan Cooper, the “father of Visual Basic”
- Momentum: This is the amount of useful work and analysis the development group can sustain.
By assigning a project to one of these quadrants it becomes obvious that we want projects to be in the B quadrant – well aligned direction and momentum. It may be languishing in either the A or C quadrants. If a project languishes in D, lacking both momentum and ideas, the business will stop investing.
Projects with direction that have lost momentum
The team is confident they have the right product. Those at the customer face are getting clear signals that this will find the market. But the project is slow to get started and continues at a frustrating pace. Inevitably, the project will run out of cash and as an investor you need to decide whether to continue.
Investors should be asking whether the project is larger or more difficult, as they are caused by different problems. Let’s look briefly at how software is developed using modern methods such as Agile. The group works through from logical start points and investigates what needs to be done. This may only be finalised a few weeks (or even a week) before the developers cut the code. Analysts describe what is needed in “stories” which go onto a ledger. The customer can often cross off some stories as now being irrelevant and the balance of stories on the ledger shows how many things need developing. If there are many more things than anticipated, then the project is getting larger. However, if it is simply taking longer to develop the things it reflects the project is more difficult.
The project is larger than expected.
The main issue here is momentum. Investors should be asking about the implications if the project takes longer (other than costing more). The most important questions are whether the group has the momentum to keep everyone engaged. A great project usually comes from a totally engaged group. It has a good vibe that spills confidence to the market, then delivers something delightful, and roughly on time.
If not, you may need to scale up the development team. This is a topic all its own. Most understand this will increase the need for managing and communicating between people – the right balance of roles may therefore change, and efficiencies may decrease. This is something our Team Lead Wade Parker deals with constantly.
The project is more difficult than expected.
This is almost always an issue of expertise. The best professional qualification in the IT industry is that you have done it before. As an account manager I see solutions arise when the developers are honest about the need for more expertise, know where they can access it, and the investors feel confident with the development crew. The more difficult situation is when the needed expertise is widespread. This is a serious issue and investors should be asking whether the developer has the flexibility in their company to pull across more senior developers and pull in topic experts.
Projects with momentum but have lost direction
These projects are characterised by major changes in direction that cut deep to the bone of what has already been developed. They become a problem when unanticipated changes continue and start to spook the horses. Nobody really knows how far they are through the ever-changing project, so this creates difficulties for planning cash flow and investment.
The investors should be asking whether they are confident in the direction. Is their enough engagement with the users? Has there been enough thinking? Does this software solution help someone achieve a far better result? How much pain does it take away?
The investors should look to manage cashflow by reducing development. This helps take immediate pressure off the product owner who can put this time into having a re-think. They need to really locate where they are getting tangled and refocus the momentum there.
A solution to these projects only comes when someone thinks a way through. Software development is a craft where every line of code is created after someone has thought about what it should say. It may be time to halt development altogether.
What investors should avoid
If you are an investor or on an investors governance group there are some things you should avoid doing as, while they seem like great governance, they just make matters worse.
Take note of early warning signals: It may be lazy to accept assurance the project will settle down. You need to be convinced there is enough direction and momentum – which quadrant is the project falling into?
Avoid asking for reports that seem like good governance but hog-tie the thinkers. For example, an urgent report sizing everything that is left to do. For many items, the team may not yet know enough detail to size them. If you push, you’ll no doubt get something. But if you have diverted the thinkers time away from focussing on where the tangle is, its likely the Gantt chart they produce for you will prove to be underminingly inaccurate.
Avoid asking for cost overruns categorised by major feature. To me this is like bayonetting the wounded after you have lost the battle. This often involves detailed categorisation of stories and rolling them back to the features. It’s hard to, for example, apportion backend development to each UI feature; and what about work to support coming new features? We have done this many times and it provides no better information for future decision-making than knowing your overall project has expanded 20% and this will continue. Investors need to concentrate on questions more specific to the problem.
Finally, shifting a project back into that ideal B quadrant can be difficult to achieve technically. The people aspect can make it infinitely worse if communication breaks down. Conversely, there is incredible power when everyone in the team thinks each morning how they can really kick the project along. It will be from people thinking that a solution will arise.