Feeds

Don’t play whack the gopher

Requirements management exciting - shock

  • alert
  • submit to reddit

5 things you didn’t know about cloud backup

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.®

Boost IT visibility and business value

More from The Register

next story
The Return of BSOD: Does ANYONE trust Microsoft patches?
Sysadmins, you're either fighting fires or seen as incompetents now
Linux turns 23 and Linus Torvalds celebrates as only he can
No, not with swearing, but by controlling the release cycle
China hopes home-grown OS will oust Microsoft
Doesn't much like Apple or Google, either
Sin COS to tan Windows? Chinese operating system to debut in autumn – report
Development alliance working on desktop, mobe software
Apple promises to lift Curse of the Drained iPhone 5 Battery
Have you tried turning it off and...? Never mind, here's a replacement
Eat up Martha! Microsoft slings handwriting recog into OneNote on Android
Freehand input on non-Windows kit for the first time
Linux kernel devs made to finger their dongles before contributing code
Two-factor auth enabled for Kernel.org repositories
This is how I set about making a fortune with my own startup
Would you leave your well-paid job to chase your dream?
prev story

Whitepapers

Implementing global e-invoicing with guaranteed legal certainty
Explaining the role local tax compliance plays in successful supply chain management and e-business and how leading global brands are addressing this.
Endpoint data privacy in the cloud is easier than you think
Innovations in encryption and storage resolve issues of data privacy and key requirements for companies to look for in a solution.
Scale data protection with your virtual environment
To scale at the rate of virtualization growth, data protection solutions need to adopt new capabilities and simplify current features.
Boost IT visibility and business value
How building a great service catalog relieves pressure points and demonstrates the value of IT service management.
High Performance for All
While HPC is not new, it has traditionally been seen as a specialist area – is it now geared up to meet more mainstream requirements?