PM Quote of the Day — Francis Bacon

A prudent question is one-half of wisdom.

“Fools rush in” should be the motto for anyone leading a global, matrixed, or virtual team.  While many projects and firms are going to English as a common language, many colleagues simply won’t have the background to know how to express nuances or translate cognates.  Sometimes the results are funny — in Singapore, I had a French counterpart spend ten minutes grilling me about the meaning and derivation of middlebrow

Too often, however, the results are time consuming at best and disastrous at worst.  Having a sense for when a colleague is struggling to express an idea is essential for cross-cultural communication.  One of the benefits of learning a foreign language as a youth is a sensitivity to translation problems, especially when trying to express complex ideas.  Here are three approaches that have worked for me:

  1. Now, when my counterparts say something that sounds “off” or awkward, I ask a clarifying question about the phrase or word — often they’re trying to translate an idiom from their native tongue. 
  2. If a clarifying question doesn’t work, then I try to re-state their position myself and highlight where I am unclear about their intent. 
  3. Finally, sometimes the misunderstanding is driven by a literal translation.  I’ll ask straight out — How do you say “fill in English word in question”? — in their native language.

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”. 

New Strategy & Projects Blog

I’m a regular presenter at the Strategy & Projects conferences, so it was good to see that the folks behind this have joined the blogosphere.  The PM Solutions Strategy & Projects blog is here.

They’re picking up on a couple of themes we’re into at SAP.  Jeannette Cabanis-Brewin notes the increased use of social media in the project environment (here), which we already use in large parts of SAP and are expanding into new areas this year.  

We also use Scrum to shorten the cycle time of our strategy management processes, so it was interesting to see that Karen White has started blogging on agility (post here).   In particular, she has been looking at using agile principles outside of the software development environment.  Karen has a new book out on the topic (press release here).

The “that’s not my role” delusion

I very much liked this post by J Schwan (here) about the dangers of over-specialization.  Some of the comments miss the point — J acknowledges the value of domain knowledge — which is that a role-bound workforce conspires against:

  1. Understanding how to optimize the whole vs one’s part.
  2. Remembering why one is doing a project in the first place.
  3. Accountability for results.

As J notes, it is easy to hide behind a “work to role” facade.  But that’s all it is, a facade and a thin, deluded one at that.  To be blunt, strictly bounded roles end up becoming jobs that get outsourced or automated.  I can’t imagine wanting to working in such an environment anyway.  

J paints a picture of a healthier technology workplace:

Sure we all have roles we prefer to play. I love technology architecture work, and if I’m working on a project that’s going to require more than a handful of people, I’ll bring in one of our PM gurus, because frankly, I’m not that great of a project manager. But I do know the difference between a Gant Chart and a Sprint Queue, and when it makes more sense to use one versus the other to manage a project. And I like the fact that our PMs understand the difference between a web server and an application server, and that our BA gurus have no qualms about doing QA work or rolling up there sleeves to fix some simple bugs if that’s what the project needs. 

Hat tips to Eric Brown (here) and Bas (here).

PM Profession Survey Answers — Fully Yes & No/Never

I’m starting the long-promised review of the answers to my survey: Is Project Management a Profession Yet?  I’ll ignore the “undecided” answers (8 percent) and start with the two extremes.

First the “nays”: five percent answered No — and it never will.  I’m not sure how one can be so confident that PM will never have any sort of professional status.  Project management already exhibits early markers of an emerging profession — certifications required for some jobs, graduate programs at respectable universities, professional associations — so “no and never” is a hard position to sustain.

That said, the “yeas” have a far tougher chore, IMO.  Yet 16 percent answered Yes, fully — like law, medicine, or academia.  Wow… now those are some rose-colored glasses.  If you think PM is a full-fledged profession, I suggest that you ask yourself these questions:

  • Does PM have a legal or regulatory framework underpinning it? 
  • Has anyone been arrested for practicing PM without a license?
  • Do you have to go to a accredited “PM School” to even be allowed to take a PM “Bar” Exam? 
  • Is there a “theory of projects” akin to the theoretical constructs that underpin even “soft” disciplines like history and economics?

More on the other answers in the next days.

Squaring up the PMBOK Guide and Agile

Glen Alleman shoots down some of the common misconceptions about the relationship between the PMBOK Guide and agile principles (here).  As regular readers know, I’m sympathetic to agile approaches, I’ve found them very powerful in the right project context, and I push to incorporate agile principles further into our own content. 

Of course, if I commented on Glen’s post itself, I’d be writing “ditto” or “I agree” a lot, so I’m just going to add on a bit:

  • While many agile advocates over-read the PMBOK Guide, the guide did imply a waterfall approach, especially in earlier editions (Chapter 2).  I can understand the confusion or over-reading.
  • The pending 4th edition does have a more sophisticated treatment of project life cycles and explicitly addresses iterative relationships among project phases.  It is hardly sufficient, but it is heading the right direction.
  • PMI itself is quite eager to engage agile advocates for future editions (or extensions) of the PMBOK Guide.  Several Global Corporate Council members were approached about how and whom to engage in the agile (or agile-savvy) community.
  • My take is that creating an Agile extension to the PMBOK Guide would be the best initial approach.  If nothing else, integrating agile-oriented PMs into the standard-setting process should be easier in an extension project.

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.

PM Quote of the Day — Gaius Julius Caesar Augustus Germanicus

Let them hate us so long as they fear us

Project managers often have to exercise influence without authority.  We can’t always get what you want from people over whom you have no authority.  We end up doing a lot of horse trading — offering what you have that the other person desires in exchange for what you need from them to be successful.  Such bargaining can be time-consuming and frustrating, but we accept it as part of the project world.

However, when project managers get formal authority, some become tempted to exercise it constantly.  Former master negotiators become “take it or leave it” leaders.  They don’t care what others think, so long as they obey.

That’s where the quote comes in.  It sounds powerful and commanding… until you realize who was credited with saying it.  For Gaius Julius Caesar Augustus Germanicus is better known as Caligula.  Not exactly a role model for leadership (or longevity), eh?

%d bloggers like this: