-
I’m a Leader… I Want to be Alone
May 24, 2012
-
Two Types of Workflow: Software and Human System
May 24, 2012
-
10 Benefits of a Project Management Software System
May 24, 2012
-
Spotting a Failing Project: 9 Warning Signs
May 23, 2012
-
Values of Effective Project Managers
May 23, 2012
-
Calm in the Eye of the Storm
May 23, 2012
-
Management by Heroics
May 22, 2012
-
Project Planning for Project Sponsors: Why You Need To Be Involved
May 22, 2012
-
Lost in Projects - Integrated Project Management
May 22, 2012
-
10 Warning Signs that Your SharePoint Implementation May Be Heading for Difficulty
May 21, 2012
Write the Project Plan
August 13, 2008 | Author: PM Hut | Filed under: Project Management Best Practices, Project Plan Development
Write the Project Plan (#6 in the series 21 Project Management Success Tips)
By Karl E. Wiegers
Some people believe the time spent writing a plan could be better spent writing code, but I don’t agree. The hard part isn’t writing the plan. The hard part is actually doing the planning—thinking, negotiating, balancing, asking, listening, and thinking some more. Actually writing the plan is mostly transcription at that point. The time you spend analyzing what it will take to solve the problem will reduce the number of surprises you have to cope with later in the project. Today’s multi-site and cross-cultural development projects demand even more careful planning and tracking than do traditional projects undertaken by a co-located team.
A useful plan is much more than a schedule or work breakdown structure of tasks to perform. It also includes:
- staff, budget, and other resource estimates and plans
- team roles and responsibilities
- how you will acquire and train the necessary staff
- assumptions, dependencies, and risks
- descriptions of, and target dates for, major deliverables
- identification of the software development life cycle that you’ll follow
- how you will track and monitor the project
- metrics that you’ll collect
- how you will manage any subcontractor relationships
Your organization should adopt a standard software project plan template, which can be tailored for various kinds of projects. An excellent starting point is IEEE Std 1058-1998, the “IEEE Standard for Software Project Management Plans” [IEEE, 1998]. This standard describes a comprehensive template, sufficient for the largest projects. Study this template to see what sections would make sense for the types and sizes of projects that you work on.
If you commonly tackle different kinds of projects, such as major new product development as well as small enhancements, adopt a separate project plan template for each. Avoid overburdening small projects with excessive documentation that adds little value. The project plan should be no any longer nor more elaborate than necessary to make sure you can successfully execute the project. But always write a plan.
Adapted from “Practical Project Initiation: A Handbook with Tools” (Microsoft Press, 2007). A condensed version of this paper was published in Software Development magazine.
Karl Wiegers, Ph.D., is Principal Consultant with Process Impact, a software process consulting and education company in Portland, Oregon. Karl’s most recent book is “Practical Project Initiation: A Handbook with Tools.” Karl is also the author of four other books and 170 articles. Karl is a frequent speaker at software conferences and professional society meetings. You can reach Karl through www.projectinitiation.com or www.processimpact.com.
Related Articles
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.
- Agile Project Management
- Ask the Hut
- Certification
- Change Management
- Communications Management
- Computer Based Information Systems
- Concepts
- Corporate Transformation
- Cost Management
- Critical Chain Project Management
- Delegation
- History
- HR Management
- Implementing Project Management
- Integration Management
- Lessons Learned
- Management
- Miscellaneous
- People Issues
- PMBOK
- PRINCE2
- Procurement Management
- Program Management
- Project Lifecycle Phases
- Project Management Advantages
- Project Management Advantages
- Project Management as a Career
- Project Management Best Practices
- Project Management Charts
- Project Management Definitions
- Project Management Ethics
- Project Management for Beginners
- Project Management Guides
- Project Management Musings
- Project Management Office
- Project Management Proposals
- Project Management Templates
- Project Portfolio Management
- Project Workforce Management
- Quality Management
- Requirements Management
- Risk Management
- Scheduling
- Scope Management
- SCRUM
- Soft Management
- Time Management
- Training
- Uncategorized
1 person has left a comment
Karl,
I totally agree with your point that a plan isn’t worth as much as the planning process. Asking the right questions as a PM in the planning process is where a good PM adds the most value to a given team.