Escalation Rules

2 min.

Summary

Escalations are nothing bad in the project or program. They are the demand for spontaneously necessary or not yet taken decisions in a defined way – provided that a regulated governance is established.

Rules

The facts of the case should always be described and agreed upon by both parties (customer and contractor).

Contents of the escalation

  • Precise description of the facts so that they can be understood directly by third parties.
  • In what area and at what time did the facts arise?
  • Who put the facts on the agenda in which reporting medium (e.g. weekly status report)?
  • What has been done to avoid the original risk or problem, to solve it when it occurs or to mitigate it?
  • Who was involved in the solution search?
  • How time-critical is the situation or by when is a solution needed?
  • Identification of the degree of risk and evaluation of the impact.
  • Which activities are proposed for the solution?
  • Description of the solution approach with estimation of the timeline, the resources and the name of the person responsible for the solution.

Communication

  • Escalation always via e-mail. Mails that do not contain all of the above should be returned.
  • Clear mention of the word “ESCALATION” in the subject line as well as in the mail itself.

Further information on the communication rules can also be found here.

Escalation steps

  • All possible measures should be taken to resolve an escalation issue at the lowest level. Before starting an escalation process, the consequences should be clearly articulated.
  • At each stage, an attempt should be made between both parties to find a solution. If this is not possible, the escalation issue should be passed on to the next escalation stage after prior agreement and taking into account the number of escalation days. (Escalation days = length of stay in working days at an escalation level)
  • The project manager is responsible for solving the problem and remains so at every escalation stage.
Escalation Pyramid

Project Early Warning System in 10 questions

5 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!

Project planning software – everything just crap?!

1 Minute

Summary:
Using a project planning and control software only as a visual representation of the planning status is a waste of time. A few tips have to be followed and MS Project and Co are also very useful for project monitoring and control.

I often hear from prospective project managers, but also from experienced project managers, that a project management tool such as MS Project is not practicable. It is too complicated and the actual control is not really possible.

If you consider the following tips nothing will go wrong anymore:

  • Set in the options that MS Project or the tool of your choice will base the planning on “fixed work”.
  • The availability (hourly capacity and holidays) of resources/qualifications must be entered in the project calendar.
  • Do not set a manual date (fixed date), except project start or finish date.
  • For each task / work package, a predecessor (at least the project start milestone) and successor (at least the project end milestone) must be entered.
  • Do not enter a duration, only the effort for the task / work package.
  • Only one resource/qualification should be entered for each activity.
  • Always display the critical path in the schedule (Gantt). This must be displayed throughout the entire project duration without interruption. Otherwise there is an error, e.g. manual date set.
  • Only plan detailed for a maximum of 2-3 months in advance (resources and effort).

And the last obstacle is again and again that your company does not invest an MS Project license for you. Then get ProjectLibre as Opensource or another freeware.

Meeting Agenda

2 min.Effective meetings are always a challenge. There are many guidelines and checklist available for meetings. But up to now I have not found a good template for an effective meeting agenda.

In my daily usage I identified the need for two different agenda formats depending on the length of the meeting or better the number of agenda topics.

Having a telco I always use following simple format (in case not many topics need to be covered) since years:

INITIAL SITUATION/AUSGANGSSITUATION

  • Project status needs to be reported to steerco until Friday 12:00 CET

PREPARATION NEEDED / ERFORDERLICHE VORBEREITUNGEN (including owner)

  • Please update your work packages until Thursday 10:00 CET Server Link (ALL)
  • Please update action items status / resolution Server Link (ALL)
  • Update reporting template (ML)

AGENDA

  • Review interface issues between work packages (MW)
  • Align on action items across work packages (MW)
  • Align on Team Discussions items on project server (ML)
  • Issues and risks to be aligned on (ML)

RESULTS EXPECTED OF THE MEETING/ ERWARTETE ERGEBNISSE DES MEETINGS

  • Aligned view on the project status

NEXT STEPS AFTER THE MEETING/ NÄCHSTE SCHRITTE IM NACHGANG ZUM MEETING

  • Report to be consolidated (ML)
  • Report to be reviewed and send to steerco (MW)

 

For face2face workshops or long lasting telcos I prefer using following format also for many years:

Berlin, Hauptstr. 14-16, 1.OG, Room E1.15a, Monday 05. Feb 2018 – CMO FMO Big Picture
Goal: Common understanding of CMO and FMO Big Pictures and related activities
Approach: Time Boxing
Preparation: Presentation: Link on Server
Materials: 2 beamers, moderation suitcase
Time (CET) Topic Host Input and preparation needed / Owner Result expected / Owner  Attendees 
09:30 – 10:00 Introduction and target of meeting MW  Introduction – no preparation needed  All  All
10:00 – 10:30 CMO Picture Overall  LI  Slide deck / LI Common understanding of the CMO  All
10:30 – 10:45 Break        All
10:45 – 12:45 CMO / FMO INM  LI Understanding CMO slide deck on specific process / LI Black Board FMO Picture / CS LI, CS, MA, UA and UA
12:45 – 13:30 Lunch break in restaurant        All
13:30 – 14:15 CMO / FMO PRM  LI Understanding CMO slide deck on specific process / LI Black Board FMO Picture / CS LI, CS, MA, UA and AB
14:15 – 15:00 CMO / FMO CHM  LI Understanding CMO slide deck on specific process / LI Black Board FMO Picture / CS LI, CS, MA, UA and SE
15:00 – 15:30  CMO / FMO CFM  LI Understanding CMO slide deck on specific process / LI Black Board FMO Picture / CS LI, CS, MA, UA and ME
15:30 – 15:45 Coffee Break       All
15:45 – 16:15 CMO / FMO CPM  LI  Understanding CMO slide deck on specific process / LI Black Board FMO Picture / CS KE, CS, MA, UA and KL
 16:15 – 17:00 Wrap up and next steps  MW   Action item log updated. / MW

