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…

PM Quote of the Day — Abraham Lincoln

Give me six hours to chop down a tree and I will spend the first four sharpening the axe.

This quote is useful to counter colleagues who disparage planning in general. It is, however, important to remember that initiating and planning activities aren’t for simply “easing into the project” (in the unfortunate phrase of a PM I once worked for). They’re meant to get the project’s execution machine fueled, oiled, and sharpened… and cutting the right tree.

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!

PM Quote of the Day — Vince Lombardi

Practice does not make perfect. Only perfect practice makes perfect.

When I was younger, I never got the point of practice.  Sure, I knew that it would get me in shape and knock of the rust off.  However, I never got the idea that practice would help me perform better under pressure.  Too many times I found myself over-thinking a situation because I hadn’t practiced enough to make it automatic.  I finally started to realize that realistic practice in all sorts of endeavors — in particular, public speaking and presenting — helped to take the edge off along with the rust.

Practice?...  Youre talkin about practice?

Practice?... We're talkin' about practice?

Lombardi’s point also applies to how we test our processes and systems.  Too often I’ve seen customers and consultants assume away difficulties in their desire to save testing time and money.  Even worse, this saving “spasm” usually comes towards the end of the project, just as the testing was about to get serious.

The best testing practice (so to speak) I’ve seen came at a global firm that does dirty and dangerous work.  As you might imagine, that company is very conscious of safety and quality.  That firm called their last round of testing not integration or user acceptance, but “business simulation.”  Business simulation didn’t simply involve folks following a script.  We brought the system, interfaces, and data up like go-live, then encouraged the users to go “do their jobs” and call support if something went wrong.

Sure, such an approach is expensive.  But how much is that peace of mind that comes with a no-holds-barred validation that the system and its support conformed to requirements worth?

Troubled Projects and Engaging Change Stakeholders

Glen at Herding Cats (here) points to a Center of Business Practices study (here) on the causes of troubled projects.  I’ve posted on some of our own findings about project success (here and here), but I haven’t elaborated on what we’ve found about the composition of change control boards.  Below is an extract from a comment I made on Glen’s post:

Our project debrief analyses have consistently found that the right level of executive presence on change control boards is essential to ensure change is managed, not simply documented. In fact, the lack of such a presence (or regular absences) marks the project as a potential escalation.

When a senior manager vets the prioritization of changes by focusing the project team on the project’s goals and intended outcomes — one should usually find scope, time, and resource changes easier to manage (with fewer, more salient change orders). It also keeps the business invested in the project. Many IT shops resist this measure, but it works wonders once they “get it”. 

The Project Management Witch Doctors

Glen at Herding Cats hits back hard (here) at one of the breed of “Project Management Impresarios”.  Not a bad label, though I like the term Witch Doctors myself (the Micklethwait and Wooldridge book is here, some second thoughts on the book’s ideas here).  Some of this stuff can be pretty wacky and verges on Gnosticism.

The arrant wankery Glen describes was quite popular during the heyday of big-bang ERP projects.  Not a surprise, because witch doctors usually pop up in big budget projects.  During those late 90’s projects, folks had the cash to pursue myriad pet theories.  I’ve also seen it in a number of other project types — KM and portal efforts seem particularly susceptible to “soft stuff” disease. 

It is amazing how quickly we can forget the basics in the quest to become more sophisticated and cunning.  Sure the “soft stuff” is important.  In fact, I believe that mastery of such “soft stuff” can be critical to leadership success.  But it isn’t the alpha and the omega that some make it out to be.  In projects, OCM tools and techniques are only means to an end — a successful project.

Value of PM in Business Transformation

I forget to whom I should give the hat tip on this topic, but Here’s a study by Logica that highlights what makes change “Winners” successful (study here, may require registration).  As you can see, project management was a differentiator in business transformation, which of course I think is great.

My take is that being good at PM is necessary, but not sufficient, to be good at change.  That’s because being better at PM should mean that one is better at delivering initiatives of any type.  In other words, PM excellence should make change-heavy initiatives more successful — but that’s because PM helps when delivering all initiatives.

Remembered the source… hat tip to Michael Krigsman at IT Project Failures.

Follow

Get every new post delivered to your Inbox.

Join 3,075 other followers

%d bloggers like this: