Archive for the 'project scheduling' Category

Hard to imagine in the world of projects that anyone would ask the question "Why do deadlines matter?" However, in the world of politics and world conflicts the argument is front and center. We learned this week, President Bush just won his battle with the Democrats in Congress. There will be no deadlines in the funding bill for the war in Iraq. To my surprise, I opened the June issue of Business 2.0 turning to Jeffrey Pfeffer, Professor, Stanford University, to see his essay Why Deadlines Matter. Read the rest of this entry ¶

The readers' comments on my last two day's postings on Gantt charts have helped me get my thoughts together for a longer up-coming project tip. In the meantime, I'll share these thoughts.

Gantt charts are snapshots of the state of a project. They leave open to interpretation the basic question everyone has about projects, "How is the project going?" The question requires an opinion. A snapshot is a poor basis for an opinion. We want to look across time to provide grounding for an assessment.

People can read a Gantt chart without training.

Progress updates on Gantt charts are misleading. The second question everyone asks is, "When will the project finish?" While done might mean "done", 60% complete doesn't tell you anything about how much time is required to finish the other 40%. If it were just one activity that was 60% complete we might have some idea about the impacts to other activities. As soon as there are more than one activity in a state of Read the rest of this entry ¶

Previous in series Next in series

I'm preparing to write another e-Tip on Gantt charts. (I know, it's been quite some time since my last e-Tip.) The Agilists and the Leanies don't use Gantt charts for planning, managing, or controlling their projects. Yesterday, I asked, What Has the Gantt Chart Done for You Lately? Chet and Jerry both left comments saying they see value in using Gantt charts for communicating overall project status, particularly up the organization. I'd also like to know,

"How are Gantt charts being used to brief the project team?"

A Gantt chart can provide a contextual view of the project.

I have the sense that a Gantt chart can provide a contextual view of the project. At the same time, I've been working on some big projects — power station construction — where the only briefing of the project team is done verbally. How do you see Gantt charts could be used to keep a team focused on the project?

Previous in series Next in series

Almost every project has a Gantt chart, but what is it doing for you? I ask the question with a sincere interest in how projects are better managed with Gantt charts. Is it a visual thing? Does it help you to steer the project? How does it aid you to stay in control? Alternatively, are their other tools that you rely on to manage your projects? Please leave your comments.

Previous in series Next in series

Johanna is doing a great job with the series at Managing Product Development. We've all seen these schedule games. We may even recognize the names. Her posts so far:

• Schedule Game #1: Schedule Chicken
• Schedule Game #2: 90% Done
• Schedule Game #3: Bring Me a Rock
• Schedule Game #4: Hope is Our Most Important Strategy

Have a look. And let's hope she keeps the series going.

A project team has a chance to succeed when team members feel free to fully express how they are doing, what help they need, and what help they can offer. Unfortunately, all too often project teams are engaged in another practice. Johanna Rothman, author of Managing Product Development, calls it Schedule Game #1: Schedule Chicken. Johanna describes the game this way:

(E)veryone claims they're on time. But the reality is that each person is waiting for another person to explain why he or she is not ready. In that case, each person graciously says, "Oh, that's fine with me if you take an extra week or two or three. No problem."

Johanna explains how it's possible to play the game:

Schedule Chicken occurs when PMs only measure the milestones (the date), and not the stuff that's created (the feature set) and the progress towards creating that stuff (velocity) and how good that stuff is (the defect levels) all throughout the project.

Based on Johanna's posting title I'm guessing she'll be treating us to a series on schedule games teams play. Let's help her out. What games have you seen team members playing?

I've been re-thinking the Daily Coordination Meeting. I've been watching daily meetings. Often, the project participants are taking care of basic coordination — doing last-minute planning — rather than managing their commitments. The name of the meeting Daily Coordination is part of the problem, but only part. Coordinating one group with another is a small part of the the daily meeting. The most important part is taking the time to let each other know that you and your group have done what you said you would do for that day. This builds trust and it creates a basis for the performing groups to take the hedging out of their promising. When one group doesn't have confidence in what another group will do for them, then we understandably get hedging. Hedging leads to work areas being ready but no one working. The aim is for the project work to flow unimpeded from one performing group to another.

Even the most reliable performers have to deal with the unexpected.

A second key aspect of a meeting for managing commitments is to make timely declarations of completion. Read the rest of this entry ¶

Previous in series

Over a year ago I published a series of postings on the critical path method that produced all kinds of comments and emails from readers. I collected those postings into a two-page article that I published on this site as CPM: Fool Me Once, Fool Me Twice. Shortly thereafter, Greg Howell caught some article in ENR on CPM. It was the usual stuff about project managers just need to learn how to use the CPM tools. In an unpublished letter to the editor (with a copy to me) he replied this way:

"CPM is the tool for you if you believe what you know is more important than what you can learn, and if you prefer being "In Charge" to getting the project done, and if out-of-date plans are more useful than a team prepared for action."

Without promising the project is full of delay. That is waste. And it leads to more waste.

While I see what he is saying, and I think the phrasing is clever, many people might not get why he says it. Greg is indirectly pointing to the stasis of the use of the CPM tools. People don't have the habits or the inclination to keep the CPM schedules up-to-date. Little variations and missing task status can throw a CPM schedule out of whack. Soon people lose confidence and ignore the schedule.

Another key issue has to do with the authorization of work. The PMBoK® says something like, "Work is authorized by the schedule." Authorization is not the issue. Coordination among the team is the issue. Team members depend on the completion of work (prerequisites) so they can begin their work. But beginning work is the easy part. Other team members want to know when you will finish your work. They, just like you, want a promise. Without promising the project is full of delay. That is waste. And it leads to more waste.

Team members can make promises on the work they will perform informed by a CPM schedule. That would be wonderful. But we don't see that behavior. In fact, we see, as Greg so aptly puts it,

"The usual project meeting is a commitment-free zone." The CPM schedule is just one of the excuses for not doing what needs to be done."

What do you prefer? I don't know anyone who would identify with Greg's characterization. And teams need some guidance of overall sequence of work. Bob Huber, Scheduling Manager, The Boldt Company, suggests The Marriage of CPM and Lean Construction in his paper co-authored with Paul Reiser presented at last year's International Group for Lean Construction's 11th Conference. He urges people to use CPM at a high level rather than a detailed task level. Further detail is left to the people performing the work. The result is a CPM schedule that is easy to keep up-to-date and doesn't have swings in it from week to week. People will use that schedule.

You can find the PDF of CPM: Fool Me Once, Fool Me Twice in the left column of the weblog. Or, get it here .

Previous in series

Some very thoughtful comments were made on some of the postings from last week's series on CPM. I urge you to read those comments. Just click on the "(#) Comments" link at the end of each posting wherever you see a number other than "Please Comment". I urge you to leave comments as well.

If what people were doing was working there'd be no reason to do something else!

A few people asked me what I was planning to do with the Fool Me Once, Fool Me Twiceseries. Based on the requests I've decided to compile the five postings as a single document that I'll link on the site. That document can be freely downloaded and distributed. I hope you find it valuable.

Now for those wondering what got me going on the series in the first place, I've been somewhat concerned about people who set out to adopt a new approach (to anything) while trying their hardest not to give up what they are doing. If what they were doing was working there'd be no reason to do something else! We know in the case of project planning and control that it routinely doesn't work.

Continuing to do the old has three negative effects on succeeding with the new:

1. It maintains the inertia of the current practice
2. It consumes scarce attention and capacity for adopting the unfamiliar and initially time-consuming practice
3. It reinforces the measurement and rewards associated with the old

Using the Critical Path Method for project planning and control is just one of those practices that seems like a good idea, but fails in execution. One issue I failed to stress last week is the lack of seriousness given to CPM as evidenced by not providing the resources to do a good job keeping the schedules always up-to-date. There is a trend seen in construction where people are preparing the CPM schedules yet they don't know how to build and don't know scheduling¹. Lack of seriousness and competence spells disaster for the project participants. Not doing CPM scheduling in many cases would be far better than doing it the current way. And certainly for those people who are dissatisfied enough to try a different approach they should give up trying to do both.

Stop the craziness of doing the old and the new.

1. As reported in ENR [ ⇑ back ]

Previous in series Next in series

Planning is conversation.

The future is uncertain and unknowable. Commitments must be adjusted as the future unfolds. Those adjustments can be done by the project manager or anyone on the project team. However, only those people involved in planning the project will be in the position to notice and then assess the need for adjustment.

Stay in conversation with all key performers and insist they do the same with those people supporting them.

So, why use critical path? All planning is practice. Each time through a project plan the participants prepare themselves for the future that is unfolding. Will it turn out just as they plan? Of course not. But taking the time to plan prepares them for the eventuality of the future being different than they expected.

Do you want your projects to finish on time and on budget?

• Accept the plan as represented on the critical path is what will not happen; task starts and finishes are uncertain.
• Investigate the level of effort for every task on the critical path. Adjust buffers in accordance with the circumstances and the competence available.
• Make assignments only when the work is ready — prerequisite work is complete and resources are available.
• Measure the performance of your planning practices as a basis for eliminating the sources of task variability.
• Include performers in planning conversations to give them practice for the inevitably uncertain future.

Let's stop fooling around on projects. Stay in conversation with all key performers and insist they do the same with those people supporting them. Use those conversations to continue exploring possible ends and means. It is the one and only avenue for succeeding with projects.

Previous in series Next in series

Task durations depend on the quality of the conversations.

Schedules are not commitment. We have been fooled enough to know that! Just because we say a task is on the critical path doesn't mean it will get done. Only when the intended performer promises to perform will it get done (and even then, maybe not). Commitment is produced in conversation. When people freely promise there is a possibility of commitment. Absent conversation, tasks will not complete as desired.

Declaring complete — saying, "I'm done" — is the step to keep work flowing.

Declaring complete is the key action for keeping any project on track. People do not do what the schedule says they should do. Yet, project managers too often expect that people will do just what the master schedule says they should do. Why? We can't do tasks that are not ready to be done. Tasks on the critical path necessarily must wait for the task preceding it. Unfortunately, performers in sequence may not be in conversation with each other. They don't know that a task is complete therefore releasing the work for the next person in line. These performers may work in different divisions, companies, or just not be aware that another person is dependent on them. Declaring complete — saying, "I'm done" — is the step to keep work flowing.

One-way communication doesn't work. Project members are informed of the schedule. Performers are told which tasks they should do. Status is given as a report by someone other than the performer. None of this produces commitments. You must be in two-way conversation to have people perform to the schedule. Only the fool thinks "telling" suffices.

Previous in series Next in series

Task durations vary.

Experienced project managers will tell you the critical path moves on a project. Why? Tasks don't start and finish as represented in the project schedule. This would be fine if all the performers for critical path tasks were always available to perform on the project, but this is not the case. In most organizations people are working on more than one project at a time or project work is in addition to their normal work responsibilities. This creates the situation where they must manage priorities: "Do I spend my time on this or on that?"

Our only avenue is to manage the project to minimize the variability.

We don't know all of what must be done. Oftentimes ad hoc work (those tasks that seem to arise in the course of doing the other work) encompasses as much time as the planned work of the project. To the extent that this ad hoc work requires the same resources as the work on the plan we see projects get behind. Performing this work often shifts the critical path.

Task durations therefore are probabilistic. They will range from times that are as short as the actual time applied performing the task to as long as multiples of the task times depending on how much waiting time and distraction time is incurred. Projects by their nature make it difficult to gauge those probability distributions because each project is unique. Our only avenue is to manage the project to minimize the variability.

Previous in series Next in series

Task durations are fabrications.

Let's say you produce a critical path (for whatever reason). The generally accepted approach is to ask each key performer to provide durations for the tasks and the precedence relationships. With this data you can find the longest path through the network of tasks. With this approach you overcome one of the problems previously identified. So, is there still a problem? You bet.

We can safely assume that all durations are at least twice as long as they need to be.

Success with the critical path method hinges on knowing task durations…how else are we to coordinate action? Each person will estimate the time it will take them to perform. If they are at all risk averse, then they will also buffer that duration based on their experience performing similar tasks. Why? Because they don�t want to be the person responsible for getting the project off track. However, we don't know what those buffers are. One person might add a 20% buffer while another adds a 500% buffer. Eli Goldratt, author of Critical Chain, and founder of the Avraham Goldratt Institute, suggests we can safely assume that all durations are at least twice as long as they need to be.

What are we to do? We must investigate task level of effort (estimated hours to perform) for every task on the critical path and consider carefully its application. Durations alone are not sufficient. We are fooled twice when we accept durations as stated.

Previous in series Next in series

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

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.

Microsoft Eats the Dog Food
Lean Project Consulting welcomes MS to the table. In this September '02 Fast Company article MS shows off how they have made MS Project 2002 post-modern, or should I say lean. They offer four 'new' axioms for successful projects — all of course now supported by Project 2002. They are:

1. Expect the unexpected. We've been saying this for quite sometime. The world is uncertain and unknowable. Plan your projects that way.
2. Measure work done, not hours spent working. The lean approach using the Last Planner� system is to measure the 'percent of plan complete' on a week-to-week basis. Not only do you stay on-track with completions, but you have a basis for investigating and improving the variances to completing work as planned.
3. Don't crack the whip; share the work. The work, that is, of planning. Rather than doing the typical top-down plan to the gnat's ass, MS is now acknowledging that a better result will come from collaborating with the folks closest to the work.
4. If you want the right people, you have to know what you're looking for. Project success depends on having people who can do the job. So, MS now has resource descriptions rather than just individual's names.

What are they missing? Good question! Here's one list. More to come later.
.. Dependence and variability
.. Working on only that work that should, can, and will be done
.. Promising reliably
.. Leadership

Still, I can't w