 Reforming Project Management |
||
|
|
||
|
Thursday, March 20, 2003
Multitasking Our Way to Stupidity
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! Wednesday, March 19, 2003
Embracing Uncertainty Again
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:
Communicating about the Uncertainty:
Practices for Catalyzing Action:
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. Tuesday, March 18, 2003
Building a Project Website the Easy Way
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:
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. Project Leaders are Responsible when Teams are Dysfunctional
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:
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. Monday, March 17, 2003
Construction Summit 2003 -- Readers Questioned
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. Visit the Archives for more postings |
 Reference Papers
|
|
| ||
