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!

Follow

Get every new post delivered to your Inbox.

Join 9,115 other followers

%d bloggers like this: