Don’t play whack the gopher
Requirements management exciting - shock
Who would have thought that some 50 people, from CIOs to developers, would feel strongly enough about anything to do with business to turn up at 7.30am in a London hotel, just to suffer a seminar. But that is what they did to witness a presentation by Luke Barrett, a senior analyst at Thoughtworks.
What was even more perverse was the subject – requirements management. I mean, just how dull is that? Yes, it’s an important subject, but important enough for a 7.30am start? After all, we all know the evidence about requirements. The Standish Group’s Chaos Report has shown that only nine per cent of IT projects are considered successes, while 29 per cent are outright failures. The majority, however - 62 per cent - are not considered as much at all. Neither success nor failure, they lie in the limbo category - 'marginal'.
We even know why they are there, if we’re honest. Getting the requirements management piece right is a lot harder than most people think, and one of the key issues is communications between the primary stakeholders in any project. These can be the business looking to make revenue and profits from the project, the consumers of the project who look to use it easily and effectively, and the implementers charged with trying to make the project work. According to Barrett the connections between these three are normally broken in some way.
It was interesting to see that most of the audience agreed with the suggestion that these relationships are usually adversarial, and there were many heads nodding in agreement. Even from behind I could sense the welling up of tears of anger and frustration in some of those nodding heads. "Most often projects fail because of poor requirements management, the softer stuff around the technology," Barrett said. "It is rarely the technology itself."
His solution to the problem is the extension of agile programming techniques to business analysis. Here, one of the key techniques is about getting project stakeholders to communicate more clearly. This involves building multi-disciplinary teams that include people from all sides of the business that are project stakeholders – business, IT, marketing, sales, operations management etc. One of the first steps is then to legitimize the time they devote to team meetings. These will usually take the form of workshops run by a facilitator (a role Barrett sometimes takes with clients). They will be held regularly, with Barrett actually recommending two meetings per day, each lasting 90 minutes.
One important tool for both getting communications going and "cutting to the chase" of specific issues is what Barrett calls popping the "why" stack. This is simply to keep asking the question "why is it done that way?" about project requirements. He gave an archetypal example of what the technique can unearth: "I once worked with a client where there was a requirement that data was printed out at a particular stage in the process, so I asked why" he said. "The answer was that the department receiving the data needed to key it in. It had never occurred to them that the data could be transferred to their application automatically."
It is inevitable that each team member will have a different view of a project, which can make capturing a consensus view difficult. The standard approach is through documentation but, as Barrett observed, words can be slippery things, and he finds models can be more powerful. They can also bring out different perspectives. He favours simple models, such as prioritized lists of high-level issues such as strategic requirements, though more complex tools such as financial and process models can be useful. At each stage the idea should be to do just enough to set the context of the project at a high level. This type of model can be as simple as three lists: 'in scope', 'out of scope' and 'unresolved';. If the drive down to more detail identifies new high-level requirements, they can then be retro-fitted. The idea is to always validate or overturn assumptions and the goal is to produce an estimated, prioritized master requirements list.
Barrett favours old technology here, using cards and pens as the modelling tools. "They can be written quickly and ripped up even quicker," he said.
He also favours the production of what he calls "low-fidelity prototypes", which can be very useful in the early identification of whether a project is moving in the right, or wrong, direction. This helps create a process that is collaborative and inclusive, and to that end customers should be part of the community."Go out early and go out often," he said. "Show them the prototype and get them using it. This has to be time-boxed and rapid, with just enough being done, quickly, and with a with a business-value focus."
He also said that this collaborative, workshop approach could invalidate the game of 'Whack The Gopher'. What’s that? It is the business management 'game', where every time someone pops their head up to ask a question (the gopher), they get whacked back down into their hole. 'I remember an IT manager who claimed to have requirements management issues totally under control because the business had learned how long it took to get anything new done,' he recalls. 'In practice, this meant the business had given up on the idea of asking IT for anything new.'
This may be a brilliant management strategy while the company lasts, but it shouldn’t be expected to last too long.®
Sponsored: DevOps and continuous delivery