Feeds

Don’t play whack the gopher

Requirements management exciting - shock

  • alert
  • submit to reddit

Secure remote control for conventional and virtual desktops

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

Remote control for virtualized desktops

More from The Register

next story
Download alert: Nearly ALL top 100 Android, iOS paid apps hacked
Attack of the Clones? Yeah, but much, much scarier – report
NSA SOURCE CODE LEAK: Information slurp tools to appear online
Now you can run your own intelligence agency
Microsoft: Your Linux Docker containers are now OURS to command
New tool lets admins wrangle Linux apps from Windows
Microsoft adds video offering to Office 365. Oh NOES, you'll need Adobe Flash
Lovely presentations... but not on your Flash-hating mobe
You stupid BRICK! PCs running Avast AV can't handle Windows fixes
Fix issued, fingers pointed, forums in flames
HTML5 vs native: Harry Coder and the mudblood mobile app princes
Developers just want their ideas to generate money
prev story

Whitepapers

Go beyond APM with real-time IT operations analytics
How IT operations teams can harness the wealth of wire data already flowing through their environment for real-time operational intelligence.
5 critical considerations for enterprise cloud backup
Key considerations when evaluating cloud backup solutions to ensure adequate protection security and availability of enterprise data.
Getting started with customer-focused identity management
Learn why identity is a fundamental requirement to digital growth, and how without it there is no way to identify and engage customers in a meaningful way.
Reg Reader Research: SaaS based Email and Office Productivity Tools
Read this Reg reader report which provides advice and guidance for SMBs towards the use of SaaS based email and Office productivity tools.
Simplify SSL certificate management across the enterprise
Simple steps to take control of SSL across the enterprise, and recommendations for a management platform for full visibility and single-point of control for these Certificates.