Lifecycle Project Management Ltd have developed a core set of best practice methods and techniques based on our extensive experience which have been applied successfully in many project environments

Project Reviews

A 'Project Review' should be undertaken at the end of each phase of the project lifecycle, to reaffirm that the purpose and direction of the project is unchanged by the events of the phase.

Major excursions from the specification, schedule or budget should be considered in detail to ensure that the mandate to proceed, from senior management or the project board, is still valid. If not, the review process must be escalated to obtain/renew the mandate.

Making time and scheduling reviews can be difficult during a busy project, often the project is only one of the many tasks the stakeholders have. But the discipline of undertaking the review, however brief, must be assured by the project manager.

The reviews represent the successful passage through the necessary phase or stage gates on the road to project closure.

Lifecycle Project Management Ltd consider that the process of project closure commences from the earliest phase of the project not just the last, refining customer requirements and expectations through to approval of design and final product delivery.

The final review, during 'Project Close-Out', is often the most difficult to conduct as the project team may be reassigned prematurely. Often seen as a dotting the i(s) and crossing the t(s) exercise, its most valued benefit is to provide feedback for lessons learned for the next project.

The 'Project Review' is a powerful project management tool and should be used and used wisely for best effect.

Financial Control & Monitoring

The basis for good financial monitoring and control of any project is established during the planning process.

Clearly, effort spent compiling a detailed estimate has to be balanced against the prospects of contract award. Where possible, a generic estimating format should be developed to minimise project specific effort and promote uniformity for ease of understanding by others.

Breaking the project scope of works down using PBS and WBS techniques (see Project Planning) provides a sound basis for the cost accounting structure and division of activity codes/booking numbers.

The project manager should understand the accounting system used by the project organisation, in particular how and when accruals occur, to derive an accurate 'cost to date' (CTD).

The project manager's ability to provide senior management or the project board, with accurate and stable 'forecast to complete' (FTC), throughout the project, will generate a feeling of confidence in his level of control.

If problems do occur that threaten to breach the authorised project budget tolerance, then this must be escalated as soon a possible to obtain direction.

The project manager is not always best placed to estimate or even control spend for specialist areas of scope. In this instance, it is often beneficial to devolve authority to specialist group managers or team leaders, defining the work scope as a sub-project or work package.

Financial reporting should be kept simple, ie. identifying CTD, FTC and deviations for each major element of the project. The report recipients are not generally interested in the pounds and pence, but the larger deviations from the budget which affect the bottom line and if the budget allocation tolerance is under threat.

Risk Management

All projects, however well planned or proven, will face some risk. The very nature of project implementation is a 'change' from one state to another.

A lot of research has been undertaken to develop methods for risk identification and management, most calculating a 'risk value' in monitary terms. Some industries/organisations have their own risk managememt processes to suit their specific needs.

Whichever method is employed, the key requirements must be to 1) Identify a risk 2) Assess its probability of occuring 3) Assess its impact if it occurs 4) Identify a trigger event to realise or retire the risk 5) Assess the proximity of the trigger event and 6) Determine a mitigation strategy for the risk.

It is important to review potential project risks early in the project lifecycle and to repeat risk reviews as a routine.

All team members must be given the opportunity to contribute to the review process and all risks, however wayward the identified risk may appear, must be given consideration in the process. Often, it is the less obvious risks that need more examination.

The aim of the project manager should be to encourage the identification of all risks and therefore remain in control to apply timely risk mitigation strategies and avoid slipping into a 'fire fighting' culture.

It is important that the project manager sets aside time to review the risk log (or register), assessing upcoming trigger events and changes in circumstance that may affect the current risk assessment position.

Communication

In the project environment, communication and team working should not be assumed because individuals have been assigned to a project or because of desk proximity.

The individual personalities, strengths, weaknesses and asprirations complicate project team dynamics. Similarly, functional, project or matrix organisational structures may add another local political dimension.

It is vitally important that the project manager establish a 'team' mentality as soon as possible after team selection and mobilisation. Identifiable roles, lines of reporting and communication play a major part in establishing the perception of the 'team'.

Equally, providing the newly formed team with a overview of the project aims and objectives and how it fits within the corporate programme, gives the project purpose and the team a sense of identity and value.

The communications process should be open and simple, ensuring that all team members have a voice and a means to contribute to develop a sense of collective ownership, objective and desire to succeed.

Project Reporting

Accurate and timely project reporting is fundamental to maintaining a clear understanding of the status of the project.

All too often, project reporting is seen as a chore, when in fact the process of gathering information necessary for the report is more of a daily routine, at the heart of good project management.

Lifecycle Project Management Ltd, advocate the use of the 'Highlight Report', rather than a long-winded narative on each project activity.

Based on a 'report by exception' approach, the 'Highlight Report' gives a bulleted outline of activities completed during the reporting period, activities anticipated to complete in the next period and a commentary on specific issues requiring senior management, project board or customer attention.

Together with an update of the project logs and the project schedule, the report provides a full reference for project status at that time.

Similarly, verbal or short written 'Checkpoint Reports' are provided by the individual team members and subcontractors for assigned work packages, in support of the highlight reporting process.

Work Packages

Just as it is important to ensure that the user requirements specification is unambiguos and achievable, individual work packages and assigments must be clearly defined and understood to avoid abortive effort and rework.

Lifecycle Project Management Ltd approach to controlling team activity is to define individual 'Work Packages', whenever appropriate.

The 'Work Package' can be defined in a short (1 or 2 page) document, stating what has to be produced, the method and tools to be used, the reporting requirement, when the package must be completed and the tolerances to apply.

The project manager works with the project team individual assigned to complete the packages to define and agree the contents of the document.

