Software Project Rescue - Get a Difficult Project Back on Track
From time to time SkillsLogic is asked to help out on a software development project that isn't going to plan. Most of these projects seem to get into trouble for one or more of the following reasons:
- Not enough good upfront analysis - requirements are never really bottomed out and underlying complexity isn't fully understood until after development starts.
- Poor initial planning - still vague requirements and over optimistic estimating lead to unrealistic delivery timescales. Project managers take developer estimates at face value and find it hard to step back and look at the project objectively.
- The customer is struggling to manage its own stakeholders/end users - again changing requirements keep the ground moving under the development team's feet.
- Lack of deep technical expertise/experience in the delivery team - feeds poor estimating and often leads to overly complex technical solutions that still manage to miss core requirements, ramp up costs and disappoint end users with poor usability.
- Progress not being tracked properly - a plan that doesn't flush out potential problems soon enough is no good. Plans need early milestones that indicate real tangible progress when they are met and flag up underlying problems when they are missed.
What can you do if you think you've got a struggling or even failing software development project?
- Get independent and objective advice from outside the development team. You might only be able to get an honest appraisal of where you are from someone not directly involved in the project. The trick then of course is to find a suitably qualified consultant.
- Review, fix and then re-prioritise the requirements. Borrow from 'agile' - think about documenting requirements as simple 'user scenarios' and have a single master list or 'product backlog' of requirements that need to be implemented.
- Stop hoping for the best and re-plan honestly. Can you release less in the first instance? Break big jobs into smaller ones? Organise work into shorter 3 week 'sprints'? Beware though - don't pick off the easy jobs and release them every three weeks without getting round to tackling the really difficult problems.
- Think twice about adding extra developers to a project that's behind schedule - you get into a world of diminishing returns and 'The Mythical Man-Month'. Our experience is that bigger development teams on struggling projects make things worse.
- Do think about getting more technical expertise to fill specific gaps/tackle the most complex areas. And that definitely also includes extra business analysis support. We've seen projects before where the problems started with too much complex requirements analysis/solution design resting on the shoulders of one over stretched business analyst who becomes a bottleneck on a project where no other single person understands the complete solution.
Finally, beware the sunk cost fallacy and be prepared to make the hard decisions. Sometimes - no matter how much time and money has been spent - it simply makes more sense to call it quits. That's not an easy thing to do and it may well make sense to get a third party to give you some independent advice before you make the decision.
