SAP PMO Webcast Recording

As a follow up, over 250 people attended last week’s SAP PMO webcast (original post here) hosted by Keith Johnson, the VP for the SAP North America PMO VP and Jim Curry, Program Delivery Director.  It’s always great to have a customer — in this case, Kelly Gear, Senior Program Manager, Johns Manville — confirm the value of some of what SAP offers and suggests.

Considering what we’ve been discussing here and here about goals, deliverables, and activities, this topic from the webcast caught my eye:

How to establish the critical link between the steering committee’s goals and the project team’s activities.

The recording is available here — you will need to do a free registration if you don’t have a SAP.com login already.

More on estimation principles

I saw this comment by Dennis Stevens (Dennis’s blog is here) on Glen Alleman’s post on software estimation practices (here).  His comment hit on two points that stood out.

Effective estimating requires a strong understanding of variance in estimating and how to account for/govern this variance.

Ditto and amen… my experience in implementing logistics optimization (I worked for formerly-independent component of Descartes) helped me get comfortable with the fuzziness of estimation (e.g., variance).  Two b-school courses were also helpful: mathematical modeling for marketing and applied multivariate analysis (I keep the latter’s textbook by my desk). This background may not make me an expert, but I have a decent estimation BS detector.

Politically driven estimates are just irresponsible management. I remember a conversation with an executive where I told him “This is a 46 week effort. If you need to say 32 to get funding, then you can say 32 and deliver 14 weeks late – or we can say 46. It’s up to you.” We presented at 46 weeks, got the funding, and delivered on time. If an organization can’t afford to do a project, it shouldn’t be done based on false estimates – this is malfeasance.

As Dennis suggests in this case, pretending that the earlier delivery target does not compromise the product or mean inevitable delays is foolish, even unethical.  My experience is that this self-sabotaging approach happens because the project can’t or won’t demonstrate the impact of such decisions on the initiative’s business case.

To that point about the business case, I’ll use a future post to lay out how we used a simple illustration of our business case to justify an internal program’s proposed release schedule.

Surviving PMO Success — The Process Maturity Trap

One of the unexpected challenges in our PMO journey has been that success can make an enterprise-level PMO appear less relevant.  A PMO must transform its approach to stakeholders or it won’t take full advantage of the improvements it fostered.  One manifestation of the problem unfolds thusly:

  1. An enterprise PMO composed of PM thought leaders executes a PM improvement program that delivers methodology, training, tools, and change management initiatives to its stakeholders (e.g., regional, local, unit PMOs).
  2. Those stakeholders [largely] adopt those initiatives and transform their project operations in significant and measurable ways.
  3. This transformation creates a new set of PM thought leaders, who often surpass the knowledge and hands-on experience of the original enterprise PMO.

The business problem has reversed; the enterprise PMO now becomes the organization that needs to change to reflect the new reality.  Deliverables that were relevant in moving from low maturity processes no longer work with a more sophisticated audience.  This issue is compounded by the difficulty in recognizing the changed environment.  Who wants to admit that he/she is no longer automatically at the vanguard of knowledge? 

In other words, the challenge for a successful enterprise PMO is: “Who will change the change agents?”

Methodology Scaling/Selection Outline

Or maybe I should say “Methodology Scaling/Selection Graphic”… Glen Alleman’s recent post on PM and Agile (here) reminded me to post this picture (click to enlarge) of a slide we use when discussing which methodologies to use for which project.  Note that we do not directly oppose “Agile” vs. “Waterfall” in our continuum.  Sure, SAPScrum is pretty pure agile, but that doesn’t mean that ASAP doesn’t contain agile concepts (e.g., emphasis on iteration short cycles during the Realization phase). 

methodologyscaling

Also, we’re emphasizing that initiative leaders must be comfortable combining philosophies when implementing solutions, which is why we’re driving program management knowledge out to our general PM community (as implied in the bottom box).

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.

PMI CEO’s perspective on the stimulus package

I forgot to link to this Greg Balestrero post (here) on the US stimulus package (then still in debate).  He asks a lot of great questions about whether Congress and the Obama administration have thought through how to make this portfolio most effective.

I’ll focus my comments on Greg’s first two PM-oriented suggestions for the plan (#3 is to accelerate the spending):

First, get the people who know how to manage complex change initiatives — these are not career politicians but are experienced project professionals — who can manage change portfolios… that can get results.

Agreed, but one of the challenges with current legislative practice is that large swaths of the portfolio are fixed by the legislation itself, at least at the Federal level. Some of the more interesting work is happening at the state level. In a recent radio interview, the RI Director of Transportation sounded like he had his portfolio ready to go. In fact, he was ready to pounce on funds that other states would forfeit because their transportation portfolio process wasn’t as smooth.

Second, emphasize the competency of project management, like they have begun to do in many of the governments around the world. But they should not allow “pockets” of excellence to prevail. On the contrary, the governments should leverage the pockets of excellence to develop an enterprise discipline in project execution.

While enterprise-wide initiatives are great, I always wonder how deep they really can go. My experience is that in any organization of substantial complexity, it is hard to cover any but the most generic PM needs at the enterprise level. The differences in line of business, agency, etc. drive variation that’s hard to reconcile effectively.

Glen Alleman’s Mission to the Agilests

Dont I look like I should be the patron of desperate situations?

Don't I look like I should be the patron of desperate situations?

I don’t know why I think of Glen’s efforts to reconcile agilests and PMs in religious terms. Maybe it’s because many in both camps see topics as either/or — either you’re with us or against us. Or maybe I worry that it’s a hopeless cause (which is why St. Jude graces this post).

There’s not much I can add to Glen’s latest: If I’m Doing Project Management Right am I Agile?  To me, this question is not either/or, it’s both. The worst misconceptions are around planning (especially the schedule), per Glen’s comments on the Agile Manifesto tenet”Responding to change over following the plan”:

The notion that plans (schedules actually) are developed and then fixed is nonsense on any practical project. There are no doubt projects where this is the case. But it’s still nonsense. Anyone suggesting this is good project management practice is either selling you a bridge or seriously misinformed about how projects are managed.

Plans – the strategy for the successful completion of the project, and the schedule – the sequence of work needed to fulfill the strategy are subject to change for every imaginable reason.

Follow

Get every new post delivered to your Inbox.

Join 3,075 other followers

%d bloggers like this: