Archive for October, 2002

Set It and Forget It? Hardly!

Thursday, October 31st, 2002

In Koskela's and Howell's (K&H) paper The Underlying Theory of Project Management is Obsolete they describe thermostatic control is the principal espoused (or inferred) theory of control on projects. Examples:

Thermostatic control locks us into a naive plan…uninformed by the world that has unfolded.

  • Cool above 72° and heat below 68°.
  • Returning from the South Pole navigating between sets of markers.

Thermostatic control is based on some decision/choice of what is right, or best, and then invokes corrective action when conditions vary from that stated norm.

What's wrong with this theory? You just can't set it and forget it. Unlike temperature or path, there is no one correct path on the project. The path to completion shifts throughout the project. Sure, we have a good idea of what must be done to finish, but the sequence can change and some of the tasks will fall off while other required actions will be discovered. Thermostatic control at best locks us into a naive plan…uninformed by the world that has unfolded.

Execution and control combine as performers rely on their intuition and experience.

The good news is we find the theory-in-use doesn't conform to the espoused theory. In response to out-of-date plans and execution that fails to consider the readiness of performers, controlling activities function as negotiation between the directors and the performers. Referring to this breakdown of control, people disparage the team by saying they are out of control rather than acknowledging they are likely better off than operating to an obsolete plan.

Where is this headed? The six σ advocates might suggest we must identify the variables and bring them under control (as if we can). But perhaps the machine metaphor has served its useful life; project control is more like navigating a boat. The crew with their hands on the wheel and the lines rely on visceral signals — a fluttering in the sheet, tension in the line, a slight list to starboard — to make their adjustments. Execution and control combine as performers rely on their intuition and experience. The destination is reached even though the boat may never be on course.

| Convert this post to a PDF document.

Related Posts

Management-as-Determining?

Wednesday, October 30th, 2002

The PMBoK® describes 10 planning processes out of a total of 13 core processes for project management. These 10 processes comprise what Koskela and Howell (K&H) call management-as-planning in their paper The Underlying Theory of Project Management is Obsolete.

It is crazy to give the greatest effort to detail when we know the least about the project…at the beginning.

It's no surprise there are 10 planning processes. We go to great extremes on projects to plan. The value of planning seems to arise out of the concern for mimimzing risk. More time on planning is supposed to lead to fewer unforseen conditions. The usual practice is for smart and experienced people to spend time up-front thinking through one possibilty after another finally landing on an approach that makes sense (to them). The plan is put to paper (or in scheduling software) then is 'sold' to project participants and the customer as the (one right) way to go. Often, planning then stops. Execution begins.

This distinct break — planning as separate from execution — is seen by K&H as consistent with the general field of operations. Planning is the process of deciding what to do. Those in execution get their direction from the plan in a usual dispatching process…following the "simple process of issuing orders". Management-as-planning in conjunction with planning-as-determining, becomes management-as-determing in the everyday practices of projects.

We can understand from history that computer time for scheduling programs was expensive. Doing a good job once, or maybe twice was all the project could afford. Further, some project activities are deemed expensive to change mid-way through the project, like changing the layout of a building or adding functions to software. So in an effort to minimize rework project teams fix the requirements and the schedule. But the future is uncertain. Plans can't possibly determine results. At best, planning prepares for the always-uncertain future.

Our herculean efforts to get the project plan in place at six levels of detail early in the life of a project is not just a waste of time, it uses key people who could be used throughout the project to better end. It is crazy to give the greatest effort to detail when we know the least about the project…at the beginning. Better (much better) is to add detail no sooner than it is needed (acting a the last responsible moment) taking advantage of what is revealed and learned. AND do this with people who are close to the project…people who actually perform the tasks.

| Convert this post to a PDF document.

Related Posts

IPO Theory is Incomplete

Tuesday, October 29th, 2002

Koskela and Howell (K&H) claim in their paper The Underlying Theory of Project Management is Obsolete the theory-in-use of project management is based on a production theory and a management theory. The production theory is transformation: input-process-output (IPO). The management theory is closed-loop: planning-executing-controlling, with the emphasis on planning (management-as-planning, the dispatching model, and the thermostat model of control). For this posting I'll focus on the transformation model. Tomorrow I'll comment on management-as-planning.

Our practices for creating the WBS get in the way of combining theories.

The transformation model is so pervasive in our experience and thinking that we don't see the world a different way. The approach is reductionist — break the project down into milestones, phases, activities, and tasks. The project management mechanism for defining and organizing plan items is the work breakdown structure (WBS). K&H argue that IPO theory misses two complementary theories: flow and value generation. Both theories have been around for quite some time, 1920s and 1930s, respectively. But in our machine-dominant world tbe IPO model pervades, missing the attention these other theories give to time and to what is of value for customers.

So where do we go from here? Some people contend that we can just put the three production theories together in our practice. In my experience, our practices for creating the WBS get in the way of this. Other approaches must be pursued. Some of the more promising approaches are business process mapping (workflow), story-boarding, and the scrum development approach of iterating.

In the meantime, perhaps there's a litmus test for defining or accepting plan items. Ask, "Would my customer be willing to pay for (see value in) what I plan to do?" If not, then adjust the plan.

| Convert this post to a PDF document.

Related Posts

Why the Interest in Project Management Theory?

Monday, October 28th, 2002

I'll start my comments on Koskela's and Howell's (K&H) paper The Underlying Theory of Project Management is Obsolete by addressing the interest in theory. Many of you may want something of more practical value. Although the engineers in the group may be quite comfortable with a discussion of theory. Why should we all be interested. Our interest is more than academic; it is quite practical.

We have been distracted by colleges and the PMI.

Let's start by considering that K&H might be right. If the theory in use is obsolete, then it would explain why we don't get the results we're after. Like 15th century navigators believing the world was flat or earlier astronomers who thought the sun revolved around the earth, there are anomalies of project performance that can't be explained. It is with the intent of explaining past behavior and predicting future behavior that we are interested in theory.

Readers of this weblog will note I often recommend adopting one behavior or another. I also criticize familiar behaviors as not effective. K&H's discussion of theory will allow you to participate in selecting practices for your project. Their paper also provides a jumping off point for developing a more encompassing theory.

We have been distracted by colleges and the PMI. We've been told if you want successful projects, then do those things recommended by the ANSI standard for project management. What is that standard? It is the PMI Body of Knowledge®, ANSI/PMI 99-001-2000. (Did you notice the designation of the registered trademark? Trying to refrain from cynical comments let me say might there be commercial interests involved?) We've been told to do more of what we've been doing. To get more people certified by PMI, to do a more comprehensive job of creating project schedules, and to always keep our CPM schedules up-to-date. It seems to me doing more of the same only benefits the status quo: the providers of software, training, and consulting. Yet we all know of projects where they are doing everything PMI recommends, and the project is still late, over budget, missing key functions, or all three. It is this anomaly that so interests K&H.

Let's all have a practical interest in theory so we can do a better job of selecting practices, so we have a basis for creating new practices, and so we can get the results we're after on our projects.

| Convert this post to a PDF document.

Related Posts

Koskela and Howell Argue for a Reform

Sunday, October 27th, 2002

Lauri Koskela and Greg Howell presented their original paper The Underlying Theory of Project Management is Obsolete at PMI's bi-annual Research Conference this past July. A number of people have asked me to comment on it. I'm struck by how persuasive Lauri and Greg are. It takes them just 12 pages to evaluate the anomalies and argue for a reform to project management. My postings for the coming week will attend to Lauri's and Greg's paper. Download your copy. Read ahead. And please join me in discussion with your comments and questions to each posting.

| Convert this post to a PDF document.

Related Posts

If I Only Had A Brain

Friday, October 25th, 2002

An ENR Summit attendee asked for my best advice for conducting planning sessions. The individual was looking for a standard agenda format. I surprised him by saying the quality of the planning is a function of the questions asked by the leaders present. I got the usual, "Huh?" I remembered the following Top Five list I use in coaching project leaders. I offered to send it to him. Only problem is I can't find the business card that goes with the promise! Oh well…I hope you're reading.




Top Five Behaviors for LPS™ Planning Sessions


  1. Inquire rather than advocate by asking, Why do you say that?
  2. Explore alternatives, How else could we do this?
  3. Build on proposals asking, How can we make it work?
  4. Anticipate risks and opportunities, What might go wrong?
  5. Encourage participation, Thank you for your contribution. Who has something else to offer?

© 2002 Lean Project Consulting, Inc.

What do you do with the above top five list? At your next project planning meeting shift your questions. Make it your goal to ask follow-up questions. Do it in the mood of curiosity not interrogation. Avoid answering your own questions or differing with the answers you get. See what happens. At the end of the session conduct a plus-delta review to get participants' views on what produced value for them and what could produce more value in the future. Focus on one or two of the items from your plus-delta review at the next planning meeting.

| Convert this post to a PDF document.

Related Posts

Project Controls and Work Sampling: A Potent Combination

Thursday, October 24th, 2002

Earlier notes on control were more conceptual. This one recounts how I became so suspicious of project controls. I became a consultant when I tried to sell Timelapse™ photographic equipment to contractors to analyze their construction operations. But they didn’t want equipment or to develop the ability to improve operations. They wanted someone to solve some specific problem. One of my first contracts was to help the project management team constructing a new coal fired power plant determine if the installation of the precipitator could be improved, and to figure out why data from two reporting systems was pointing in the opposite directions.

I arrived on site, introduced myself to the boilermakers, and climbed the chimney to record the operation. I watched it all day. The 6-man crew loaded 5 pipes into a skip and climbed the structure to where the skip was unloaded and the pipes installed. Then they climbed down and repeated the process. I knew after the first few cycles that they were spending less than 10% of their time installing pipes, and that another skip and small unloading platform would more than double performance. At 11:45, they left for a half hour lunch and came back at 12:45. This was all interesting and maybe useful. (Later I found the management really weren’t concerned about the precipitator installation process; rather they were sure the boiler makers were leaving early and getting back late.)

But the boilermakers weren’t the most interesting thing I saw. At first, I thought that prize would go to a group of laborers moving a stack of lumber, but by 2PM I was convinced it went to the work sampling program because I could always tell when a porta-potty was occupied.

Worksampling began 2 months earlier in response to declining productivity. Management was convinced workers were milking the job because they were lazy or dishonest. The rate of decline reflected in cost reports increased after the sampling began. Schedule slippage was growing too. Classic project controls showed things were getting worse, but reports from the sampling program showed workers were spending more time doing productive work. Workers were recorded as doing productive work if they were placing materials in their final position, and received half credit if they were moving materials. As a result, the laborers carried three of four pieces of lumber to the new stack and one on the way back. They had learned this improved the reports on their efforts. An occupied toilet was easy to spot because it had a short piece of pipe, lumber or rebar leaning next to the door. Everybody knew the reporting rules. Don’t go to the bathroom empty handed.

The exit interview was interesting. I showed the boilermakers were only doing "productive work" about 10% of the time, they took too long for lunch (one of them told me later, "You can’t get dinged for not working if you aren’t there."), and that a simple reorganization of work could double output. I wish I could say the project turned around because of this effort. They did drop the sampling program but they never could get past their belief that motivation was the problem. Not much happened to brag about. They never bought the photographic equipment – and even if they had, I doubt it would have made much difference.

| Convert this post to a PDF document.

Related Posts

Ford Gives River Rouge a Green Coat

Wednesday, October 23rd, 2002

Yesterday I mentioned the River Rouge project. Today the NYT published a great article on Ford's revitalization. Here it is Ford Gives River Rouge a Green Coat (Thanks Steve for the lead.)

| Convert this post to a PDF document.

Related Posts

  • ENR 2002 Construction Summit
  • I had the opportunity to participate on a panel discussion this morning at the annual ENR 2002 Construction Summit. Our...
     
  • Toyota Bests Ford in 2007
  • WSJ reported, "Ford and GM reported lower December sales, capping off annual declines of 12% and 6%, respectively. Toyot...
     
  • Do We Share A Common Language?
  • Magnificent projects are underway throughout the world. China is getting more of my attention these days. The Chinese ...
     
  • Model Project Managers
  • Model Project Managers, Dr. O.P. Kharbanda writing for Gantthead.com. Dr Kharbanda points to Mahatma Ghandi, Henry Ford...
     
  • Read Jim Womack if You Want to Avoid Ford’s Fate
  • "Ford needs to remake itself once more, this time in the image of the company that copied Ford’s original system: To...
     

