Benefits Realization: Demonstrating Initiatives’ Value

Debbie Crawford just taught a refreshed version of our Benefits Realization class. The topic is one that bedevils PMOs, largely because it takes a while to figure out that it’s not a closing phase task. In other words, it has to be planned, executed, monitored, controlled, and delivered…just like any other initiative deliverable. Below is an overview of the class:

Benefits are not just another dimension of portfolio management, but are the basic rationale for any investment of funds.  As such, benefits should drive those investment or change decisions from initiation through implementation and beyond. It is the methodology needed by any organization intent on effectively demonstrating that desired benefits are achieved in practice.

This course, built on a wealth of real world experience and lessons learned, will engage the participants in achieving:

  1. Increased organizational ability to forecast benefits which are complete, realizable, and represent real value for the money. In other words, we are investing in the right things and getting them done.
  2. Realize forecasted benefits in practice by ensuring the required enabling, business, and behavioral change takes place; ensuring that the performance of the benefit matches the business case promise.
  3. Realize benefits as early as possible and sustain that realization for as long as possible.
  4. Capture and leverage emergent or unplanned benefits (and minimize any dis-benefits) to optimize the benefits realized and the value for money is achieved.
  5. The organization’s ability to demonstrate the above – not just as part of the framework of accountability but also so that we learn what works as a basis for continuous improvement.

Why Project Management Expertise Isn’t Enough: Lessons Learned from Security Breaches

How many times have I heard that “a good project manager can manage any project?” Too often for my taste. My biggest issue with the claim is that it begs the question: he statement assumes we all agree that any project manager with a mastery of the profession’s tools and techniques can succeed anywhere.

We’ve finally learned better, and PMI has acknowledged this in its new requirements for PMP continuing education. As PMI itself puts it:

As the global business environment and project management profession evolves, the [certification] program must adapt to provide development of new employer-desired skills…. The ideal skill set — the PMI Talent Triangle — is a combination of technical, leadership, and strategic and business management expertise. (PMI 2015 Continuing Certification Requirements (CCR) Program Updates)

Our pending research on project skill gaps (stay tuned for a webinar invite) shows that executives and senior managers understand this much better than project practitioners. They emphasize strategy, business, and leadership improvements, while practitioners don’t.

Perhaps an example from the current headlines will help. As most of you know, security breaches have wreaked havoc on a number of prominent firms: Target, Home Depot, Sony are simply the most well-known. The sad thing is that the most famous failures could have been prevented.

One of my new favorite podcasts is from Andreessen Horowitz, the venture capital firm. My most recent listen was an interview with Orion Hindawi of Tanium. I recommend listening to the whole thing — it’s less than 30 minutes — as Orion provides some great color to what, where, why, etc. on security attacks and vulnerabilities. The summary hits his sobering message on the head:

The paradox of security is we pretty much know what we are supposed to do most of the time — but we don’t do it. If you examine all the recent high-profile attacks, somebody in the organization knew something was wrong before it happened. They just didn’t have the ability to escalate the problem, or the ability to raise a flag that people took seriously.

In other words, we don’t lack the technical understanding of security risks, or the tools and techniques to mitigate them. We lack the leadership and business savvy to confront the challenge of communicating the risks, then deploying and using our toolkit effectively. The last two sentences show how these skills gaps drive the root causes:

  • Ability to escalate the problem” is a leadership challenge. This suggests that “somebody” wasn’t connected, articulate, or brave enough to get to decision makers.
  • Ability to raise a flag that people took seriously” is a symptom of weak strategy and business skills. If the threat isn’t framed, articulated, and understood in terms serious leaders get, then such warnings are ignored…or even worse, viewed as counterproductive scare mongering.

A gloomy picture of how business perceives CIOs

I followed and commented on this Forrester article re: CIO/business perception, which Dan Muse (@dmuse) of CIO.com posted on LinkedIn.

Half the problem is that we don’t consistently come to the table with technology solutions for business problems/opportunities before being asked. In other words, we react and don’t anticipate what other functions will need. Either that, or we do it in fits and starts, especially if our proferred solution is shot down or unwelcome. Too often we withdraw into our shells — sometimes in a snit — then wonder why we aren’t at the table.

Give and take about initiatives is every other function’s lot in life. We have to persist in proposing new directions over time to have that seat at the table — and solicit, then listen to, the feedback about rejected proposals — so that our next great idea gets the hearing it deserves.

Value Management and PMOs

I’ve been working on an initiative called “Value Delivery,” which will incorporate value management into our various PMO methods, tools, etc.  These activities are often listed as typical PMO functions, but this really only honored in the breach.  Value management never seems to take off given a PMO’s traditional emphasis on implementing project management methods, tools, training, etc.

In our approach, we will ensure that value management has its own identity, especially when it comes to training.  While value and benefit management is baked into the various program and portfolio standards around, it isn’t part of the typical project manager’s skill set.  Rolling out value management separately should emphasize the organizational and personal changes required to be successful.

What is value management’s objective? To ensure that execution remains focused on delivering against executives’s and stakeholder expectations. How does value management happen? Maybe the best way to illustrate is to briefly lay out the lifecycle we’re using below:

  1. Value Discovery: Establish a performance baseline
  2. Value Realization: Identify required process improvements and KPIs
  3. Value Optimization: Review and steer benefit attainment

Bridging the PM/Management Gap

I like the title of Sanjay Saini’s post on the lack of communication between project managers and senior management — “Make the Effort.” One can quibble with his specific suggestions, but his exhortation to communication more regularly, frequently,and transparently is right on:

Reviewing progress and profitability should not be something that waits until year’s end. Instead there should be some monthly or quarterly checkpoints in between. This regular communication should also include client feedback–both good and bad.

PM Standards are not Holy Writ

Andrew Meyer at Inquiries into Alignment provides a useful corrective to the faith that we project management types put in our industry standards and frameworks (post here).   He hits on a lot of topics that are only alluded to in our project management “bibles”:

[P]rojects often pull people from different departments together to work on a project. While that is what the project requires to be successful, what does that mean for the people pulled from the different departments? Is the project of primary importance to them or is what’s happening in their department of primary importance?

Now, I believe Andrew that has set up a bit of a straw man here.  I’m not sure that it is the responsibility of the PMBOK Guide or PRINCE2 to elaborate some of these topics fully (I’ll leave Agile aside for the moment).  At least in the case of the PMBOK Guide, it is only a guide to the project management body of knowledge.  While a guide should reference the need to ensure business alignment, only so much content “meat” can be expected from such a guide.

My take is that firms should not count on generic standards to cover some of these topics —  one’s firm-specific methodology should elaborate the questions Andrew suggests (and more):

What is the business environment your company is working in?
How is that environment changing?
What is happening inside the business?
What is the state of the project?
Where does it need to go?
What needs to happen to get it there?  

IT/Business Marriage Counseling

I agree with most of Susan Cramm‘s pieces, but she goes on a bit of a rant on the role of line managers in making IT’s life impossible (here).  While there is at least a grain of truth in her complaints, the IT “can’t do” attitude that infuriates line executives pervades the piece.

IT managers are tired of being treated like high priced waiters serving technology de jour on a moment’s notice.

Perhaps IT managers should stop acting like waiters and order takers for the business. It would be nice if IT wouldn’t “need to study” a request to deploy only somewhat new technology — e.g., Enterprise 2.0 — then come back and say “yes, but”.  Perhaps IT could anticipate what the business needed, for once?

Luke’s business “partners”… in their single-minded pursuit of customers, products and profit [emphasis mine],… simply forgot about IT.

If only IT knew what it’s like to have a single-minded pursuit of those pesky customers, products, and profit.  Not like that’s where their paychecks come from…

Alignment is meant to ensure that the right IT products and services are available to meet business needs with minimal angst for all involved [emphasis mine].

This definition/goal sounds good, but articulates a common IT mistake about defining alignment — avoiding conflict (“yes, but”).  Continue reading

Follow

Get every new post delivered to your Inbox.

Join 12,277 other followers

%d bloggers like this: