Project Management
Documents
Need
project management documents for an information management change
request and want some practical suggestions to ensure rapid change
delivery?
What are documentation standards?
Information management change management projects can evolve from a
change request or a business case.
The change management process must either:
- Create project documentation as part of the
information management process; or
- Ensure that all project documentation is
reviewed, and modified, if impacted by the change request.
What information management project management documents are required?
Business Case
This important document is essentially a contract between the business
owner, who is paying for the project, and the IT departments, who will
develop, implement and operate the solution. Approval of the business
case signifies that:
- The business owner agrees with the project
approach and commits to provide the resources;
- The IT department commits
to develop the solution based on the
approach, cost and schedule specified in the business case;
and
- Project planning can commence.
Project plan
Project
management documents are based on a project plan which builds on the
business case. This document is an agreement between the
project manager, the IT owner and business owner. It provides more
planning information than the business case. Approval of the project
plan signifies that:
- The project manager commits to deliver a
solution, that will meet business case objectives, with the resources,
management approach and schedule specified in the project plan;
- The IT owner and business owner agree to the
approach and schedule and commit to provide the resources specified in
the project plan; and
- Requirements analysis can commence.
Requirements
definition
The project manager uses the requirements specification as one of the key project management documents to update the
project plan and schedule. If the expected cost or schedule is
substantially different than the business case cost
projections, then the requirements need to be reviewed to
ensure that they are really in scope.
This
is one of the most
critical project
documentation components. If the financial projections are
significantly different from the business case, then the business case
may need to be updated and approved, or, the requirements may need to
be “down-sized”.
When the requirements are documented and approved, the architecture and
design/development team should be able to commence work without having
to ask a many business related questions.
The requirements specification is an agreement between the end
users, the business owner, the IT owner and the project
manager. Approval of the requirements specification signifies
that:
- The end users and business owner agree that
the document specifies all structure and design, data movement,
security, data quality, information usage, service level and
functional requirements;
- The operations/production support team agrees
that the document specifies all system, or non-functional requirements,
needed to implement the solution;
- The business owner and operations/production
support owner commits to accept the solution based on the acceptance
criteria specified in the requirements specification;
- The technical lead agrees that the requirements
specification provides sufficient detail to commence architecture and
design;
- The test lead agrees that the requirement
specification provides sufficient detail to create quality
assurance and user acceptance test cases;
- Architecture and design can commence; and
- Quality assurance test case preparation can
commence.
Architecture
and design
The architecture document is another key component of project management documents. It serves as a communications link
between the
architecture and design team, the requirements analysis team and the
user team. This critical document is the last chance
to make modifications to the project schedule and/or cost.
An approved architecture document is the basis for development
work. Any changes after this is approved have to be treated
as a change request because they are not included in the approved
project plan. Approval of the architecture document signifies that:
- The business owner, IT owner, project manager
and technical lead agree on the solution;
- The IT owner commits to obtain any architecture
components specified in the architecture documents; and
- Details design specification can commence.
Design
specifications documentation standards
These critical documents serve as a communications link between the
design team, the development team and the integration test
team. Approval of the design specifications signifies that:
- The technical lead agrees with the technical
design;
- The requirements analysis team agrees that the
design accounts for all requirements;
- The development team commits to develop code to
meet specification;
- The integration test lead agrees that the
design specification provides sufficient detail to create
integration test cases;
- Development can commence; and
- Integration test case preparation can commence.
Unit test
results
Individual developers complete unit testing and unit test results
demonstrate that code performs to specification. Unit test results form
part of the code review. Approval of unit test results signifies that
the designer agrees that:
- Code was developed to standards and best
practices;
- Code meets specifications; and
- System/integration testing can commence
Test plan documentation
standards
The test plan is vital component of project management documents and
must be completed early in the project. It is an agreement between the
business owner, the IT owner, the project manager and the technical
lead. Approval of the test plan signifies that:
- The technical lead agrees to the test approach
and commits that expected results of integration test cases
confirm the solution meets architecture and design
specification;
- The test team commits that expected results of
quality assurance testing confirm the solution meets
requirement specifications;
- The operations/production support owner commits
that expected results of non-functional testing confirm the
solution meets non-functional requirement specifications; and
- The business owner agrees to the test approach
and commits that expected results of user acceptance tests confirm the
solution meets business objectives stated in the business case
User
acceptance test exit criteria
This document is part of the test plan and serves as formal
confirmation that testing is complete. Approval of the exit criteria
signifies that all stakeholders agree that the solution is ready to
move to production.
Release plan
The release plan is one of the final project management documents. It serves as a
communications link between the project team and the production support
team. It identifies each configuration item that will move into the
production environment. It also includes all of the documentation
needed to maintain and operate the solution.
It is a commitment between the release manager, the IT owner and the
operations/production support team. Approval of the release
plan
signifies:
- The technical lead certifies that the
configuration items included in the release package are the same set of
configuration items that passed final acceptance test;
- The operations/production support owner commits
to provide the resources specified in the release plan;
- The release manager commits to test the release
process as specified in the release plan;
- The operations/production support owner commits
to accept the solution upon completion of release acceptance criteria;
- The IT owner commits to provide post production
support as specified in the release plan; and
- The business owner commits to accept the
solution and close the project upon completion of release acceptance
criteria.
Summary…
Standard project management documents ensure
effective communication among and between project team members. Each
piece of documentation is designed for a specific purpose. Project
documentation needs to be managed to ensure that each piece of
documentation meets objectives.
Tight control of this process will reduce project time loss due to
miscommunication.
|