Project Management as “table stakes”

Regular readers know that I’ve been harping on the increasing importance of program management, especially when it comes to realizing the benefits or value of projects.  Project managers who simply run projects without reference to the larger business environment are becoming a commodity. 

During the recent Global Corporate Council forum, I heard two thoughts that illustrated the challenge for PMs:

  • Greg Balestrero, the CEO of the Project Management Institute (Greg’s blog is here), calls project management “table stakes”.  In other words, PM has become so widespread that it is no longer differentiating for an organization or person to be good at PM.  In Greg’s opinion, PM-only lets/keeps you in the game…no more.
  • One council member quanitified the value of the PMP in terms of experience.  He had to counsel a project manager who was very itchy to advance but was perplexed that his PMP hadn’t taken him further.  The council member put it to him bluntly: “A PMP is worth about two years of experience in our organization, which is something…  But it isn’t equivalent to leading and delivering a multi-year project or program.”

Why get involved w/ industry associations?

One of the reasons I’ve been remiss in my posting is that I’ve been preparing to host the Spring 2009 executive forum of PMI’s Global Corporate Council.  My SAP colleagues did a great job helping me host and this forum was particularly productive.

“Networking” is a pat response when one talks about joining or leading industry groups.  What exactly that means came home to me after discussions with my counterparts from Siemens, Joe Sopko and Kevin McDevitt.  On two topics, just a few minutes of conversation helped me confirm the validity of one approach (on how to augment on program management content) and introduced a better metaphor (for the architecture of our new methodology).

Nothing big, eh?  But how much benchmarking and justification will I avoid because I can say “well, Siemens had a similar problem and they did X“?

Closing up the PM “professional” survey

I’m trying to tie up some loose ends, especially follow-ups promised in earlier blog posts (here).  In particular, here are the top two answers from the “Is Project Management a Profession Yet?” survey (survey here):

  • 38 percent: Yes, but second-tier — like engineering or non-university teaching (33 of 86 answers)
  • 26 percent: No, not yet — could reach at least second-tier profession (22 of 86 answers)

I’m with the “No, not yet” crowd.  I can see project management achieving some of professional attributes, but I see few in place now.   For example, certifications are all well and good — and the PMP is becoming more universal — but they are a long way from licensure.  Take a look at the some of the requirements, benefits, and documentation for the Professional Engineer license (here).

BI, Deliverables, and Change Control

This post may court the Business Week curse, but I’m highlighting this story on BI and the recession (here) as the jumping off point for a couple of observations.  Rob T.’s comment in the piece (sorry, but I can’t link directly) notes that:

Unlike ERP, BI can be implemented step-wise, first in targeted, strategic areas, and then using a broad brush once it’s value has been proven. A wise strategy for this economy is to start small, pick a problem or area where a quick win is possible and attack it with a 60-90 day effort.

I mentioned this opportunity for short, focused projects in my WSJ interview.  These short cycle times and the nature of BI work pose problems for traditional ERP change control and deliverables definition. 

For example. what exactly is “done” on a BI project?  The traditional ERP definition of deliverables — focused on processes that deliver tangible, measureable outcomes (e.g., Order to Cash, Purchase to Pay, Hire to Retire) — doesn’t work well for BI.  Typically, reporting projects focused on # of reports, explicitly defined.  Also, in analytics projects those reports or queries often spark more ideas for how data can be cross-tabbed, projected, etc.  Do you always want to be presenting a change orders for new reports?

What has worked for you when defining deliverables and change control for BI initiatives?  Now if you’ve read this blog for a while, then you can guess that I’m in tune attacking these issues with a capabilities-focused approach to deliverables.  This approach points one in the right direction when defining what done looks like.  However, many PMs find it hard to grok the requirements and required capabilities of analytics-savvy stakeholders and consultants.

WSJ Interview on “The Experience Trap”

FYI, a Wall Street Journal article (“Dangers of Clinging to Solutions of the Past”) based in part on interviews w/ yours truly came out today (link here, page B4 in the paper).  Thanks to Kishore Sengupta of INSEAD for pointing the WSJ my way and to Phred Dvorak of the WSJ for conveying the perils of experience so well and so succinctly. 

As I’ve noted to a couple of colleagues, it is hard to believe that only 250 words of copy came out of two hours of interview time.  Insert your own joke re: my verbosity here…

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.

Deliverables, work packages, and the schedule

This temptation to fix a schedule and get to work is constant in enterprise IT.  It is particularly alluring for any application tied to a SOX-compliant landscape — some governance models only allow two opportunities/year to deliver — where project durations strongly suggest themselves and time is always “a-wasting”.

Of course, as Glen Alleman reminds us here, starting with the schedule  is wrong.  I won’t recapitulate his post here, but I’ll borrow from his comment to another post which points out the fallacy in this kind of thinking:

[M]any…process improvement projects have failed, along with Enterprise IT, because the WHY of the effort is not established or well understood. The principles establish WHY we should be doing something. The practices of course tell us HOW.

This rush to “get working” short-circuits on of the most important functions of a WBS: stakeholder management.  Properly defined deliverables and work packages aren’t simply inputs to the schedule, budget, etc.  If nothing else, a WBS  is the most accessible framework for a discussion with one’s stakeholders that ensures that the what of the project supports the why of the project.  Wouldn’t it be a good idea to make sure that why and what are elaborated and priorities agreed upon — even at just a couple of levels — before getting down to who, when, where, and how?

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).

%d bloggers like this: