I’ve been trying to read Requirements Led Projects by Suzzanne and James Robinson for a few months and I think I’m about to give up. I’m about 150 pages into a 300 page book but I’ve been stalled for a while now and my attempts to re-start have not got far. This is a shame because I do like the book, and I don’t want to give it a bad review but if I can’t make it to the end then it has something lacking.
I bought this book because for the last year or so I’ve been very concerned about requirements on development efforts. OK, I’ve been concerned about this for a while but my level of concern has increased in the last year. So, I decided I should look into this subject some more.
Perhaps I read the wrong book. Write at the start to authors suggest their book Mastering the Requirements Process is the one to read if you want to know about writing requirements.
I briefly met Suzanne at SPA a few years ago and was impressed with her knowledge. I have no doubt that the two authors know there stuff and many people will find this book useful. But...
Firstly I haven’t been getting any real insights from this book. Its a problem I’ve found a lot recently, when you’ve been involved with as many development efforts as I have, and when you’ve read widely, it can be hard to find something really new and insightful.
Second, I think the authors have a bit of a mixed up view on who writes requirements. This is partly due to the book subject (projects and requirements) and partly due to the industry. To name the elephant:
Project Managers should not be writing or inventing project requirements.
Project Managers manage projects, they should be concerned with the when and who-else questions on the project. Those attracted to Project Management don’t (usually) have the analytical, inquisitive nature, or the training that makes a good requirements writer. The person who creates the requirements should be a Business Analyst or Product Manager. Project Managers need to be focused on near term deliverables. Requirements creation requires a long term (and possibly strategic) view.
However you wouldn’t know this from many job ads which confuse the roles of deciding what needs delivering with actually delivering it. I guess this book is written for project managers who find themselves in this situation.
On a small project the two roles could be merged provided you can find the right person. And there are a few people can do both roles. But these cases are the exceptions.
This book does set out to discuss requirements led projects so one might expect it to blur the Project Manager / Business Analyst divide but the authors blur the divide without acknowledging it. Sometimes they talk of the project manager gathering requirements and sometimes the BA.
It seems to me the authors are much more familiar with the Business Analyst as requirements writer and not Product Managers. As someone who champions Product Management I found their chapter on “Inventing requirements” to be quite naive. Product Managers are not mentioned and their is no sign that the authors know their techniques. The idea that nobody asked for a mobile phone so it was invented is very simplistic suggestion.
So, if your fairly new to requirements writing this could be the book for you. Unfortunately its not the book for me.
I’m reading some more about Business Analysts at the moment, and I’ve been sent some good links on product management so I’ll return to this subject soon.
I bought this book because for the last year or so I’ve been very concerned about requirements on development efforts. OK, I’ve been concerned about this for a while but my level of concern has increased in the last year. So, I decided I should look into this subject some more.
Perhaps I read the wrong book. Write at the start to authors suggest their book Mastering the Requirements Process is the one to read if you want to know about writing requirements.
I briefly met Suzanne at SPA a few years ago and was impressed with her knowledge. I have no doubt that the two authors know there stuff and many people will find this book useful. But...
Firstly I haven’t been getting any real insights from this book. Its a problem I’ve found a lot recently, when you’ve been involved with as many development efforts as I have, and when you’ve read widely, it can be hard to find something really new and insightful.
Second, I think the authors have a bit of a mixed up view on who writes requirements. This is partly due to the book subject (projects and requirements) and partly due to the industry. To name the elephant:
Project Managers should not be writing or inventing project requirements.
Project Managers manage projects, they should be concerned with the when and who-else questions on the project. Those attracted to Project Management don’t (usually) have the analytical, inquisitive nature, or the training that makes a good requirements writer. The person who creates the requirements should be a Business Analyst or Product Manager. Project Managers need to be focused on near term deliverables. Requirements creation requires a long term (and possibly strategic) view.
However you wouldn’t know this from many job ads which confuse the roles of deciding what needs delivering with actually delivering it. I guess this book is written for project managers who find themselves in this situation.
On a small project the two roles could be merged provided you can find the right person. And there are a few people can do both roles. But these cases are the exceptions.
This book does set out to discuss requirements led projects so one might expect it to blur the Project Manager / Business Analyst divide but the authors blur the divide without acknowledging it. Sometimes they talk of the project manager gathering requirements and sometimes the BA.
It seems to me the authors are much more familiar with the Business Analyst as requirements writer and not Product Managers. As someone who champions Product Management I found their chapter on “Inventing requirements” to be quite naive. Product Managers are not mentioned and their is no sign that the authors know their techniques. The idea that nobody asked for a mobile phone so it was invented is very simplistic suggestion.
So, if your fairly new to requirements writing this could be the book for you. Unfortunately its not the book for me.
I’m reading some more about Business Analysts at the moment, and I’ve been sent some good links on product management so I’ll return to this subject soon.
No comments:
Post a Comment
Note: only a member of this blog may post a comment.