MSP v VDM (1)

by jed simms on August 17, 2010

Both the OGC’s “Managing Successful Programmes” (MSP) approach and Value Delivery Management™ (VDM) are focused on ‘benefits’ but the two approaches have different definitions of what a benefit is and different ways of ensuring they are delivered. Not surprising, we find VDM’s much easier, clearer and practical.

1 THE BLUEPRINT — and the need for more specificity

MSP revolves around the Blueprint. The Blueprint is a model of the business, its working practices and processes, the information it requires and the technology that will be needed to deliver the capabilities described in the program’s ‘Vision’ statement. It defines what is wanted, but not how the organization will operate or be in the future. It is used to maintain the focus on delivery of the new capabilities.
The Blueprint is an Enterprise Business Architecture view/specification of the program and is developed by the Business Change Managers in conjunction with business analysts (not the Program Manager).

MSP is not proscriptive as to what the Blueprint needs to contain or in terms of detail, but is generally defined in terms of ‘POTI’

P policies, processes, procedures
O organization, people, structures, role, responsibilities, work practices, stakeholder relationship, culture
T tools, techniques and technologies
I management information and KPIs

The Blueprint appears to be a somewhat componentized definition of what the solution is to be. It would state, for example,

  • this is the future structure
  • this is the future information required
  • this is the future role of the XYZ position
  • this is the number of staff we want in the call center, etc.

The Blueprint defines the current and future states with the delta being the (quantifiable) benefits.

The Blueprint can be defined progressively in more and more detail as the project progresses and needs to allow its achievement to be verified.

A typical Blueprint statement example is – 
“Objective staff assessment and tailored personal development plans, supported by easy to access local training facilities.”
While this statement can be assessed as met or not, a wide variety of solutions could be equally assessed as meeting the same statement. In VDM terms it is not specific enough. VDM would define a desired business outcome like…

“Each staff member is assessed at least annually against a set of pre-agreed performance criteria and is supported by a tailored personal development plan. Training courses are available locally to meet common and organization-specific development needs so as to make it easy for staff to meet their development and performance goals.”

The range of solutions that will meet this ‘desired business outcome’ definition is now much narrower and each element has some level of qualification on its delivery. This level of outcome specificity also makes it easier to define the changes required to achieve the outcome, as it is far clearer and the options narrower.

In VDM terms, the Blueprint is somewhere between an Outcomes roadmap and a requirements definition and lacks the specificity of the Outcome definitions and roadmap and the detail of the requirements definition — leaving a lot of room for ambiguity, misunderstandings and varying results.

VDM brings a much higher level of specificity, trackability and measurability to program delivery that project and program managers find clarifies what they are delivering and makes easier how they communicate what their project is all about.

2 comments

Independent program managers are often told what approach they will use.
Fortunately the disciplines in describing benefit statements in VDM can equally be applied to MSP.

by Kevin Hanvey on August 18, 2010 at 2:28 pm. #

Jed, I read your article on MSP vs VDM with interest and although I am not familiar with your VDM method I would like to clarify that a blueprint could contain the level of detail you have outlined in both statements, there is also a benefits management strategy, plan and benefit profiles which describe in more detail benefits and measurements. The difference between output, outcome and benefits is clearly defined and supported by an outcome relationship model. I hope this assists your understanding of the MSP methodology. I am happy to provide further information to support the MSP if you require. Kind regards, James Bawtree (Registered Consultant in MSP, PPM, PRINCE2 & P3M3)

by James Bawtree on August 18, 2010 at 3:09 pm. #

Leave your comment

Required.

Required. Not published.

If you have one.

By submitting a comment here you grant this site a perpetual license to reproduce your words and name/web site in attribution.