Project Management Methodology

Our project management methodology is outlined diagrammatically below.

Our objectives are to:

• deliver the project to meet our client's goals;
• achieve the most appropriate balance between time scale, cost and quality of deliverables;
• manage change and risks so as to maximise gains from opportunities and minimise adverse impacts.

This approach has been developed over a large number of consulting projects of widely varying scale and nature, both large and small and “hard” and “soft”. It also draws upon our experience of helping project focused organisations in areas such as defence, aerospace, shipbuilding and pharmaceutical research to improve their project management processes.

The following sections briefly describe the key elements.

An essential first step is to define clearly the scope of the project and a set of overall project policies. The form of the scope definition varies for different types of project but typically lists the overall goals, the organisational, process and geographic areas that are to be included and any specific exclusions. Where the project relates to a subset of an organisation structure or of a business process, diagrams may be used to clarify the project boundaries.

Policy statements describe intended ways of working and any specific constraints, such as confidentiality, within which the project must operate. They may also identify tools and techniques to be used, critical reporting requirements, change control principles and key features of the desired consultant/client relationship. Another critical area of policy is work share between consultants and client.

The scope definition and policy statements are controlled documents. Once agreed with the client's Project Board they may only be altered through a formal change control process.

Effective execution of significant projects requires a clearly defined project organisation with agreed and well understood roles and responsibilities. Whilst there will be variations between different types and scales of project, as a minimum there should be:

• a Project Sponsor with overall responsibility for the project who usually chairs the Project Board and acts as a high-level champion for the project;
• a Project Board or Steering Group responsible for:
  • approving the project scope and policies;
  • approving the project budget, milestones and deliverables;
  • authorising changes to the scope, policies, budget, milestones or deliverables;
  • ensuring that appropriate resources are made available to the project when needed;
  • resolving conflicts, either within the project or between the project and other business activities, that cannot be resolved at a lower level in the project organisation;
• a Project Manager responsible for:
  • defining the project scope and policies;
  • reviewing project plans before submitting them to the Project Board for approval;
  • managing the project and delivering it to time, cost and quality targets;
  • allocating project resources within constraints set by the Project Board;
  • resolving conflicts within the project, negotiating agreed resolutions to minor conflicts with other business activities and referring other conflicts to the Project Board;
  • reviewing deliverables for completeness and quality before submitting them to the Project Board for approval;
  • monitoring progress and completion;

• a Project Team, which may comprise both consultants and client personnel, responsible for:
  • defining project tasks, resource requirements and deliverables;
  • executing project tasks;
  • producing deliverables;
  • managing project risks.
• In addition, for larger projects, there may be:
  • Task Teams, which may include consultants but will typically be comprised mainly of client personnel, to whom the Project Team delegate execution of some project tasks;
  • a Project Support Office that carries out clerical and technical tasks such as:
    • maintaining networks, and resource plans using software such as Microsoft Project;
    • issuing and collecting turnaround documents and tracking progress against the plan;
    • preparing routine project reports such as schedule deviations and earned value;
    • maintaining controlled project documents such as the Scope and Policies, the Issues Register and the Risk Register;
    • ensuring that the project's infrastructure such as PCs, copiers, phones, whiteboards, etc. is properly established and maintained;
    • maintaining a diary of meetings, etc. and tracking the location of team members;
    • typing up minutes of meetings;
    • maintaining general project files and other records;
    • holding project databases;
    • ensuring the security of confidential files and data;
    • producing copies of deliverables;
  • a Project Assurance Team comprised of client and consultancy personnel who report to the Project Board and are independent of the rest of the project organisation. They provide a Quality Assurance function to ensure that the project is executed according to the agreed policies and procedures and that deliverables are of satisfactory quality;
  • for very critical projects, a Challenge Team or “Red Team”, usually comprised mainly of client personnel, whose role is to probe and challenge the work of the Project Team and Task Teams to ensure that findings are complete and accurate and that recommendations are appropriate, practical and robust.

Project management is notorious for the problem of “95% complete for 95% of the duration”. Monitoring by deliverables is one of the main ways of avoiding this pitfall. Overall project deliverables are broken down into individual task deliverables and a task is not considered complete until a full set of deliverables of satisfactory quality has been produced. In general, we avoid measuring progress by percentage completion of tasks unless a clear, simple and reliable measure of progress can be identified.

