Customer Reviews

Requirements-Led Project Management: Discovering David's Slingshot

5 star:		(0)
4 star:		(3)
3 star:		(3)
2 star:		(0)
1 star:		(0)

 

 

This is a decent book on using software requirements to help center and guide the running software projects. The Robertsons break no new ground here that wasn't probably better explained in their "Mastering the Requirements Process" for the requirements aspects of the book. As a project management book, I think that requirements are important but so are many things in running a project. I have found the Robertsons approach a bit too simplistic and I think that shows on the project management side as well.
The key message here is that if you get the requirements right, the project will fall into place and run much better. Requirements are key to getting good estimates, scheduling, aligning stakeholders, testing, etc. Well this is true, but hard. The Robertsons talk Agile talk but don't do the Agile walk. One of the keys to Agile is that full, complete, or even mostly complete requirements are a myth. Learn a little, build a little. The Robertsons change that to learn a lot, build a little. Not quite the same. I personally agree that we should learn more about the problem space of a software project than what some Agile methods call for. Then again, I don't reference Beck and Folwer as much as the Robertsons do.
What I personally am having difficulty doing is agreeing to the Robertsons advice to "invent" requirements. To me this is a slippery slope not worth going down. I think the requirements analyst's job is to fully understand the business problem space, perhaps better than the stakeholders themselves. I would like to leave it to the designers to invent the solutions. Sometimes that is the same person and that is OK by me. However, I think as an activity list, they should be different categories.
So, if you have read "Mastering the Requirements Process" and you are primarily interested in requirements techniques, there isn't much need to buy this book. If you are into project management and want a different viewpoint from many of the PM books out there, this may work for you.

The title suggests that you will understand how a project can be managed from a requirements perspective. In actual fact the book is a treatise on how to create and manage software requirements during the requirements gathering phase of a project.

The book touches on important aspects of creating and managing software requirements such as writing testable requirements, creating use cases, drawing context diagrams, etc.

Some of the statements within the book are questionable. For instance (I'm paraphrasing), a requirement is not a requirement if you can't afford to build it. I've found that prejudicing requirements sessions with early budget and technical constraints is, at best, counter-productive.

Also, the discussion of the change control over requirements (and it's impact on the design, test plans, construction deliverables) is given short shrift within this text. The suggestion is made that if requirements were well done to begin with, there wouldn't be changes. Surely better requirements provide better requirements stability, but any project would benefit by a fairly robust requirements-led change control process.

The bottom line is this is a good text on software requirements and related practices, but not a classic text. For that you may have to look elsewhere.

The process of aquiring and implementing the requirements for any project can be difficult. To read a book on the subject can be worse. This title succeeds where others fail. It is full of usefull resources and practical examples.

Project management and development is more an exercise is psychology than architecture. The Robertsons are aware of this and build their methods around human interaction.

I'm glad I read it. I learned quite a bit. The other books reccomended throughout this title are a great find and the recipe for the perfect dry martini is in fact quite accurate.

Jean-Charles
www.FlashCodersNY.org

There is some great content in this book, and the writing style is fun and engaging. But at the same time the book often goes here and there with lots of extraneous information, which while interesting, is also distracting.

The book covers conventional project management in a compelling and interesting way, and offers practical experienced based insights. Based on that I would give it five stars. The centering of the management process around requirements is a great idea. And the use of lo-fi prototypes is genius. So there is great content in here. But, unfortunately the distracting content and the sub-par quality of the illustrations leads me to give it a four out of five.

Still, if you are looking for a way to break out of the mold of your current development process. And you are looking for something that could lead to a more compelling product design for your customer. You may find the answer you are looking for in this book.

The authors are from Britain and often make references to British companies in the book. So I was surprised and amused to see a photo of a tablecloth they'd scribbled on with ideas. It was from the Crocodile Cafe in Pasadena, Los Angeles. A restaurant I'd also often been to. Small world?!

The book has one key chapter. On inventing. Everything else is secondary. The authors discuss how you should strive to see what makes your company unique compared to its competitors. What is its core competence? Or your own, for that matter. Does your company offer a quicker response to customer queries? A quicker delivery time? An easier ordering process? They encourage you to think up new advantages. And to do this continually. They suggest that brainstorming once a month or less is not really brainstorming. Ditto for prototyping new gadgets or features. Innovation needs constant intellectual exercising.

This chapter is clearly the most hazy and frustrating of the entire book. So intangible compared to the other chapters, which describe processes that can be straightforwardly implemented. But this chapter is also the most valuable. Your ability to innovate faster than your competitors may ultimately be the only real advantage you have.

By the way, the book refers to eBay and says "Meg Whitman [the CEO] had the very simple inspiration of putting auctions on the Internet". Not so. It was the founder, Pierre Omidyar, who conceived of this. When Whitman came on board, eBay was already conducting these auctions.

I think this is a book for persons wanting a subject overview. It contains a lot of discussions but, in my opinion, too few practical rules.