Dr. Project: Outcomes-Based Planning

 

I would like to find out in how much detail one must go into when doing outcomes-based planning. Do you maybe have an example of a software development project or software upgrade project I can use to form an idea of identifying obstacles and outcomes?

South of the Border in Africa

Dear South of the Border,

Are you anywhere near Mazatlan? Oops...just looked at a map and you're really down south! You should know that Dr. Project is continually amazed by the number of old ideas wrapped in new packaging and priced accordingly. Conceptually, Outcomes-Based Planning is amazingly similar to Top-Down Project Planning. Of course, to hire a Top-Down Project Manager is not as pricey or as sexy as hiring an Outcomes-Based Project Manager. Outcomes-Based Planning begins with stating what you want at the end product, determining the three to five necessary outcomes to achieve the end product, understanding the outputs that will produce those outcomes and (finally!) analyzing the necessary inputs to create the outputs. Or so it goes...

As in most project planning methodologies, the more detail you put into the plan, the better the plan. However, I have two cautions. First, too much detailed planning can bury even a good project manager in a sea of details that quickly become unmanageable even with the best tools and lots of administrative help. Secondly, detailed…

Please log in or sign up below to read the rest of the article.