Task durations are estimates.

The critical path method (CPM) is considered THE standard for managing projects. Customer contracts often require developing and maintaining the critical path schedule in great detail. Universities teach CPM in project management courses. CPM is the primary function of the best-selling project management software. Large plots of project schedules hang in construction trailers and project management offices depicting the network diagram and the critical path. No project professional in his or her right mind would start a project without calculating the critical path. So, if it is so widely used, then why are projects late, over budget, and dissatisfying customers?

Knowing who will perform and the circumstances for performance make more of a difference.

We are fooled by the critical path. The central presumption for establishing a critical path is that we know how long each activity or task will take. When the activities are then strung together according to precedence relationships one can find the minimum time through the project. That is the critical path.

So what is the problem? How could you know what the real time will be for completing a task? You can't. It is complicated by not knowing exactly who will be performing the task. (Rookies take longer than experienced people.) And it is further complicated by not knowing the circumstances (or situation) for performing the task. (Even experienced people can be distracted or can have an off day.)

So what does this mean for anyone managing projects? If you think that managing a project means just keeping your eye on the critical, then you are mistaken. Knowing who will perform and the circumstances for performance make more of a difference. Don't be fooled.

Next in series

A few weeks ago I wrote about Patrick Lencioni's Leadership Trilogy. In his book Four Obsessions of an Effective Executive he proposes two must-have disciplines:

..create organizational clarity
..over-communicate organizational clarity

One company, Cranium, profiled by INC Magazine Inside the Smartest Little Company in America attributes their success to these disciplines. They've done it by developing their own vocabulary.

Why am I writing about a toy company? To show the power of the principles. Cranium is a product development company that relies heavily on their ability to innovate. As such they are always doing projects. To my knowledge they are not using a lean approach. However, they are working with a variety of people on an always-distributed basis for getting their new products to market.

The founders came from Microsoft. That's right. And they brought the MS way of product development with them. One of the hallmarks of MS is the attention given to communicating the goal. (A computer on every desk and in every home) Cranium's goal: to create moments in a game where every player can shine — appearing smart and funny in front of their teammates. Cranium took this one step further. They created a vocabulary so everyone associated with a project would know just how to act. They call it CHIFF: clever, high quality, innovative, friendly, and fun. They go all out making sure every employee and every partner understands the goal and the guiding principles. By over-communicating just these two things Cranium now sits at the top of the heap. And the odds of any new game surviving, let alone making it to the top, are a long shot.

So, what could we be doing? I often see teams go to the step of setting a goal and agreeing to guiding principles, but then fail to take it the next step: over-communicating. "How many times do I have to say…?" is a project managers lament. When it comes to communicating the goal and the principles (or standards) we can't say them enough. Put that in your cranium.

Dr. Edward Hoffman, Director of the NASA Academy of Program and Project Leadership claims there isn't a better magazine for project management than ASK Magazine. I've poked around for awhile and read a few articles and reviews including the Conference Report: Masters Forum IV, February '02. One of the highlights was a presentation made by Greg Howell on lean project delivery. Don Margolies, from Goddard (Space Center), remarked, "Greg Howell's talk was among the highlights of the meeting for me. Thought provoking, radical (in my experience) and screaming out for future considerations." I noticed more than a dozen links to Fast Company articles. I'm beginning to see what Dr. Hoffman is talking about.

BTW, for more provocative thinking from Greg Howell and co-author Lauri Koskela, read the paper Greg delivered in July 2002 at the bi-annual PMI Research Conference 2002 titled The Underlying Theory of Project Management is Obsolete.

Sometimes I think there's more interest in project software than there is in developing good practices of planning and execution. Maybe it is the 'magic pill' that we oh-so-hope will work. PC Magazine regularly reviews project management software. Earlier this year they reviewed MS Project Professional 2002 and MS Server 2002 in the article Enterprise-Level Project Management from Microsoft. In the most recent issue they looked at the web-based competition in the article Handle Projects with the Web's Help. I'm more interested in what they do not write about than what they do. Perhaps they don't know how to manage projects.

PCMag emphasizes the conventional practices of large project management in their reviews: work breakdown sturctures, organization breakdown structures, costing, resource-loading, statusing, and CPM scheduling. Some of these programs do well in all categories (MS Project and Artemus) others are strong in the emerging practices — especially collaboration. In spite of their emphasis on conventional practices, PCMag gave it's coveted Editor's Choice award to Project.net saying, "Project.net is a capable and flexible product—especially for individual team members. Companies that want to emphasize collaboration over the centralized planning common to many enterprise project management programs will like its approach." Project.net differs in functionality from all the other applications:

"Project.net avoids terminology and processes associated with traditional project management apps. Instead, it uses an approach called Project Lifecycle Methodology, which includes planning and scheduling for Lifecycles (projects), Phases (project stages), Gates (milestones), and Deliverables (completed tasks or document elements).

"Project.net emphasizes a more collaborative (bottom-up) approach to project management rather than centralized planning (top-down). This philosophy is obvious in the Workflow Designer, a project management tool that lets users (not just project managers) create a series of tasks or documents."

So…some people are getting it — projects evolve; planning is collaborative (conversational); and centralized control is an illusion.

Have you collaborated online? I have. All day long. (Ok, only 14 Hrs.) I've been using AOL Instant Messenger to aid my son in his research project. From one link to the next we began to build a picture of blogging that could change the practices of project management. How? By putting performers in the position of planning and collaborating throughout the project. The tools are robust. They are easy to use and set-up. With access to a little space on a company server you're ready to go.

What could it look like? The major project participants would be co-authors of the weblog. They would post as they need to or on a schedule. They might include project documents, schedules, contracts, etc. Other participants would use commenting tools to ask questions, offer suggestions, and give their opinions. So no one misses what is going on, they all would subscribe to the project weblog. During my adventures yesterday I found a subscription service from Bloglet that I've added to this site. (Subscribe to this one today!) There are also free calendar tools and search engines (I use Atomz.) to fill out the project weblog.

Planning is conversation. That conversation is principally one for coordinating action and making assessments. Blogging is a new verb for getting it done. The world of projects may never be the same.

I just finished reading a short article tucked away in the Sept 16 issue of ENR, the construction industry news weekly published by McGraw Hill, Schedule School to Fill Skill Gap. (No byline on the article.) ENR reports that PMI is creating a school to teach project scheduling to the folks who are sitting at the computer. Why? It seems the scheduling software is so easy to use and inexpensive to run that a large number of people with no experience in project planning and scheduling are creating the schedules. I suppose that education is better than no education. But what are they thinking?

• Do project managers think inexperienced people (with computer skills the PM might lack) using MS Project and the like can create the project schedule they will operate by?
• Do these rookie schedulers think they are producing schedules that can be used?
• Does PMI think that this should continue?
• Does ENR think that construction projects will get done on time when these people are trained in scheduling?
• Does anyone think that, just maybe, the doers need to be the ones engaged in the planning?
• Do the customers know what is going on?

Maybe no one is thinking at all. That could explain why projects take too long, cost too much, and fail in some significant way to deliver on the customers' conditions of satisfaction. Gee, and I thought it was more complicated than that. We just have to start thinking.

I'm in the process of writing a paper with Greg Howell titled Projects, Planning, and Promising. In the paper we are setting out to show what isn't covered today in the accepted practice of project management while offering a new definition of what needs to be covered and how that might occur. In the course of a conversation with two project managers using the Last Planner System® this past week, I made the claim that while planning is temporal — it has an often-short shelf-life — the exercise of planning is a make-ready activity for the planner-doers.

Planning is a practice session that gets planner-doers ready for later on being in action. One go through a planning session is ill preparation. It is like hitting one golf ball and thinking you are ready for the game. The more often one is in planning conversations, the more practice one gets, and therefore the more ready one is to act in the future that is surely to be different (in some way) from the planning scenario. Yet, when the planners are also the doers, then these people will be prepared to plan again on-the-fly.

Unfortunately, the current practice separates planning from execution. A few smart and experienced people do the planning. Once the plan is accepted by the customer and management, then it is baselined (frozen) and published to the team. By that time the shelf-life may have expired leaving the doers in the situation that they can't be guided by the plan, yet they will be measured and controlled to it. For them it is a double whammy. They missed the practice session so they are not prepared for dealing with the unanticipated and they must still perform to the baselined plan.

What could they be doing? Planning could be connected tightly to execution. Planning cycles could be short — one-week intervals rather than the usual 90-180 day planning intervals. Finally, they could be learning as they go, adjusting their plan as their competence increases and the future unfolds. Such a shame…

Did you notice yesterday's post was made by Greg Howell? Greg is a friend and business partner. He is a co-founder of the Lean Construction Institute and the co-author with Lauri Koskela of the paper The Underlying Theory of Project Management is Obsolete presented at PMI's Research Symposium in July 2002. I invited Greg to weigh in when he saw the opportunity. Look for more posts in the next few weeks.

Trust and communication have been the primary issues in every one of over a hundred partnering meetings I have facilitated. The meetings themselves were designed to align objectives, establish lines of communication for resolving disputes, and to develop personal cooperative relationships. The underlying premise was that all project participants could get more out of the project by cooperating than by fighting. This would be accomplished by better relationships, communication within the organization, and more rapid dispute resolution. In many cases the resulting project organization was able to work more effectively than expected and many believed the project was well served by the effort. Even so, most people moved from being wary at their first partnering session to cynicism by the third. Why was this?

I think the answer comes in two equally important parts. First, the participants assumed that the underlying approach to project management was effective and its performance was not related to the problem. As a result, nothing was changed in the way the work itself was managed. Second, participants shared a belief that trust could be built by aligning objectives and improving communications. Let me take them one at a time.

Trust develops when people make and keep commitments. But promising to "communicate" isn't as effective as promising and delivering the submittal documents on a date certain. But people on projects, even with partnering sessions, are reluctant to make specific promises for performance when they lack confidence in their ability to deliver when they know other people are unlikely to deliver the needed prerequisites. So people promise to "try" and they say delivery will be "hopefully" on time. Project performance spirals down as delays compound.

I now believe that project management itself, particularly the separation of planning and execution, is the root cause of the problem. No specific commitment to action is necessary in current project management because action is triggered by the project plan. Senior managers make contingent promises to deliver, but people at the operating level rarely make firm promises. How can their commitments be solid if the can�t say "NO!" when the conditions for doing the job are not at hand? The very idea of allowing people to say "no" rather than to accept a deficient assignment is hard to accept in an industry built on "Can Do."

So we need to reform project management. Our project management system must enable people to work ready so those responsible can make specific promises. And we need to develop the ability to make and secure reliable promises. Project performance spirals up as the system and behavior develop together. Like love and marriage, horse and carriage, you can't have one without the other. Ah but if you do…

I keep seeing people pursuing the best solution. In the process they delay receiving any benefit from the good solutions in hand. Imagine how much further we might be, how much more competitive, how much more agile, if we just adopted one improvement after the other.

Dear Joe,

Thanks for sharing your interest in comparing the paybacks of local improvements with the paybacks of investing in the 'big' solutions. I'll offer a way of thinking about some usual cases.

Local improvement with a quick time for approval
I work in a work cell. Throughout the day I need to leave the workcell to use a drill press across the plant. It takes some time to traverse the plant. (Sometimes I have to make the trip twice because the piece needs reworking.) I discover the plant owns extra drill presses. As an individual I see the opportunity to claim one of the excess drill presses for my workcell. My workgroup leader likes the idea so we move to implementation. I spend 1 Hr arranging, moving, and setting up the drill press. The plant is now in the hole the value of 1 hour. The benefit is now the removal of the interruption — stopping, time walking to the drill press, returning, and re-starting. The drilling is the same whether close by or distant, except that the drill press might stay in a 'ready state' for drilling when it is part of a work cell. Immediately, I have the extra time for producing more throughput and I might encounter other side benefits. When graphing this the plant makes the investment of 1 Hr. and begins getting benefits immediately. When using a time scale of a week, you might not see the money spent, let alone using the time scale of a month.

Compare this with the 'big idea' improvement
An engineer and others spend time for week after week studying, collecting data, analyzing, proposing, getting approvals, dealing with well-intended suggestions from somewhat interested others, and finally implementing. (Please don't read that as cynical. It acknowledges the usual drive for a correct solution. I'll say more later.) During that time no new value is accruing. Costs accrue through the time when the proposal is implemented and returns begin. Plotting this would show starting at zero going negative for N months then beginning the climb back to zero. Only the great solutions climb fast enough to show payback in one year. Most "investments" show returns of 15-25% thus taking anywhere from 3-7 years to payback.

In the first case let's say you are getting 3 improvements every 4 days for a group of 50 people (consistent with national averages of good companies getting 4 improvements/person/year). That is not a bad rate, but it still shows thinking attached to the conventional wisdom. What's that wisdom? People can be expected to act in their self-interest rather than for the benefit of the company. (This harkens back to Adam Smith.) However, if you can avoid the approval process, then the rate of improvement can go way up. One group of 45 people I recently worked with 'adopted' just under 500 improvements in their first 7 weeks. That is about 5 or 6 improvements/person/month! Notice I didn't say 'proposed' and 'approved'. They usually did neither. We used three rules to avoid that.

1. If the workgroup agrees it will be more value, AND
2. If it doesn't require a new cash outlay, AND
3. If it can be done on your shift without interrupting production or others, then just do it.

Everything else needs the foreman's approval. I don't recall how much went to the foreman for approval, but they were acted on promptly.

Pursuing 'correct solutions'
In usual situations managers and engineers removed from the factory floor or the operations of a workgroup are responsible for improving the performance of the process. They pursue this work as projects. Workers are just responsible for production. In these cases we often find the detachment of the engineers and managers leads to proposals about improving local productivity rather than the ideal 'objectivity' and optimal solutions we are seeking from these objective people. Anyone who has even the slightest concern for prudence will choose to take time to be sure that what is being changed will do more good than harm. Investigating that is what so often consumes the time on these projects. In the end we get what we get. Some changes are real improvements while others are write-offs.

Now don't get me wrong. I think we should be doing process engineering, making capital investments, and bringing in subject-matter experts. Here's the problem: almost any investment proposal looks good when evaluated against a poor current state. But what if the current state was on a continuing path of operator-directed improvement? What if those improvements were focussed on reducing dependence and variability? What if those improvements resulted in increased throughput? And, what if those improvements were done with little to no delay? Then…what would we be investing in? I bet they would be very different. We might even have fewer projects.

Hope this helped.

Now, for all you folks who want to look at the graphs…you'll just have to wait! It will take me time to create something that shows how profit velocity varies in the two cases.

The trip was great. It started very early on Sept 11. As you might imagine both Boston Logan and the Philly airports were empty. There were less than 10 people on board. Eery.

The sessions were quite productive. I wish I could report that four teams got off to a great start. Scheduling kept many project team members from attending. However, 6 project leaders did attend. Among other topics, we explored making project performance improvements across projects. We settled on a practice of reviewing weekly project reliability data — the percent of planned tasks completed (PPC) — and analyzing the sources of variability on projects. I think this group will develop a new practice. I'll report on it later. There's a specialty contractor in Texas who I hear is doing something similar. I'll research it.

BTW, look for regular postings every Mon, Wed, and Fri mornings with a few random postings in between. I'm also interested in what readers have to say about these rantings. Click on the "Sound Off" link to leave your comments for me and other readers. You'll know there is something to read when a number precedes the text "Sound Off".

I'm working with a defense contractor today and tomorrow to put a series of projects on the Last Planner� System (LPS). The division has been using the LPS on numerous improvement projects for the last 8 months. They are now setting out to make the LPS the everyday way of managing projects. What's in store? We recognize three challenges:

1. People have the habits they have. This goes for team members and managers alike.
2. Business measures support the current practices. Changes to these measures may disturb otherwise fine operating conditions.
3. People need support for their learning and improving. This requires shifting how managers and leaders are spending their time.

We are using the blitz to accomplish in one quick step what otherwise takes weeks. Project teams will be operating in a new way with other project teams who are doing the same. Among the group we are looking to find some quick learners who can help others. We are looking to link people across the boundaries of their department and the project organization. We are expecting to encounter objections that others in the group can address instead of managers and outsiders. And we are intending to have some fun with it all.

With a little luck on our side we will leave the group in a spirit of enthusiasm for learning and accomplishment. I'll write again on this to let you know what we encountered and how it all comes out.

A Few Thoughts On Coaching
Much of my time is in coaching conversations with leaders in the midst of implementing lean project practices. Lencioni's Leadership Trilogy is just one of my supporting guides. A more all-around useful support is Coachville. I encourage anyone leading change to join Coachville — it's free through the end of 2002. I have been coaching for over 12 years. I have benefited more from Coachville during the last year than from any other single source.

Why coach? Coaching is a skill I see effective leaders use. The skill is particularly important during times of rapid change and learning. People need a leader's help mostly because as human beings we are permanently blind. What do I mean? We are not just unaware of our behaviors or of improtant distinctions, but there are some things that we cannot see if we have our attention on what we should be looking at. Take golf. If one is shifting weight inappropiately during a backswing, looking at the shift in one's body while swinging as a means of correcting the situation takes one's eyes off the ball. Do that and one is sure to miss the ball. So what can we do? Get a coach who can observe us in action. As a leader you can do the same for your team. But how do you interact? What are you looking for? How do you engage with your team?

Begin by exploring the Coachville's tremendous offerings. Coachville offers training for coaches: coaching models, coaching principles, 'How to Coach Anyone' course-by-email, 'What is Coaching' by Real Audio, live conferences, certifications, an abundance of supporting resources, and the most innovative approach to learning: the telecourse — courses by teleconference. Many of these resources and courses are free. Others have nominal fees.

You've got nothing to lose. Join Coachville! And if you are looking for a coach CoachvilleReferral is the largest site for finding a coach.

I work with teams in the midst of challenging projects. So often these teams need guidance, not just with their team members, but also engaging their executives in supportive ways that will help the team succeed. More and more I find myself referring to the work of Patrick Lencioni for that guidance. Patrick has developed a theory set contained in a trilogy of books. He uses a parable as the setting for introducing the principles. Each story finds an executive with trouble. While working through the situation Lencioni exposes leadership principles. Readers find the approach engaging and memorable. I'll offer comments on each book, but don't cheat yourself…read the books. Better yet, use them with your team to plot your own strategy for bringing forth the leadership you need to make your lean projects successful.

The Five Temptations of a CEO
for producing exceptional results through others

• choosing status over results
• choosing popularity over accountability
• choosing certainty over clarity
• choosing harmony over healthy conflict
• choosing invulnerability over trust

The one thing anyone who has led knows is that the future is uncertain and unknowable. Yet, the same people are often tempted as Lencioni's CEO was tempted. All projects are risky. All customers want confidence that their project will be successful. All leaders are human. Lencioni shows us we can expect our behaviors to be unintentionally unsupportive. When we observe our behaviors with these distinctions we are prepared for taking different actions.

The Four Obsessions of an Effective Executive
for attaining organizational health

