Book Review: Requirements-Led Project Management
Discovering David's Slingshot


Suzanne and James Robertson
Addison-Wesley 2004

ISBN 0321180623 (boards)

Buy it from Amazon.com
Buy it from Amazon.co.uk

Other Reviews

 

 

This elegant and informative book is the follow-up to the Robertsons' Mastering the Requirements Process (1999) (MRP). It isn't very often that a reviewer finds he can't put a technical book down, but it happened this time. Every page is full of wisdom gained by experience: and more than that, it comes from "observing our clients, participating in project teams, and listening to the wiser people in our industry." This book is the product of seriously good consultancy over "more than a quarter century"; and that is supported by beautifully clear writing, not to mention James Robertson's fresh and witty illustrations.

'Never go to a meeting without a prototype'

Pundits and textbook authors have been arguing for well over a decade that projects absolutely must straighten out their requirements, or they're bound to go wrong. So why haven't project managers listened? Two obvious reasons spring to mind:

  1. we're preaching to the choir, not to the sinners outside: i.e. managers don't read requirements books;
  2. our sermons haven't spelt out to managers and decision-makers what they'll get back if they do their requirements better.

The Robertsons address managers directly in their own language. What is the Return on Investment (RoI) of requirements? Chapter 2 talks all about it. What should managers do, given that time and resources are short? Each chapter ends with practical sections

That doesn't sound like High Priest-speak, with the swish of flowing robes barely audible through the jargon. It's the sound of helpful companions who know that the job of running a project is stressful.

Chapter 3 looks at Project Sociology. I had better confess that I get a mention for having worked with Suzanne on the Onion Model of project stakeholders. But the chapter does far more than explain the layers of the onion and the roles involved; the discussion ranges effortlessly over the team structure needed for decision-making, like the Botswanan Kgotla, and Belbin's wonderfully practical analysis of team roles. The point is that nobody can do everything, but a team can. Teams are built, says Belbin, of people such as creative and imaginative 'plants'; confident 'coordinators'; cooperative 'teamworkers'; conscientious 'completers'; single-minded 'specialists', and others. You need to choose people who are not only eligible for a job, but suitable, having the right personality attributes. And the chapter shows how to put all this knowledge to good use.

Chapter 4 turns to the core of requirements work: discovering what people need. This touches on the processes described in their MRP book, but with a different slant: what do you need to ensure happens on your project. "Requirements are free if you pay for them" is one of the paradoxical pieces of advice and wisdom.

Chapter 5 has the provocative title 'Inventing Requirements'. Of course it's something you're not supposed to do; Colin Potts wrote a famous paper on 'Invented Requirements and Imagined Customers'. But the authors argue convincingly that analysts should invent; engineering is after all about shaping the world we live in. Nobody, they argue, asked for the printing press, or spreadsheets, or the Web, or PDFs or MP3s, but these things have found markets for themselves. As usual, the arguments are lively, and made with well-chosen anecdotes and illustrations (in words, photographs, and drawings).

Chapter 6 is called Requirements Simulations, but it's about something much wider than simulation modelling: the use of prototypes, scenarios, hi-tech and ultra-low-tech ways of giving people an idea of what you might build -- always with a view to catching more and better requirements. Prototypes can be drawings on a whiteboard; playfulness is encouraged. Talking like this takes courage, and doing it successfully demands experience.

Chapter 7 manages yet another oxymoron: Requirements for Existing Systems. Most projects are upgrades of existing systems, and most requirements are for enhancements. Yet, most textbooks have blithely assumed simple 'green-field' developments, unconstrained by awkward facts like existing interfaces, legacy code, and user expectations. So it's really nice to see a detailed and clear process for handling change projects.

Chapter 8 looks at requirement metrics -- a vital tool for management. Whether you believe in Function Points or not, you can hardly avoid having to estimate the effort and cost of your projects, and there's usually nowhere else to start from than the requirements.

Chapter 9 looks at managing the requirements themselves; and the people who deal with them. This is certainly a much broader look than is usually hidden in the acronym 'RM': but it's probably far more realistic. What's the least that can be got away with? A list of requirements deliverables, suggest the authors -- all the classes of knowledge involved.

Chapter 10 is about 'meta-management', such as of the interfaces between projects. This higher-level stuff is crucial, but rarely mentioned; it's the bigger, systems engineering picture that seems to be left out of management school courses.

Finally, Chapter 11 focuses on 'Your Requirements Process': again, covering some of the ground of MRP, but from a different perspective: not doing the tasks, but choosing which set of tasks, which process to use.

This is a book with a grand scope but a practical purpose. It is well-conceived and beautifully produced. Let us hope that managers read it and adopt some of its many suggestions: they should.

© Ian Alexander 2004