Don’t PMs get that they’re “business” people yet?

I saw a somewhat depressing article in this month’s PM Network about the need for project managers to get business-savvy.  Not that there’s anything wrong with what Gary Heerkens writes (the article itself is here).  What saddens me is what this article implies about the mindset of project managers:

  1. Too many project managers don’t see “business understanding” as part of their job.
  2. This expectation isn’t explicit enough in PM job descriptions or how PM performance is managed.
  3. PMs seem to want the title, but not the responsibility. 

IMO, a project manager who can’t participate in business discussions can’t meet the substantive requirements of whole swaths of the PMBOK Guide.  How can a project manager participate in charter, scope, and change control discussions without knowing the business?  Otherwise, aren’t they really project coordinators, assistants, etc.?  As Gary notes (and understates):

Basing choices solely upon technical or functional considerations means all of the critical inputs required to make the best possible decision aren’t being considered.  Project managers who do not understand the business aspects of their projects are destined to make subpar decisions from time to time.

The unasked change control question

This change will be cool...it has fire.

This change will be cool...it has fire.

When evaluating change requests, I’ve seen many of the same questions asked:

Do we have the needed budget?
Do we have the right resources?
Have all the business partners signed off on this change?

More sophisticated approaches will also bring focus on the benefits, risks, and added complexities that the change will introduce.  However, I’ve only seen two change control boards ask this question:

What will we NOT do if we accept this change request?

In my experience, raising this topic clarifies much about the change.  First, it validates that the sign-offs referenced above weren’t simply a formality.  For example, I’m reassured when the requester can say that “we looked at these three options…” or “this scope change had a higher benefit than the other two proposals”.

This question also surfaces risks that the change will introduce.  In one case, I saw a very plausible change for a new entry screen proposed.  The costs, resources, and benefits were all in order.  However, the “what won’t you be doing” question produced blank stares.  A few probing questions surfaced what wouldn’t be done: the team has assumed away two weeks of testing effort to make room for the change. 

Request denied.

Management + Leadership = Ordered Liberty

As part of my blog reanimation, I popped over to Bas de Baar’s “Project Shrink” blog for a few ideas. Lo and behold, Bas had a brief post (w/ Crossderry link) and a video clip with his take on the difference between project management and project leadership.

Bas opposes “dependence vs. independence” to capture the difference between management and leadership. There is a great insight in that distinction, because it  brings the concept of entrepreneurship to the project world (where it is sorely lacking, IMO).  Al Gore’s policy entrepreneurship on the environment — notwithstanding the many issues I have with Gore’s substantive case — makes a great leadership contrast to Bas’s Ag Department bureaucrat.

As Bas closed the clip, he mentioned that “we need both [management and leadership]“.  This aside gets to the crux of the matter, IMO.  We need to have some combination of manager/leader.  

Bas’s policy-focused metaphors of bureaucrat vs. entrepreneur also brought to mind the concept of ordered liberty:  “freedom limited by the need for order in society. ”  That phrase neatly captures the paradox of  vision versus/and plan.

Interview on PMOs by Michael Krigsman

Last week Michael and I had a great discussion on PMOs — what they are and how they contribute to IT governance and project success.  In particular, the SAP PMOs have a unique role in optimizing the success of the entire SAP ecosystem…otherwise, relations among the stakeholders can devolve into what Michael calls the IT Devil’s Triangle

The post and podcast (player is at the top of the post), are here.  Thanks to Michael for arranging this and for even taking a good photo of me!

Pareto, Saas, and the “Real World” (Part 1)

All ERP customers lament the size and complexity of their implementations.  My experience has been that they just don’t get what they’re trying to do — create a real-time model of their businesses.  Most IT folks have been used to only automating bits and pieces, without looking at how they optimized the whole.

The seduction of SaaS is that you’ll be able to get “good enough” or “roughly similar” functionality as needed, at dramatically lower cost.  The core processes will work just fine for most everyone.  Per the consultant’s mantra to calm the customer: “We want the 80:20 solution, not the perfect one, right?”  Vinnie Mirchandani has hit this theme again and again (here, here, and here)

I don’t quite buy it.  Someone, somewhere is going to have to interface with the real world.  So many of the implementation cost drivers are that last 20% of customization — RICEF+Workflow objects — which provide the bridge from bits to bricks.

  • Reports for the pointy-haired among us and the authorities
  • Interfaces to other systems — e.g., barcode readers, handhelds, RFID, etc.
  • Conversions for systems that go away
  • Enhancements that add customer-specific logic
  • Forms for Customs, Shippers, IRS, Inland Revenue, Zoll, Douane, etc.
  • Workflow for approvals, alerts, etc.

This 20% that gets talked away during process design time gets talked right back in once the business gets its hands on the solution.

Portfolio Management and Troubled Projects

SAP has had a lot of success using project portfolio management — especially via regular monitoring and controlling of the project inventory — to reduce the number of troubled projects and their impact on margin.  Michael Krigsman’s IT project failures blog has a useful post summarizing some of the main challenges.

Michael’s comment is spot-on…my bad.  Thank God for “edit…” 

His interview w/ CA is tool process-centric, and of course an SAPling won’t downplay the value of PPM tools!  In fact, we’ve found that putting a basic process foundation in place — regardless of tool support — to be very effective.  The very act of systematically monitoring the project portfolio surfaces potential project failures more quickly, reduces the probability of failure, lowers the impact if failure(s) happen, and shortens the duration of the adverse events. 

SAP PMOs that operationalized PPM — even with first-generation tools — have had fewer, shorter, and lower impact escalations than those that don’t.  PMOs that wait for the “perfect” approach always seem to get blindsided.

m = F/a

Finally broke the inertia and got the blog started.  I hope I can keep up the momentum!

My focus is on getting initiatives to produce something useful, so we’re going to chat a lot about strategy execution, knowledge management, and project, program, and portfolio management.  Also, since I lead an enterprise PMO of sorts, I’ll put out a bit of chaff on starting, growing, and succeeding with project management organizations.

Follow

Get every new post delivered to your Inbox.

Join 2,518 other followers

%d bloggers like this: