Podcast on barriers to successful IT/CRM

Michael Krigsman over at IT Project Failures hosted the first in what he hopes will be a regular series of “Town Hall” podcasts (here)  It was originally supposed to be a meet-up, but the weather was dodgy at best so the session went virtual. 

Anyway, Paul Greenberg moderated an excellent discussion that covered a lot of ground.  As Michael notes, Paul’s CRM background focused the conversation

…on issues drawn from customer relationship management. CRM brings together core business functions — how a company interacts with customers — with technology intended to streamline and improve those relationships. Since these goals are business-oriented, CRM offers excellent examples of non-technical failures connected with technology implementation projects. For example, one participant noted corporate managers sometimes deploy CRM hoping to control end-users, who in turn reject the system in a predictable failure. 

Be warned… I jump in at about the 30 minutes mark!

“Change gap” from 2008 Global CEO Survey

This result from the 2008 IBM Global CEO survey (intro here) illustrates the suddenly yawning gap between what executives see as their needs/expectations for change and their firms’ demonstrated ability to do so.

change_gap_ibm2008globalceosurvey

Two thoughts came to mind once I saw these numbers:

Sorry, but in this case... two out of three is bad

Sorry... two out of three IS bad

  1. The success rate for “change” could suggests a perceived success rate for initiatives (e.g, projects and program).  While ~60 percent is better than other numbers published re: project success rates, it is sad that even this optimistic figure wouldn’t merit a “D” in school.
  2. How quickly we’ve gone from complacency to urgency.  IMO, much organizational wankery that was tolerated — and even rewarded — a few years ago isn’t likely to survive.   At least not in its current form…

More on saying “no” to customers, stakeholders, etc.

Pawel Brodzinski had a good comment (here) on my post about saying “no” the right way (here), which links to his post laying out his full perspective on the customer is always right principle.  I replied to his comment — agreeing with the principle, but cautioning on its application — which I’ve posted below:

Sometimes it is about saying no — or as the Japanese say “Yes, but.” There are times when we don’t take business, especially when we are being “forced” to do so. But if we aren’t taking their money, is that customer really a customer? IMO, no, at least not for that topic.

Of course, I agree that the customer is always right — which makes it critical to be choosy about one’s customers. But the application of that principle is tricky. PMs who allow scope creep to happen on their projects often justify it with a customer service rationale — “the users asked us to build it.” But are the users really the customer of the project? Aren’t the executives who chartered the project and the company they represent the customer? Too many IT staff and PMs are very confused about who is the “real” customer.

Continue reading

Saying “No” the right way

A colleague of mine, Schalk Klee, has a couple of posts of interest (Schalk’s blog is here).  I had forgotten to link to his original post on saying “No” as a PM (here), so his follow up post on when and how to say “No” (here) was an appreciated reminder.  Schalk highlights the balance that must be struck:

We all know that good scope management and customer focus are both critical success factors for value adding projects and in a professional service environment there is always the sales focus as well.  How do I balance this?

This is where I believe the art of making a deal comes into play.  This is a skill that a “good” project manager has to develop.  How do I give my client what they want without putting myself into a worse position?  Creative thinking, negotiation tactics and customer focus all need to be combined. 

Deal-making and negotiation skills are not emphasized enough in most PM career paths; frankly, I could stand brushing up on them myself!

PM Quote of the Day — Roald Amundsen

Adventure is just bad planning.”

I’ve found that the amount of adventure in a project is inversely proportional to the amount of proper planning that went into — and continued throughout — that project.  Glen hits that point (here) when he uses the 5 P’s — a long-ago Scoutmaster (a USMC sergeant) introduced them more saltily as the 6 P’s — to frame a discussion of emergence in project requirements. 

In his own way, Sergeant Martinez made emergence very clear to we tenderfeet many years ago.  When we whined about having to learn how to prevent and fix blisters, to pack correctly, to read a map, etc., he asked those very same “If -> What” questions Glen mentioned:

  • If you get blisters, what will you do (without knowing how to prevent and fix)?
  • If if rains, what will you do (without a poncho)?
  • If you get off the trail, what do you need to to get back on it (without a map and knowing how to reach it)?

When we protested that we weren’t Marines he noted — after advising us that under no circumstances would the Corps want us anyway — that it was more important for inexperienced hikers to plan so that we didn’t get into trouble.  As he went on to note, on our hikes we were looking to have fun, learn a bit of woodscraft (actually “desert craft”), and otherwise enjoy our encounter with nature.  Fending for our health and lives wasn’t one of our hikes’ requirements…

Projects can die a good death

Hello.  My name is Inigo Montoya.  You killed my project.  Prepare to die.

Hello. My name is Inigo Montoya. You killed my project. Prepare to die.

Nice to see that projects are being ended more often than I would have thought.  Michael Krigsman (here) points to a survey (here) where just under 45 percent of the surveyed organizations claimed to have ended a IT project before it was fully implemented.

Roughly half of these projects were stopped for business-related reasons: changed priorities or business needs or because they didn’t align with business strategy.  Another 40 percent were ended because of what sound like project execution issues: they didn’t deliver as promised or were over budget.

A big miss IMO, is that the survey results don’t note the phase in which these projects were ended or how much of the budgeted cost was spent.  That would have given more insight into how effective the portfolio review processes really were.

Based on my experience, projects stopped for business reasons experience a quick and efficient death.  Any rudimentary portfolio process — even if informal — usually catches these issues earlier and dispatches them in such a way that all know that it was the right thing to do.  Sadly, poorly executed projects often become undead zombies or vampires — hiding and spending in the dark — until someone finally puts a stake in their hearts (FYI, zombie execution techniques here).

Ugh…this sounds like a toxic culture

I  liked the tone of this post by Johanna Rothman (here).   Of course, she doesn’t include some facts that might help w/ conclusions — e.g., I don’t know what the progress of the program was/is — but here’s my two cents.

The replacement program manager has been telling people to do this task and that one, not providing context, and has been holed up in his office creating the ultimate Gantt chart.

I’ve seen this syndrome enough to worry.  I never like to see program managers holed up for very long, though apparently he does come out every once in a while…

He yells, but I have no idea why he’s upset. 

I’m not a “yeller” — I’m 6′ 4″ (192cm) and 240 lb (110 kg) and am scary enough when I’m calm. But on the rare occasion I yell. It isn’t a button I like to push very often, and not just because it is impolite and uncivil.  It ultimately is ineffective when used much at all.

If you measure or assess people on how they perform certain tasks, such as yelling at program staff, or how well people work on a task in isolation, you will get what you measure. But it won’t be what you want. 

I have worked in a culture like this; the boss was expected to be brusque and even belligerent. Oh, and he/she should be directing every minute part of projects and operations.  Not my “cuppa” and I wasn’t there long…

Monitoring and Controlling — what the PMBOK Guide says and shows

My last PM Quote (here) reminded me of this PMBOK Guide issue.  There’s an awkwardly phrased topic sentence in Chapter Three that gives some the impression that the PMBOK Guide intends to segregate monitoring and controlling activities in the executing process group:

The Monitoring and Controlling Process Group consists of those processes performed to observe project execution… to control the execution of the project. — Page 59, PMBOK Guide 3rd Edition

The focus on execution is unfortunate, because a lot of folks seem to stop there when skimming the Guide.  Throughout the Guide — and even on this same page — we find better indications of the team’s intent, IMO:

The integrative nature of project management requires the Monitoring and Controlling Process Group interaction with every aspect of the other Process Groups. — Page 40, PMBOK Guide 3rd Edition

[A]ll of the Process Group processes would normally be repeated for each phase or subproject. — Page 41, PMBOK Guide 3rd Edition

The Monitoring and Controlling Process Group not only monitoring and controls the work being done within a Process Group, but also monitors and controls the entire project effort. — Page 59, PMBOK Guide 3rd Edition

The botched topic sentence notwithstanding, the PMBOK Guide doesn’t give us an out.  Monitoring and controlling activities are needed throughout the project.  There’s even a purdy picture…

processgroups_pmbok

PM Quote of the Day — Pauline Kael

[T]he critic is the only independent source of information. The rest is advertising.

This quote came to mind as we’ve been going through an internal program’s requirements.  One of my colleagues regularly refers to, and insists on, using the “Four Eyes” principle.  In other words, one should always involve a second set of eyes to verify and validate work product.  If the project team is the only arbiter of progress

Too often, the four eyes principle often only gets honored in quality control — e.g., during post-build testing processes.  As my colleague’s insistence suggests, we find that an independent opinion is most valuable early in an initiative.  For example, wouldn’t it be useful to have an independent validation during planning that the requirements and deliverables really represent (and will make real) the capabilites the project or program is intended to put in place? 

It is tough enough to re-work a deliverable that doesn’t conform to requirements.  It is worse to have to re-build a deliverable that had conformed to requirements, but find that those requirements were never valid in the first place.

Changing from a “work” to “deliverable” mindset

Glen Alleman has been a roll at Herding Cats, provoking some excellent back-and-forth in recent posts and comment threads.  His post (here) on Deliverables Based Planning (which is a service mark of his firm, I believe) prompted some knowing nods on my part.  As Glen notes in a comment:

You cannot believe…or maybe you can…how uncomfortable this makes people. They want to plan tasks! They want to track tasks! They want to be in control! (Deliverables are just a detail to be de-scoped when necessary).

We have passed through this vale of tears ourselves.  Since I’m on vacation and feeling particularly lazy, I’ll simply cut-and-paste from my own comment (with a few edits for clarity):

[T[he mindset change from simply planning “work” and “effort” to focusing on well-defined deliverables has been tough.  However, once we got through driving that change, we found few problems making most SAP project deliverables “tangible or verifiable.”

This approach is especially effective when looking at the solution itself — most ERP-type deliverables should reflect enabling the execution of customer business processes (and the outcomes and benefits that ensue). This definition has proven quite tangible (the execution of enabled processes themselves) and verifiable (tests of the increasingly complex models of the processes, e.g., unit, string, integrated, business simulation tests).  Decently contructed tests should confirm whether or not the realized solution conforms to requirements. Furthermore, one can track the outcomes from these deliverables and trace the benefits — realized vs. expected. 

%d bloggers like this: