Own your project’s story (HT @MelanieDuzyj and @mkrigsman)

We all should know how critical project communication is to project success.   A compelling story can build strong sponsorship and sustain stakeholder commitment, even in the most challenging of circumstances (also see Michael Krigsman’s project success checklist) .  However, many project managers assume that their audiences — or even worse, key influencers and “re-communicators” — understand the story as well as they do.

The group blog at BlissPR has a useful post by Julie Johnson on “Getting the Details Right“.  I’ve often suggested that project managers leverage what their PR professionals more.  IMO, the ability to influence is an essential behavior for an initiative leader.  Why not listen and learn from people who know?

In this case, the lessons for driving accurate press coverage apply well to any project that needs to own and drive its story.  Simply substitute “project” for “company” or “industry”, and “stakeholders” for “media”. 

  • It’s more important than ever for a company to take control of its reputation – after all, you either control your reputation or someone else will
  • Educating media about a company or an industry can be even more important than garnering coverage
  • The story you tell must be simple – especially when the truth is complicated

Why can’t we plan for leadership?

Glen Alleman asks “Why is it so hard?” and focuses on one of the most difficult line items for IT projects to fund: project/program management, including contract planning and controls. 

I’ve had varying success in positioning these resources, so I’m still stumped.  Arguments that worked for one initiative failed for what should have been a similar initiative. 

So here are two questions to you all:

  1. What arguments, research, findings, etc. have been EFFECTIVE in ensuring that your projects or programs have the leadership they need? 
  2. Does these “effective” factors work better for one type of project over another?  In other words, do some types of projects lend themselves to “selling” project management better than others?

What is “ready to use”?

Sorry, Derek, it's prêt-à-l'emploi not prêt-à-porter.

I’ve found that the packaged application and custom development fields make at least some nod to standard project management practices.  No doubt there are many suboptimal practitioners, but few ignore or openly bad mouth project management.

Infrastructure — servers, network, and desktop — appears to still be another matter.  I’ve been shocked by how much expediting and Potemkin planning — plans that are only for show — I’ve seen in the last six months.  One of the most frustrating practices is when IT Operations claims victory over useless milestones after having claimed that planning would have done nothing but slow them down.

Perhaps slowing down would prevent rework and wasted effort (by one’s customers!).  For example, our service provider’s infrastructure team tried to get credit for server delivery.  Except that the server was only powered on and connected to a network — it was far from “fit for use.”  No one could access the network remotely — is it based in a data center after all — and even if they could potential users were then stymied by no log-on being set ups.  Never mind that we couldn’t use the server anyway because it hadn’t been qualified (we’re in a FDA validated industry).

If you don’t own “fitness for use” as the underpinning of your deliverables, you aren’t managing your projects, you’re playing “whack-a-mole“.

Which PM “faux pas” make your hair stand on end?

In my last post about the “school solution,” I noted that there’s something unnerving about project and program managers who skip over the basics.  As Glen Alleman noted in his comment, the PM school solution or black letter law almost always has some merit as a start.

Thinking about this post brought to mind the various project management myths, missteps, and mistakes that put me on edge.  These three always make me wonder about the person who says them:

  • Calling a project schedule a project plan.
  • Not knowing the difference between an issue and a risk.
  • Suggesting that planning is useless if we don’t know all of the activities.

What are your pet peeves?  Which PM faux pas makes you nervous, irritable, and discontented with those who make them?

I smell a poll here!

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.

%d bloggers like this: