Prince2 Project Management
Software development projects unfortunately have a poor history of success. Many issues surround this from the difficulty in estimating the true costs of a project, the fact that project requirements change often, the fact that issues outside of our control can affect the project and of course technology is changing and moving making technical projects difficult to control both risks and costs.
DataOne has a history of successful projects that typically:
-
Succeed close to budget, project timeframe and purpose
-
Require less rework
-
Are architected and built well reducing maintenance costs ongoing
-
Meet or exceed designed requirements
To achieve this we draw on a mix of collaboration, other projects, extensive experience and
have deployed a Quality Management approved process which includes many things such as:
-
Documented Quality Lifecycle Development Process
-
Documented source code control
- Document Management System
-
Documented controlled release and migration processes
-
Adopted Project Management methodology
DataOne follows a 'Prince2' project
management methodology ('Projects In Controlled Environments') for handling our projects. This
typically
requires several people from both DataOne and your company with clear
assignment and responsibility. We also provide regular
communication with our customers on progress, issues, costs and plans.
1. Project Roles
2. Project Plans
3. Project Processes
4. Project Stages
In order to promote sound management control, a project is split into stages as an approach to defining the review and commitment points of a project.
Stages in an IT project typically are:
a. Initiation stage
b. Analysis
c. Design
d. Coding
e. Testing
Stages are not necessarily the above Software Development Phases. In a small project a stage can contain all the above phases and in a big project a Software Development Phase should be broken down into multiple stages. In general a stage is a collection of activities and products whose delivery is managed as a unit.
5. Stage Plans should be created by the PM for each stage and should be approved by the board.
a. Identifies all the products that the stage must produce
b. Provides a statement of how and when a stage’s objectives are to be achieved, by showing the deliverables, activities and resources required.
c. Identifies the stage’s control and reporting points and frequencies.
d. Records the stage tolerances.
e. Specifies the quality controls for the stage and identifies the resources needed for them
A stage plan is more to do with managing the activities in that stage, monitoring, reporting, time and budget, quality check, etc. The Stage Plan is produced before the stage commences, it is a product of the stage before that which is being planned. For our small projects, a Gantt chart of activities, needed resources, outcome description, some needed quality tests and checkpoints should be all we need.
6. After approval of a stage, Work Package definitions are defined for that stage. TM is usually involved at this stage to give consultation on specific details on work packages. The PM and TM agreed on the specification and expected quality of the work package.
Work package contains the Product Description(s), details of any constraints on production such as time, cost and interfaces.
Work Packages will be handed over to team members to complete an area of work for the project. So preferably they need to only contain details necessary to complete the work. They can be kept together with other stage documents by the PM.
7. It is then the responsibility of TM to coordinate his/her resources to get the work completed according to the quality and specification stated in the work package definition.
During the Stage Plan PM defines needed resources and then the Board should approve this. When it comes to doing the actual work, it is the responsibility of the TM to coordinate the allocated resources and get the work done.
8. Checkpoints may be used to monitor the progress of the work package by the PM.
In the Project Plan and Stage Plans there are predefined, time-driven checkpoints where work status in a team is ascertained. So they are tested against Stage/Project Plan. The output of the checkpoint is the Checkpoint Report. It answers the questions "What is going according to plan?" and "What is not?". For example, a check to see if the Database Design is going according to the stage plan where the stage contains all designing activities.
9. Any issues and risks during a stage should be escalated from the TM to the PM and from the PM to the board.
10. Reports should be given to the board by the PM.
At anytime during the project, based on the PM’s reports and updates, the Board can close the project if the business case for the project is no longer viable.
11. Board gives ad-hoc recommendations to PM on issues or after reviewing reports from PM
12. Once the work package is completed, it is handed to the PM, who then assures that the completed work package is consistent with the standard specified in the work package definition.
13. Above steps are repeated for all work packages that are to be delivered during the current stage. Multiple work packages can be initiated concurrently.
14. If the PM realises that targets set by the current stage plan may not be realised, he should created an exception plan and submits it to the board. Then board decides if the project is still viable and approves the exception plan.
A Stage Plan can be updated by the PM as long as it realises defined targets. It is a bit different than the Project Plan in the way that the Project Plan is a high-level plan showing the major products of the project, when they will be delivered and at what cost.]
15. When the current stage approaches to the end, PM creates the next stage plan and submits it to the project board for review.
