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

Making sure that your deliverables’ benefits are realized

With all my recent scope management posts lately, here’s a timely post on benefits realization (here) at John Gough’s iJourneys blog (here).  I like the theme of his post, that “…benefit realisation does not start when the project ends.”   I also second his point that IT sees itself as apart from the “business” and often has a leadership void at the top.  John puts it plainly:

Get Out of the Comfort Zone — There is a view…that the IT project manager delivers the project (i.e. the delivery of outcomes) but the business is responsible for building capability and realising benefits.  CIOs complain that they are too often sidelined by the business, but they do not always have the balls to … declare that: “we have taken the project this far, now give us responsibility for the business change”.

I’m not very comfortable, however, with his suggestion to:

Ditch the Business Case — The Business Case is designed to justify the project, but too often towards the end of the project, the dusty document is retrieved to “see what the benefits were”. The benefits are the project, and should guide the process from beginning to end, whereas the Business Case is just a means to an end.

My experience is that ditching the business case is what happens too often.  It should inform deliverable definition, the expected outcomes of those deliverables, the relative priority of proposed scope changes, and the benefits expected from the outcomes.  Instead, projects deliver “whatever,” the outcomes and benefits aren’t what were expected, and IT wonders why IT is “sidelined” by the business. 

Hat tip: Elizabeth at Girl’s Guide to Project Management (here)

Follow

Get every new post delivered to your Inbox.

Join 2,905 other followers

%d bloggers like this: