Promises and Prescriptions
Part 5 - Set a Priority to Eliminate Multi-Tasking

I agree with Frank Patrick whole-heartedly on this. Multi-tasking is a the primary source of waste in professional services firms. We have our attention on keeping people busy all the time. And then we go measure people on that. It's no wonder that those same people are starting and stopping tasks. We've got to stop multi-tasking before we go broke!

At the portfolio level, prioritize and launch projects only at the rate that the system can absorb them. If you try pushing ten pounds of project through a five-pound pipeline, you won't even get five pounds of successful projects through to the end.

Here's what you can do: adopt a hard and fast rule. Staff are not allowed to start a task that is not in a condition to be finished. That way, the only stopping is when the task is completed. Now, the action for you as project manager is to see that tasks are queued in a ready state for work. That's no small task. However, profits will soar and customers will be delighted!

I so am enjoying Frank Patrick's series on Projects and Promises. Part 4 - Multi-Project & Mixed-Function Multi-Tasking is a gem.

(P)rojects are usually delivered as one of a portfolio of efforts and often share resources with others in the pipeline. It is not unusual for scarce, highly skilled contributors to support multiple projects. The usual response to having a lot of work in one's inbox is to use the squeaky wheel method of prioritization. Whichever project is squeaking the loudest in the morning gets attention for the day, whether the previous day's task is completed or not.

Professional service firms have adopted multi-tasking as a strategy for profitability. Keep engineers very busy and profit will be optimized. Turns out, there's a limit to that.

(B)ouncing back and forth between unfinished tasks in an effort to show progress merely delays all the handoffs involved and wastes valuable capacity in unnecessary set-down, set-up, and "Where was I?" questions at every restart.

Not only do those starts and stops add to the time it takes to do the project tasks, they take away from the quality of the work performed. "Where was I?" is every engineer's lament. Not convinced? Have a look at Franks' simple graphic of multi-tasking. You'll be motivated to eliminate the practice.

For more on multi-tasking read Head-Banging in the A/E Industry.

This is a continuation of my comments on Frank Patrick's series on Projects and Promises, Part 3 - Work Your Way Out of Rework.

Frank proposes 3 actions that we can take to reduce our contributions to the rework on projects:

• Get rid of task due dates
• Develop a clear understanding of the major interdependencies between tasks
• Question assumptions about "necessary" handoffs between tasks

I'll focus here on the first prescription. How could we possibly get rid of task due dates? Of course tasks have due dates. Right? Maybe not!

Frank's prescription is in the usual context of project schedules. If a task is on the schedule, then it has a due date. He's not recommending that we change that. Instead, only put those tasks on the schedule that represent promises to the customer. He says, The only dates that count are those promised outside the project. He urges us to leave all other tasks off the schedule to avoid the predictable missed task starts and finishes. I certainly agree with Frank; the only dates that matter are the ones promised to the customer. But the schedule does more for us than just represent customer promises. Read the rest of this entry ¶

• Why do people work at the edge of safety?
• Why do smart people take crazy risks?
• Is there such a disregard for ones life and others' lives?
• Is construction just a tough guys' business?

I don't think any of those questions are answerable from a rational perspective. At one very safe construction firm a person was recently observed working without fall protection. He knew what to do. His life had been saved just a few years earlier when the fall protection worked. Yet here he was working without fall protection alongside of another person working without fall protection on a day their foreman was absent.

People do what they do, just as they always have done.

This is unacceptable. And it happened. And it will happen with someone else someplace else in the future. We cannot understand this as a rational act. At what time will we face squarely that people are just not rational? Not that we are always not rational. We aren't. But we are capable of doing what is not rational. If you want to understand this just look at Martha Stewart. That woman was on top of the world when she traded her stock (with less than 1% of her net worth at stake). She was offered a plea bargain but declined it. She is now convicted of four counts of obstructing justice and lying. This woman's pride, arrogance, and obstinacy brought her down. And Martha was just doing what Martha does and had always done.

Read the rest of this entry ¶

I regularly get into conversations about decision-making. One commonsense understanding of management is as decision-making. Yet, where do we get trained for that role? Peter Drucker has some good advice. Thanks go out to Glen Alleman for sharing Drucker's thinking.

The Project Reformer's e-Tip of the Week

023: Three Are Smarter than Two

So much is made in business of effective decision-making. We've all seen groups paralyzed to make decisions. What if they are wrong? They can't be wrong. So often the reality is there is no right decision, just the opportunity to begin to act effectively. Effective people do not make great decisions. They try to make the few important decisions on the highest level of conceptual understanding. They try to find the constants in a situation. They are therefore, not overly impressed by speed in decision making. They want impact rather than technique; they want to be sound rather than clever. – Peter Drucker, The Effective Executive What does it mean to make 'the few important' decisions. How do you know what is important and what is not important? Here's our best advice: Use your team. Engage them throughout your project in the decision-making practice. Two are smarter than one; three are smarter two. Your team will help you choose which decisions are important. And, they'll be there to participate in those few important decisions with you. The Project Leaders' Studio™ This week's Project e-Tip was suggested by Glen B. Alleman. Got an idea for an e-Tip? Email me!

