If you haven't checked out the article in Builder.com How to Identify a Failing Project it's not too late. I wrote about it last Monday. Once you read it leave your rating, although it appears there's a problem. Previous low ratings have disappeared. Imagine that!

Good article on Earned Value Management titled Do the Math in the current issue of Projects@Work. Unfortunately, the website lags the publication of the journal. The article was written by Ray Statton coauthor of the future PMI Earned Value Practice Standard. He describes the EVM approach in two pages.

Elsewhere in the journal are two other articles that hail the merits of EVM. Let me be perfectly clear… I am not a proponent of EVM. In fact, if I had to come down on one side or the other, then I'd choose to be an opponent. The problem I see in organizations is EVM adds a level of administration (and bureaucracy) to essentially provide a highly detailed rear-view mirror. It ends up being a tool for tracking rather than steering. There is rarely time available for replanning the EV, let alone to use other tools for planning and steering. The major problem is fixing the EV in the system having the effect of making it real. While the world continues to be uncertain, there is often significant resistance to making any changes to what has already been committed in the accounting system.

A few of my colleagues and friends were given a book coauthored by Robert J. De Koch, COO of The Boldt Company and Phillip G. Clampitt, Ph. D., Professor, University of Wisconsin. The book is titled Embracing Uncertainty: The Essence of Leadership. It might as well have been titled Succeeding on Projects. One friend and colleague mentioned the book in a comment on an earlier posting about uncertainty. Get the book. This book is a winner. I will write about the authors' views and the relevance to projects for the next few days. I am also adding the book to a new listing of Books (look for a new blogroll on the weblog).

The authors claim "it is better to embrace uncertainty than to eliminate it." They go on to say there are issues for which leaders don't have answers AND there is a sledgehammer-like requirement for knowing even in the face of no one can know. They offer six propositions for managing in our uncertain world:

1. Embracing uncertainty enhances the quality of life for employees and organizations.
2. There are some powerful forces that make it difficult or socially unacceptable to embrace uncertainty.
3. There is a lot more uncertainty in the world than ever gets acknowledged.
4. People and organizations spend a lot of time creating the appearance, not the reality, of certainty.
5. The illusions of certainty are pervasive and often debilitating. The problem is getting worse, not better.
6. There are effective ways to embrace uncertainty in your lives and organizations.

The book is refreshing in the possibility of embracing that which we all know is so — the future is uncertain and unknowable — will lead directly to new patterns and practices for coping and thriving in our endeavors.

Article titles on project management don't get catchier than How to Identify a Failing Project, by Jason P. Charvat. The article appeared last Friday on Builder.com, a website/ezine aimed at the information technology crowd. Builder.com frequently publishes articles on project management. The site is worth bookmarking. Unfortunately, the article doesn't offer much insight.

Claiming "almost two-thirds of all IT projects fail" Charvat identifies six problems you might encounter on projects and possible actions. Do yourself a favor. Take a good look at the chart. The author goes on to identify 12 sources of projects going out of control. Charvat starts with a point that all in the agile community will disagree with:

• Sloppy requirements: Every project depends upon solid user requirements being firmly locked down prior to any work being undertaken. Failure to do so is a leading cause for project failure.

Perhaps he hasn't noticed the future is uncertain and unknowable. Perhaps he thinks the customer and the team members will not learn.

I can agree with two of his points:

• Poor communications: One of the biggest reasons why any project goes bad is due to a lack of communication. I have seen many projects fail simply because no one understands what to do and receives no communication as to current progress; this, inevitably, results in project failure.
• Poor decision-making: Decision that aren't made at all and decisions that are delayed due to second-guessing are both risk factors. Additionally, some decisions are so turned out-of-context as responsibility for them is passed down the line that they end up being made based on faulty information. This doesn't bode too well for any critical project.

However, anyone who spends just a little time around projects could say those things. Charvat writes the usual pabulum; he offers no new diagnosis, let alone new action. He did however make one statement that got me hopeful,

"The executive team of the company couldn't understand why the project was doing so poorly because previous updates from the project manager indicated otherwise."

To my dismay he never addressed the issue leaving us to wonder what if anything can be done.

All in all, Charvat is himself a good example of what is wrong with project management…he proposes actions for a world of no uncertainty. Maybe he could learn something by turning his attention to the project teams that are succeeding.