Single Pie(ce) Flow Yields 125% Increased Productivity

Wednesday, October 23rd, 2002

Joe's Lean Diary

5,000 (well, 4,502) Apple Pies

Take a break to see what was learned in one fund-raising activity. Joe offers details and comments on his learning. He noted there was an 80-90% productivity improvement. Message to Joe…I thought you were a math major. I calculate a 125% productivity increase!

| Convert this post to a PDF document.

Related Posts

Is Management Possible?

Wednesday, October 23rd, 2002

I only wish I asked the question first! Instead, Thomas A. Stewart asked it writing for the last time in his fortnightly web column for Business 2.0 Is Management Possible? Thomas is one of the preeminent thinkers and writers on management and intellectual capital. While he points out the short-comings of the prevalent approaches to managing, he comes squarely down on the side of management is possible.

The publishers of the Harvard Business Review agree. Thomas Stewart joins them as the new editor. Congratulations Thomas! There's more good reading ahead.

| Convert this post to a PDF document.

Related Posts

ENR 2002 Construction Summit

Tuesday, October 22nd, 2002

I had the opportunity to participate on a panel discussion this morning at the annual ENR 2002 Construction Summit. Our panel topic was Beta Testing Construction Innovation. Harvey Bernstein, President, CERF (Civil Engineering Research Foundation) moderated the discussion. The six panelists mostly agreed…risk avoidance and consequent litigation, organization silos, and single-project client relationships are significant impediments to innovation. The highlight of the conference for me was an afternoon panel conversation on Ford's redevelopment of the legacy River Rouge factory complex.

River Rouge is where Henry Ford made the advancements in production, design, and labor that made the automobile possible for the general population. Bill Ford, current CEO, decided to redevlop the site following sustainable practices. Bill McDonough, perhaps the father of sustainable architecture and design, was on the panel with three other partners: Ford's facilities manager, the senior manager from the contractor, and a principal from the engineering firm. Also on the panel was a similar partnership for MedCath Health Care. The panel discussed Creating True Partnerships Among Owner/Designer/Contractor. Again there was agreement in the conversation. Here are their summary comments:

Audience Participant:
"How do you [flow] down the passion and responsibility we see in all of you to your staff members?"

Panelists:
"Give them the accountability to act on their own."
"Speak the vision [often]."
"Match company metrics and rewards to project goals."
"Talk to people daily [about their role on the project]."
"Leadership and enthusiasm are contagious."
"Help people understand they are building [something special], not just doing a job."

The conference finished with a presentation by the head of facilities development for China's 2008 Summer Olympics. (I'll post the URL to the presentation when it is available.) It was quite the day!

| Convert this post to a PDF document.

Related Posts

Somewhere Near Wilmington People Moved to the Center

Monday, October 21st, 2002

Riding the Acela Express from Boston to Washington DC this morning I wondered if I could explain my thoughts on the work of projects. (While the train is supposed to travel at 150 MPH, the tracks were under construction throughout much of Conn. The scenery was nice!) Yesterday I mentioned there are two kinds of action on projects. I've tried to simplify those actions to one word or concept for each. For the first I tried making or doing or manipulating, but none are general enough. So moving on I see the second type of action as conversation for coordinating action. But that isn't inclusive enough. The linguistic action of projects includes the assessments we make — evaluating how well we are doing; it includes the speculating and planning we do; it includes setting goals, assigning roles, establishing rules, and setting standards; it also includes the negotiating, approving, deciding, requesting, promising, and deciding. So you see the trouble I'm having?