Work package descriptions amended. / work package owners

Steering Board Decision preparation / LI

 All

 

Advantage through early warning in the project – team spirit as an indicator

4 min.

– Methodical usage of emotions in the project –

Summary

As a project portfolio manager you want to avoid full blown up project audits in all of your projects to identify potential deviations. Therefore you may use a very simple survey to avoid any surprises.

As project director or project portfolio manager, you also have another early warning system at your disposal.

As a project or program manager you want to compare your current endeavor with previous engagements in a very simple way.

There are multiple ways to gather the team morale in project teams. I am using following approach for a few years now with reliable and sound results.

There is a systematic way in doing so by gathering “SmileyPoints” via an online survey tool. Examples for free tools are kwiksurveys.com, the free version of surveymonkey.com or Google Forms.

Questions to gather in the survey

  1. “How happy are you being on the program/project?” Then the below picture should be attached to this question.
  2. “What can Program / Project Management do to improve?”
  3. “What can you do yourself do to improve?”
  4. “Rumor Box: If there are rumors around and you have any questions related to these please let us know here to clarify.”

In larger programs you may add a question to identify the participant’s team assignment to be able to give indication on the discrepancies between the different teams within the program.

The survey should be run every second week in case of a longer lasting projects or programs. It can be a good trend indication during the project life cycle. The minimum participation of project members should exceed at least 10% of all project team members. Less will not be representative. For smaller teams a higher minimum participation ratio must be achieved.

Result interpretations

The average and the standard deviation of all results of responses to question number one gives you a clear indication on the team morale within the program or project team.

The higher the standard deviation of all values to question one the more obvious are
– a lack of communication within the team
(especially from top to down and bottom to up)
– roles and responsibilities not well defined or not transparent to the team and
– the scope not well defined or not transparent – at least to the extended team

The lower the average value of the results to question one is the less attractive is the project for the team members. Therefore the enthusiasm being part of the project is lower too. In very critical project situations (e. g. work life balance not achievable due to work load) the average tends to be low.

Now the question comes up of there is a *correlation between standard deviation and average”? Not really in all instances. The standard deviation should be low in a well-organized program. In the same over-worked organization if such things as structures, roles and responsibilities, communication channels, scope are well defined and transparent to the team the standard deviation should be still low.

The next questions is what is low and what is high”? A good one! Experience shows that values between +2 and +4 as an *averageare very common for projects in good shape. Of course there is a tendency for new joiners in a project to rate their personal happiness in areas of +6 to +10. These artifacts need a critical mass of responses to balance out.

This does not support the hypothesis that a new project with new team does automatically mean a good SmileyPoint average value. The team as a whole is well observing all team quality criteria before providing their SmileyPoints and in average the rating will be again to the “real” value.

On the other end of the SmileyPoint scale low average values as -6 to -2 indicate projects which are in a turnaround mode or at least in a need to turnaround. Immediate actions need to take place.

For standard deviation following pattern can be identified. Values of 6 show massive deficit of structures implemented, missing role definitions or at least transparency on it. Criteria e) to i) from below listing do impact the standard deviation up to my experience. Programs in a good shape show a standard deviation of less than 3. 

Of course a survey like this will not replace individual talks and interviews but it gives you a very precise supporting evidence of your findings in conversation or at least an initial feeling in case you did not have any contact to the program at all.

In a next posting I will list a couple of elements and ideas on what to implement to improve the SmileyPoints in your team.

Your comments and participation to improve SmileyPoints

Use SmileyPoints actively in your projects!

Your comments and active participation are welcome. Both can be entered in the following survey and you will be informed about new findings on request.

This values shall be gathered
– average and
– standard deviations
– number of participants out of total number of team members

from some of your projects and programs. Especially helpful would be if you can add a typical auditors or your personal rating on the same scale from below on following topic clusters:
a. team morale within the extended team
b. program financials in good shape and transparent to the project management
c. infrastructure well established (e. g. printers, office space)
d. right skills on board
e. architecture and solution well defined
f. methodologies applied properly
(e. g. project planning, issue and risk management)
g. roles and responsibilities and structure well defined
h. scope and acceptance and completion criteria well defined and transparent
i. governance well defined and in place

Please use this form to submit your feedback to improve SmileyPoints.

This article was originally published on 23.07.2011 on GooglePlus.