Project Early Warning System in 10 questions

6 min.

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.

Handover of a Program in 6 Phases

2 min.

If you are leaving a program, you should consider a few things when preparing and handing over the program. Here, a 6-phase approach has proven to be the best for me, which I use again and again.

1. Preparation (as early as possible!)

  • Align with stakeholders
  • Outline Knowledge-Transfer-Plan
  • Agree budget for knowledge transfer period
  • Search for successor and receive okay on specific person from stakeholders
  • Confirm final start date of successor (adapt timeline of knowledge transfer plan)

2. On-boarding (-3 weeks)

  • Successor starts on project as additional source
  • Project assignment to be defined
  • Onboard successor following all regular administration activities as access rights, calendar invites, handover process documentation etc.
  • Introduce successor in newsletter
  • Shadowing (-2 weeks)

3. Shadowing (-2 weeks)

  • Successor is your current stand in if anyhow possible
  • Successor attends all of your meetings too
  • Successor is watching all of your core activities
  • Successor updates and amends joint knowledge transfer plan and ticks off activities

4. Re-Shadowing (-1 week)

  • Show less presence, only attend team meetings but no customer meetings
  • Be there for any help for your successor
  • Be prepared to take over some operational activities
  • Send all still incoming requests / questions to your successor

5. Backup (starts with day of handover)

  • Show less presence, only attend team meetings but no customer meetings
  • Be there for any help for your successor
  • Be prepared to take over some operational activities
  • Send all still incoming requests / questions to your successor

6. Phase Out (+1 week)

  • Process all off-boarding activities for yourself
  • Release Project Assignment
  • Be there to help your successor
  • Do not take any operation tasks anymore
  • Give a farewell party and say good bye in the newsletter.
  • Send all still incoming requests / questions to your successor
  • Leave! (+2 weeks)

Success factors for a proper handover

  • Involve customer and all stakeholder in an early stage.
  • Do not arrange processes program / stream person centric but process / accountable centric.
    • Do not be single point of contact for multiple processes yourself,
    • Instead make each of your team member accountable for one or more processes from the beginning of the engagement (Management by Objective).
  • Plan and prepare your leave as an own project itself.
  • Prepare a knowledge transfer plan which must be agreed by all stakeholders.
    • Break down knowledge transfer in granular activities (1-3 hours).
    • Ask your successor to maintain this plan and tick each closed activity off.
    • Handle this plan and update it like any other project plan.
  • Communicate your leave to whole team latest at beginning of knowledge transfer period.
  • Foresee a backup period after successful knowledge transfer of up to two weeks.
  • Define a clear handover date in knowledge transfer plan.

Have fun in your new project / program!

Agile vortex?!

3 min.

Summary

Agile work or delivery is only possible if necessary decisions can always be called up. It also does not work without appropriate governance. There is huge similarity in turnaround situations of classical projects with the approach of agile projects. The focus here is on short iterations and close coordination with the customer. The introduction of agile principles should be based on this observation. Agile principles will continue to spread differently in different industries. But whoever thinks of agility about method or technology is wrong! Early results in the project and close coordination with the real customer are not method or tool results.

Agile project management does not work without appropriate governance

Agile work or delivery is only possible if necessary decisions can always be called up. In my article “Communication Principles in a Project” it is easy to see that the short time until a decision is made is extremely important. This is often slowed down or even blocked by the middle layers of management in a company. This so-called permafrost cannot comprehend the need for agility often sensibly identified by top management. Likewise, decisions necessary in the course of the project cannot be made by the senior management themselves, as are not be placed correctly with them.

Agile project management is very similar to the approach of classic projects in turnaround situations

In both cases, the focus is on short iterations and close coordination with the customer. The introduction of agile principles should be based on this observation. The classic project plan is then usually only a reference for contract-relevant delivery items. The chain of failure in projects is the customer relationship and thus the governance structure, then the tools and processes and at the latest the employee frustration. When introducing agile principles, the sequence is exactly the other way around. In my experience, the team atmosphere in project organizations can indicate a wide variety of problems at any time, and not only that “something” is wrong, but also in which project management domains (see my article SmileyPoints). It would also be interesting to use this method when introducing agile project management.

How will the agile vortex spread now?

As can be deduced from my article “Project Manager in 2030“, the agile principles will continue to spread differently in different industries. What this “agility” will look like, whether pure SCRUM, SRUM of SRCUM, Kanban, scaled agile, SAFe, LeSS, Spotify will be shaped by the customer and company environment (i.e. products, services, industry, size, etc.). Is “classic project management” dead? Certainly not, because there are certain complex (very large programs) and complicated (repetitive projects) for which classical project management will be the better alternative. Nevertheless, it makes sense for the classic project manager to make tool picking out of the agile box. But whoever associates agility with method or technology is wrong! Early results in the project and close coordination with the real customer are not method or tool results. Concepts and planning are required in both approaches. Approaches such as scaled agile approaches e.g. SAFe take this aspect particularly into account.

The challenges for product owners or project managers

The challenge for the drivers of ventures, whether product owner, project manager or program manager, will now be that they should play different instruments in different environments. Because the dogmatic orientation “we only do agile single projects” can only take place in companies that have no need for diverse interfaces and environments. The exclusive product owner or program manager will therefore rather remain the rare species. A stigmatization of the two approaches is therefore certainly not meaningful, but the combined application or simply said the agile classical project is the future. Early and constant results and close end customer coordination are the success factor in all projects.