We misunderstand value-adding work as transformative: input > process > output. This transformation model doesn't fit software programming, digging a hole, placing concrete, and making decisions. That is all legitimate work of projects. Capturing that works as making and manipulating miss the nature of the action on projects. The nature is not intrinsic; nothing has intrinsic value independent of some customer for the work. The nature of our work has as context the concerns and standards of our customers. Context and value is established in conversation. We don't dig a hole, write a procedure, or solve a problem independent of someone wanting it for furthering their own purposes. And, we don't take the action without promising to do so.

Somewhere near Wilmington it hit me. There are the conversations that shape and reshape a future eventually resulting in promises and then there's the work of fulfilling those promises. It takes people to speculate, to make judgements, to request, and to promise. The nature of projects is the human-ness.

Put people at the center& they make the promises and they fulfill them.

| Convert this post to a PDF document.

Related Posts

Running on Rails: Two Kinds of Action

Sunday, October 20th, 2002

I had the pleasure of visiting a construction site last week in Milwaukee. It is a good sized project — over $100 million — to add on to a hospital. The construction site was well-organized. People were quite busy and working cooperatively. The project is approaching the two-year mark — on time and on budget. How do they do that? They understand projects involve two kinds of action.

We generally understand the 'real work' of projects (value-adding) to be that which touches material or produces something. These people in Milwaukee understand an equally important work is linguistic action. What do I mean? All deliberate action between two or more people involves assessing, requesting, and promising.

Each week the 17+ trades foremen come together to plan with each other what they will have their crews do in the up-coming week. The meeting takes the same form from one week to the next. They start by reviewing the current week's planning performance. How much of what they said they would do did they get done? For every case that they didn't complete as promised they perform a five why analysis so they can investigate the source of the plan failure. They follow this conversation by reviewing the next six weeks of the plan looking particularly at those issues (constraints) that could keep them from performing as desired. People step-up to address the constraints to the plan making promises. Finally, the foremen say what they will do for the coming week. Negotiations occur to resolve where two crews may want to work in the same area at the same time (much like two programmers both wanting to check out code at the same time). They end the meeting with a new plan for the coming week based on the informed commitments of the people closest to the work.

I often hear people say meetings are a waste. The 'real work' happens outside of the meeting. But not with this group. They take these conversations — linguistic action — very seriously. And well they should. When asked how the project was going, the project superintendent replied, "It's running on rails."

| Convert this post to a PDF document.

Related Posts

How do project controls work?

Friday, October 18th, 2002

We all know the way they are supposed to work. It goes like this — A variance from standard is detected in the reports, the cause for variance determined by managers who take action. Or at least it is supposed to work this way. Can anyone give me an example where this has worked? I mean where the standard was accepted, the variance was recognized as genuine, the root cause was identified, and the action taken made a clear difference.

While we are waiting for the examples to roll in, consider Professor Clarkson Oglesby's observation that people mostly do what management thinks is important. When pressed, he said people knew what mattered by the questions management asked and where they spent money. Two questions come each week straight from management to the crew, "How much did you get done? How many hours did you spend?" In anticipation of next week's "question", people do what they can to make their answers look good. Pipe fitters call the work they do to increase recorded progress near the end of the month, "Show Pipe." The reports look good but real performance drops. The situation is made worse when people select work with the most favorable ratio between effort and credit received. Management turns up the volume as performance declines. They "ask" the questions more forcefully and fire those who can't find a good answer.

Installing show pipe or doing the easy work first ain’t dumb or being difficult. People are doing just what management asked. It is hard to call the results, "unintended consequences" when people respond this way. Let me say it plain — project controls pressurize short-term performance. The fact that the information in monthly reports is rarely used to make management decisions is mostly a good thing. Firing "poor performers" or adding more people rarely turns a troubled project around.

Project controls work in the sense of causing people to pursue local productivity because they regularly repeat the question that appears to most concern management — even when management really wants something else. The effect of these questions cannot be overcome by less frequent questions about something else.

What are we to do? Pay attention to how controls really work. Design cost and schedule reporting systems to cause the action you really want — optimization at the project level- and to provide the information you really need - information to support projections on this job and estimating on the next. Reduce reporting frequency and level of detail to support these objectives. Measure what matters starting with planning system performance. This will tell you how well you are coordinating action within and between crews. Ask about improvements in workflow reliability and the ability to make work ready. Ask the right questions often and in person.

