Planning and Scope

Project planning is the construction of a dynamic agreement across diverse functional groups involved in a project. This agreement specifies the goals and deliverables of the project -- what is being developed -- and the major activities that will be performed to achieve those goals. It includes the assumptions that were made and identifies major risks as they become known. The planning process allows for changes to this agreement during the project's execution. As the planning process is documented, the documentation becomes a dynamic guide for the execution of the project.

The benefits of good planning seem obvious. So why do so many organizations and project managers fail to plan their projects? New project managers may lack paradigm knowledge about planning, but why do even some experienced project managers ignore or actively avoid good planning? What are the elements of a good project plan? No matter how much or how little I plan a project, the plan ends up gathering dust on the shelf during execution - why? What are some of the methods used to create such a plan? How detailed does the plan need to be? How can I identify the risk areas early? What is the difference between project scope and product scope? What is "scope creep" and how can I avoid it? How do I manage the trade-offs among project stakeholders? What processes and tools can help me turn a product vision into a coherent, executable plan?

• Click here for Burning Questions and know-how on Planning and Scope
  
  
• We have an extensive list of templates and checklists for project planning -- you'll find them in the Concept and Initiation phases in our Templates and Checklists. Among the highlights:
  • Collaborative Milestone-Driven Planning Process
  • Development Project Plan
  • Maintenance Planning Guidelines and Plan Outline
  • MS Project Template for IT Software Development Project
  • Planning and Managing Multiple Small Projects
  • Project Alternatives Tradeoff Table
  • Project Charter
  • Project Scope Definition: Statement of Work (SOW)
  • Project Team Leader Description - Roles & Responsibilities
  • Project Vision Example: Defining a Software Release Life Cycle
  • Project Plan Example – Small Project
  • Responsibility Allocation Matrix
  • Software Release Life Cycle WBS (Microsoft Project file)
  • Software Release Team Member Glossary
  • Task Responsibility Matrix Formats
  • Tools and Equipment List
  • User Documentation Plan
  • WBS for Electromechanical Systems Project
  
  
  
• The most detailed on-time deployment in the world won't matter if your customers don’t know how to use it. Instead of treating training as an afterthought, this Information Week article by Charles Trepper discusses how planned Staff Training Can Help Deployment Efforts. It discusses pointers for creating a training plan, decisions like "make or buy," continuous improvement, and more. Make sure the training team is involved in creating a smooth transition to the new workplace, and avoid the catastrophic effects of the Big Red Button syndrome.



• The Software Project Plan template is a favorite of interviewee Barbara Zirolli of HP (see also our interview with her). It contains a wealth of guidance for creating a detailed software development plan. The template includes extensive detailed tools and guidance for sizing a complex software project in the early days, to enable intelligent tradeoff decisions based on scope of software development, resource availability, schedule flexibility and more. The sizing guidance includes a quality-minded focus on deciding what code reviews and inspections should be done, and ensuring that adequate staff time is planned for those critical activities. The entire template is annotated to explain what should be included in each section.



• Completion criteria are explicit goals that must be attained to call an element of a project, or the entire project, "complete." Completion criteria are really a communication tool and an important aspect of "quality management" on your project. They ensure the team agrees on when a particular activity or phase will be "done" and plans work, testing, and reviews accordingly.




• The following files define recommended deliverables for the first 4 phases of a Software Release Life Cycle, focused on planning a major software release composed of multiple projects. The guidelines provide a one-to-two page detailed definition of each deliverable in the phase, defining Purpose, Audience, Prerequisites, Driver (who should drive or take responsibility for this deliverable getting done), and a detailed checklist of "recommended accomplishments" - what the deliverable should contain. These phases provide an upfront process that ensures all sources of requirements are considered, while helping cut through the clutter of all the things that COULD be included in a software release, to ensure the release focuses on important features and projects, AND is humanly possible to complete in the alotted time!
    Phase 1: Preliminary Requirements Gathering
    Phase 2: Scope Definition
    Phase 3: Planning and Negotiation
    Phase 4: Release Plan Refinement