This document discusses developing a Project Early Warning System (PEWS) to detect potential issues in a project early. It recommends engaging the entire project team to serve as "eyes and ears" to log any issues. Technical team leads act as "gatekeepers" to filter issues and escalate important ones. Signal detection methods include earned value tracking, risk management, and external scanning of related projects, stakeholders, and the operational environment. The document provides templates for tools like SWOT analysis, stakeholder analysis, and assumption surfacing to aid in anticipation. It emphasizes issue logging and regular review meetings to address problems before they become major crises. The goal is to move from reactive "management by crisis" to proactive management through early issue
1. David Whelbourn January 2007 Page 1 of 7
New Year’s Resolution for Project Managers for 2007
As project managers, we bear the responsibility to deliver our projects within the
agreed constraints. No one is expecting a 100% success rate -- well perhaps some
unforgiving organizations do.
But we should be seeking continuous improvement. This means that as PM’s we must
continue to learn and develop our professional knowledge in order to improve our
project delivery performance.
So make yourself a new year’s resolution to improve your personal project delivery
performance. I have a tip for a quick win area that will also improve your general
management style.
My new year’s resolution tip for you is: Develop a Project Early Warning System
What on earth is a Project Early Warning System, I can hear you asking?
I served in the military for twelve years and we always used early warning systems to
keep us safe. These ranged from the technologically advanced ground radar to spot
intruders, down to the basic trip wire of twine and a tin of pebbles. Around us wildlife
use early warning systems all the time; animals pick up on each other’s alarm calls
and use them as warnings well before they detect any danger.
But my idea of a Project Early Warning System is not based only on my tin can with
pebbles and some bits of twine or a few bird alarm calls experiences.
In the mid seventies (the same time as I listened for rattling tins) Igor Ansoff, a
professor in mathematics and a management guru working in strategic management
approaches, developed a management theory on Weak Signals. He used this theory to
develop the idea of a Strategic Early Warning System.
The aim of a Strategic Early Warning System (SEWS) is to assist organizations in
dealing with discontinuities or strategic “surprises.” By detecting “weak signals” (Igor
Ansoff, 1975), SEWS allows organizations to react strategically ahead of time. The
same applies to your project.
Project Early Warning System
In project management, it should be the same; in fact, as a PM you need a project
early warning system more urgently than any CEO does. Your project probably has a
fixed end date, and it would be useful to detect issues long before they become time
consuming crises?
Management by after the fact is not a good option for project managers. It is fine
when the rate of change is slow and there is enough time to react.
Some project managers use Management by Extrapolation in the form of Earned
Value Tracking to give them an early warning of things going wrong in the project
delivery.
Others use Management by Anticipation, using risk management techniques to
identify potential problems and their impact, and then formulating mitigation
strategies. PM's also use their experience and knowledge to pre-empt any issues by
planning tasks and activities that reduce the risk of a crisis.
2. David Whelbourn January 2007 Page 2 of 7
Another form is Management through Flexible Rapid Response. They have the
foresight and some say luxury to add in the contingency to put a Tiger or SWAT team
in place to tackle an unexpected crisis. Their experience tells them that one will
probably arise from somewhere before the project is completed.
Now that we understand what the purpose of a Project Early Warning System (PEWS)
is, the question is how do we actually set up our PEWS?
Will we be using bits of twine and tin cans with pebbles to tell us of an imminent
attack? Or do we have some amazing ground tracking radar capable of detecting
really weak signals so we have plenty of time to prepare?
To answer this question, let’s first take a leaf out of the animal kingdom’s book of
early warning. To create an effective early warning system you need to engage as
many pairs of eyes, ears and brains as possible. But unlike the wildlife, we can
purposely set up processes to help scan the horizons (lookouts). Once we have found
the issues we can use some tools and techniques to filter the signals and react
sensibly to them.
The Early Warning Team
Employ the whole project team as your eyes and ears, and ensure that all have access
to the issue logging procedure/tool and feel it is okay to log issues that may be
dispatched easily or go nowhere.
Remember, an early warning is what you are after. Do not let the filters go on the
weak signals before the issues are logged. Treat issue logging similar to brain
storming; put all thoughts on the board and filter after.
Gatekeepers
To stop you from being overwhelmed with issues, take your technical team leads and
employ them as gatekeepers to watch over their specific area of issues in the log and
use their judgment to filter and synthesize the information.
They should be able to manage the issues with quick responses to questions and
requests for information. Plus they can amplify the weak signals so the project
management team can review them.
Develop Signal Detection Methods
Utilise some of those already identified
o Earned Value
o Anticipation using risk management and other methods such as SWOT analysis,
Stakeholder analysis and Assumption Surfacing (see appendix)
o Build in some contingency for your Tiger Team
o External Scanning by the gatekeeper. This could include the environment
external to the organization the project will deliver into
o Internal Scanning with the project team
External scanning would include items such as:
o Technology reviews / articles. Why not actively initiate a literature search for
other projects in other organizations similar to yours and use your gatekeepers
to review their respective area in the related projects to look for issues/weak
signals.
3. David Whelbourn January 2007 Page 3 of 7
o Analysis of stakeholders either external to your project or on the outer edges
of the project. These outer edges are the places where someone often lurks to
throws hand grenades into your peaceful project, or ambush you just when you
think the requirements have been defined or business change has been
accepted.
o Another external scanning target could the operations section where your
project will transition its end product in. Ensure that there are no issues
lurking in the transition stages. Just when you think the project close is about
to be triggered, someone always seems to shout WHOAAAA!
Issue Logging & Tracking
The biggest tool to help you is the Issue Log. Recording issues enables you to start
knocking off those easy to deal with issues. Your gatekeepers can review their
relevant sections, answering any queries or escalating them to the appropriate person
to be answered. Track them through to the end. Do not allow them to sit and fester
because without treatment they will grow into a big ugly resentful catastrophic crisis.
Issue reviews
Weekly review of outstanding issues can be combined with a review of the risks that
may be approaching. Check to be sure that the Gatekeepers are managing their issue
groups.
4. David Whelbourn January 2007 Page 4 of 7
Work with your team to review and react to the issues; ensure that they are
evaluated for the impact and timing.
If you need to trigger immediate action, consider using the same approach that
Toyota has adopted on the Lexus line. When a worker spots a problem, they hit a
button which stops production line for the whole factory. This drastic measure
ensures the problem gets the attention it deserves, rather than the worker applying a
band-aid solution on the fly. How many computer systems have gone live with band
aids in place only to fail once pressure is applied?
Here ends my tip for a New Year’s Resolution for improving your project management
capabilities. Best Wishes and Good luck for 2007
David Whelbourn PMP, MBA
Appendix A – Anticipation Analysis Techniques
S.W.O.T Analysis
Technically this is a management technique for analysing an organization. The aim is to
brainstorm the strengths, weaknesses, opportunities and threats that apply to the
organization. There is no reason why you cannot carry this out for your project.
First identify the objective of the project and with this objective in mind, use SWOT analysis
to to help in the pursuit of the objective
o Strengths: attributes of the organization/project that are helpful to
achieving the objective.
o Weaknesses: attributes of the organization/project that are harmful to
achieving the objective.
o Opportunities: external conditions that are helpful to achieving the objective.
o Threats: external conditions that are harmful to achieving the objective
Correct identification of SWOTs is essential because subsequent steps in the process of
planning for achievement of the selected objective are to be derived from the SWOTs.
5. David Whelbourn January 2007 Page 5 of 7
Assuming that the objective is attainable the SWOTS are used as inputs into a creative option
generating process by asking four questions:
1. How can we Use each Strength?
2. How can we Stop each Weakness?
3. How can we Exploit each Opportunity?
4. How can we Defend against each Threat?
Stakeholder Analysis
Identifying the stakeholders, their groups and assessing their interests in your project will
help you identify potential issues. Compare the groups with their related groups for influence
and problem awareness. Then assess their importance. Below are a set of worksheets that you
can you use.
Stakeholder
Group
Nature of Interest
Internal or
External
Importance to
the change
Posture
Level of
Affect
Top
Management
Group
TMG
Cost reduction by
reduced marketing
expenditure
I High Support High
Sales
Management
Group
SMG
Reduced close time
Improve productivity
I High Support Medium
Sales Staff
SS
Improved commission by
closing more deals
I Low Oppose Low
CHARACTERISTICS OF STAKEHOLDER GROUPS IN THE PROJECT
Stakeholder
Group
Special
Expertise
Stakeholder
power
Previous
Problem
Experience
Typical
Problem
awareness
Contribution
To Solution
Top Management
Group
Medium,
delegated
decision to
SMG
Sales
Management
Group
Full
understanding
of the sales
process.
High
Responsible
for Decision
Already had
failed attempt to
implement
standard solution
Process
Definition
Sales Staff Group High
Influence
Workflow
Definition
Prospects &
Customers Low, unaware
6. David Whelbourn January 2007 Page 6 of 7
Importance to the success of the Solution
Posture of
the Group
Low Importance High Importance
Oppose
Sales Staff
Neutral Top Management Group
Support Sales Management Group
Assumption Surfacing
The aim of this technique is to make underlying assumptions more visible.
1. Identify Assumptions you have made and what assumptions you made to make
this choice.
2. List the assumptions and write the counter assumptions not necessary the
negative but the opposite to the issue it represents.
3. Work down the list and delete the ineffective pairs i.e. the ones that it
wouldn’t make much difference which assumption you chose.
4. Assess each remaining assumptions in terms of high or low potential impact and
high or low likelihood
5. Plot them in a 2x2 matrix high/low impact on one axis and high/low plausibility
on the other axis.
likelihood
Low High
Potential
Impact High
Medium Most
Serious
Low
Least
Serious
Medium
6. High impact and high likelihood are obviously the most crucial, but high impact low
likelihood assumptions need to be taken seriously, in case they turn out to be true
References
Ansoff, Igor H., Strategic Response in Turbulent Environments, Working Paper No. 82-
35, European Institute for Advanced Studies in Management, August, 1982, pp.41.
Coffman, Brian S., Weak Signal Research, Part I: Introduction, Journal of Transition
Management, January 15, 1997
Coffman, Brian S., Weak Signal Research, Part III: Sampling, Uncertainty and Phase
Shifts in Weak Signal Evolution, Journal of Transition Management, January 15, 1997,
7. David Whelbourn January 2007 Page 7 of 7
Mannermaa, Mika, Tulevaisuuden hallinta- skenaariot strategiatyöskentelyssä,
Ekonomia-sarja, WSOY, Porvoo 1999, p.87-92.
Åberg, Leif, Viestintä- tuloksen tekijä, Infoviestintä oy, Helsinki 1996, p.245-254.
Coffman, Brian S., Weak Signal Research, Part IV: Evolution and growth of the Weak
Signal to Maturity, Journal of Transition Management, January 15, 1997,
Lücken M., Blaisch F.& Klopp M., Understanding the Company’s Future and Installing a
Premise Controlling”, in Performance Measurement- Theory and practice, p. 71-81
Cambridge, 1998.
Ansoff, Igor H., Implanting Strategic Management, Prentice/Hall International, 1984,
pp.510.
Elina Hiltunen,
Conference paper for Seminar on Scenario Building - Turku - June 2001
Ilmari O. Nikander
Early Warnings - A Phenomenon in Project Management 2002