©2004 Hal Macomber | weblog.halmacomber.com | e-Tip Archive | PDF | Submit Tip

Have a conversation today with your team about the decisions on your plate. It may be the best thing you can do for yourself!

David Schmaltz is in great form in the latest issue of Compass Newsletter. He uses the metaphor of the performing artist to examine the state of the art of project management.

I have to admit that it took me two reads to appreciate David's message. I'm not a thespian, theatre buff, nor art aficionado. The metaphor was overworked for me. However, David puts it succinctly:

The state of any art has never been defined by that art's business.

While art these days needs to be supported commercially, the quality of the art is not synonymous with the commercial returns. Extrapolating, just because a project or project methodology produces commercial value doesn't mean that the way we do those projects produces the value that we intend.

I was surprised to find these comments tucked at the end of the article:

Those who have chided us for avoiding involvement with the XP, Agile, and Lean movements expected us to hop onto one or another of those bandwagons. Our question was and always has been, ?What will people do once they take to these stages?? We find players performing in remarkably similar ways, whether the stage holds a waterfall, a spiral, or a high school production of the land-rush scene from Oklahoma!

But reflecting, David has his own idea of methodology and ideology. To put words in his mouth, 'Projects are personal. People already always have what they need to deliver project results. Just let them be human.' [David, how did I do?]

David Schmaltz is one smart guy. He's backed up by business partner Amy Schwab who proves the rule two are smarter than one. Read this issue of Compass and get yourself on their subscription list. And if you haven't done so already read his book The Blind Men and the Elephant, Mastering Project Work.

Life has been quite hectic. We are not able to have our scheduled interview with Norman Bodek this month. (What will you do with that free hour?) I am sorry for any disappointment. Perhaps we'll be able to interview Mr. Bodek at another time. We will be on schedule to interview David Anderson next month.

Promises and Prescriptions
Part 2 - The Added Work of Rework, by Frank Patrick

"There's never time to do it right, but there's always time to do it over." The need to re-do something is rooted in one of two possibilities. Either it was not done right the first time, or something has changed to make the original attempt less than fully useful.

Frank does a good job describing how single-point estimates for time-to-complete become memorialized in schedules and then "are translated into commitments". We see this on projects everywhere. Smart experienced people get together early on to create a schedule of tasks, durations, and due dates. The project has not yet started, nor do we know who will perform each task. Add to that the uncertainty of the future. It's no wonder that schedules are no good for authorizing the work on projects. They have no basis in the performers' current reality.

Frank goes on to describe how doing work early increases the likelihood that conditions of satisfaction will change, circumstances around the task will change, and the task will be out of sequence with other work. Want to avoid these risks? Listen on your project for these words, "Let's get a jump on it." It's a leading indicator for possible rework.

Adding a task to a to do list is the precursor to failure.

Frank misses two important aspects of promising regarding schedules. [I did read ahead in his series to see if he wrote about them.] First, in spite of our practices, schedules are never promises for task completions. Only people can make promises. At best, schedules are only suggested requests. I say 'suggested' to acknowledge that as time goes on, project tasks are completed, team members learn, and the customer makes changes. What was memorialized in the schedule might no longer be relevant. Remember this: only the promise spoken by the intended performer has any reliability.

Second, while people are bound to make poor estimates, failing to allocate capacity is equally responsible for the unreliability on our projects. Rephrasing Frank's opening statement,

"There's always time available for doing a task, but there's never time when the task is due."

To do lists get in the way of project reliability. Want to increase reliability? Then have your performers allocate the time they estimate — have them block time out in their calendars. Adding a task to a to do list is the precursor to failure.

Next up, Part 3: Work Your Way Out of Rework.

Been a crazy last three weeks for me. A little ski accident (my wife not me — she's recovering nicely) resulted in turning my world upside down. I hadn't realized how I've been squeezing my writing and blogging into my already-full day. I did a quick look at the posting times for my last 20 entries. Most were late at night. I've decided to bring that to an end. No more last minute manager for me.

Here's my plan: I will post Project e-Tips on Wednesdays and Safety Thursday. I will continue to update the safety sideblog on Safety Everyday throughout the week. I will also post one other time, probably Mondays on whatever moves me.

There are so many unfinished writing projects. Although it's quite late, I will continue to comment on Frank Patrick's outstanding series Promises and Predictions. But don't wait for my continued commentary go visit Frank's series today.

Have you noticed that crane injuries and deaths are dominating the news in construction safety? [See the Safety Everyday Sideblog.] The regulations for cranes and derricks have not changed in 30 years. OSHA has a working group that was planning to meet at the end of March. It has been postponed to early May.

It seems odd to me that the regulations haven't changed in 30 years. Have we learned nothing during that time that would result in a change in regulations? It just doesn't seem possible.