Peter Rose is technical director of TEKenable and has over 30 years’ experience working on a wide range of IT projects. In this article, Peter looks inward and advises on how to avoid the F-word (Failure).
Generally, we engage with a client to deliver a total project solution, working from the initial scoping all the way through to development, testing and handover. On occasion however, we’re brought in to turn a project around after it has hit problems. This is always an interesting experience, and we’ve learned some valuable lessons
Peter Rose, CTO, TEKenable. Image: Paul Sharp/ Maura Hickey
When I look back at failed IT projects, probably the best lesson I’ve learned is that disaster doesn’t usually come out of the blue. Instead, problems emerge slowly over time and on a number of fronts. Then there comes a tipping point where the project breaks down and failure results.
I tried to get this point across at a breakfast briefing with the analogy of the ‘boiling frog’. From distant memory of my school biology classes, if a frog is put suddenly into boiling water, it will jump out, but if it the same frog is put in cool water and then brought to the boil slowly, it will not notice the danger and will be cooked to death.
In my experience the same principle applies to IT projects. So, here are ten early warning signs which can alert you to a problem. Generally, if you have more than two of these warning signs, your IT frog is in danger of being cooked!
These are not in priority order, but all are significant:
1. Constant Re-planning
A good project plan addresses five key factors, specifically; scope, or what the project will cover; resources, who and what is available to meet the scope; time, in terms of what tasks are to be undertaken and when; quality, in terms of the spread or deviation allowed from a desired standard; and risk, what may happen to drive the plan off course and what will be done to recover the situation.
If you find yourself constantly re-planning your IT project, then one or more of the above is changing or poorly assessed from the outset. I call this the “Every project is on time according to the last plan written” syndrome.
2. Late working
Constant late or weekend working is a strong warning sign that all may not be well. A good project plan should have identified the appropriate level of resources. Of course, projects will occasionally require some late working but sustained long hours is a clear indication that something is amiss. Fatigue and stress are a very effective way to erode quality.
3. Constant re-scoping
Re-scoping is frequently a warning sign of trouble ahead. When a software project falls behind, the team may square the circle by changing the scope. This is particularly problematic with Agile projects where re-scoping is easier to hide. I am not sniping at Agile, we use this methodology on many projects. But it can allow the team to convince itself that the project objectives have changed when it is at risk of non-delivery.
4. An ‘it will do’ mentality
A bad attitude to quality is another indication that your frog may end up being cooked. It inevitably stores up problems further down the line. An example I frequently encounter is willingness to accept poor code early in the project rather than emphasising high standards from the start. his leads to a “long tail” of issues in which the quality issues destroy the project plan forcing rework during testing, which is usually late in the project and more expensive and risk at that time.
5. A ‘we will catch up’ mentality
I’ve learned from experience that if projects fall behind early on, they generally continue to fall behind unless action is taken. Hoping to catch up is not a strategy. My advice? Don’t bury your head in the sand – denial can waste valuable recovery time and don’t leave it too late to call for help.
6. Project surprises
All projects will contain surprises but good planning helps reduce the risk. We spend time identifying technical risks and uncertainties and seek to deal with them up front or in a ‘Proof of Concept’ project. Data migration is the risk that keeps giving and a prime example of an activity that needs to be started early in the project and not left to the end.
7. Increasing senior management involvement
If you find that senior management is spending increasing amounts of time on your project you may need to watch out. If they are genuinely needed, then that’s one thing as inadequate stakeholder involvement is also a big negative. However, frequently more eyes on a project add no value. I once worked on a project in the UK where management demanded updates every two hours and no, it did not help!
8. Requesting additional staff
Long experience has taught me that there’s a natural team size for a project and adding to the team won’t get the project completed any faster. Of course, I’m not the first person to notice this. Back in 1975, a man called Fred Brooks wrote a great book called the Mythical Man Month. One of his conclusions: ‘ adding manpower to a late software project makes it later’.
9. A ‘don’t bring bad news’ culture
Honest communication is very important. The development team must be able to raise issues without fear of being punished. Failure to do this almost guarantees nasty surprises. It also makes it likely that these surprises will only be discovered at the point of maximum impact – when the project is nearly complete.
10. A Project ‘monitor’ vs ‘manager’ mind set
It’s important that the project manager has the appropriate level of skill to manage the relevant software project. All too often, the person managing the project is only a ‘monitor’ – ticking the boxes and reporting on the project progress. While reporting is important, the project manager must also have the knowledge to ask the right questions, pre-empt risks and plan around difficulties before they impact – and certainly on large projects, it’s very important to understand the software development process and something of the technology.
So those are ten tips on how to avoid project failure. My advice is to watch your project closely. If two or more of these issues emerge and you don’t address them your frog is at risk of being cooked!
Finally, I’m sure you have your own favourite tips on how to make your software project a success. I’d be delighted to hear them and to get your thoughts on my own list.
Image: fizkes/Shutterstock
Written by Peter Rose (peter.rose@tekenable.ie)
Published: 19 August, 2019
