 Reforming Project Management |
||
|
|
||
|
Wednesday, February 18, 2004
Project e-Tip: Expectations Breed Results
This week's Project e-Tip came from a suggestion Clarke Ching made for a rule of conduct. At first look, neither of us thought there was an e-Tip in it. As the week went on I noticed that how we conduct ourselves in relationship to others has a significant impact on the others' behavior. Greg Howell reminded me that I say, "You get apples from apple trees. What kind of apple tree will you be for your team?" So, after a few more conversations we have something to offer. The exercise of creating the e-Tip really makes the point that 2 are smarter than 1 and 3 are smarter than 2.
How about some more contributors to this weekly undertaking? Tuesday, February 17, 2004
Why Projects are Hard
This sidebar to Frank Patrick's series on Promises and Prescriptions attempts to show why it is we find projects hard. I found it hard to understand the sidebar! (Just kidding Frank.) Projects are hard due to the interaction of uncertainty and variability. Our efforts to minimize uncertainty, for instance by deciding early, serve to limit the actions available to performers as the future unfolds. At the same time, we introduce variability by being unreliable with our project commitments. "Hard" is an understatement. For those of you subscribing to Reforming Project Management via Bloglet, you can add a subscription to Frank's Focussed Performance Business Blog and have our postings delivered together automagically in the same email message. (You'll find Frank's subscription box at the top of the right-hand column.) Try it out for awhile. Promises and Prescriptions
Frank Patrick is at it again. His series Promises and Prescriptions that started Feb 15th is worth reading a few times over. Frank starts with the statement, Projects -- including software projects -- are about promises. For some reason this needs to be said over and over again. We routinely involve people in our project without telling them what has been promised to a customer. Then we wonder why they do things that are inconsistent with the promise! Projects are about turning uncertain work efforts into reasonably certain outcomes. The collected outcomes represent the set of conditions for satisfying the customer. We want to be very clear about those conditions with the customer. And we need to stay in conversation with the customer about that set of outcomes to adjust as the team innovates, learns, along with the customer. Project sponsors, customers, and stakeholders rely on project promises to carry out and coordinate larger strategies in support of organizational needs. While we know that others rely on our promises, we often don't find out why the promise matters. The "why" serves as the context for the project. Knowing the "why" allows the team to innovate rather than just do what had been decided by others sometime in the past. The "why" offers team members freedom to be their creative selves. Yet, making and keeping those promises are hindered by common problems: people on projects are reluctant to promise the unknown, plans are disrupted by rework, and schedules are thwarted by contention for resources that are involved with more than one effort. Eventually we get to the point where each project performer has to make commitments. It's the only way projects are completed. As Frank says, people are reluctant to do so in the face of uncertainty. It looks like Frank has organized the balance of the series around three common complaints: rework, resource contentions, and fear of promising the unknown. Frank made three postings so far including a sidebar Why Projects Are Hard. I'll offer my comments on that tomorrow. In the meantime get over to Frank's Focused Performance Business Blog. While you're their subscribe by email or add his RSS feed to your feedreader. If you care about projects, then you want to be reading Focussed Performance. Monday, February 16, 2004
When Sponsors Abandon Your Project
Interesting little article in Computerworld today on what to do when your project sponsor walks away from your project Surviving the Sponsor Exit. Kathleen Melymuka describes an approach offered by Gopal Kapur of the Center for Project Management. She infers we can anticipate that sponsors will fail the team.
I enjoyed the article. It was a quick read. I walked away with a few clever sayings. But it got me wondering why are we talking about project sponsors? What does that mean? The author says, "The project sponsor is the executive or manager with the fiscal authority, political clout and personal commitment to see a project through." In my experience that is not good enough. Who is the customer for the project? All project work has a customer and one or more performers. The team needs someone to say, "I'm satisfied" when the work is complete. You can skip the above 11 actions if you don't do any project that doesn't have a customer. And if the customer walks away, then you know the project is over. Sunday, February 15, 2004
Embrace Uncertainty...Why Would I Do That?
Uncertainty increases with increases in the planning time horizon. One way to bring more certainty to your planning is by planning in shorter and closer in horizons. Save the detailed planning for today, tomorrow, and the next day. Plan at higher levels beyond that. The greatest uncertainty has to do with what the team will learn and innovate. While we can't know months ahead of time how the team will evolve, we can plan that they will do just that. The implication is that we must continue planning for those teams that are most innovative. Any who doesn't want that? Join Greg Howell and I in our interview this Thursday, Feb. 19, from 1:00-2:15 PM EST, for our conversation with authors Phil Clampitt and Bob DeKoch. Visit the Archives for more postings |
 Reference Papers
|
|||||
| ||||||
