 Reforming Project Management |
||
|
|
||
|
Saturday, November 15, 2003
Grid Blogging the "Brand", December 1, 2003
Being Saturday, I thought I'd offer something different. As regular readers of weblogs know bloggers link to other bloggers. It makes the experience of reading a blog so interesting. When I visit a blog I do so wondering "where will I go today?" Blogs like mine have a topical focus. You can read all sorts of things about project management, but you won't be reading about Brittany. (It is possible to escape the pop culture.) Most links on my pages will take you to other useful perspectives having some relationship (in my mind, anyway) to the topic of reforming PM. The linking of all these postings through time presents an evolving consciousness and body of knowledge. Hold onto your chairs. You are about to witness an explosion in both the connectedness and production or presentation of knowledge. How? Through grid blogging. Instead of a few of us blogging on the same topics from one week to the next, Ashley Benigno has proposed that a whole bunch of us blog on a single topic for a day. That first topic is the "brand".
While we don't know what to expect or how many people will get involved, there are some models for this behavior. On these pages and in their respective weblogs, Frank, Joe, and I blogged on the Theory of Constraints for a week in Down 'n Dirty with the Theory of Constraints. Like this proposed effort we knew a week or so in advance what we would do. We also shared our postings with each other before we posted so we would do a good job introducing the topic. Not only did the three of us learn, but we had very high readership for the week and shortly thereafter. Something similar happens each year on World AIDS Day where bloggers post their thoughts. See www.linkandthink.org. I am so excited about this. While the topic of the "brand" is interesting to me, what I'm more interested in is the possibility of extending what we know and can do by being focused like this. It should be great for those writing as well as those just reading. Mark your calendar: Grid Blogging the "Brand" on December 1, 2003. I'll be joining in. How about you? Friday, November 14, 2003
How Do Scrum and CCPM Compare?
This posting came from Clarke Ching, Scotland, writing in the TOC Experts Yahoo! Group on November 10. Clarke is a regular reader of this blog and the contributor of Project e-Tip 009: Eliminate Multi-Tasking to Speed Project Completion. Clarke is a smart guy who writes well. He graciously allowed me to reprint his posting. Thanks Clarke. [Look for my comments throughout the text.] A reader asked the group how Scrum compares with Critical Chain Project Management (CCPM). Here's Clarke's reply. Scrum is one of several Agile/Lean Software Development techniques. The opposite of Scrum/Agile/Lean is the waterfall development lifecycle where analysis, design, development, system testing, and user acceptance testing are done in sequential phases. Scrum/Agile/Lean works in short iterations - between 1 and 12 weeks each. The core conflict for software development projects (and most others I imagine) looks like this.[This is a fine example of Goldratt's Evaporating Cloud]
D - Allow change throughout project
B - Build functionality required by customer
A - Have a successful software project
C - Deliver on time and to budget
D'- Agree scope up-front and don't allow change throughout project
Or this see this graphic provided by Clarke. [Read the above chart this way: I want (A) a successful software project. To be successful I need (B) to build the functionality required by my customer. And I need (C) to deliver on time and on budget. For me to build the functionality required by my customer I need (D) to allow for change throughout the project. However, for me to deliver on time and budget I need (D') to agree to the scope up-front and not allow changes throughout the project. (D) and (D') are in conflict and cannot coexist.] In a traditional/waterfall environment "change control" is the mechanism used to do both D and D' poorly. The agile approaches attack three assumptions:
[Clarke examines three cause and effect assumptions behind the evaporating cloud as it was described. He sets out to invalidate each one.] The key points of Scrum are:
[Those of you who use the Last Planner System™ will recognize similarities with Scrum. The backlog of tasks grows, as does a weekly work plan, as the project goes along. Project performers take tasks from the backlog making promises to complete them. The Scrum approach is done or not done. No credit for effort. And very much like lean, people understand their projects as complex and evolving.] How does Scrum differ from Critical chain?
Despite these differences I believe that CC and Scrum are not only complimentary but synergy should be gained by using both together. That said, I don’t know of anyone doing this. Scrum is mostly used in IT along with changed engineering practices, but it has been used in non-IT projects. [Good concise comparison.] Write Clarke at clarke@chingz.com. Thursday, November 13, 2003
A Guru's Approach to Project Management
Project management could use more qualified gurus, if for no other reason but to solidify PM ideas and theories. That was the opening line of Bob Weinstein's latest Gantthead article, A Guru's Approach to Project Management. Let's here it for Bob Weinstein and Gantthead. Woohoo! Weinstein is a regular columnist for Gantthead as well as an author of a dozen books. This article is a gem. Print or save a copy. Weinstein interviewed two people he designates as gurus. Dave Schrader is the director of strategy and marketing at Teradata. Bob Sutton is the author of the well-known book Weird Ideas that Work. He calls them both "the real deal." So what does he mean by guru? Gurus are justifiably praised for their unconventional view of the world. They have the unique capacity of taking theory and applying it, a skill possessed by a select few. Here's a short summary of the two gurus' take on project management. Read the article for the rest. Dave Schrader's seven guidelines for good project management
Bob Sutton: The Process Paradox, Too little or too much process is dysfunctional.Start out pretending there is a process, yet avoid falling into the trap of thinking that's all there is. Myopic thinking leads to failure. Don't let the process become an end in itself or a formula. Think of it as an initial roadmap that will have to be changed as problems surface. The people who are really good accept this fact of life. They understand project management is never as linear as it seems. Wish I had said it. Gantthead is becoming a powerful voice independent of the PM professional forums. They take a practical view of the world while still being provocative. This article is just one of many examples of what Gantthead has to offer anyone managing projects. Wednesday, November 12, 2003
Try the Search Facility on Reforming Project Management
I am really embarrassed. Over a year ago I added the Atomz search tool to my weblog and website. I've tried it a couple of times and was disappointed I couldn't find what I had written. Today I decided to dig in. I found I was not including my own weblog in the target for the searches. Aargh! I apologize to all of you using the search tool. Just one more example of there's too much to know. Try it. You'll find the search tool in the left-hand column part way down the page and on the archives page. Project e-Tip of the Week
Today's Project e-Tip comes from Glen Alleman. Glen is quite a good thinker and writer taking on tough subjects and making sense for others. His book reviews are among the most complete I've read. When Glen offers his opinion he also shares how he has come to that opinion. I learn from his writing. I'm sure you will to. Here's his tip:
Take a look at more of Glen's thinking. He writes a monthly column for PM Forum titled IT PM: Herding Cats (complete listing of his columns). His latest piece was published yesterday, The DIPP Formula Project Control Flag, An Assessment of the DIPP Indicator. Glen selected The Portable Coach from my bookshelf as his gift for having his Project e-Tip published. There's more where that came from. Share your wisdom with readers. Tuesday, November 11, 2003
Trust Is Crucial in Project Coordination
This article was written by Michael Sheerin, P.E., Healthcare Division Director TLC Engineering for Architecture, Orlando, Trust Is Crucial in Project Coordination. Sheerin opens his article this way: The key ingredient of any successful project is trust: the owner must trust the building team to envision and create the owner's goals; designers must trust the contractor's ability to work within the framework of construction documents to build a living environment; the contractor must trust that the design team has developed a plan comprehensive enough to get them all out of the jungle without too many snake bites. Great start, unfortunately, there is no more. He has the right idea, but doesn't offer insight into how to do it. Certainly, the best method for keeping on track throughout the course of a project is communication — the unambiguous, respectful, formal kind as well as the inquiring, personable, informal kind. He goes on to speak about compromise in the coordination of design documents: ...every coordinating agent should seek to balance the competing interests of all of the design and construction team members to achieve ownership — and acceptance — of sometimes difficult decisions. He shows his cynical side here: (A) contractor may take some satisfaction in button-holing a designer for some area of flawed thinking. In the face of concrete dimensional data, designers must drop their egos at the door. Aargh! I can't go on. Right title...no understanding of trust. Trust is nurtured and preserved on teams. It starts as compound assessments of each other's competence, reliability, care for the other, and sincerity. Once we spend enough time with each other, trust can be elevated to a central component of a relationship. The problem on projects in the AEC world is we start out as strangers and too often end the project that way. [Strangers, Friends, and Partners] Yes, trust is crucial in project coordination, just as it is important in all project endeavors. Leaders have the greatest opportunity for intervening where trust is insufficient for the task at hand. The rest of us have the responsibility to see that our leaders do just that. Monday, November 10, 2003
Tom Peters Unabashed, Master or Geezer?
Great teleconference today. Tom Peters was his usual candid, outrageous, provocative, and not-to-be-trapped self. Here are some representative questions and my best attempt at capturing his responses: "What are you passionate about?" My passion is passion. "How many CEOs really get it?" Jack Welch is the most youthful human being that I've ever met in my life. He is one rare duck. (But most leaders) are guys without nerve. "Why don't you like Jim Collins?" I love Jim Collins. He's a good friend. Jim says what we really need is quiet stoic leaders who can reform companies quietly. My problem is Jim describes companies who transformed companies financially, but they have not set the world's agenda. "How do we work with people who are passionless?" Avoid them like the plague. Life is too short to work with dorks. In answer to the question, "Which leaders do you admire?" Tom refused to be pinned down. Instead, he answered, My hero is a person who is willing to risk a stable life to do something entrepreneurial. "What do we do in this time of outsourcing?" Raise hell. They'll send your job to India anyway, so you might as well make some noise along the way. Catch Tom's interview Rants with Tom Peters for the next few days. Let's hope Greg and I can do a respectable job when we interview David Schmaltz and others next year. Sunday, November 09, 2003
Habits Die Hard
This is a continuation of my series of postings on the theme Variation as an Enabler that started on Sept 12th. It's obvious to say it takes people to do projects. But what we've missed in putting projects together and managing them through calm and troubled times is the people on the project are the source of power on the project. Trite? I don't think so. Companies spend buckets of cash on facilitation, problem resolution, dispute resolution, brain-storming, and team building all with the intent of being more participative. The results are checkered. For the most part, people who take part in these activities report 'good feelings' about having participated. And, too many will tell you that the effects are not lasting. Habits die hard. To think that we can provide a shot in the arm misses the nature of being human. We are social beings. We are biological beings. The routines of social interaction are etched into our biology. The biologist Humberto Maturana describes this as structural coupling. Through repeated interactions with others we develop ingrained patterns or habits of response and engagement. These habits allow us to be effective with those around us. (I can go into more of this if readers are interested.) Here's the big point. While we can agree intellectually that two are smarter than one, and three are smarter than two, we generally lack the structural coupling on projects to manifest that smartness. Why? Project teams by definition (or practice?) are temporary organizations. Everyone knows that. Some organizations go so far as to staff projects (not project teams) with 'interchangeable cogs' -- some general skill and experience level suitable for some understanding of the tasks. (The term 'interchangeble cog' is so demeaning.) They do this with the intention that they can switch out resources as needed. This is absolute hooey. Teams perform when they have personal relationships with each other. Based on Maturana we can make the case that collections of people aren't teams unless they are structurally coupled. Yet we act like skills and experience are interchangeable just like machines in a factory. And, we know they are not. We have a great opportunity on our projects for manifesting the talents, gifts, intellect, and creativity of project performers. With that will come the surprise -- uncertainty or variability -- in project results. Patience and persistence required. Visit the Archives for more postings |
 Reference Papers
|
|||||
| ||||||
