Value Management – The Missing Area in PMBOK

As you probably know, I’m an agile guy – as a practitioner, enthusiast and project manager. I’m also a certified PMP (Project Management Professional) – or a “real project manager”, as one of my agile friends jokingly remarked. I’ve been an agile enthusiast for far longer than I’ve been a PMP, by the way.

I’m not going into the “is agile compatible with PMBOK” debate now (it mostly is). My interest is in creating maximum value with the software projects I’m involved in, regardless of methodology, framework or whatever you want to call it.

And frankly, “real project management” as defined by PMBOK (Project Management Body of Knowledge) is not impressive with regards to value creation. Let’s take a look.

PMBOK Knowledge Areas

Here’s a list of the PMBOK Knowledge areas, that is, areas in which a project manager should have competence:

Integration Management
Scope Management
Time Management
Cost Management
Quality Management
Human Resource Management
Communications Management
Risk Management
Procurement Management

Put on your Value glasses, and see if there’s anything missing. You’re right!

Value Management

There’s no knowledge area for ensuring that the customer or users gets maximum value, not even that they get something of value – only that they get “something”!

If you have access to an electronic copy of PMBOK, do a search for “value”. The results are pretty depressing.

Frankly, I cannot think of anything more fundamental to a project than that it should deliver value to its stakeholders. It is the very reason for the project’s existence. It should be something the project manager helps happen every day on the project. It should be a knowledge area in itself.

What’s Value Management Anyway?

A Value Management knowledge area should contain everything that is necessary to ensure that the project delivers real value (as opposed to “something”) to its stakeholders. It would probably include something like identify stakeholders, identify their needs (fulfilling those needs represent value), find ways to measure stakeholders needs (i.e. quantify value), identify potential product goals, evaluate product goals vs stakeholder needs, find ways to measure product goals, identify product solutions (or design ideas), evaluate solutions vs product goals, prioritize most valuable solutions, implement, estimate actual value delivered, repeat from “identify product solutions” (or earlier, if necessary).

Basically, I think you could plug in most of Evo, and get a pretty good Value Management knowledge area.

To be fair, you will find many value-related activities and concepts in PMBOK. “Identify stakeholders”, for example, is a process within the Project Communications Management knowledge area. And the Project Statement of Work (input to the “Develop Project Charter” process) references business needs and contains a rough description of the “characteristics of the product” – could be quantified, Evo-style.

So if you really look for it, you will find some value concepts here and there in PMBOK, and some more places where you could plug them in.

However, I don’t think the central issue of “value” should be found “here and there”. It should be blatantly in your face and in the forefront of your mind! It’s more important than Cost Management! It’s more important than Time Management! It’s more important than Scope Management! If we don’t create value, it doesn’t matter if the project is on time and budget – it’s waste nonetheless.

So the PMBOK knowledge areas should be reorganized, with Value Management at a center position.

What about Agile and Value?

I’m an agile enthusiast and practitioner. Is that because agile projects deliver more value? Well, Agile methodologies are generally better at expressing that the purpose of the project is to create value – at least, that’s what we agile enthusiasts are always saying. In practice, agile projects have a tendency to focus on functionality rather than value, means rather than ends, and we are often not even aware that we suffer from a lack of tools to identify and express value.

In short, “Value Management” as a discipline is not – yet – central to agile methodologies either. But I think this issue is growing in the agile community, and I think it will be the next big thing in agile. At least, that’s what I’m working on.

Writing this article, I found this blog post via twitter – also pointing at value driven project management as the next step in the evolution of agile project management. Good one.

I’d really love to hear any thoughts you might have on this issue!

This entry was posted in Agile, value and tagged , , , . Bookmark the permalink.