To be a useful means of assessing task completion, deliverables must tangible, auditable and wherever possible quantifiable. Definition of deliverables is one of the key elements in task definition.

For certain types of "soft" project a network plan may be inappropriate, as the task definitions and dependencies are too subtle and difficult to define rigidly. However, for most projects, the schedule is developed as a critical path network, with earliest and latest dates calculated by conventional algorithms.

Where, as in most cases, resources constrain the timing of the plan, the network is then resourced and a resource constrained schedule produced. This serves not only to provide a realistic time scale, but highlights critical resources that represent risks to the project.

The original, approved project plan is saved as a baseline for monitoring. If significant deviations from plan occur, the plan is rescheduled on the basis of work actually completed, taking account of planned recovery actions, to give a realistic estimate of time and cost to complete.

For large projects, particularly those involving elements of research, design and development, it may not be feasible to plan the whole project in detail at the start. In this case, the initial plan contains only an outline of the later phases, with the detailed planning of those phases being included as tasks in the plan.

Issues are matters that arise during the project where information or decisions are required in order for project tasks to be completed. A common cause of project slippage is allowing difficult issues to remain unresolved until they impact task completion dates. Issues that cannot be resolved within a few hours should be logged in an Issues Register that identifies the issue, the person responsible for obtaining a resolution, the target date and the tasks affected. Occasionally, major issues that require extensive effort call for a revision to the project plan and become new tasks in their own right.

Risks are potential future occurrences, to some extent outside the control of the Project Manager, that may significantly affect the outcome of the project. A risk is usually defined in terms of its probability, which often can only be estimated subjectively, and its impact. Negative impacts may be termed “hazards” and positive ones “opportunities”. Risk management starts with the identification and assessment of risks, which should be an ongoing process throughout the project. For each adverse risk a decision must be made to avoid it, if possible, mitigate the impact or accept it. Where avoidance or mitigation has been chosen, someone is assigned responsibility for developing avoidance and mitigation strategies, monitoring the risk and initiating any necessary actions. Similarly, major opportunities should be assessed and plans made to benefit from them if they occur.

Risks are recorded and tracked in a Risk Register that is formally reviewed on a regular basis. However, the keys to successful risk management are not the register but identification of risks, assessment, ownership and, particularly, development of cost-effective avoidance and mitigation strategies.

In projects where success is dependent on the quality and quantity of data, effective mechanisms for managing, sorting and utilising that data are vital. Data management involves the codification of physical and electronic data, its analysis and use, so that the origins of conclusions and ideas can be traced. Project data management requirements are very diverse and we design data management structures to suit the needs of each individual project.

Data management tasks may use relational databases, spreadsheets, text documents, HTML or XML as appropriate.

An effective project management process is a set of inter-linked, closed-loop control systems. The starting point is the project plan, which provides the targets or set-points for the control loops. Efficient feedback requires routine, formal reporting by exception. This is most easily done with turnaround documents identifying the new and current tasks for which each individual is responsible. Establishing routine feedback through the Project Office frees the Project Manager to focus on resolving issues and avoiding risks.

In addition to basic progress reporting, a structure hierarchy of regular reports and meetings is necessary to ensure that all stakeholders are kept properly informed and have appropriate opportunities to participate in decision making. The form and frequency of reporting and the depth of coverage at each level, along with the frequency and format of meetings should be decided at the start of the project.

In addition to formal project meetings, for larger projects it is desirable to provide other forms of communication so that everyone affected is provided with appropriate information. These can include:

• project news letters posted on notice boards or circulated;
• short sections on the project included in routine cascade briefing processes;
• articles on the project included in in-house publications;
• formal or informal briefings specifically about the project;
• a project web site on the company's intranet.

Change control is critical at several levels:

• documents and data;
• appointments, schedules and resource allocations;
• task definitions and task deliverables;
• milestones and project deliverables;
• scope, overall time scale and budget.

At each level we implement a formal control process to ensure that uncontrolled change does not occur or is trapped and corrected on the rare occasions that it does.

Changes to project-level documents and decisions should be made only by the Project Board, usually in response to a formal request from the Project Manager. Mechanisms for controlling such changes normally form part of the contract for a consulting assignment.