 Reforming Project Management |
||
|
|
||
|
Saturday, November 22, 2003
Creating Faster Cheaper Projects
Johanna Rothman offered this advice yesterday, in her weblog Managing Product Development. "If you really want to perform projects faster and/or cheaper, start them earlier."Her proposal includes running with a smaller team. Can't say I agree. Having worked in both software development and the AEC industry, I can see the point of having a smaller team. Fewer conversation lines does reduce the chance of miscoordination and therefore breakdowns. As Johanna points out, there's also likely to be less multi-tasking, and more organizational flexibility from this approach. On the other hand, as the team size decreases the opportunities for innovation and learning will decrease along with the decrease in total skills available. There are three other issues that Johanna is missing.
Here's my operating principle: Promise the end conditions at the first responsible moment and then commit to all the intermediate actions and start at the last responsible moment.Example: The client wants something in 5 months. You don't have the people ready for 1 month. There's 10 person months of work to do. The way I would do this project acting as the project manager is to delay the start even further to get the project in a condition where once people start their tasks they can work on them 'til they are finished. So, delay the start by another month, put 4 people on it working for 2 1/2 months, and deliver 2 weeks early. The invested time is kept low and there's time at the end for something unforeseen. Everyone wins! Wednesday, November 19, 2003
Project e-Tip of the Week
We're on a roll. Readers are responsible for the last four e-Tips. This one comes by way of France. Laurent Bossavit is a project guy and he's a book guy. He maintains the site Bookshelved Wiki, a community of people who write about and comment on books. It's very cool. Have a visit.
So the challenge is on. Let's keep the e-Tips coming in from readers. I can send a book anywhere. This week I sent Laurent my last autographed copy of The Blind Men and the Elephant. Who's up next? Tuesday, November 18, 2003
Capacity for Language Introduces Uncertainty
There's a book or two (or three) on this topic. I'll make a few points. Perhaps you can add to them with your comments. n.b. Remember the context of this posting is doing projects. We take our capacity for speaking for granted. We can't remember a time when we couldn't speak. It's just what we do. But communicating with language is not straight forward. We think the meaning of our speaking is clear, only to discover the listener understood something different than we meant. Humberto Maturana claims denotative meaning (precise definitions) in speaking is not possible; there is only connotation (inference, nuance). He's saying that each of us gives meaning to what we hear based on the distinctions we can make, our preoccupations (concerns) at the time, and the relationship we have with the speaker. In other words, in spite of the care we give to saying what we mean, people will listen what they listen. One of the tragedies of projects is when someone sees that action is required but they fail to speak about it. Sure, sometimes we see people complaining to a friend or coworker. But they don't speak up to a person who's in a position to act. We can speculate why this is the case. Frankly, it's not useful. Just knowing that people don't speak up is enough to begin changing the behavior of people with the authority to act. Another tragedy of the project setting is when people don't listen. Not just the bosses. Finish the sentence, "How many times have I told you ..?" We've all said that. Breakdowns are inevitable when their are patterns of not listening. Further, not listening leads to not speaking. "Hey, I'm justified in keeping my mouth shut. They don't listen to me anyway."The work of projects is coordinated through conversations. It's not about process. It's not about schedules. Work is certainly not coordinated through controls. It's all about conversations, particularly requests and promises. Yet people don't see the coordinating aspects of commitment conversations. Instead, they see writing code, hanging doors, designing product, and doing one report after the other. It fits that people don't get highly competent at something they don't see. To recap,
Disaster? You bet! But it is also the good news for project managers/leaders. We can anticipate that we'll encounter one or all four conditions throughout our projects. I bet you will find examples today! Sunday, November 16, 2003
Projects Are People-Centered
Continuing in the series of postings on variation as an enabler let's explore more of what I mean by "projects are people-centered." Why do I keep making this point? Because our language in business is so often that of the machine. In the last ten years the computer metaphor has gained ground. Those metaphors hide the nature of what happens on projects. Work doesn't flow like material flows in factories. People don't access their memory bank like computers. That people are not machines nor computers hardly needs saying, but how can we speak of our projects with a vocabulary that brings forth the nature of the project? Let's start by looking at what constitutes human-ness. I've written about both the social and biological aspects of being human in many postings. Let's fill out five elements for starters:
I'll explore these five attributes one-by-one in the coming week, or so. I suggest you start looking at how human-ness creates opportunities and challenges on your projects. Please share what you notice as comments to these postings. Visit the Archives for more postings |
 Reference Papers
|
|||||
| ||||||
