A project plan is more than just a schedule...

1. May 2016PROJECT PLAN OVERVIEW
More than just a schedule…

2.  Scope Management
 Requirements Management (often included as part of Scope Management)
 Change Management (often included as part of Scope Management)
 Time (Schedule) Management
 Cost Management
 Quality Management
 Human Resource Management
 Communications Management
 Stakeholder Management (in practice, may be part of Communication
Management)
 Risk Management
 Procurement Management
CONTENTS OF A PROJECT PLAN
NOT JUST A SCHEDULE…
In practice:
• This is a list of “best practice” items to consider for any project
• A project manager should select those most appropriate for
his/her environment
• In developing plans, relying on existing templates, tools and
tailoring to the size/scope of the project is highly encouraged

3.  Scope involves getting sufficient information required to start
a project, and the features the product would have that would
meet its stakeholders requirements. Note that this enables
both waterfall and agile development methodologies.
 Project Scope: "The work that needs to be accomplished to deliver a
product, service, or result with the specified features and functions."
 Product Scope: "The features and functions that characterize a
product, service, or result.“
 If requirements aren't completely defined and described and
if there is no effective change control in a project, scope or
requirement creep will likely ensue.
SCOPE MANAGEMENT
• Project Scope is work-oriented, (the hows,)
• Product Scope is oriented toward functional requirements. (the whats.)

4.  Basics
 Ensure that an organization documents, verifies, and meets the needs and
expectations of its customers and internal or external stakeholders.
 Begins with the analysis and elicitation of the objectives and constraints of the
organization.
 Includes planning for requirements, integrating requirements and the organization for
working with them (attributes for requirements), as well as relationships with other
information delivering against requirements, and changes for these.
 Traceability
 Used in managing requirements to report back fulfillment of company and stakeholder
interests in terms of compliance, completeness, coverage, and consistency.
 Support change management as part of requirements management in understanding
the impacts of changes through requirements or other related elements (e.g.,
functional impacts related to architecture).
 Communication
 Is facilitated through written requirements, between the project team members and
stakeholders, and adjustment to requirements changes throughout the course of the
project.
 Ongoing and regular communication among members of the development team is
critical.
REQUIREMENTS MANAGEMENT
Many companies have adopted requirement management
software to facilitate this work
Strong tie to Quality Management

5. Ensures that changes to the project scope are properly analyzed and
approved in a consistent manner
 Defines the process to limit scope creep
 Product scope (the whats) AND
 Project scope (the hows)
 Common approach/tools:
 Request form
 Impact analysis
 Definition of a Change Control Board (CCB)
PROJECT CHANGE MANAGEMENT
Many larger companies have adopted change management
software to facilitate this work
In practice:
• Execute the change management plan once
the project baseline has been approved
• Documented changes to the project scope
will help facilitate a retrospective

6.  Includes
 Project milestones
 Deliverables
 Intended start and finish dates
 Development of baseline schedule per project scope
 Work breakdown structure (WBS)
 Effort estimates
 Resource list and availability
 Maintained
 Effort estimates for remaining work
 Analysis of scope change (product or project)
 Regularly updated (weekly for most projects)
TIME (SCHEDULE) MANAGEMENT
In practice:
• Development of a baseline schedule is an
important communication tool with
stakeholders and customers
• Maintaining an exacting schedule in a
rapidly changing environment may be not
always be the best use of time – manage
the project using a critical path approach,
not the tool

7.  Plan
 How will costs be estimated (planned for)?
 How will expenses be controlled/approved during the project?
 Estimate costs
 Human resources/employees (obtained through baseline planning)
 OPEX (contractor work) and CAPEX (tools, equipment, etc.)
 Risk contingency
 Determine budget
 What is the rolled-up budget? This is the baseline.
 Controlling and approving costs
 Comparing actual expenses to budget
COST MANAGEMENT
In practice:
• The project manager should produce a
baseline budget for the project
• The practice of controlling and
approving costs will vary greatly,
depending on organization and culture

8. Ensures that an organization, product or service is consistent.
 Quality planning
 Translates quality policy into measurable objectives and requirements, and lays down a
sequence of steps for realizing them within a specified timeframe. System Test Plan is a
good example.
 Quality assurance
 Administrative and procedural activities implemented so that requirements and goals for a
product, service or activity will be fulfilled.
 Quality control
 Product inspection or documentation
 Testing of products (white box or black box)
 Quality improvement
 Systematic approach to reduction or elimination of defects
 How are we improving?
QUALITY MANAGEMENT
Quality management is focused not only on product and service
quality, but also on the means to achieve it.
Central concept to
Six Sigma is DMAIC

9.  Identify required skills
 Don’t hesitate to identify gaps in knowledge
 Need for training or mentoring
 Specific key personnel
 Specialist(s)
 Timing within the project schedule
 Entire duration vs. specific time period
 Roles and responsibilities within the team
 For larger or more complex projects, determining a project organizational chart
and RACI matrix may streamline project execution and communication
HUMAN RESOURCE MANAGEMENT
If resource availability or capability
gaps are identified, those should be
brought to the attention of the
Executive Sponsor(s), enabling
either a reprioritization of resources
or approval to augment staffing
from outside the business.

10.  Who needs what information?
 Customers, executive management, project team, etc.
 Stakeholder analysis
 When is the information needed?
 Weekly, monthly executive briefings, etc.
 What is the format of the information?
 Email, Wiki, Trello, Powerpoint, verbal, custom website, etc.
 Who will be responsible for transmitting and providing the information ?
 Project manager, lead engineer, product manager, etc.
COMMUNICATION MANAGEMENT
In practice:
• This is very dependent on organization and
culture
• Seek to determine a common format to
address multiple users of information

11.  Identification
 Who is involved
 What areas are of most concern (technical, resource, regulatory, etc.)
 Assessment
 Impact to the project success
 Probability of occurrence; may be qualitative or quantitative
 Prioritization
 What are the top 3-5 risks
 Think big to small
 Monitoring and mitigation
 Risk management is NOT a singular event
 Risks and opportunities to the project change over the project duration
RISK MANAGEMENT
In practice:
• Risk management is an ongoing event
• Include into baseline schedule
• Discuss and update risk at regular project team meetings
• Maintain a “risk register”
• Risk management is a team effort
Assure uncertainty does not deflect the endeavor from the business goals.

12.  Project specific procurement decisions
 Acquiring products or services in support of successful project
outcome
 Should align to existing business procedures, i.e. vendor
qualification, NDA, MSA, etc.
 Vendor management
 Contract performance
 Communication
 Examination or validation of deliverables
PROCUREMENT MANAGEMENT
In practice, vendors may be treated as close
business partners where appropriate, but must be
held accountable for what they deliver.

13.  Configuration management
 Product and project documentation, engineering drawings
 Source code
 Defect management
 Prioritization process
 Who is involved?
 Deployment management
 Early adopters or beta program
 Training program
 Manufacturing or supply chain management
 Build vs. purchase
 Manufacturing location, supply chain architecture, etc.
OTHER ITEMS THAT MAY NEED TO BE
CONSIDERED
In practice, the type of project will likely
dictate additional types of plans that
should be considered – ONE SIZE DOES
NOT FIT ALL

14.  A Guide to the Project Management Body of Knowledge
(PMBOK Guide), 5th Edition, PMI
 Project Management: A Systems Approach to Planning,
Scheduling, and Controlling, 8th Edition, Harold R. Kerzner
REFERENCES