10 Responses to Value Management – The Missing Area in PMBOK

  1. Edijs says:

    Most agile methodologies emphasize on increased customer value (ROI), but somehow iteration after iteration the focus on ROI gets lots and what we get is more functionality. At certain point continuing developing product leads to law of diminishing returns.

    And that is quite normal, because we do not have any metrics for measuring ROI. We use metrics (e.g. burn-down charts, burn-up charts) to measure the progress of functionality. What about business value?

    I have found that applying Earned Business Value (EBV) Management can be of great help when measuring the potential business value. Pdf: http://danube.com/system/files/CollabNet_WP_Earned_Business_Value_041910.pdf

  2. trond says:

    Edijs, thank you for commenting!

    It’s true that in mainstream agile we don’t have any metrics for ROI. Or rather, metrics for the ‘R’ – return – part is missing (we usually have the ‘I’ down pat). Thank you for pointing to Dan Rawthorne’s paper on EBV. This is basically assigning “value points” to stories. I’d say it’s better than nothing, but there are definitely some issues with it, and we can do much better without spending too much effort up front. Creating measurable product goals is a great start. Then you can measure progress towards those product goals.

    Check out the article “Measurable Business Value” by Ryan Shriver: http://theagileengineer.com/public/Home/Home_files/MeasurableValue.pdf (PDF)

  3. Pingback: New PM Articles for the Week of September 6-12 « The Practicing IT Project Manager

  4. Pingback: Value Management « The Practicing IT Project Manager

  5. Dave Gordon says:

    Trond, I’d like to suggest that “value” isn’t a knowledge area – it’s a product. At the project level, the project team maximizes value as the result of a correct balance of cost, schedule, scope, and quality. There is nothing more useless than “perfect, but too late.” Neither is there much value in a product that is on time and on budget, but hobbled with defects or an incomplete feature set. Nor is there much value in a product that is found to be unmaintainable or otherwise doomed to exceed its planned life cycle cost. Thus, value management includes those analyses and decisions that enable delivery of a product that arrives just in time, which delivers whatever features are actually needed at that time, at the quality level required for the success of the users, and is cost effective both at the time of acquisition and throughout the life cycle. Read the rest on my blog, The Practicing IT Project Manager.

  6. trond says:

    Dave,

    Thank you for mentioning this post on your great blog, and also for taking the time to comment here and write a reply on your blog!

    Whether or not Value Management is a knowledge area, is not something that is given by nature – it’s an act of human construction; it’s something we decide.

    And my strong professional opinion is that “value” is so central to what we should focus on, that we should have it as a knowledge area. Otherwise, we risk delivering less value even while still performing the current knowledge areas flawlessly.

    Case in point: We can do everything in PMBOK perfectly and still deliver something that’s ultimately useless to the customer – because neither the customer nor we discovered that what was specified was a bad solution to a vaguely defined problem.

  7. Bruce Melendy says:

    The PMBOK defines scope management as ‘The work that needs to be accomplished to deliver a product, service, or result with the specified features and functions.’ If value consists in things that are worth having, in this context it consists in the products, services, features and functions that make up project scope. So if the things of which value consists are already covered by one or more existing KAs, what is to be gained by creating a new ‘value management’ KA?

    That said, I entirely agree that the focus needs to be on delivering tangible benefits – value – to the organization. What are the best ways to remind ourselves of that? The PMBOK does say things like this: ‘The scope is then managed by continuously delivering increments of the product and prioritizing requirements to minimize project risks and maximize product business value.’ And this: ‘The implementation of a requirements traceability matrix helps ensure that each requirement adds business value by linking it to the business and project objectives.’

    Not exactly depressing from my perspective, but perhaps both BOKs could do more to emphasize the importance of a) identifying needs and goals that will bring real benefits to the organization, and b) planning and managing a scope and delivery process that stays (flexibly, adaptively ) focused on those goals. I believe the next version of the BABOK is heading in this direction and it would be good to see the PMBOK following suit.

  8. The conclusion is obvious – Dedicated Software Team model is the best value provided that you look at IT sourcing as a long-term strategic function allowing both cost saving, effective budgeting of IT projects and strong skills exchange. For more information and practical tips on the effective setup of a Dedicated Agile team check out this blog post as well as this webinar recording. http://intersog.com/blog/agility-team-management/fixed-price-time-and-material-or-dedicated-agile-team

  9. Value is not delivered through the project, but the program. The program is the cross functional coordinated effort that delivers the value. Case in point: You develop and deliver the software. Ok. but, the software is useless until applied to a specific business problem and probably useless until the users receive training. Those activities of training and applying the software to a business problem, are other projects and activities that make up a program.

  10. Value management is not part of project management, but is a part of program management.

Leave a Reply

Your email address will not be published. Required fields are marked *