webinar_ad_ptimes_wid00133
AddThis Social Bookmark Button
hansHans Jonasson, PMP, CBAP, founder of JTC Unlimited, has over 25 years of experience in the areas of project management, business analysis and professional development training. Hans started his career with Volvo LTD in Gothenburg, Sweden, in 1980 as a systems analyst/programmer. In 1984 he moved to United States to work on new development projects for EDS and General Motors. He has managed all aspects of software development projects varying from $100,000 to $10 Million for the automotive industry. He has been a Project Management Professional (PMP®) and member of the Project Management Institute (PMI®) since 1996. He is a member of the Great Lakes Chapter of PMI® and the International Institute of Business Analysis (IIBATM), and a Certified Business Analysis Professional (CBAPTM). He has authored his first book titled Determining Project Requirements which was published in October 2007.

PMI is Taking Over the World...!

How's that for a heading? Exaggerated? Cheap shot? Maybe, but probably also with a bit of truth. Opening the PMBOK 4th edition I saw that PMI has added "Collecting Requirements" to the core processes and this immediately made me very uncomfortable. I have been in the PM business for 20 plus years and in the requirements business even longer, and I have always talked about the importance of separating the ownership of the product definition from the ownership of the project execution. The ownership of the product definition lies with the customer, or the buyer. They are the ones that must define what they want, the capabilities and functions that they are looking for in a product. The project manager represents the seller, or the developer, and as such their interest is often in direct conflict with the buyer.

Now, this does not mean that the project manager does not need to be involved with driving the project and the requirements gathering and even, in many cases when you are working on internal projects, be the person actually documenting requirements. But it is noteworthy that when the project manager acts in this capacity, they do it representing the customer organization They should be aware that they are wearing two hats and may have to develop a split personality. So while in real life this often happens, it is preferable to split the job of requirements gathering between the business analyst (or whatever you call that function in your business) for all product related requirements, and the project manager for all project related requirements. These requirements should be documented in two different documents with different ownership. The product requirements goes into the BRD (Business Requirements Document) and the project requirements belongs in the project plan.

It is also clear that the process of collecting requirements in the PMBOK 4th edition could use some enhancements. The inputs are the charter and the stakeholder register. While this may be defendable by making assumptions about what goes into the charter, I think it is noteworthy that, without a solid understanding of the existing business architecture, goals and objectives, strengths and weaknesses and much more, the collection of requirements may focus too much on the project and not enough on the business. And after all, a project that does not help the business achieve its goals is not a very good project.

So... after all the complaining, can say nothing positive? It is clearly good to focus attention on requirements. Many projects fail because of poorly defined, continually changing, and misunderstood requirements. It is great that PMI recognizes and highlights this. And there is no doubt that the project manager must be a major player in this area. Just remember that the project manager is not necessarily the best person to capture and analyze what the customer wants. After all the expertise a good project manager brings to the table is how to implement those requirements.

Good luck and challenge everything!

Hits: 1127
Comments (2)Add Comment
Elizabeth Larson
...
written by elarson, May 06, 2009
Hi, Hans,
It's me here, a lead contributor to the section that is causing you so much consternation in the PMBOK® Guide - Fourth Edition Enjoyed your blog!! Much to think about. And I agree--it's best to keep the role of the BA and PM separate.
I admit to having felt confusion by the new Collect Requirements section at first, too. A couple of things have helped me:
1. Project managers need to make sure requirements are collected, which doesn't mean they have to do all the work themselves.
2. PMI is concerned with project work, so the pre-project work that the BA does is outside the realm of the PMBOK. Therefore, the charter, as described in the PMBOK® Guide, seems a reasonable input to me.
George Jucan
...
written by gjucan, May 07, 2009
PMBOK is a set of standards defined as those things that most project managers do, in most projects, most of the time. And the reality is that project managers MANAGE requirements gathering – do not PERFORM it though! So PMBOK 4th Edition is simply acknowledging the reality – and nowhere in that process description there is anything that would indicate that the PM should replace the BA. Plus, the PM under scrutiny might very well be a “business” PM, in charge of coordinating one or more BAs and SMEs to gather requirements.
I personally think that the new edition is a huge step toward bringing the PMBOK very close to reality, thus dismissing the “PMBOK planet” critique sometime addressed to previous editions.

George Jucan

Write comment
You must be logged in to post a comment. Please register if you do not have an account yet.
Click Here to login or create a free account.

busy