• build and maintain a cohesive leadership team
• create organizational clarity
• over-communicate organizational clarity
• reinforce organizational clarity through human systems

Think of these obsessions, or as Lencioni refers to them as disciplines, as a structure for establishing habits of leadership in your organization. By habits I mean the daily routines that you don't think about, but just do. For instance, the third discipline 'over-communicate organizational clarity,' could be manifest by routinely starting every meeting with a re-statement of why — for the sake of what — the group is proceeding with a lean approach to project delivery. Speaking about this once is not enough. Lencioni claims we must raise the issue throughout the life of the inititiative.

The Five Dysfunctions of a Team
building a hot group

• absence of trust
• fear of conflict
• lack of commitment
• avoidance of accountability
• inattention to results

Many of us have come to expect the usual stages of team performance — forming, storming, norming, and performing — as the usual progression of team dynamics. Yet many of us may never have reached the elusive fourth stage. Lencioni (while not using the four stages) offers a different way of viewing team dynamics and performance. These five distinctions offer any team member a 'handle' for shifting the team behavior. I see so many teams leaving the acts of leadership up to the designated leader. Using these distinctions each of us can shape and reshape team behavior becoming more functional.

One last comment on the trilogy. Lencioni offers practical advice with his short lists on leadership. Let me add some more practical advice that I got from Ken Blanchard in Leadership and the One Minute Manager. Be S.M.A.R.T. about how you proceed. Focus your actions in one area rather than 14. Set a goal that is specific, measurable, attainable, relevant, and trackable. Get your result then set a new S.M.A.R.T. goal. Notes on Developing a S.M.A.R.T. Approach.

I've spent the last three days working with a program management team who have ~80 projects to complete in the next three years. The scope is big; budgets are tight; they're planning a shotgun start on 4-10 projects; and staffing is not in place. Oh, I forgot to mention these projects will be performed throughout the US. Historically, this group and most other companies would hole-up to do detailed planning that would be base-lined at a task level. This would allow a central control of the project. The good news is this group of people have concluded the usual approach simply would not work. In no time the central plan would be out of sync with the reality of the field. This program requires a massively distributed project planning and execution system. The key challenge is to know that project managers everywhere are planning reliably. They have settled on a lean approach to project delivery using the Last Planner� System. [The LPS is a trademark of the Lean Construction Institute.]

So, what's so special about this approach? To start, the focus of the system and practices is to make work ready — that as tasks are coming up to be performed all constraints to performing the task are resolved prior to the start of the task, e.g., availability of competent staff, materials, tools, specifications, authorizations, etc. The intent is to get the task in a condition that it is ready to start and finish…in lean parlance once the performer starts work work continues until it is finished avoiding the usual wastes of demobilization and remobilization, waiting, and hand-offs. Earlier I wrote about should-can-will planning. This step is the "can" activity.

The next difference is organizing recurring planning conversations with those people — last planners — who will assign the work to performers. In this conversation the last planners make promises to complete tasks on specific days. Planning-as-promising results in dramatically increased reliablility of task completion. I have seen overall project reliability jump from under 50% tasks completed as planned to over 75% tasks completed as planned just by conducting these weekly planning conversations with the last plannners.

Finally, task completions are tracked just like Microsoft now recommends (see entry on 8/26/02) rather than tracking hours applied to tasks. Simple 'yes' or 'no' records are kept. Whenever a 'no' is recorded a reason for that variance is also identified. Accumulated reasons for variance can be studied and addressed so that over the life of the project some of the more prevalent causes of the variances are eliminated.

Now, back to the 80-project environment…instead of operating under the illusion that a complete master schedule gives the program manager control over the projects, the program manager in this lean environment is monitoring the quality or effectiveness of the planning system through the results that are recorded on a week-to-week basis. This offers the opportunity for the program manager to offer assistance to those project managers whose planning reliability is low or not improving. One colleague describes the process as adding headlights to the project where the usual project only has taillights: after-the-fact end-of-month reporting.