If you're new here, you may want to subscribe to my RSS feed. Thanks for visiting!
I've been attending many project meetings lately. They all had one thing in common. People spoke about what they would be doing without talking about what that would accomplish. Planning starts with the promises you make. Once you get clear about what you will accomplish, then what you do becomes clear.
The Project Reformer's e-Tip of the Week |
| 035: Take the Time to Plan Outcomes before Activity |
|
The language of project planning includes the nouns: milestones, activities, tasks, and durations. We use these terms like there is a well-understood common meaning for each term. We also use these terms like the relationship between the terms is equally agreed upon. Neither are the case. In spite of what you might find in a dictionary of project terminology, people use these terms differently, even in the same company and on the same project team. I won't take on the task of producing standardization. I'll leave that up to others. But I want to address a major problem with our current planning. Time after time people talk about their planning in doing terms using verbs rather than in the terms of the outcome of their doing using nouns. When we plan we want to place our attention first on what it is we are promising to produce — a product of our efforts. We can then get into what will it take us to produce that product. When we jump into the planning conversation saying what we will do first, then next, etc., we end up missing the key issues for satisfying our clients. Clients don't care about the doing. They care about the results (promises). Start each planning session with the outcomes. Take all the time you and your team need to be clear about the conditions of satisfaction for the result. Check those outcomes with your client. Only then move onto how you will produce the result.
|
©2004 Hal Macomber | weblog.halmacomber.com | e-Tip Archive | PDF | Submit Tip |
Let's hear from you. Send me your tips on project management.
![Reblog this post [with Zemanta]](http://img.zemanta.com/reblog_e.png?x-id=03314884-90d1-47e5-acf3-2821313e9fdc)
![Reblog this post [with Zemanta]](http://img.zemanta.com/reblog_e.png?x-id=4ce3f392-8989-448a-a97a-c1432dd3fce6)
{ 1 comment… read it below or add one }
To aid this PM’s have to stop thinking in terms of a Work Breakdown Structure and move to thinking of a Product Breakdown Structure that defines ALL the products a project will create. This includes management products(Plans, risk registers etc…) as well as quality products(the deliverables).
After defining the PBS you can then build a product flow diagram to identify true dependencies. PM’s who want to explore this idea further should review the PRINCE2 Project Management methodology.