Feeds

Don’t play whack the gopher

Requirements management exciting - shock

  • alert
  • submit to reddit

The Power of One Brief: Top reasons to choose HP BladeSystem

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

Seven Steps to Software Security

More from The Register

next story
Secure microkernel that uses maths to be 'bug free' goes open source
Hacker-repelling, drone-protecting code will soon be yours to tweak as you see fit
KDE releases ice-cream coloured Plasma 5 just in time for summer
Melty but refreshing - popular rival to Mint's Cinnamon's still a work in progress
NO MORE ALL CAPS and other pleasures of Visual Studio 14
Unpicking a packed preview that breaks down ASP.NET
Cheer up, Nokia fans. It can start making mobes again in 18 months
The real winner of the Nokia sale is *drumroll* ... Nokia
Put down that Oracle database patch: It could cost $23,000 per CPU
On-by-default INMEMORY tech a boon for developers ... as long as they can afford it
Another day, another Firefox: Version 31 is upon us ALREADY
Web devs, Mozilla really wants you to like this one
Google shows off new Chrome OS look
Athena springs full-grown from Chromium project's head
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.
Consolidation: The Foundation for IT Business Transformation
In this whitepaper learn how effective consolidation of IT and business resources can enable multiple, meaningful business benefits.
Application security programs and practises
Follow a few strategies and your organization can gain the full benefits of open source and the cloud without compromising the security of your applications.
How modern custom applications can spur business growth
Learn how to create, deploy and manage custom applications without consuming or expanding the need for scarce, expensive IT resources.
Securing Web Applications Made Simple and Scalable
Learn how automated security testing can provide a simple and scalable way to protect your web applications.