The Standish Group's periodic CHAOS report suggests that only around a third of such projects can actually claim success. And while some may quibble about Standish's methodology, says Luke Barrett, senior business analyst, from ThoughtWorks, there is no doubt that this reflects the anecdotal experience of many project teams; present this statistic to a room full of IT executives and the response is a sea of nod-ding heads.
Given that the majority of IT projects fail, what are the primary reasons? CIO Magazine reported that 71 per cent of projects fail due to poor requirements management.
The Standish Group themselves point to a lack of user input together with incomplete and changing requirements as the leading causes of challenged pro-jects. On the flipside they identified user involvement, executive sponsorship and clear requirements as the most important indicators for success.
So, any approach claiming to address failures from the outset needs to be convincing about how stake-holders are engaged and how requirements are clearly captured and managed. We’ll look closely at these two themes as we consider what is required from people and processes to prevent teams from failing.
A little context
Before getting to grips with people and processes it is worth mentioning that many of the ideas here are drawn from the realisation that what has been so effective for Agile software development can be just as ef-fective for the work that leads up to that development: Agile analysis, if you like.
This means much of what is described here is based on a time-boxed, iterative, interactive and feedback-seeking approach to work. It is also based on a belief in the core values of Agile methods like Extreme Pro-gramming.
These values of communication, simplicity, feedback, courage and respect are more broadly ap-plicable than just to the writing of code, and they place emphasis on the way that team members interact. With this context, and given Agile's focus on people and their interactions over processes and tools, let's begin by looking at people.
People
There are at least three constituencies that need to be represented in the project team: the business itself, those implementing the solution (IT often being at the forefront) and the end-users. A disconnect between any of these groups threatens the success of the project.
Alarmingly, while most teams consist of some combination of the business and IT, all too often actual flesh and blood end-users are omitted, despite the fact that it is their increased productivity (employees) or satisfaction and spend (paying customers) that often power the project's benefits case.
This is what the Standish Group means by lack of user involvement. While it is distressing to see a user struggle with the application in which you have invested time and money, it is better to learn this as soon as possible rather than waiting until user acceptance testing. This can be achieved through user feedback sessions with cheaply and quickly created low-fidelity prototypes.
While the omission of end-users is one of the more obvious issues to address, more challenging is ensuring appropriate representation from the wider business. The goal is to achieve frequent input from those who have the best grasp of the business.
In practice this may mean input from multiple departments and various levels of seniority. In addition there will be contributions from members of cross-cutting functions such as legal, security and back-office operations, although the frequency of their input is likely to be lower.
The point about seeking input from multiple levels of seniority is worth restating. It is likely that on a day-to-day basis the business representative on the team will be someone of moderate seniority; senior enough to have a good grasp of the business, but junior enough that this is their day job.
Again, one cause of project failure is lack of executive sponsorship, so it is essential to use tangible outputs at weekly or twice-weekly showcases to engage with, and extract feedback from, senior business representatives.
Process
With a multi-disciplinary team gathered, it is time to develop a series of lightweight models to describe the problem and its solutions. These models will drive out a shared understanding - essential if the team is to capture the clear requirements we are seeking. It can be helpful to think of the models as exploring three areas: strategy, business process and implementation.
At the strategic level, a simple prioritised list might be used to agree project objectives with their associated metrics, while a financial model might be used to quantify the benefits case. It remains remarkable how many projects proceed with no clear quantification of their benefits.
At the business process level, the high-value, high-frequency processes that the solution needs to support are modelled, often pictorially. These models explore how key user types achieve their highest value goals.
Again, the models are lightweight and ideally at a level of abstraction that requires no more than seven to nine steps. The aim is to provide a framework for the more detailed solution decomposition that will happen at the next level down - that of implementation.
At the implementation level, the team is exploring the output of the higher level models and capturing them as business requirements - with sufficient detail that the software development team can estimate the delivery effort.
The team's understanding of the written requirements should also be validated by the creation of low-fidelity prototypes of key usage scenarios. The people who will do the software development (not the project manager or analyst) need to provide estimates and should also have sufficient information to allow a technical architecture to be formed and options presented for the main technology choices.
This list of models is indicative rather than exhaustive, and the process by which these artefacts are evolved is of equal importance. Experience suggests that two to four weeks of effort spent in evolving the models, distilling the requirements, prioritising them from a business perspective and estimating them from an implementation perspective will prepare a team for release planning and then development.
The first week or so tends to be spent in workshops. The team work together in short sessions, collaborating to evolve the models. Where possible, updates occur live in the workshop; where this is not possible, feed-back is incorporated between workshops.
For example, using marker pens and index cards it is easy to model and refine a high-level process: cards can be re-ordered, ripped up if necessary, replacements writ-ten, new ones added. Likewise, high-level requirements captured on index cards have the same flexibility and allow the whole team to participate at the same time.
As the process continues, the intensity of workshops reduces, allowing more time for consolidation of the artefacts, detailed analysis away from the main group, workplace observation and usability testing. A minimal rhythm of workshops remains to ensure the team is informed about the progress being made on all fronts.
This approach addresses our two themes of engagement and clarity of requirements, by having a multi-disciplinary team intimately involved in the evolution of the models that represent their shared understanding.
The team see their feedback being used to create the artefacts in front of them - feedback that is in response not only to written requirements but also to models (particularly the low-fidelity prototypes) that give them a visual, tangible feel for what is being discussed.
Combine this with weekly presentations to senior stake-holders, and the approach provides a powerful mechanism for engaging stakeholders across multiple areas and levels of seniority.
The seeds of success or failure are sown early in the life of a project. By applying iterative, feedback-driven and people-centred working from the outset, businesses improve their chances of success by ensuring they have engaged stakeholders who collaboratively evolve clearly understood and agreed requirements.
