eXtreme Project Management™
Getting It Right the Last Time

A Flexible Project Model - Part I

By Doug DeCarlo

"We are facilitators of disorder."
- Margaret Wheatley, Leadership and the New Science

Take a moment and take the extreme test: Which of the following describes the project you are currently managing? Check all that apply, if you have time.

[ ] High speed
[ ] High uncertainty
[ ] High change

Checked all three? One of the hallmarks of extreme projects is that they are surrounded by uncertainty, a sugarcoated way of saying "Surprise du jour." By surprises, I mean both external and internal factors over which we have little and no control. External factors include changes in technology, customer needs, competition, supplier delivery commitments and federal regulations among others. Internal factors include team turnover, multitasking, changing priorities, etc. On extreme projects, about the only constant is unpredictable change. Pin this one on your wall for future reference:

In the extreme project environment, about the only thing you have control over is how you respond to the fact that you have no control.

It should come as no surprise, then, that extreme projects are not merely complicated; they are complex. For example, a complicated project would be asking you to change the tire on a car while the car is still in motion. A complex project would be the same, except under conditions where the driver has been drinking heavily. We can't even pinpoint the destination.

A Working Definition
"An extreme project is a complex, self-correcting venture in search of a desired result." (That's my definition at least for now, until I have to change it.)

In my definition, the term "Desired Result" is key. In his landmark book, Adaptive Software Development, James A. Highsmith III gives us a graphic that I have modified slightly.

In Classical Project Management (CPM), we're taught to identify the destination (Planned Result) up front, then build a path to get there. We then put in place control measures to minimize the variation between the plan and what's actually happening. Since deviations from the plan tend to be frowned upon, we take corrective measures in order to preserve the Planned (promised) Result including schedule, resource and scope commitments. Yet, how often have we found that when we achieve the Planned Result, the customer says, "That's what I asked for but that's not what I want."

Jazz vs. Classical Music
Extreme projects are messy. They are not linear or serial and do not follow the typical waterfall model. Applying the waterfall model is a pitfall. Unlike the Classical Project Management (CPM) model and the Software Engineering Institute's Capabilities Maturity Model, the goal of eXtreme Project Management™ is not efficiency. It is effectiveness: producing the Desired Result. Because so much is unpredictable, success comes from improvisation and spontaneity. It's jazz, not classical music.

This means that we need a different mindset. That is, we have to change our mental default settings from a Newtonian mindset to its opposite: A Quantum mindset. To summarize, the Newtonian view assumes that things are predicable and that we can pre-determine a path that will get us to our destination, the Planned Result. The Quantum mindset says we'll pick a destination and figure it out as we go along. It boils down to Aim then fire versus Fire and re-direct the bullet.

For a more complete review of the critical distinctions between the Newtonian and Quantum mindsets, see my article "Is There a Madness to Your Method?".

The Quantum mindset is the essential, overarching context for managing the extreme project.

Once the Quantum mindset is in place, I see 4 Critical Success Factors (CSFs).

  • A Flexible Project Model
  • Leadership by Commitment
  • Real-time Communication
  • Self-Mastery

The goal of this approach is to:

  • Improve the likelihood of achieving the Desired Result
  • Speed things up
  • Energize people

A Flexible Model: The Elements
"If you can't show why your process is better than random, don't use it."
Gerald M. Weinberg, Quality Software Management, Volume 4.

The five elements of the Model are:

  • Initiate
  • Speculate
  • Innovate
  • Reevaluate
  • Celebrate

In this article, I'll highlight the first two elements: Initiate and Speculate.

Once the project is initiated, the four elements that follow work together as an iterative cycle that repeats until the Desired Result is achieved.

"A small mistake in the beginning leads to a big mistake in the end."
Thomas Aquinas, Summa Theologica

Any project, extreme or traditional, can be thought of as going through three stages: beginning, muddle and end. Initiate is the beginning of the beginning. I've often heard it referred to as the fuzzy front end of the project because that's the time when people are learning about the endeavor for the first time and are groping to get a basic understanding of what is expected and why it's needed in the first place. The two fundamental components of Initiation are:

  • The What, and
  • The So What

The What
During this stage, the initiator (customer, sponsor or staff member) articulates the goal of the project: the problem to be solved, the new capability to be put in place, the thing to be produced, etc. Since extreme projects are often blazing new trails and live in unpredictable environments, Initiation is a tense time. The project's goal is typically vague. More like a mirage or even an hallucination, as I heard one project manager put it. Because things are vague, the project team wants to nail down the requirements and come up with a solution, even before having a complete understanding of the Desired Result.

Often, the customer doesn't really know what the intended result is, even when they can articulate it in great detail. And, if they can, that doesn't assure that the project team has the same interpretation as the customer. Even if everyone is on the same page, the environment is so fluid that what is understood to be the deliverable could change, or be obsoleted in no time; e.g., by a competitor's swift move.

The big danger during project Initiation is rushing to a solution or specification in order to gain a sense of (false) security. Being too specific too early - even if the customer gives you a tight specification - is a big danger.

Take this example of a Sponsor who's very specific. Our Sponsor says to Noah: "A gigantic flash flood is coming. Your mission is to build an ark to hold your family and the chosen animals."

A better mission statement might be: "Your mission is to provide safe passage for your family and for the chosen animals during the flood."

That leaves options open if later on Noah discovers that the most effective vehicle would not be an ark, but a submarine or perhaps, his and her life rafts.

So what?
Why are we doing this project? Here I'm referring to the underlying business strategy (motivation) and business justification for undertaking the project. For example, the strategy for an e commerce project might be "first to market." Within this context, schedule is everything. Scope, quality and budget will be secondary in importance.

However, in the middle of the project, the strategy could change if the competition gets to market before we do. Instead of being first-to-market, we switch to a strategy called "fast follower" and shift the priority to scope and quality. Without understanding the project's underlying "So What" we could be sitting there in dry dock on flash flood day with an ark only to discover that the flood was cancelled and has been replaced by a holocaust.

An often overlooked "So What" is to draw out the importance of the project in terms of its impact on the greater good. Look for the WOW factor as Tom Peters terms it. People who work for Fast Company, the Publishing House, don't see them themselves as working for a magazine. They see themselves as leading an entire movement, one that is reshaping the way corporate America does business. Now, that's a WOW. And it unleashes people's energy to be part of something meaningful.

Outcomes during Initiation:

  • Sponsor identified
  • Business Strategy/Context understood
  • Link to Wow factor present
  • Expectations expressed in terms of Time, Resources, Scope, Quality
  • Rough business case stated
  • Project Mission drafted
  • Rough Product and Project and Boundaries understood
  • Critical Success Factors postulated
  • Team requirements guestimated
  • Nature of project determined: extreme or other

Role of Team Leader During Initiation:

  • Listen and raise key questions
  • Do not make commitments until more of the unknowns are known
  • Educate (if necessary) the Sponsor and customer on the extreme nature of the project and what they can expect
  • Avoid falling into the specification trap

Speculate means further defining the "What" of the project and agreeing on the "How" it will be accomplished.

Classical Project Management (CPM) assumes we know at the outset what are final deliverable is to be. And, if this were CPM, we would begin building the detailed plan in earnest in order to eliminate uncertainty and help ensure predictability. If we were building an ark and we had high certainty that there would be a flood and not a holocaust or meteorite storm, we'd be on our way.

In contrast, extreme project management requires an admission that we don't know what the final deliverable truly is or how the project's context might change. Only that it will. The nature of the project is to discover the Desired Result as we go along. Hence we view planning as "speculation" a word intended to signal that we are embracing uncertainty, not trying to eliminate it. We're setting targets and putting in place just enough detail and discipline to allow freedom without going off the deep end.

Scenario building
A helpful tool made famous by Royal Dutch Shell is that of scenario building. Scenario building is the act of describing possible future states along with options and implications in case that state becomes the reality. For example, in the Noah project, the stakeholders might create several scenarios during Speculation: What if the flood was replaced with a worldwide flash freeze? Or with fire and brimstone? A massive plague? What would we do to achieve our mission of providing safe passage for the family and chosen ones? Given these scenarios, such options might include building an ark, a submarark, his and hers rockette ships, rafts, or using cryogenics.

This is quite a different project than what was originally specified: "Build me an ark."

Outcomes produced during Speculation include:

Scenarios drafted Interproject dependencies identified
Mission re-drafted with stakeholder buy-in Risk / Uncertainty stated
Desired Functionality/Capabilities elaborated Resource Requirements guestimated
Deliverables listed Time-boxed Deliverable Schedule
Support components identified Project communication infrastructure in place
Vision of success described One page Project Summary Sheet

Role of Team Leader during Speculation:

  • Ensure buy-in to the extreme process among team and stakeholders
  • Commit to only those dates that have been committed to by the team
  • Maintain continuing dialog with the sponsor and customers throughout

In the next installment of this mini-series, I'll go over the other three elements of a Flexible Project Model: Innovate, Reevaluate and Celebrate. In the meantime, procrastinate no more.

eXtremely yours,

©Copyright 2000-2018 Emprend, Inc. All Rights Reserved.
About us   Site Map   View current sponsorship opportunities (PDF)
Contact us for more information or e-mail info@projectconnections.com
Terms of Service and Privacy Policy