| Convert this post to a PDF document.

Related Posts

Produce Alignment and Trust in the Stories You Tell

Wednesday, October 16th, 2002

One last comment (for now) on story-telling…There is a 'richness' that comes from the diversity of project participants. That richness can be realized, or go unrealized. One key action for project managers is to produce alignment among the diverse participants to have them work in concert with one another. Alignment is produced in our story-telling.

Patrick Lencioni distinguished five dysfunctions of teams. The foundational dysfunction is the absence of trust. There is only one way to build trust; you must talk about trust to build trust. When people trust each other, they cooperate, collaborate, innovate, and learn. When they distrust they argue, shield, preserve, and despair.

Hands-off project management doesn't work. Avoidance of conflict doesn't work. Detached objectivity is an illusion. Projects succeed when project leaders engage enthusiastically with their team, shaping the conversation about who they are and what they are up to. In so doing, the project manager produces the foundation of trust that makes all else possible.

| Convert this post to a PDF document.

Related Posts

Story-Telling Reforms the Project

Tuesday, October 15th, 2002

I've made a number of references to story-telling as necessary on projects. Yesterday, I spoke of the importance of story-telling to producing alignment. Today, I have another twist to offer. As author Dr. Matthew Budd puts it in the title of his book, You Are What You Say. Dr. Budd wrote about health, well-being, and living a life. Little did he know (or did he?) that he was writing a guide for project leaders.

How is his message pertinent to project leaders? Each of us walks around in an everyday-always conversation about ourselves in our world. We talk to ourselves. We say all kinds of things — mostly assessments, some positive, many not so positive. We find ourselves saying, "I can do that. I'm good at those things." Or, "That will never work. Those things never do."

Projects are challenging. Projects are uncertain. People add to the challenge and the uncertainty with their own private unspoken conversations about themselves and each other. Story-telling is the project leader's opportunity for intervening in the already present mixture of stories on the team. Through story-telling the team begins to acquire a new perspective about themselves and each other. Instead of "This or that won't work" team members see what can be done and where they can take action.

I am not promoting happy talk. Nor am I suggesting a kind of pop-psychology. Try this out: catch yourself in your private story about you and your project. Then inquire what others are thinking about themselves in the same situation. You are bound to find a mismatch, often one that will get in the way of the two of you pulling together.

John Udell proposed in Telling A Story that there is a place on projects at the "intersection of the messaging and publishing mediums" for the story-teller. He suggests that the story-teller keeps the team together and focussed on the promises of the project.

What is there to tell? Tell the stories of ambition, achievement, satisfaction, worthwhileness, and determination. Tell the stories of cooperation, collaboration, learning, and resilience. Tell the stories that unite, bond, and build trust. Tell the stories that dispel, focus, invite, and encourage. Tell the up-coming story of accomplishment. Just tell stories. It is the one avenue available everyday for reshaping the collection of individual realities into a collective reality.

| Convert this post to a PDF document.

Related Posts

When Good Strategies Fail in Implementation

Monday, October 14th, 2002

I've been working my way through Mary and Tom Poppendiek's book Lean Development: A Toolkit for Software Development Managers. Chapter Five: Alignment Tools is a very good survey and synthesis of some of the best thinking on how to get projects done. The chapter is well-written and engaging. This primer provides good guidance whether you're doing software development, hardware engineering, or carpentry.

Mary and Tom expose one of the major struggles for organizations. Good strategies fail in implementation. Why? The chapter title says it all — alignment. Organizations fail to produce it. Mary and Tom propose three tools for getting your team going in the same direction and then keeping them going: professionalism, passion, and signalling and commitment. As is usual throughout the book the authors do a good job sharing their references behind each of their claims.

I see managers speak about issues of alignment once thinking that if something has been said then it is so. Align is a verb. It is an action that must be taken throughout the course of the work of teams and projects. I'll add a twist to Mary and Tom's proposal. Leaders and team members use stories to elicit profesionalism, to evoke passion, and as context for coordination. Good strategies fail in implementation when the practice of story-telling is missing.