Do you know a failed project when you see one?

When faced with a riddle, it can be difficult at first to see a solution but once you know the answer it becomes trivial.

Solving a failing project can feel very similar in that it may not be obvious whilst you're in it but is easier to spot with hindsight. The list of reasons is almost endless but here are five areas to be wary of.

1. A sponsor's dream may be vivid but lacks clarity and business value in reality

An idea from a corporate executive is tasked to an enthusiastic delivery team to expand the concept and develop a design and implementation strategy. The team progress against a desired timeframe motivated by the senior manager who also sponsors development, testing and deployment effort. After an efficient promotion phase and early adoption, a senior user requests to meet the sponsor to raise a query "what is the value of this initiative to our business?"

2. Start now, plan later

With ever-increasing demands to deliver something (in some cases anything), the desire to be doing rather than planning at the beginning of a project is understandable. But without a high level breakdown of the major activities, associated deliverables and key milestones, the journey can be directionless. Furthermore, many projects have high-level, vague, and generally unhelpful requirements. This often comes from a lack of early input from the parts of the organisation that are either intended to benefit from the project or be impacted by it. The result is to build what is believed to be needed in the absence of key stakeholders and their requirements. An inevitable consequence is that the final solution is not fit for purpose. Users must know what it is they need, and be able to specify it precisely – with ongoing involvement through requirements gathering and analysis, design and development activity. Without this, the user community may not feel committed to a solution and may even become hostile to it.

3. How long will it take?

Be wary of estimates undertaken by management alone along with projects that carry very long timescales. Involve subject matter experts as part of the planning process (leveraging experience from successful engagements) and break down long projects into shorter activities or sub-projects. The role of the project manager is to balance the desire for fast delivery against the potential danger of unrealistic timescales through ongoing monitoring, control and oversight. A wider governance function also ensures that all project plans and associated control processes (to manage risks, issues, dependencies etc.) are regularly reviewed to ensure they remain realistic and enable them to be challenged if stakeholders have any reservations.

4. Change, change, change

The operational and strategic landscape of an organisation constantly changes so it should be no surprise that the scope of a project may change over its duration. Whilst controlled and managed change is one thing, unchecked scope creep is something different and one of the main reasons many projects are deemed to be failures. One response is to shorten timescales and adopt a phased approach to delivery and implementation so that change has less chance to affect development. However, the project manager must have a change control process to ensure proposed changes can be evaluated and their impact on timescale, cost and the risk to the project assessed.

5. Informal testing and sign-off

Although the level of testing through development, build and configuration phases of a project may be extensive, ultimately it is the user community that needs to validate the solution to ensure it meets the original business requirements. User testing is typically the final indication of acceptance, but it can often fail to highlight faults before a system goes live because: - Original requirements weren't captured or accurately recorded - Testing is adhoc, unstructured and unplanned and lacking method and thoroughness - Users have not been trained appropriately or with limited understanding of their testing and sign-off responsibilities - Inadequate time to execute tests given delivery pressure - The release of fixes, enhancements and new features is not co-ordinated with testing activity In summary, users need to gain confidence with new or upgraded solution before it can be expanded to a wider community. To accept any new system they need clear requirements that can be validated. They should also expect the tests to be well designed, planned and co-ordinated as well as be adequately trained, and have sufficient time to meet the objectives.

Read more topical articles from past editions of 4ideas.