The 'report by exception' approach is adopted, such that the individual only need highlight any issues to the project manager if they expect the tolerance to be breached.

The use of work packages allows the project manager to break the project down into smaller, more manageable lumps or sub-projects, devolving responsibility to his team member or subcontractor and therefore mitigating risk.

Project Logs

Concise and up to date records are an absolute must for the project manager, but maintaining such records can be a full time job in itself, leaving insufficient time for team management and involvement at the coal face.

Equally, the project manager does not want to have to maintain several records, containing similar information, for differing stakeholder audiences.

Lifecycle Project Management Ltd believe the key is to keep a simple set of project logs, which are available for update by any team member as events occur.

The 'Issue Log', 'Action Log', 'Risk Log', 'Quality Log' and 'Lessons Learned Log' should be updated continuously and reviewed on a frequent basis by the project manager.

The project manager may attach the logs to his 'Highlight Report', escalating specific issues for attention of senior management, project board or customer.

Project Planning

Time taken by the project manager to develop his implementation strategy and detailed planning during project mobilisation will pay dividends throughout life of the project. All too often, contract award or authorisation to proceed, is received later than required resulting in the project schedule being stressed. This should not, however, be used as a reason for rushing the planning process or worse still not producing a plan at all!

A well thought out and structured project plan should be seen as a project manager's tool, not a pretty picture for the customer or organisation's management. The plan is more than a 'Gantt Chart' or 'Network Diagram', it is a document that states, 'What will be done', 'How it will be done', 'When it will be done' and 'Who will do it'.

The plan should provide the reader with sufficient information and confidence that the project strategy is such that the three corner stones of 'quality', 'time' and 'cost' will be satisfied to achieve project success.

Lifecycle Project Management Ltd approach to project planning is to start with a 'Product Breakdown Structure' (PBS), to ensure that all deliverables and component parts are identified. Next, a 'Work Breakdown Structure' (WBS) is developed for each product, to ensure that all activities necessary to complete the product are identified. The PBS and WBS are then used to develop the project schedule (ie. Gantt Chart), from which the project time line, resource plan and cost estimate can be derived.

The project plan is then developed from this information, including 'project aims and objectives', 'key milestones', 'communications strategy', 'roles and responsibilities' and appropriate 'quality procedures' necessary to control the project and ensure the quality of the products.

It is important that all stakeholders and team members understand and accept the content of the project plan, once approved it is base lined to monitor project progress and performance.

Requirements Definition and Design

The key to the success of any project is an unambiguous and achievable statement of user requirements. So many projects fail because customer expectations differ from what the supplier is able or expects to deliver. Interpretation of a statement in a requirements specification can also vary widely depending on the specifier's understanding of the available technology and indeed the supplier's understanding of the users business or process. Similarly, the end user may not be directly involved in developing the specification, with the result that although compliant with the requirements specification, the delivered product/system does not do what the user wanted and therefore does not satisfy the intention of the business case.

To mitigate this situation, Lifecycle Project Management Ltd encourage the earliest involvement of 'nominated and authorised' end users in the requirements specification and definition phase. Clearly, this process requires strong management to ensure that requirements are detailed to an appropriate level (users are not detailed designers) within a sensible time frame to satisfy the project schedule or programme. The 'nominated' end user must have the authority of the customer organisation to make decisions and state requirements.

A 'User Requirements Specification' (URS), approved by all participating parties, represents the conclusion of the requirements definition exercise, steering the project through this significant phase gate. From this point forward, user requirements are fixed for change management control and provide a starting reference for the design phase.

At Lifecycle we prefer to apply a formal requirements definition approach such as the ‘Volere Requirements Process Model’ to ensure that all stakeholders have the opportunity to contribute to and therefore own the solution delivered by the project.

Environmental, Health and Safety

Increasing environmental, health and safety legislation is irreversibly shaping future company policy for all organisations in modern business. The detail of implementation practices adopted can vary considerably between orgnaisations and industries but all follow similar fundamentals. At Lifecycle Project Management Ltd, we take our responsibility for health and safety of personnel and plant very seriously and wherever possible adopt practices to limit our impact on the environment.

The majority of assignments undertaken by our staff involve working on customer sites for short or long term periods, during which we adopt the environmental, health and safety policies of the site. CDM Regulations play a major role in many of our project assignments, as a consequence the processes developed by Lifecycle Project Management Ltd comply with the spirit of the regulations, incorporating the flexibility to adapt to a customers specific site rules or interpretation of the CDM regulations.

Project Lifecycle

Ensuring that all project stakeholders understand the 'project lifecycle' and the significance of each phase, is a fundamental requirement to achieving project success.

There are many diagramatic representations for the 'project lifecycle'. The representation preferred by Lifecycle Project Management Ltd is given below:

Theoretically, progress should flow sequentially from one phase to the next ie. the current phase being completed before moving on to the next.

In the real world, however, progress is seldom as straight forward as this and innevitably there will be some overlap. This situation is manageable within control methods and regimes, but the benefits of remaining receptive to customer change and open to collaboration must be balanced against the exposure to project schedule delays, cost overrun and risk of potential liquidated damages.

Methodology and Best Practice

Lifecycle Project Management Ltd have honed their project management methods and techniques over the past 20 years, adapting and improving to suit the project content, scale and industry.

The 'Book of Knowledge' (BoK), developed by 'The Association for Project Management' (APM), is adopted as the foundation for our approach.

In addition, selected techniques are taken from the Prince2 methodology and amalgamated with our experience and the BoK approach to form the 'core set' of methods and techniques employed by Lifecycle Project Management Ltd to achieve project success.