Develop Supporting Plans for Specific Activities to Control The Details
August 5, 2008 | Author: PM Hut | Filed under: Project Management Best Practices, Project Plan Development
Develop Supporting Plans for Specific Activities to Control The Details (#6 in the seris Effective Planning for Big Projects)
By Timothy Prosser
First a disclaimer: I don’t claim to be the world’s expert on project management, and I urge anyone who is involved in or interested in project management to seek good sources of information and study, as this is a profession requiring a lot of skill and knowledge to do well. That said, I believe my decades of experience (planning projects up to 4 years in length and over $1 billion in cost) gives me some basis to write this. You may notice that I tend to focus more on the timing aspects of large scale plans. I am not ignoring the financial side of the discipline, but not stressing it either, because I have usually had a parallel financial planning effort, run by accountants and financial experts, to lean on. You may also notice that I am trying to address the realities, the impact of human nature, on the work. That said, be aware that good planning requires a focus on all three major components of business processes and projects: time, cost, and quality. I have summarized with a list of suggestions at the end, and hope you find this entry helpful.
Develop supporting plans for specific activities to control the details, with shared integration points to tie them to the master plan. A single plan can rarely contain all the details behind the process, especially in large and complex organizations, without becoming an “eye chart” that nobody can read. Also, the more detailed the plan the greater the risk that dates will have changed again before the current round of updates can be finished. I have seen plans so detailed they could never practically be kept up-to-date. Supporting, or subordinate, plans enable you to keep track of the details (better yet, find someone else to do that) while you maintain the master plan in a highly readable, maintainable, and effective form. The integration points that tie a subordinate plan to the master should be limited to inputs, outputs, key events, and status reports to management, thus keeping master plan content to a highly-effective minimum. Some software tools allow dynamic linking between plan files, which allows the sharing of dependencies between plans. Be aware, however, that this introduces additional complexity that may not be manageable.
Timothy Prosser - Ann Arbor, MI
Timothy spent the past ten years planning vehicle development programs and tracking parts at a major auto manufacturer in the Detroit area, employed by Integrated Management Systems, Inc. of Ann Arbor, MI (www.imsi-pm.com).
Past experience, in reverse order, includes 3 years writing and supervising technical documentation at a major automotive supplier, 7.5 years engineering computer printers for Unisys Corporation, 3 years of technical work in the image processing and automatic inspection industry, 5 years of network and peripheral service work for ADP, Inc., and 3 years selling wholesale electronic parts.
Education includes an MBA from The University of Michigan (1991), a BS in Geography from Eastern Michigan University (1974), and *countless* training classes by various employers. Timothy has also taught many seminars on project management and various tools involved in the work.
Timothy is a lifetime musician (www.mandolinmaniac.com, www.martianentropyband.com), a 30-year amateur radio operator, and writes a number of blogs including www.timprosserfuturing.wordpress.com.
Related Articles
No comments yet.
feel free to leave a comment
Comment Guidelines: Basic XHTML is allowed (a href, strong, em, code). All line breaks and paragraphs are automatically generated. Off-topic or inappropriate comments will be edited or deleted. Email addresses will never be published. Keep it PG-13 people!
XHTML: You can use these tags: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>
All fields marked with " * " are required.










