There's been quite the discussion of Koskela's and Howell's papers in the NewGrange listserv group. Unfortunately, there's no archive of the discussion that you can read. I'll just say that people have very strong opinions about the value (or lack) of the K&H papers. The participants of the discussion group are experienced, well-versed, project professionals. One member is the leading author of the PMBoK®. After four days of debate, argument, sniping, and not listening to one another (IMO), I couldn't stay on the sidelines any longer. The following is my letter to the group. (Sorry for the length.)

Email to NewGrange. Subj: Re: Lean Construction and Traditional PM

I don't know where to start…so how 'bout I jus' offer a "stream of unconsciousness" (as one participant characterized my blogging) without the [snips] (references to specific postings).

I can echo many arguments on both (all) sides. I learned in Engineering Economics that one can justify many investments against a poor current case. Business is in a project age as Claude Emond puts it, yet our company systems, our formal education, and our vernacular all harken to days of the industrial revolution.

The usual case in companies I see is projects that are poorly initiated…unclear objectives, no one acting as a customer, late to staff, competing demands for team members, and piss-poor project leadership. The project uses some form of project software (MS Project or P3) operated by a computer jockey often detached from the team. We inappropriately characterize this situation as "traditional PM". It is bad management. Period.

Having said that, there are plenty of examples of well-managed companies, who take care initiating projects, providing appropriate staffing, and competent leadership who are dissatisfied with the results they get with other than agile approaches. (I don't want to get shot for calling it "traditional".) You may all be surprised to learn that the leading companies using the Last Planner were already leading companies in their markets. When asked why did they try something so different from the status quo they'll tell you their customers were dissatisfied with the waste; their investors were dissatisfied with the risks and returns; employees were burning out; and along the way people died building buildings.

[pause while I confront that reality again]

Even the well-managed firms deliver projects late, over budget, missing some key aspect of customer satisfaction, and the employees get hurt. We've been facing this for decades, centuries, millenniums. The broad population in the industry is resigned about those conditions. Did you know that construction represents 10% of the industrial workforce and 40% of the industrial accidents? Can you guess what percentage of those accidents are preventable? OSHA will tell you over 80%.

[let's pause again]

I won't go into the history of lean construction nor the more generalized lean project delivery. Suffice it to say it has its roots in the Toyota Production System which traces its roots to Henry Ford. Let me just say that the leading companies practicing a lean approach to project delivery were already getting their projects done on time. Not always on budget, but on time. They were already the safe companies enjoying experience modifier rates 30% or more better than the average. These firms are now delivering one project after the other on time or early AND at or below budget AND safer than ever before. The largest Danish contractor has been keeping records. They've found comparing 500,000 hours reported on lean projects with 500,000 hours reported on projects doing it the conventional way they are getting their projects done earlier (one to two months), cheaper (anywhere from 10% to 20%) and much safer (over 60% fewer lost time accidents). All of this is related.

I won't try to present the explanation in this five-minute email. Koskela and Howell spent considerable time writing their papers and still they have trouble explaining. Suffice it to say something very different is going on when projects are delivered in a lean fashion. Might complex adaptive systems offer an explanation? Yes, but still incomplete. Might lean thinking principles show the phenomena? Only partially. Linguistic action? That, too. CCPM? I wish. Here's my hunch…yes, it's a hunch, or maybe just an inkling…our deterministic reductionist approach to projects is the limiting condition. New theory must embrace both the uncertainty that is the project milieu and the unpredictable, serendipitous, richness of the human condition when interacting one with the other.

Call me an optimist. New theory will lead us to easier, more rewarding projects in the project age.

Project (Portfolio) Management…Like Herding Cats? by Glen B. Alleman. Glen is a regular contributor to PM World Today writing on Information Technology projects. Check out his other articles when you visit this one.

While many of us project managers struggle with our own project, firms often need to manage collections of projects. Glen has been writing about how to think about and organize an approach that can be successful.

Glen writes, "Before projects can be ready for (project) portfolio management (PPM) they must possess certain attributes."

• The clear start and end date — what is the drop-dead date?
• A definition of "done" — what needs to be in for this project "earn its keep?"
• A business case — on what day does this project breakeven?
• A priority ranking — what projects are more or less important than this one?

"These attributes seem "obvious" at first glance, but it is breathtaking how many projects don't posses these simple attributes."

The Foundation of Portfolio Management

Glen says PPM depends on four concurrent processes.

• A Balanced Scorecard strategy to define priorities and establish a connection between every project and a specific strategy and objective.
• A public registry of projects, resources, and deliverables housed in Microsoft Project 2002 Server.
• An Earned Value performance reporting and measurement processes to make visible performance metrics for cost and schedule.
• A process to select, classify, measure, and guide the implementation for collections of IT projects.

"(W)ithout a business context and a strategic goal, the project manager is simply a cog in the administrative wheels of the firm."

Stick with this guy. He's thoughtful, practical, and working at the edge of emerging theory and practice.

Today I complete my comments of the paper The Theory of Project Management: Explanation of Novel Methods
by Lauri Koskela and Greg Howell. The authors are careful to use the phrase underlying theory to denote that project management theory is not explicit. The authors make their inferences of theory from the practices and behaviors of prescribed project management.

Making inferences is tricky business. We can never be sure that what we say is right or wrong. So, we make our case. Later, all we can do is assess the relative usefulness of the inferences when we set out to act in accordance with them.

K&H use the word obsolete as their summary characterization of the effectiveness of current theory in use.

Obsolete: Outmoded in design, style, or construction. Superseded.

To call underlying theory obsolete is only to say that there is indication that it falls short in producing what is desired and something better is available. K&H are out to uncover better theory.

The authors place high value on theory. Not higher than being effective in action…explicit theory provides the opportunity for examination, measurement, learning, innovation, and resulting effectiveness of action. Like many others, the authors have been dissatisfied with the results of projects conducted along the lines of traditional or conventional practice.

>Their investigation of theory took them to the PMI PMBoK® as the obvious repository of theory. Reading their first paper I see their disappointment in the absence of explicit theory in the PMBoK® for guiding practice.

I know the authors. They would like nothing more than to engage in serious inquiry with project management theorists. So I Googled 'project management theorist' to see what I'd find. Max Wideman came out at the top of the list. Coincidentally, K&H have recently engaged in conversations with Max. Perhaps we'll see Max write about those dialogs. Max too calls for a need for explicit theory in a series of papers on First Principles. Redo the Google search to investigate others.

The authors chose an unfortunate point to break their text to insert Table 2: The underlying theories and assumptions of project management. Without carefully reading one might be left with the impression the contents of the table are the intended evidence to support their claims. In fact, the authors only name their sources of evidence without offering it in this paper. Those sources are:

1. the plausibility and consistency of the theory in itself;
2. empirical validity;
3. competing theories; and
4. alternative methods based on competing theories

The authors never claim their inferences of theory and assumptions represent evidence.

Why write about all this? Some say it's just pickin' a fight. I say why not write about it? Projects routinely take too long, cost too much, and fail in often significant ways to satisfy the customer. Scrum is one response to that dissatisfaction. Lean project delivery using Last Planner® is another response. Both approaches are producing good results. So…what's the fuss? Let new theory emerge.

Scrum has emerged as one of the leading approaches for delivering software projects on time, on budget, and performing as intended. It is one of a class of methods known as agile development. Koskela and Howell (K&H) take a look at Scrum as an example of a project delivery approach that strays from convention conforming instead to 'new' theory, The Theory of Project Management: Explanation of Novel Methods.

First, I'm no scrum master. I'll do my best with this, but PLEASE correct me in a comment or by email if I've misunderstood.

Scrum

Scrum is a dynamic integrated planning and execution process for delivering software projects. Teams work in highly collaborative ways. They shun the usual practice of detailed up-front requirements analysis and specification writing. Instead, the scrum approach works in one-month intervals — sprints — to deliver a working feature set. One sprint is followed by another until the completed system is delivered.

Tasks are derived and offered up by the performer of the task in daily scrum meetings. The teams' heightened level of communication and coordination more than compensate for the traditional detailed planning and structured work break-down structures.

Theory of the Project

K&H explain the theory of the project operating with this approach as principally flow and value generation. The teams' attention is on producing and delivering what they understand is of value to the customer. Any more than that is not value, particularly when additional features get in the way of completing a feature set that can be put into use. The Scrum approach keeps the team focussed on just one project avoiding multi-tasking and the consequent delays and remobilizations.

Theory of Management

The Scrum approach relies extensively on managing as organizing to set the conditions for the team to conduct themselves while system requirements evolve and they manage development. Effective execution relies on the competence of team members to conduct coordination conversations — language/action perspective. Control is accomplished through continued adjustments learning from one task completion after another. K&H call this the scientific experimentation model.

Comments

Scrum evolved in response to a dissatisfaction with project delays, budget busts, and buggy bloated software. K&H ascribe theory to make sense of how Scrum has been successful. Tomorrow I will offer some summary comments on their paper.

Read more about the agile approach at The Agile Alliance and the Agile Manifesto.

The Theory of Project Management: Explanation to Novel Methods

After reviewing their argument for calling the underlying theory of project management obsolete, Koskela and Howell introduce a proposal for a new basis. In this paper they propose to additions to current theory rather than replacements to it. (Those additions are identified in bold text in the following table.)

Koskela and Howell are careful with their comments on new theory.

It is clear that what has been presented does not yet provide a unified and complete theoretical foundation for project management. However, this foundation shows manifestly that a better theoretical foundation can be created for project management.
Future research will extend and unify the ingredients found until now.

Tomorrow I will explore how the authors say the Last Planner System™ conforms to the evolving theory. The following day I will examine Scrum. Finally, I will offer summary comments on the paper.

Lauri Koskela and Greg Howell expound on Scrum and Last Planner™ as "practical responses to the failure of conventional project management methods" in their paper The Theory of Project Management: Explanation to Novel Methods. The authors published this paper as a follow-on to their paper The Underlying Theory of Project Management is Obsolete.

In the next few days I will explore the authors' paper. In the meantime, get yourself a copy, read ahead, and get ready to offer your comments.

The Theory of Constraints folks will tell you that multitasking leads to project delay, rework, and higher costs. Read Frank Patrick's Top 10 Sources of Project Failure. (Number ten has three good references on multi-tasking.) Now there's a report that the consequences are worse. Writing for the Wall Street Journal, Sue Shellenbarger warns,
Multitasking makes you stupid, studies say. Enjoy.

Read Frank Patrick's posting today on the same subject!

Projects are performed in a setting of uncertainty. To that we add dependence (linked tasks) and variation (uncertain task completions and task releases). The result is a crap shoot. Who's to know when a project will complete? Awhile back I raved about the book Embracing Uncertainty: The Essence of Leadership, by Philip Clampitt and Robert DeKoch. The book is really a winner. There are other texts by the same authors and they're free! Embracing Uncertainty: The Executive's Challenge, by Philip Clampitt, Robert DeKoch, and Dee Williams, June 2001, lays out the basic premise of their book on leadership.

The authors' work is based on research, experience managing operations, and consulting. They claim our predictive deterministic approach produces a false confidence that inevitably produces anxiety and results in missed objectives. Instead, they say embrace uncertainty. They describe three classes of actions for engaging with teams.

Cultivating an Awareness of Uncertainty:

1. Occasionally "shake the platform."
2. Challenge existing heuristics or rules-of-thumb.
3. Orient organizational identity around core competencies not particular products.
4. or services.
5. Monitor the internal and external environment.

Awareness is a first step. When we are attuned to the uncertainty of the situation we are in a position to take action.

Communicating about the Uncertainty:

1. De-emphasize formal presentations.
2. Modify organizational language.
3. Discuss contingencies.
4. Ask penetrating questions.
5. Focus the internal communication system on thinking routines and speed.

The key here is to change the everyday dialogue on the team. Aim for a shift from "I know what is going on" to "I wonder what we will encounter?"

Practices for Catalyzing Action:

1. Hire the right people.
2. Look for the deeper pattern.
3. Experiment.
4. Use technology as a lever.
5. Decide at the last possible moment.
6. Play the odds.

And while you're at it, avoid practices that add to the variability on your project. Only release work that is ready to be finished. Manage from the bottoms-up by encouraging team members to promise their tasks reliably. Learn from your plan successes and failures.

If you liked the above article, then check out the complementary paper by Clampitt and Williams Managing Organizational Uncertainty: Conceptualization and Measurement. It offers more supporting details on their research.

Want to read more on the subject? Take a look at this posting on Managing Project Uncertainty and the related paper published in the MIT Sloan Management Review.

Building a project Web site the easy way by William T. Kelly. Covers all the basics. Encourages the use of standard templates from MS FrontPage and Macromedia Contribute.

Kelly offers these three reasons to create a project website:

• A central user interface connects project team members to such project information as the requirements and design documents, functional specifications, and other documentation. The site provides a repository that is available to all team members.
• It provides centralized scheduling information.
• A library of project information is available for ready inspection/review by senior management and other selected stakeholders.

The author misses one of the most important issues. Teams tend to drift off of purpose. A project website is a place for maintaining the "story" of the project.

The author makes no mention of daily status weblogs or project weblogs. What could be easier than a weblog? See my posting and the P-Log specification.

Team dysfunction is a serious concern for project leaders. Scott Robinson writing Learning to play well together: Negotiating personality conflicts, one of fifteen articles he published in the last three weeks, sets out to address what team leaders can do.

Robinson suggests an indirect approach for dealing with personality conflicts among team members. While he identifies the consequences of those conflicts to the team and the firm, he fails to prescribe actions for eliminating the conflict. Instead he recommends:

• Create a programming trio
  Introduce a senior third party to subtly raise the standard of behavior.
• Try multimodal communication
  Resort to email and IM to keep them separate but still communicating.
• Go public
  Use good natured ribbing to call attention to the behavior.
• Read 'em the Riot Act
  Last resort. Don't be afraid to use bold and italics.

AARGH! These aren't the actions of leaders.

Robinson should stick to what he knows — XML, Java, data handling, etc. Readers sounded off with dissenting views. Scott, take a lesson from Patrick Lencioni in his book The Five Dysfunctions of Teams. You don't have personality conflicts; you have dysfunctional behavior.

One of the roles of the leader is to declare acceptable standards of behavior for the team. When team or individual behavior is inconsistent with the declared standards then the standards are clarified and the individuals instructed to adjust behavior. Continued poor behavior would be grounds for removing the individual from the team. This in not about negotiation. This is not about personality. It is only about behavior.

A few readers asked me to comment further on my postings about Construction Summit 2003. Mostly I was not clear about my views.

In the Day One postings I wrote,

The presenters were unusually supportive of web-based solutions. While talking extensively of shared data they neglected to speak about how the data would be used or the day-to-day practical issues of project coordination and bottoms-up planning.

In later conversations with presenters and other session participants people argued first you have to collect the data (as much as possible) then you modify your processes based on it. Baloney! Let's get practical if we are to invest scarce capital in purchasing systems and implementation.

Bottom-line, the daily value-adding work of projects is coordinating with one another. It's not record-keeping; it's not report writing; and it's not reporting on budget variances. Well-designed systems of all types are built around the central value-producing actions. (Take a look at the new web-based CRM applications to see.) Project systems must be based on coordinating action with one another for the successful release of work to another.

The other issue is planning, or better said, on-going planning among the people who perform the work (bottoms-up). Regular bottoms-up planning isn't just an alternative to up-front detailed scheduling, it is the approach that best matches the nature of project situations. Projects are uncertain by nature. The participants in projects learn, discover, collaborate, and innovate as they engage with each other on the project. Project systems can help or hinder that, hence the preponderance of offerings of project collaboration tools. However, those tools miss the principal aspect that re-planning is the best practice.

In the posting Project Firms Need Radical Change I wrote,

Leaders look for ways to guide (steer) their businesses…The recommendations don't have steering qualities. Mark Zweig is saying manage the business from the bottom up. When he said radical change he meant it. He just didn't share what was behind his prescriptions.

There were no steering mechanisms for Mark Zweig to offer. I suggested that executives look for points of leverage, e.g., trim tabs. Mark was suggesting firms adopt practices that are far more distributed and beyond one person's control. While Mark never used the words "emergence" or "complex adaptive systems", he is surely in the camp of people who believe in the power of an informed, competent, highly distributed, and aligned organization acting on its own…because it's that way anyway.

The balance of the summit was out of sync with Mark Zweig's call for radical change and the panel discussion of the merits and practices of a lean approach to project delivery. There's no reason to expect otherwise. We live in a world that is successful based on the strength of our science and engineering. That world is basically reductionist and deterministic. We extend that thinking inappropriately to people and projects. And then we wonder why our results are unsatisfactory. On with the reform.

People have written me in the last two weeks asking about my comments on Lauri Koskela's and Greg Howell's paper The Underlying Theory of Project Management is Obsolete. This is the paper they wrote and presented at the PMI 2002 Research Conference. Back in October I made a series of postings on the subject. I compiled those postings into a paper Notes on The Underlying Theory of Project Management is Obsolete.

People have also wondered do I say the PMI is obsolete? Absolutely not! The organization continues to attract project management practitioners for the educational opportunities and the professional affiliation.

Enjoy the paper. I made a PDF file for you as well.

I've been thinking about Mark Zweig's ZweigWhite presentation at Construction Summit 2003 that I called platitudes in an earlier posting. First the definition of platitude from Merriam Webster Online

1. the quality or state of being dull or insipid
2. a banal, trite, or stale remark

I mis spoke. The recommendations made were quite good (IMO). However, when I did a small poll of participants, they listened to the recommendations as platitudes. When asked, they all said they would not be taking action. I'm now wondering…why?

Here are some highlights from the presentation:

• There's a crisis in confidence in the industry characterized by flat revenues and reduced profits.
• Money is cheap; more industry consolidation is coming; more firms are for sale & there are fewer buyers.
• Unbridled growth will not continue.

Radical changes are required in

1. how you do business planning & the importance placed on it
• All employees must have input & access
• Plan is broad & philosophical AND practical & implementable
• No bullsh*t — simple is better
2. information tracked & how it's shared
• More is not better
• Information geared to heading off problems
• Continuous trend analysis
3. how you market & sell
• It's all about market sectors
• Build your brand
• Teach everyone in the business to close business
4. compensating & connecting people to the enterprise
• Widespread ownership (numerous firms present were employee-owned)
• Everyone connected to company profits
• Less segregation; less perks
5. information technology
• All investment decisions can't be cost-justified
• It's all about communication
• Make it easy to support people
6. leadership & management
• Give up on the notion of the infallibility of leaders; false idols
• Vision must be articulated by leaders
• Show confidence in the firm

(Remember this is advice to the architectural, engineering, and construction industry.)

So let's say there's something for everyone on the list. Let's also say that the people in the room were at the top tier of their firms. They are in a position to take action. And like me, participants were taking good notes. What gets in the way of taking action?

Is it resignation? Is there just already so much that needs their attention that they can't see their way to initiating one (or two) more actions? Or might it be confidence? Perhaps the actions they've taken in the past have not been well-received.

I don't think it's any of that. Consider this…there's so much inertia in the market, in the industry, and in the company that the maybe above actions don't appear to make a difference. Leaders look for ways to guide (steer) their businesses. Maybe that's the real issue. Read the recommendations again. The recommendations don't have steering qualities.

Mark Zweig is saying manage the business from the bottom up. When he said radical change he meant it. He just didn't share what was behind his prescriptions.

The Construction Summit finished like it started. There was a hodge-podge of presentations. The one that kept my attention was on architectural engineering quality assurance. The presenter was from Skidmore, Owings, and Merrill, SOM. (Skip the website; it is an annoying flash animation that is very difficult to navigate). The approach recommended harkens of the days of old fashioned after-the-fact quality control. Once the drawings or specifications have been completed then a group of experts check the work. I used to think that some QA was better than none, but no longer. Architectural engineering can learn from the agile software community. Pair programming could be a very useful model for pair engineering and pair architecture. It's bound to improve the quality of the work.

The construction summit opened with the first of two presentations on the Dig Big . Dan McNichol, author of The Big Dig, facilitated the presentation with Dan Wood, Federal Highway Adminsitration. While the project is notorious for cost overruns, it will become known for its technical achievements, community responsiveness, and partnership among project participants.

Take note of this bigger than big project:

• Adjusted for inflation the Big Dig is 30 times the cost of the Hoover Dam.
• Twice the cost of the Panama Canal
• At the peak of construction for 3 1/2 years 5,000 workers spending $3.5 million/day.
• Funded from over 15 sources involving over 200 contractors

What more can we say. Take a look at the book. It is as beautiful as it is informing.

Lean Construction — Challenging Current Project Management

As moderator it's difficult for me to say how well the panel came off. I can say the panelists did a wonderful job of answering my questions and those from the audience. They offered these lessons:

• Like any organization, initiative needs support. Perhaps it takes keeping the torch on the fuse, or maybe just remember it's difficult starting a grass fire after a rain.
• Be clear for the sake of what you are pursuing a lean approach. What are the issues that will make you more competitive?
• Support people while they are learning.
• Top management must be enrolled. Don't do anything else before getting their enrollment.
• Place value on your time as professionals. It allows you to assess progress you make delivering value on your projects.
• Keep the emphasis on the conversation of planning rather than the tools or artifacts of planning, e.g. schedules.

Let's see what happens. Will interest and good advice result in new users of lean approaches, or did we just entertain?

There were two other presentations. Tod Rittenhouse, Weidinger Associates, briefed us on how buildings are being designed to withstand the threats of terror. Great presentation by one of the leaders in the field.

The final presentation was by Mark Zweig an authority on construction industry management practices. While he exhorted us with platitudes of good corporate management practices, I can't say he was wrong. In short, he advised to take care of your customers, take care of your employees, invest in systems to separate you from your competitors, and share information throughout your organization. Good advice, except people are likely to walk away without taking action. That is a shame.

More tomorrow!

Construction Summit 2003 has begun. It's been raining here in Jacksonville, FL. (Read: no golf…yet.)

The program today was dominated by four sessions on using the internet for managing construction projects. The presentations were basic. Here's the presenters' best advice:

• Use COTS (commercial off-the-self) applications. Construction firms are not software developers. Let the experts do what they do best.
• Implement systems with an eye towards the specialty contractors. They represent 1/2 of all the players yet only 25% of them use email regularly in their business.
• This industry is driven by risk. The usual practice is risk shifting rather than risk sharing.
• Implement systems for business results. Digital technology will lead to reductions in cycle time and costs. Sharing data is the principal source of these improvements.

The presenters were unusually supportive of web-based solutions. While talking extensively of shared data they neglected to speak about how the data would be used or the day-to-day practical issues of project coordination and bottoms-up planning.

Monday's agenda is more exciting: two presentations on the Big Dig, designing terror-resistant structures, and lean construction. Stay tuned.

Chris Tulino offers this cheeky view on project managers:

Every project manager I know is looking for a "good" project. A project that is not a nightmare, where success can happen. This is similar to the hopeless romantics looking for true love. It's not that it doesn't exist. It's just not practical to spend time looking for it. If you get lucky, you get lucky. But for the most part, you just buckle down and do the best you can with every situation that arises. If you work at it hard enough, in six months, this project could become a great project. But you can't just will it to be great and you won't just find it out there somewhere.

Chris hasn't posted for awhile, but when he does it shouldn't be missed. He's got a great twist on a Yankee Swap he calls Cut-Throat Pollyanna. I'm already looking forward to next Christmas!