Builder.com invites readers to rate their articles from 1-5 (5 being most useful/valuable). While you're reading the article take the time to leave your rating. (As of this moment 5 people had rated the article.) I gave it a "1″. Let's see what the rating is at the end of the week.

Sorry everyone for the problem with the commenting function. From what I can tell it is not the Haloscan commenting system. It appears random edits are being made to my template. I've informed the folks at blogger. In the meantime, if you have comments to make and the system is down, please send them along to me. I will post them for you.

Each month I take out two days for training others in leading lean projects. Among other topics this past week, we discussed the paper Managing Project Uncertainty: From Variability to Chaos. The participants appreciated the novelty of modifying the project management style to the various degrees of project uncertainty. The usual approach we see and they experience is a one size fits all approach that is often prescribed by company policy and investment in project management tools. The authors make a further claim. They say the project manager's role must also change for different uncertainty profiles. I beg to differ.

The role of a project manager is to always have the project in a condition for the team members to do what they set out to do. Further, the project manager's role is to keep the team in a condition that they can perform tending to their concerns, their mood, and their learning. Far too little attention today is given to the mood of the team members. So little, I am not surprised that the authors suggest other issues need the project manager's attention. We don't have the experience to conclude attending to the mood of the team makes a difference.

As project uncertainty increases so does the need for project manager care. Team members can become anxious, doubtful, and may distrust one another and the leader. So what does the project manager do? Listen. Anticipate. Attend. Care. Provide.

The project manager role is the one constant at all levels of uncertainty…servant to the team.

A few more thoughts on Managing Project Uncertainty: From Variability to Chaos…Earlier this week I participated in a workshop in Washington, DC titled How will homeland security shape tomorrow's capital projects?. The workshop was the second in a series for mapping the technology for automating the delivery of projects for the construction industry. I could only attend the first day due to other commitments (I'll write about that tomorrow.). The conference was sponsored by the Construction Industry Institute, the National Science Foundation, The White House National Science & Technology Council, and others.

The key note speakers were great. (Read more about the speakers and the agenda.) I'll just comment today on one of the talks: Vulnerability of Public Infrastructure: A Systems Perspective, by Robert Prieto, Chairman, Parsons Brinckerhoff. Mr. Prieto has been moving around the speakers' circuit, previously seen at the Polytechnic Institute's conference Engineering the Protection of Our Cities. Bob shared his views on homeland security and project management. He was a principal investigator of the tragedy at the World Trade Center. Bob gave good marks to the changes that had been made since the previous bombing in '93. What caught my attention were these remarks,

"We did well on September 11th because people exercised good judgement not because of good systems."

"Don't squeeze the person out of the loop."

Bob also spoke at length about projects. Here are two of the more relevant quotes:

"Look at preplanning for training operators with what they will encounter."

"The most successful projects are those that evolve with the owners' understanding of their needs."

Later in the day we were tasked with assessing how project planning and management could deal with the evolving homeland security issues and innovations. Bob Prieto's words couldn't have been more relevant. After quite the discussion of how building codes must evolve so they don't limit the adoption of innovations, we discussed how our style of project management would matter. Flexible, adaptive, multi-headed project management will be needed to deal with the increased level of uncertainty introduced by newly understood customer needs and emerging innovations. Call it scrum or call it lean; either way, the way we deliver capital projects will have to deal with an increased uncertainty in the project environment. As the authors of Managing Project Uncertainty put it we need a style that anticipates the unknown unknowns and responds appropriately.

Sorry for the problem with the 'comments' not working on the weblog. I don't know what happened…somehow the code on the template changed.

Thanks fo all who are sending me writing proposals, links, and other suggestions. And thanks, as well, for your ratings on HOT or NOT? If you haven't already rated the weblog please do so by clicking the link.

I've been writing about variability and uncertainty for the last few days. Someone asked, "What do we do when we are already busy? We'd like to improve but we don't seem to have the time for it." It just so happens the same group manages the project staff to virtually 100% utilization. They do it by seeing that everyone has more than one thing to do. The reasoning is understandable. So much of what we work on in projects is not ready for completion. People are expected to do what they can, then go on to another task. All the while, they keep their utilization high. This is a usual condition, particularly in engineering organizations and professional services firms.

High utilization is not equivalent to high productivity. Managers fail to realize the cost of the repeated de-mobilizations and re-mobilizations of work. Not only is that mobilizing time a pure waste, but for knowledge work and creative work the performer has fallen out of flow. The quality of the work has to suffer. Managers also fail to see they can do something about the exact issue they are responding to. They can set out to make work ready.

Ready work can be promised reliably. Ready work can be performed uninterrupted. Ready work completes on a predictable basis releasing work for others in the same predictable way. Ready work is simply more rewarding for the performers. It is a principal responsibility of the project manager and the planning system to make work ready.

The Last Planner™ System of Production Control is an approach for planning and preparing the work of the project team. In doing so, a principal source of variation — planned work in an unready state — is minimized. Oh, but we (the project team) don't have the time (capacity) for making work ready. What a shame. Stop what you are doing! Adopt the rule: only begin tasks that are in a condition for completion. Watch productivity soar!

I am beginning my twelfth week at this endeavor. Frankly, I didn't know whether I'd have something to say or comment on for this long. (Although some of my friends knew better!) What started as a personal writing project has become a project to educate Hal.

I am enjoying this blogging thing. It has been quite easy to get going, particularly with the wealth of tools available (most for free). My inspiration came from Dan Pink. His Just One Thing weblog connected me day-to-day to Dan and his evolving interests. However, what looked like an easy practice of writing a journal has turned out to be quite the research effort. That's good. I am getting more grounded and clear about why a change is needed and what possibly we can change to.

I really appreciate all of you who are steady readers. My inbox is certainly flooded with unsolicited email. For you to subscribe, adding to the email you get everyday, is quite a compliment. As of this morning 55 people are subscribing. Thank you. I also appreciate those of you who are mentioning me in your weblogs and various forums. I've seen an 80 times increase in the number of mentions in a Google search from the day I started 'til now. Finally, I can't give enough thanks to the people who comment on the postings. You sharpen my thinking and my writing. I'm a junkie for your comments!

I am getting ready to speculate (I don't dare say "propose") on a basis for a new theory and practice of project management. In the upcoming weeks I'll write more about uncertainty as a basis of project theory and practice. I'll try to identify a collection of principles for a new unifying theory. I'm also considering proposing a curriculum for the reformed project manager. As I do this I want to connect to more people who share a dissatisfaction with the status quo. I need your help in getting the word out. This morning I added Hot or Not?, the weblog rating service, to the bar under the Reforming Project Management title. Please take the time to click on the link and rate the weblog. Over the last 8 weeks I added an email subscription process (Bloglet), a refer-a-friend process, and a blogrolling link for others who are writing weblogs.

If you are enjoying the weblog, then please subscribe, tell others about it, and most especially comment on the postings or email me. Thank you.

Special note to those subscribing by email: visit the weblog every once-in-awhile to check out the new links and documents I post.

The authors of Managing Project Uncertainty suggest the usual practices of risk management on projects fall short of what we need to be doing to deal with uncertainty.

To deal with such extreme uncertainty, managers need to go beyond traditional risk management, adopting roles and techniques oriented less toward planning and more toward flexibility and learning.

The authors describe four levels of uncertainty and their recommendations for actions at each level. I don't quibble with what they say. (I urge you to read the paper if you haven't done so already.) However they miss an important point. We can do something about the level of uncertainty on projects. We don't have to live with uncertainty like noise (or general randomness) that is present at all times.

In working with many different teams on a variety of projects most of the week-to-week variability is in the control of the project participants. No kidding. The primary source of variability is the tasks are not in a condition to be started and finished as planned. Upon further analysis the cause of that state of 'unreadiness' is a failure of coordination. That failure I call not making a reliable promise.

Promising is in our control. We can say "yes" or "no". (I know some people think they must say "yes" to keep their job.) When we say "yes" but we mean "no" we add uncertainty to the project. When we say "yes" but fail to allocate sufficient capacity to the task (blocking time in our calendar) we add uncertainty. When we say "yes" but don't understand what will satisfy our customer we add uncertainty. Do I need to go on?

We can't know what will happen tomorrow, let alone 14 months from now. What we can do is minimize the stacking effect of uncertainty upon uncertainty by adopting a practice of promising reliably on projects. Perhaps many of the 'complicated' situations described by the authors of Managing Project Uncertainty are just complex projects compounded by sloppiness in promising conversations. Stop adding variability to the uncertainty. Set the standard of securing reliable promises on your projects. You'll have more time for dealing with the remaining variability.

I didn't get the interest I expected from my posting on Wednesday How to Think with Your Gut. I asked readers to leave a comment describing a situation where a project benefited in a surprising way from someone thinking with his or her gut. No one commented! Might this just be a foreign practice? Or is this uninteresting to comment on? Or is it something else altogether? I'd really like to hear from a few people on this topic. Your comments will help me focus my writing for you.

At the risk of beating a dead horse, my post today will elaborate on Thomas Stewart's article. As I began thinking about yesterday's posting on Managing Project Uncertainty the skill and practice of thinking with your gut looked more relevant. Stewart makes three important points for us as project managers.

"What the science suggests is that intuition — or instinct, or hunch, or "learning without awareness," or whatever you want to call it — is a real form of knowledge. It may be nonrational, ineffable, and not always easy to get in touch with, but it can process more information on a more sophisticated level than most of us ever dreamed.

"People excel at "abduction," which is less like reason than inspired guesswork. (Deduction: All taxis are yellow; this is a taxi; therefore it is yellow. Induction: These are all taxis; these are all yellow; therefore, all taxis are probably yellow. Abduction: All taxis are yellow; this vehicle is yellow; therefore this is probably a taxi.) Abduction leaps to conclusions by connecting a known pattern (taxis are yellow) to a specific situation (this yellow vehicle must be a taxi). Compared with computers, people are lousy number crunchers but superb pattern makers — even without being aware of it.

"Research suggests that neither nose-in-the-spreadsheet rationality nor pure gut inspiration is right all the time. The best approach lies somewhere between the extremes, the exact point depending on the situation."

Why are these points so important to us? The answer lies in a four-level model for solving problems. (Notice the similarity to the four levels of uncertainty?)

1. The problem is covered by rules.
2. The situation is complicated.
3. The situation is complex.
4. The situation is chaotic.

The author describes how we must adjust our behavior to the situation. Gut thinking becomes more relevant as one moves towards chaotic situations. Most projects fall somewhere in the middle; they are complicated and complex. Calling on our own gut thinking isn't just a good thing, it might be the only way to address the problem.

Stewart leaves us with the following reassuring thoughts,

"Chances are that the classic linear model you thought you were following — data comes in, you analyze, draw inferences, make a decision — was partly an illusion anyway. "The data doesn't just 'come in,'" Klein points out. "You have to figure out where you're going to look — and that is an intuitive process." In other words, you already are more of an intuitive decision-maker than you may have thought."

For more on developing the skill see the inset Getting in Touch With Your Gut on the first page of Stewart's article. He offers four guidelines for becoming "high intuitives." Try it out. Our projects can only benefit.

When Bad Things Happen to Good Projects by Robert Hertzberg.

A friend sent along a Quiz: Is Your Project at Risk for Disaster? from Baseline Magazine, a Ziff-Davis publication, on assessing project risk. It took me a while to get to it. (Sorry, Chris.) I toyed around with it for awhile. The quiz is fun. It is interactive and it offers an analysis of your project risk. Try it.

The case studies in the accompanying article are better. Hertzberg discusses the four types of variability: variation, forseen uncertainty, unforseen uncertainty, and chaos. He presents a case study for each type of uncertainty along with critiques of project team performance.

The quiz and article are based on a paper published in The Sloan Management Review. SMR only offers articles by purchasing the reprint. So like a good researcher I went to Google and found the article available on the INSEAD website. Managing Project Uncertainty: From Variation to Chaos by authors Arnoud De Meyer, Christoph H. Loch, and Michael T. Pich.

Look for more postings!

Rectangular duct is manufactured and installed in six steps. Sheet metal is cut (1) to length and folded (2) in half. Then the halves are assembled (beat together in the lingo of the trade) (3) into a sections (a box with a hole in both ends). A series of sections are joined (4) and then lifted (5) and secured (6) in place. Steps 1 & 2 are almost always done in the fabshop. And 4,5 & 6 in the field. Step 3 may be done in the shop or in the field. I asked a mechanical contractor what considerations drove the choice between shop and field assembly. He said that it was a matter of determining the most economic solution. Completing step 3 in the shop was less expensive but that raised shipping costs as folded pieces could be nested for transport. So decision was based on the distance from the shop to project — or so he said.

This sounded good but the rule wasn't followed. Sometimes duct was shipped unassembled to nearby projects and assembled clear across town. When pressed the contractor said, "The superintendent make the call." So I went down the block to the nearby project and asked why the duct wasn't shipped to this nearby project in assembled sections. After some weight shifting and attempts to change the subject, the superintendent explained it this way.

"Sure it is cheaper to assemble pieces in the shop, and that works great if the project is well run. But this is a crazy job. Coordination is terrible so work rarely available in a predictable amounts. I can't always join sections and lift them in place. So I keep the crew small and move them between assembling (3) and 4, 5 & 6. It cost me more to assemble but doing it here is cheaper than having those people standing idle. The crazy thing is, the worse coordination gets, the more work contractors bring to site so there is more to do onsite, making coordination harder. As a general rule, I only bring assembled units to well-run projects." (Well I know he didn’t say it just this way but you get the drift.)

Nature builds complex systems the same way. It works from the bottom up by aggregating small units (cells) into larger chunks (organisms). Evolution starts then from "cooperation" as these smaller units learn to work together and continues as they form ever more complex systems. Complex systems do not arise from competition between units. Competition weeds out the units least able to propagate. Evolution of sub-units by cooperation continues as long as the resulting units can evolve fast enough to keep up with changes in the environment. A stable environment helps and a larger population of standard chunks (with a few oddities) is a must if larger units are to form.

Back to construction: Projects can be built better, quicker and less expensively by increasing prefabrication but that will require increased workflow reliability. New forms of commercial contract don't hurt — they open new possibilities for cooperation and aggregation — but they aren't enough. Evolution demands cooperation and reliability. (along with time, and lots of failed experiments.)

Good 2-part case study written by George Sifri, the consultant who did the work: Planning a Web-based project management system and Challenges to implementing a Web-based project management system. What makes it good? From my experience the case is representative of the usual situation — no more, no less.

I couldn't let this Business 2.0 article slip by. Thomas Stewart writes How to Think With Your Gut a great piece on calling on intuition. Great decisions often lack an underlying rational argument. We need more of this on projects. And according to Stewart, we can cultivate and manage for it.

What surprising results have you seen on projects by thinking with your gut? Please leave a comment.

Lauri Koskela and Greg Howell (K&H) argue successfully that current theory is obsolete in their paper The Underlying Theory of Project Management is Obsolete. However the authors may be limited in producing a new theory by exactly the same background paradigm that makes current theory obsolete. K&H seemingly accept the machine metaphor as appropriate for projects. Machines can be perfected; machines can by optimized; machines persist in spite of changes to the environment.

The machine metaphor conceals the nature of a project.

In accepting the metaphor they make three mistakes.

1. They accept "project management is a special instance of production" discussing inadequacies of theory in the production terms of "flow" and "value generation".
2. They continue to see planning, execution, and control as separate processes as proposed in their Exhibit 2. Ingredients for a new theoretical foundation of project management.
3. Their "Discussion" (section) misses the presence of people and all that is entailed by having the everyday influence of learning, innovation, relationships, and complex ever-changing behaviors on a project.

The machine metaphor conceals the nature of a project. Current theory is activity-centric as are machines. The usual practices of optimizing machines is by understanding it by component..breaking it down into smaller and smaller elements. This is the same practice employed in producing project work break-down structures. We've learned enough about reducing the waste of the materiel processes. We need to put our attention on a more significant waste…the under-employment of people on projects. We need practices that are systems-oriented and people-centric to produce project organizations that can respond to and enable learning, innovation, relationships, and effective action.

Where can we look for guidance? I am encouraged by the work in other fields (not projects or production) on autonomic systems, complex adaptive systems, and biomimicry. I also see the relevance of living systems thinking (Margaret Wheatley, A Simpler Way and Turning to One Another), community (Derek M. Powazek, Design for Community), and sustainability (William McDonough and Michael Braungart, Cradle to Cradle). I doubt current operations theory will provide a unifying theory for projects. Instead, I suspect we will see a convergence of thinking that will lead to new theory.

Consider this my leaping off point. Where this will go who knows!

Previous in series Next in series

I'm just a little burnt out after reading Lauri and Greg's paper over and over and over again. So, how 'bout a little fun. The following is a list of anagrams for the same word or phrase. What is it?

ARCANE MEN TEMPT JOG
A GAP EJECTMENT NORM
A PREGNANT MOM EJECT
MONTANA PC MERGE JET
A JAM COMPETENT ENGR
CRANEMAN GET JET MOP
MAMA EJECT GENT PORN
CAMPER AMONG JET TEN

Have some fun making your own anagrams at the Internet anagram Server.