Wednesday, 11 April 2012

Project Management: a simple system


Project Management: a simple system
We have recently been addressing project management for one of our clients. Project management is one of the skill sets we prize highly in our team as often once we have designed a solution with our clients project managing the implementation is  natural step if there is no in house capacity either in terms of time or skill set. There are many systems out there to choose from such as PRINCE 2 which came out of the UK governmental system.  If you have time and money to get staff members trained in such a tool we really support having a clearly defined systematic approach to projects that covers your entire organisation. For those of you who don't have that time here is. A simple system we have derived from our experiences over the years. It is not a proprietary system so cut, paste, edit and adapt to fit your purposes.  If you have any questions feel free to drop us a line; we'll do what we can to help.
The case for a single project management tool is simple it saves duplication of effort, time wasted in unnecessary work and provides a framework for excellent performance with having undue quantities of staff on standby to act. It is particularly useful in a project that overlaps departmental borders such as finance, PR, HR and operations.
Methodology
Step 1
The prime document - this document may have many names but at its heart it is a statement of objective, a list of desired outcomes and the point to which all subsequent actions, discussion and documents must answer to in terms of do they fall in line with this the prime document. There should be no "how to" input in this document only the "what".
NB : A prime document may be changed with the consent of stakeholders but in the event changes are made all subsequent stages of project planning must be reviewed to ensure the changes have not "torn the fabric"of the project plan.
Building project plan tasking identifiers - this level should be given a three letter identifier for the project.  For this model we will use PRO
The stakeholder list
Anyone who may have an interest in the project in terms of outcome or input needs to be included in the stakeholder list.  They may be represented as departments, individuals steering committees or even clients and users but all interests need to be represented. It is possible to classify these stakeholders into 2 groups: consumers and resourcers (it is possible that some stakeholders will sit across both groups).
Consumers want something from the end product
Resourcers will contribute to the building of the end product
Building project plan tasking identifiers - each stakeholder will have a two digit code (more digits can be added if the project requires it)
The action plan
The action plan is the headline titles of steps to achieve the outcomes defined in the prime document. This is the first level of breaking down the tasks required to make a project successful. This is unlikely to contain any "how to" information it is effectively a more detailed look at what it would take to reach the prime document goal.
Building project plan tasking identifiers - each task in the action plan should have a 3 digit identifier (more digits can be added if there more action plan tasks)
The work packages
To define the work packages the project team must cross reference the action plan with the stakeholder list.
Going down the list of the action plan If a stakeholder has an input then this creates a work package for them. The work packages are owned by the stakeholders, in that they populate what goes into the achieving of their part of the action plan. They make a commitment to an objective, by a deadline, for a cost. This is effectively a contract whether internally or externally placed. Be sure to think through things like who brings in the money to pay for this, your finance team my hold the central key to your timeline.
 Building project plan tasking identifiers - work packages have a 3 digit identifier which completes the project library coding.
Project.           Stakeholder.      Action plan      Work
                                                   Task.              Package
PRO-                12-                     123-                123
Dependencies
The project team must agree dependencies (ie don't pour boiling water before the mug is in place). The dependencies will drive communication and project progress.  By identifying which work packages and action points require completion before another can take place gives each work package a family of dependants. Stakeholders/ in conjunction with the project manager are responsible for communicating to dependants any delays in implementation of a work package, releasing the stakeholder owners to commit to other work pending completion.
Taking the work package duration and dependencies will give you the in service date of the project objective, although it is good practice to add a percentage for slippage which invariably occurs.  This slippage can clearly be captured and give a clear new in service date.
A visual representation of dependants:
Parent
PRO-12-123-123
                Dependant
                >PRO-14-345-123
                >PRO-01-567-245
This is effectively the project plan, it can be represented in a GANTT chart that can be built on excel or any number of project software products.  The project manager then just needs to keep an eye on that timeline encouraging, reminding and policing.  The Project managers main role is to communicate communicate and communicate some more.

1 comment:

  1. Well, you can implement facility management software in your company that can generate various automated reports including project management, construction management, Operations & Logistic.
    project management

    ReplyDelete