Tải bản đầy đủ (.pdf) (50 trang)

Tài liệu Module 6: Project Plan Approved Milestone pdf

Bạn đang xem bản rút gọn của tài liệu. Xem và tải ngay bản đầy đủ của tài liệu tại đây (479.41 KB, 50 trang )

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:


Principles and Concepts
The principles behind the
planning phase and how they
enable you to achieve the
project plan approved
milestone
9²9# # 0RGXOH#9=#3URMHFW#3ODQ#$SSURYHG#0LOHVWRQH
3ODQQLQJ#WKH#6ROXWLRQ
What Could Have
Been Sufficient
Result of the
Design
What the User
Described
and the Analyst
Understood
Result of
Implementation
What the
User Needed
The functional specification establishes an agreement between the project team
and key project stakeholders.
When project goals include releasing a product that is responsive, stable, and
easy to manage and support, the functional specification is invaluable in
recording the decisions and agreements reached on the functionality, interfaces,
design goals, and priorities.
When planning, it is important to keep your goal in mind. Otherwise, you don’t
know where you’ll end up and you’re likely to conclude that what you get is
what you wanted.
0RGXOH#9=#3URMHFW#3ODQ#$SSURYHG#0LOHVWRQH##9²:

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

Approved
Project Plan
Approved
Deployment
Complete
Release
Freeze
Baseline
Although it is relatively uncommon, projects can suffer from too much
preliminary planning. The team needs to be willing to move forward even
though some unknowns exist. In almost all cases, the team will need to modify
some initial assumptions and plans as the project moves forward. Additionally,
the team should add detail to the functional specification, master project plan,
and master project schedule as the project progresses through the
developing/stabilizing phase.
0RGXOH#9=#3URMHFW#3ODQ#$SSURYHG#0LOHVWRQH##9²<
&KDQJH#&RQWURO
Change control mechanisms
help the team to effectively
direct its change-related
activities, avoiding costly
errors while maintaining
acceptable quality levels
Change control provides
a framework for establishing


Why
the change is needed



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.



Determining the level of effort required to implement the change.


Establishing what constraints exist or must be imposed on the change.


Identifying the risks associated with the change.


Establishing a process for tracing the change.
9²43# # 0RGXOH#9=#3URMHFW#3ODQ#$SSURYHG#0LOHVWRQH
THIS PAGE LEFT INTENTIONALLY BLANK
0RGXOH#9=#3URMHFW#3ODQ#$SSURYHG#0LOHVWRQH##9²44
/HVVRQ#5=#3ODQQLQJ#3KDVH#2XWOLQH
Lesson 2:
Planning Phase Outline
The organization of the
process model developing
phase and the milestones
and deliverables that must be
achieved
9²45# # 0RGXOH#9=#3URMHFW#3ODQ#$SSURYHG#0LOHVWRQH
7KH#&XOPLQDWLRQ#RI#3ODQQLQJ
Project Plan
Approved
Project Plan Approved
Milestone
Agreement on


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

,QWHULP#0LOHVWRQHV
3URMHFW#3ODQ
$SSURYHG
Functional Specification Drafted
Master Project
Plan Drafted
Master Project
Schedule Drafted
Development
Environment Set Up
The interim milestones allow the team to show visible progress and share
information on the components of the project plan before the end of the phase.
The planning phase is the time when key decisions are made that pertain to the
trade-off triangle (features, resources, and release date).
9²47# # 0RGXOH#9=#3URMHFW#3ODQ#$SSURYHG#0LOHVWRQH
'HOLYHUDEOHV
Project plan approved milestone

Draft functional specification

Draft master project plan

Draft master project schedule

Working development environment
Draft functional specification begins the detailed definition of the product.
The team should describe all functionality at a high level as it works out details
during the design process. The team achieves this interim milestone when the
functional specification has enough detail for development, testing, user
education, and logistics management to begin laying out project plans for their

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;

development plan/schedule
Design evaluation; testing plan/schedule
Design evaluation; technical education
plan/schedule; logistics plan/schedule
User education; communications; usability test
plan/schedule
Product management. Takes the lead on developing the conceptual design
portion of the functional specification. Manages the process of documenting
usage scenarios that describe the full scope of the planned release as identified
in the vision/scope document. Also responsible for identifying and managing
budgetary concerns of the project.
Program management. Takes the overall lead during the planning phase and is
accountable for driving the team to the project plan approved milestone.
Compiles the functional specification and the consolidated project plan and
schedule from documents that other team members create.
Development. Takes the lead on developing the physical design portion of the
functional specification. When the physical design is complete enough to make
accurate estimates, determines the time and effort required to build and stabilize
the product. May also build proof-of-concept prototypes to shed more light on
particularly difficult areas of the product.
User education. Identifies user training requirements and documents a training
plan that meets these needs. Also develops a high-level communications plan
and schedule, and a usability test plan and schedule.
Testing. Defines integration testing strategies for each component identified in
the functional specification, defines issue-tracking methods and procedures,
establishes completeness-of-unit test requirements with development,
establishes compatibility lists for regression-testing changes with legacy
hardware and software, and defines release mechanisms.
Logistics management. Evaluates and provides feedback to the team on the
completed design from the perspective of the legacy environment. Develops a

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


All systems, application, and organizational
interfaces are identified
This is the first deliverable produced during the planning phase. It represents
the contract between the customer and the project team and is the basis for
building the project plan and schedule. At the project plan approved milestone,
the functional specification is baselined and placed under change control.
0RGXOH#9=#3URMHFW#3ODQ#$SSURYHG#0LOHVWRQH##9²4<
&RQWHQW#RI#WKH#)XQFWLRQDO#6SHFLILFDWLRQ

Vision/scope summary

Background information

Design goals, usability goals, deployment goals,
constraints, and expectations

Solution design document

Usage scenarios

Features and services description

Enterprise architecture documents

Component specification (products and
configurations)

Top 10 risk list


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

solution. Many infrastructure solutions require enterprise-wide designs to
define how multiple server components interact.
Component specifications. Define the products that will be used to deliver
required features and services as well as the specific instances where the
products will be used.
Appendices. Include additional conceptual design detail (for example, field
surveys and user profiles) and physical design detail (for example, vendor-
provided product descriptions or existing server and/or client configuration
detail).
9²53# # 0RGXOH#9=#3URMHFW#3ODQ#$SSURYHG#0LOHVWRQH
'HYHORSLQJ#WKH#)XQFWLRQDO#6SHFLILFDWLRQ

Set a deadline for completing the draft

Specify concisely and to a consistent level of detail

Quantify where necessary

Define terms early

Determine the level of detail that needs to be done
now

Define a change management procedure
To avoid pitfalls, everyone must have the same view of the critical success
factors.


The specification should be viewed in terms of its goals; when the goals are
met, the specification is complete and ready for approval.



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.

×