What Project Management Methodology do we use?

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

 management roles





2.       Project Plans

management plans

3.       Project Processes

project plans


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.



16.   Al the end of the last stage the project manager should ensure that the project has delivered all deliverables with quality standards and closes the project.