Documenti di Didattica
Documenti di Professioni
Documenti di Cultura
Application
Development
Project Plan Template
[This project plan template is intended to be used as a guide for planning and managing real world software
development projects. This plan is not a real plan and should not be used without modifications required for your
unique project.
Table of Contents
1
Overview........................................................................................................ 3
1.1 Project Objectives....................................................................................... 4
1.2 Project Constraints...................................................................................... 4
1.3 Project Risks............................................................................................... 4
Proposed Solution.......................................................................................... 5
2.1 Business Requirements............................................................................... 5
2.2 Architecture................................................................................................ 6
2.3 Development.............................................................................................. 6
2.4 Testing........................................................................................................ 6
2.5 Deployment................................................................................................ 8
Project Resources........................................................................................... 8
3.1 Roles and Responsibilities...........................................................................8
3.2 Issue Escalation.......................................................................................... 8
3.3 Project Staffing Plan.................................................................................... 8
3.4 Project Materials......................................................................................... 8
Project Approach............................................................................................ 9
4.1 Development Model.................................................................................... 9
4.2 Configuration Management........................................................................9
4.3 Communication Management...................................................................10
4.4 Change Management................................................................................ 10
4.5 Testing...................................................................................................... 10
4.6 Documentation......................................................................................... 10
Estimate....................................................................................................... 11
Schedule...................................................................................................... 11
Overview
Project deliverables
Project risks and opportunities
Estimates
Project resource information
Project delivery method
Configuration and change management
A project manager would generally use this section of the document to provide an
overview of the entire project.
Need for project
This section discusses why the project is being undertaken. There are many
reasons for undertaking a project, including:
Challenges
What known challenges will impact project planning and execution? These might
include:
Opportunities
By implementing the project, what specific opportunities become available? For
example:
Risk Probability
Risk probability analysis involves measuring the likelihood that an event will be
actualized. Probability analysis usually includes quantification and assignment of a
particular probability value (e.g. high, medium, low).
Risk Impact
It is important to be specific when defining the potential impacts associated with
each particular risk. If, for example, the impact of a particular risk would be cost
overruns, then a statement providing an estimated value would be more beneficial
to the risk planning process. Impact analysis also generally includes quantification.
The combined values of total probability and impact for a particular risk determine
the overall risk for any particular risk element. This enables project stakeholders to
properly weight and prioritize risk in a project.
Risk Mitigation
Copyright 2008 The Project Diva | Overview
The purpose of risk mitigation is to reduce the probability that a particular risk even
will occur. Risks with a higher probability and greater impact should be addressed
first. For example, a major project risk could be delay in delivery of the production
platform. This could be mitigated by earlier ordering of the hardware.
Contingency Plan
The purpose of a contingency plan is to reduce the impact of a risk that has been
actualized. An example of a contingency plan might be to provide the customer
with temporary hardware should the production hardware not arrive as scheduled.
Proposed Solution
Users update multiple data stores with duplicated information. Data is often
out of synch. The data will need to be synchronized before being migrated.
This will require a substantial amount of application down time for the
existing financial reporting application.
Existing data stores span multiple platforms. Legacy data migration will
require more time than originally anticipated.
Integration with legacy accounting package is required. Accounting package
has not been patched or updated in several years. Newer software versions
are available from the vendor. A series of upgrades will be required before
the accounting package can be integrated with the planned application. This
will require substantial effort and should be considered as a separate project.
2.2 Architecture
This section of the document provides the technical blueprint of the application.
Expect to use mock-up screenshots, sample designs, diagrams, workflow models
(e.g. UML) and considerable detail in describing exactly how the application is going
to work.
Functional Specifications
Functional specifications include details regarding how the application will interface
with, for example, legacy applications, provide database models and describe the
relationships between the different data entities, and detail how each component of
the application interacts with every other component.
Technical Specifications
Technical specifications might include the following:
Network Diagrams
Platform specifications
Development languages
Peripheral specifications
Security Specifications
If security is integral to the application being developed, then consider a specific
section to document the security specifications relating to the application and
supporting infrastructure.
2.3 Development
This section of the document would describe the features to be included in each
release or phase of the development process.
Copyright 2008 The Project Diva | Overview
2.4 Testing
This section describes both he overall approach to testing as well as provides details
on what will be tested, when the testing will occur and who will be responsible for
the testing.
Software development is an iterative process, and is tested constantly. That said,
only the testing process need be documented, especially if the testing requires
client interaction or includes a formal feedback and bug reporting process.
Details regarding the formal feedback process should also be documented in this
section. A sample bug tracking form can be provided. If you have access to web
based bug tracking software, then the client should be informed that such tracking
will be done electronically.
2.5 Deployment
Major Milestones
This section should be used to define project milestones. Milestones are often times
linked to a contract payment schedule. If this is the case for your project, then the
milestones should be referenced in the payment schedule section of the project
contract.
Project Resources
Also consider including the Resource Breakdown Structure in this section of the
project plan document. This provides a basis for cost estimating and is fundamental
to understanding resource allocation during the course of the project.
Project Approach
Tools
This section describes the tools or techniques used in executing the configuration
management processes. These may include, for example, software or code library
management systems or forms and documents (e.g. change control submission,
analysis and approval documentation)
Reporting
This section describes the reports issued by the project team and may include:
Change History
Release status reports
Project Baseline analysis reports
Audit data
Archiving
Define what should be archived and the length of archival time.
Archive Control and Audit Review
Copyright 2008 The Project Diva | Overview
4.5 Testing
A testing plan is usually developed as part of the functional specification phase of
the development project. This provides for a detailed test plan, as the analysts
developers understand more about the components that will require testing.
Testing should be done both in a test environment and also within the intended
production environment. This will minimize issues associated with configuration
variances.
This section should provide details associated with the test process: the project role
(and individual, if a specific person has been identified) responsible for testing,
other human resource requirements and a schedule for testing (or associated
milestones).
If an application will be used to track bugs or provide testing feedback to the
development and management group, then this should be documented here as
well. Otherwise, feedback documentation should be provided in the project plan.
10
4.6 Documentation
This section details what documentation will be delivered during both the course of
the project and at project end. Clients are usually most interested in system
administrator and user documented. It is important to document how the
information will be provided in electronic, physical media format or perhaps both.
Documentation is a project deliverable, just like the User Interface. Expect to
provide clients with several versions for review.
Estimate
This section should be used to detail the projects cost estimate. There are many
methods to estimating project costs. All methods require basic information relating
to scope, timeframe for delivery and resources available. In the associated
TheProjectDiva.com application development sample project documents, a cost
estimate is provided. This estimate uses input data from the Work Breakdown
Structure to create a Resource e Breakdown Structure document. It is this Resource
Breakdown document which provides the basis of the cost estimating template.
Schedule
The project schedule can be completed only after all project tasks have been
defined and prioritized. The schedule is one of the last components of a project
plan to be completed.
11