Projects, Like Sailboats Are Rarely on Course
September 12th, 2003 by HalArticle Series - Variation Is an Enabler
- Variation is an
EnemyEnabler of Project Success - Projects, Like Sailboats Are Rarely on Course
- Projects Are People-Centered
It seems I'm writing about the same topic over and over. I sense there's a new way of saying something about projects, but it is just beyond my reach.
Greg Howell and I were discussing the various types of uncertainty on projects. There's always the uncertainty of the future. While we can take actions that shape our possibilities, the future is by nature uncertain and unknowable. It is this uncertainty we should stop fighting…embrace it.
On the opposite end is the uncertainty of whether an individual who has a task to perform will get the task done to the satisfaction of the customer and at the time expected. This variation we can do something about. Through engaging in serious commitment conversations the performer can reach agreement with the customer or project manager when the task will be completed. Completing as promised allows others to start their work as they plan to start it. In fact, a reliable promissor creates the situation for others to plan and mobilize for action rather than waiting to see what gets finished.
The two scenarios don't describe all the cases of uncertainty, but it is good enough to examine the kinds of actions we can take on projects. I can put those coping actions in the following four categories:
- Reducing the likelihood of variation
- Mitigating the consequences of uncertainty
- Discovering conditions
- Adjusting to the situation
(I think I am missing some categories.)
I'll go into more detail later. For now, consider what I am proposing and please help me with my thinking by offering either your comments to this post or send me email. Here's a metaphor for you to consider:
Sailboats (under sail) are rarely on course. Sailors set their sails to capture the most wind. They 'tack' at an angle to their course. This requires zigging and zagging rather than a dead-on course. I've heard that rockets are also somewhat off-course. The 'guidance system' makes very frequent minor adjustments returning the craft to course.
Related Posts
- Variation is an
EnemyEnabler of Project Success Consider this a starting point in a series of postings. At this moment I'm just rambling. I'll use following postings ... - Avoiding Breakdowns A few faithful readers have offered some rigorous ways for looking at good and bad variation and uncertainty. (Check ou...
- Good and Bad Variation This topic has struck a chord. On top of the comments listed on the previous post I've received a handful of emails dir...
- Projects Are People-Centered Continuing in the series of postings on variation as an enabler let's explore more of what I mean by "projects are peo...
- Habits Die Hard This is a continuation of my series of postings on the theme Variation as an Enabler that started on Sept 12th. It's ob...











September 13th, 2003 at 1:30 am
Your direction here, Hal, sounds a lot like some of the territory I covered a few years ago in a paper, albeit a paper with a strong Critical Chain slant. The theme was that, at its core, Project Management is primarily about Risk/Uncertainty/Variation management, and other pieces of a methodology best serve the effort if they serve the identification, mitigation, acceptance, and response to variation/uncertainty/risk. You’ve probably read it before, but it’s at…
http://www.focusedperformance.com/articles/ccrisk.html
September 13th, 2003 at 1:32 am
By the way, given your seafaring metaphor, did you see the picture of the ocean in my latest blog entry?
September 13th, 2003 at 6:27 am
Just today! Attending a project kick-off – is this another name for a commitment ceremony? – I was astounded by the variation of understanding in the room.
“What is scope?”
“What is a project definition document?”
At one point, when asked if any project objectives have been defined to support the project goal, the Project Sponsor replied in utter frustration, “Objectives? What kind of lingo is that?”
Here we are. A room filled with well-educated multi-disciplined people, each with their own set of skills to contribute to the project, and the sponsor is wondering what the hell an objective is. Is this “variation?”
In the view of the commitment ceremony metaphor, the Project Sponsor, Manager, and Leads were challenging their ‘hired’ Project Administrators for daring to ask about assigned staff’s levels of time commitment in order to resource load [more lingo] the schedule. “These people have other jobs too you know.”
I’m concerned about this variation of understanding: understanding why you can’t have goals without objectives; understanding why the Sponsor, et al, needs to model commitment to goals and objectives, and dedicate resources to the project; and understanding of how to translate all of this through the role of leadership. Now that I have rambled on – what variation where you talking about?
September 13th, 2003 at 1:44 pm
Erudite;
I have also found myself in the position on several occasions working with well-educated MBA types that do not understand the basic concepts of project management. (Not being an MBA myself I wonder what they teach them at B school)
I am not surprised to read that your project stakeholders found it difficult to understand the lingo (i.e. scope, deliverables). Nor would I be surprised that they have never really thought about defining the objectives of a project before starting work.
In kick off meetings I have run across the same scenario several times during my career. I have learned that the best way to deal with this is to walk the group though the processes of developing a project plan using an abbreviated and simple jargon free process.
Sorry for getting off the original thread.
September 13th, 2003 at 5:11 pm
I have only recently found your blog (via Frank Patrick’s blog). I too am trying to make sense of how to deal with uncertainty and variation in projects.
It seems to me (based on my experience of NPD projects) that a major source of variation in task duration is that, nearly always a task is not under the total control of one person or group. For example in order to design a gear, a designer might use an analyst to carry out stress calcs, talk to a supplier about hob parameters, work with an assembly guy to figure out how to mount it, etc. etc. Then once he’s finished he probably has to have it design reviewed, get his drawing checked and so on.
The chances of all these people being available at the exact instant the designer needs them is practically zero. They all have variability in their own tasks and often other priorities.
I’ll also bet that a large proportion of the time, the contribution of most of these other ‘actors’ is not recognised on the project plan.
I’m not sure how we can completely deal with this kind of variability, but Critical Chain Project Management does go some way, by recognising that if this task is on the critical chain, all others must give the designer’s needs their top priority.
However, this implies that non-critical chain tasks of this nature can potentially face huge variability that is often not recognised.
September 14th, 2003 at 6:15 pm
Hal, at the risk of being like (as Lonesome George Goble said) “a pair of brown shoes in a Tuxedo World,” I must say that none of the comments seems to care about what the Customer wants, thinks or believes to be those uncertain issues. Nor did it seem any of those present at the meetings mentioned in the comments had been given the opportunity to hear from the Customer.
I guess I tend to take things to the extreme, but I try to look at Project uncertainty like a heart surgeon preparing for surgery. That helps me to avoid the temptation of focusing on cost or schedule or work scope. Everything has to be based on performance requirements. When a Customer and you sign a deal, it is understood that you are to deliver the product agreed upon. Because - why were you selected by the Customer in the first place (assuming it was for a reason other than low bid) - your knowledge, experience, resources, and reputation? So if one focuses first on schedule or cost or your own frustration, I think the patient will be a little disappointed with the results. The patient does not want the surgical team to be concerned about these items during surgery. The Hospital may, but definitely not the patient. The patient wants you to pay attention to the details like proper equipment, patient preparation, vital signs, color, staff attitude, etc.
As you, Hal, and Greg have so aptly stated. All projects start with a group of strangers. I would guess that each major surgery has some new staff (strangers) in attendance. So, how does the Surgeon communicate the work scope? How does the Surgeon schedule the surgery so that each of those assigned has no schedule conflict? Is there uncertainty in major surgery? I think there may be some.
We all know the project execution plans developed at the proposal stage invariably have to be modified during execution. That’s why Glenn Ballard is right about staged scheduling and the “Last Planner.” THAT IS WHY UNCERTAINTY SHOULD BE EMBRACED. Because it forces us to use our knowledge and resources to create value. That’s what makes Project Management so exciting.
So as you and Greg also say, the Project Manager has to make strangers into friends and friends into a Team. Once you have a Team, you can make commitments to each other and the Customer. But of course that requires trust. And once you have trust, you have eliminated 85% of the uncertainty.
gary
September 20th, 2003 at 4:57 pm
I am late on this one Hal, but I just want to say that anonymous Gary is so right about many project management commenters forgetting about the big player on the project team, the client. All the stuff he says is so right to my mind.
I hope he won’t stay anonymous for I would like to start a campaign to get him/her elected as the president-for-life of PMI.
Claude