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!
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
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)
Pingback: New PM Articles for the Week of September 6-12 « The Practicing IT Project Manager
Pingback: Value Management « The Practicing IT Project Manager
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.
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.
You’re in reality a good webmaster. The website loading velocity is incredible. It seems that you are doing any unique trick. Also, The contents are masterwork. you have done a magnificent activity on this subject!