Module 6: Project Plan Approved
Milestone
6
THIS PAGE LEFT INTENTIONALLY BLANK
0RGXOH#9=#3URMHFW#3ODQ#$SSURYHG#0LOHVWRQH##9²6
2EMHFWLYHV
At the end of this module, you will be able to
„
Understand how to write a functional
specification
„
Evaluate the need for planning documents
that comprise the master project plan
„
Organize master project schedules with the
appropriate level of detail
„
Understand the key components of a robust
development environment
9²7# # 0RGXOH#9=#3URMHFW#3ODQ#$SSURYHG#0LOHVWRQH
/HVVRQV
Lessons
1. Principles and Concepts
2. Planning Phase Outline
3. Creating a Functional Specification
4. Creating a Master Project Plan
5. Creating a Master Project Schedule
6. Building a Development Environment
0RGXOH#9=#3URMHFW#3ODQ#$SSURYHG#0LOHVWRQH##9²8
/HVVRQ#4=#3ULQFLSOHV#DQG#&RQFHSWV
Lesson 1:

7KH#,WHUDWLYH#1DWXUH#RI#3ODQQLQJ
„
Functional
specification
defines what
the solution is
„
Master project plan
defines how the solution
will be developed, tested,
and deployed
„
Master project schedule defines
when the solution will begin rolling
out and when rollout will be complete
Start Here
Master Project
Schedule
Master Project
Plan
Functional
Specification
The three major documents—the functional specification, the master project
plan, and the master project schedule—are baselined (not frozen) at the project
plan approved milestone. Each document depends on its predecessor and allows
work to continue on its successor, creating a cycle of improvement that helps
the team fully realize the solution.
9²;# # 0RGXOH#9=#3URMHFW#3ODQ#$SSURYHG#0LOHVWRQH
%DVHOLQH#(DUO\/#)UHH]H#/DWH
Vision/Scope


Who
is accountable for the change
„

What
the impact of
the change will be
„

How
the change
will be traced
Change is inevitable in any project. Change control enables the team to control
the quality of the solution by:
„

Determining the reason for the change.
„

Establishing who is accountable for the change.
„

Assessing the merit of proposed change.
„

Determining the feasibility of the change.
„

Assessing the impact of the change on the project.

„
Interim milestones
„
Key development
dates
„
Deployment
strategy
„
Change control
„
Cost/benefit
„
Selected technology
baselined
Release
Vision/Scope
Approved
Deployment
Complete
After the team approves the specifications, plans, and schedules, the documents
become the project baseline. The baseline takes into account the various
decisions that are reached by consensus by applying the three project planning
variables: resources, schedule, and features. After the baseline is complete and
approved, the team transitions to the developing phase.
After the team defines a baseline, it is placed under change control. This does
not mean that all decisions reached in the planning phase are final. But it does
mean that as work progresses in the developing phase, the team should review
and approve any suggested changes to the baseline.
0RGXOH#9=#3URMHFW#3ODQ#$SSURYHG#0LOHVWRQH##9²46

portion of the work.
Draft master project plan includes all of the detailed plans. The scope of each
plan is aggregated to make up the entire project scope. The team reaches this
interim milestone when each of the component plans has been defined well
enough to start putting together the master project schedule.
Draft master project schedule includes all of the detailed project schedules,
including the release date. The team determines the release date after
negotiating the functional specification draft and reviewing the master project
plan draft. Often, the team will modify some of the functional specification
and/or master project plan to meet a required release date. Although features,
resources, and release date may vary, a fixed release date will cause the team to
prioritize features, assess risks, and plan adequately.
Working development environment allows proper development and testing of
the solution so that it has no negative impact on production systems. If the
organization does not already have a suitable test lab in place, the team must
build one.
0RGXOH#9=#3URMHFW#3ODQ#$SSURYHG#0LOHVWRQH##9²48
7HDP#)RFXV#'XULQJ#3ODQQLQJ
Product management
Program management
Development
User education
Testing
Logistics management
Role Focus
Conceptual design; business and user needs
analysis; budget
Functional specification; master project
plan/schedule
Technology evaluation; physical design;

training plan and schedule for technicians as appropriate. Depending on the
scope of change, takes the lead on various logistics-related planning activities,
including pilot/rollout plans, capacity plans, facilities plans, procurement plans,
and security plans.
9²49# # 0RGXOH#9=#3URMHFW#3ODQ#$SSURYHG#0LOHVWRQH
THIS PAGE LEFT INTENTIONALLY BLANK
0RGXOH#9=#3URMHFW#3ODQ#$SSURYHG#0LOHVWRQH##9²4:
/HVVRQ#6=#&UHDWLQJ#D#)XQFWLRQDO#6SHFLILFDWLRQ
Lesson 3:
Creating a Functional
Specification
The contract between the
customer and the team as to
what will be deployed
9²4;# # 0RGXOH#9=#3URMHFW#3ODQ#$SSURYHG#0LOHVWRQH
)XQFWLRQDO#6SHFLILFDWLRQ#'UDIWHG#,QWHULP#0LOHVWRQH
„
The solution delivers business benefits
„
The solution meets known requirements
„
Responsibilities and committed schedules are
stable
„
Implementation risk is acceptable
„
Strategy for test platforms, scripts, configuration,
and customization are defined
„
User’s needs are defined

Project standards
„
Additional conceptual, logical, and
physical design documents
The functional specification addresses what the solution needs to include.
Vision/scope summary. A summary of the vision/scope document as agreed
upon and refined. It may be useful to provide a brief restatement of the driving
vision and scope.
Background information. Places the solution in a business context. The design
goals and constraints depend on the existing environment and the user
operations.
Design goals, usability goals, deployment goals, constraints, and
expectations. Key design goals that development uses to make decisions.
Testing and logistics management will verify these goals as part of the
validation process. They include dependencies on other projects and only the
constraints that are external to the requirements.
Solution Design Document.
„

Usage scenarios. Describe the users’ business problems in the context of
their environment. There may be multiple types of users and/or technical
environments (for example, engineer versus administrator; desktop versus
laptop; LAN access versus dial-up access).
„

Features and services. Define the functionality that the solution must
deliver.
„

Enterprise architecture documents. Define the overall architecture for the

„

Each feature that the functional specification identifies should map to an end
user and business process (and/or, in many cases, to an information
technology technician and operations support process) identified during
conceptual design; the team must be able to verify that each feature meets a
need and that all needs are met.
„

All team members must reach consensus.