Project Early Warning System in 10 questions

6 min.
4.7/5 - (4 votes)

Summary

In project portfolio environments or even for project directors themselves, it is often not easy to get clear signals from the projects. This is to check whether they are on the right track. Often quite extensive and complex project portfolio control systems are used to determine exactly this. Practice shows that due to the heterogeneity of the projects (very large vs. very small, in country X or country Y, in business area A or B) these are not available the same number of reliable measurement points for the most diverse projects. This report shows how 10 identical simple questions provide reliable early warnings for a wide range of project sizes and types.

Why do I need a simple project early warning system?

I have already described another early warning here, which has completely different measured variables. Depending on the usage, one these approaches should be applied. In a company with highly standardized methods, processes and tools in project management, the next logical step on the way to even more quality for projects is to check the compliance of these specifications. The project management handbook describes processes, provides templates and tools to handle all types and sizes of projects in a standardized way. Even the specific usage of standard applications such as MS Project is often described and specified in detail. Compliance criteria therefore arise in the areas of policies, processes, templates and tools.

Because efficient and above all uniform methods are often lacking, which could quickly identify core problems of projects (and can quickly avert them), senior management – despite high standardization in project management – is often surprised by projects which

  • are behind schedule,
  • overrun the budget
  • and do not achieve the agreed scope

which in turn leads to

  • Customer dissatisfaction and
  • not achieving the business goals

An early warning system (EWS) contains questions on the project status, which are to be answered monthly by the project managers in the form of a questionnaire.

Objectives of the early warning system

The objective of the Early Warning System is to develop and/or integrate a set of tools and processes that quickly identify potential project problem areas and provide a meaningful tool for escalation and problem resolution as long as they are still available in a simple form to avoid surprises.

The detail goals can be:

  • Introduction of a simple, scalable system that is easy to maintain through state of the art technology.
  • Introduction of a system that enables problems in projects to be identified and eliminated in the quotation phase, start up phase and run & maintain phase.
  • Introduction of processes and tools that cannot be bypassed and ignored; to confirm compliance to processes and tools.
  • Use the EWS results to extend existing reports with the EWS information.
  • Ensure tight time-boxing from problem identification to resolution.
  • Develop a management communication plan to continuously inform senior management about the consistent implementation and enforcement of EWS tools, processes and reporting across the organization.

The success factors of the early warning system

In order to ensure a global early warning system, the following success factors must be observed:

  • Timely and accurate evaluation of program/project status related to key indicators.
  • Line management with profit & loss responsibility for programs and projects is responsible for responding to negative responses and tracking actions until completed.
  • The questions must be examined intensively by senior management.
  • The questions must be used globally unchanged in all possibly existing regional systems.
  • Program and project managers answer these questions monthly for each project.
  • Standard reports are made available to program/project sponsors to support action tracking.

Objectives of the early warning system

The following questions represent a selection for an early warning system. When adapting for specific organisations, the relative deviations are also adapted in the form of numerical values. The so-called risk response indicates the response option, which leads to a forced commenting of the entry and serves as an “alarm signal” in a consolidated evaluation.

#QuestionRisk Response
1Did the last customer survey score more than 3.5 points (out of 5)?
No
2Is the project plan updated and recalculated weekly with work done and remaining work?
No
3Are all approved change requests mapped in the project plan?
Yes
4Does the staffing run according to the planning in the project plan?Yes
5Has joint project governance been adopted?Yes
6Has a steering committee been held in the last 30 days?
No
7Is the Schedule Variance > 10%?
Yes
8Is the cost variance > 10%?
Yes
9Has the project done any work outside the approved project defined scope? Yes
10Have all deliverables performed so far been accepted?No

In a database system, the questions in the “Answer” field must be answered with “Yes/No”.

If a question is answered positively, then this question is finally answered.

If the answer to a question is negative, the project managers are asked to enter measures to solve the negative situation.

  • “Action” field: Enter measure to solve the negative situation
  • “Responsible” field: Select the name of the person responsible for the action.
  • “Planned date” field: Enter the date by which the task is to be completed (planned date).
  • “Status” field: Select the status of the action.

The results are ideally presented in a company-wide web-based EWS tool to create central reports and evaluations.

The link with a project management handbook questionnaire

If (worldwide) uniform guidelines, processes, tools and templates are available in the project management area, an extension of the questionnaire should be considered.

A detailed survey should be carried out initially at the start of the project and in the case of significant project changes by means of a detailed self-assessment questionnaire, which clearly goes beyond the following possible questions on the EWS supplement.

#QuestionRisk Response
1Was the project definition template from the project management handbook used?No
2Has the estimation procedure and the estimation templates been used according to the project management handbook?No
3Is there a weekly Earned Value calculation based on the current project plan?No
4Are problems, risks, acceptances, change requests continuously recorded in the template from the project management handbook?No

Personal observations on the EWS

I was able to observe the following findings during the supervision of project managers on the subject of EWS and the evaluations:

  • Despite very precise and unambiguous questions, additional explanations (ideally in the form of a manual) to the project managers and, in the other direction, comments on specific issues by the project managers are often required. Uniform guidelines by the central authority for specific non-standardized cases are to be ensured. This ensures the quality of the early warning system in these cases as well.
  • The project management handbook supplementary questions confirmed that only project and program managers who had already been trained could provide meaningful answers. It is better to not ask as a mandatory question in order to not dilute the quality of the statements.

When analysing the adaptation of a comparable system in an organisation, the following basic considerations arise:

  • The first questions can be transferred almost completely to other companies.
  • Such a supplementary (parallel) reporting can only be enforced by global guidelines. Regional or even departmental initiatives would experience too much resistance.
  • An automatic notification and reminder for the creation of the EWS report must be provided.
  • A monthly frequency may prove to be too low for companies with smaller projects on average.
  • An automatic analysis of the results is required, taking into account the additional manual comments. An analysis without consideration of the additional comments results in a wrong picture of the overall evaluation.
  • As with all other reporting, it should also be noted here that an early warning system can also be excluded for particularly confidential projects / customer environments.
  • The reports must be mapped IT-technically in such a way that they (almost) cannot be circumvented and ignored; in order to confirm the compliance to processes and tools. These should, for example, be linked to the filing of the official status report.
  • The EWS results should be integrated into existing reports in order to inform the classic addressees of the project status report about the additional status of the early warning system. This ensures that this group of recipients also carries out a direct or indirect quality assurance of the information.
  • The results of the early warning system should be regularly compared with complete project or programme audits in order to validate and continuously improve the meaningfulness.
  • In a project, the early warning system must not be triggered initially by the first filing of a project status report, but by the creation of project numbers or project codes, for example.
  • The early warning system should be introduced in stages. First, only projects with high project volumes or complexity should be included in the scope (it is important to apply hard criteria). This also allows the analysts to better manage the project manager’s support efforts.

Published by

Marc Widmann

My name is Marc Widmann, husband, father of two sons, enthusiastic amateur photographer and lives in Hattersheim near Frankfurt. In my daily work I manage projects and programs in the field of information technology. I coach project managers and audit projects. I have many years of experience in consulting and IT outsourcing with project portfolio management tasks. I particularly enjoy working with international teams at Tata Consultancy Services. I volunteer my time at the Gesellschaft für Projektmanagement (GPM-IPMA) as an assessor in project management personal certification. I myself am also certified as IPMA Level A Certified Project Director (GPM) and IPMA Level B Certified Senior Project Manager (GPM). More about me.

Leave a Reply

Your email address will not be published. Required fields are marked *