Lynda Bourne

Using Project Controls for Effect

Using Project Controls for Effect
Decrease Font Size Increase Font Size Text Size Print This Page

Light_never_turnsDescribing scheduling, Earned Value and financial management as ‘project controls’ is, I would suggest dangerous!  The steering mechanism on a car is a control system, you move the steering wheel and the front wheels turn; and if the car is in motion its direction of travel is altered. Control systems cause a change.

Altering the duration of a task in a schedule, or calculating the current CPI and EAC for an Earned Value report changes nothing. All you have is new data. If the data is going to cause a change three things must occur. First the data needs to be communicated to the right people. They need to receive, understand and believe the data (this changes the data into information). Then they need to use this new information to change their future behaviours.

This is a communication process. The challenge facing schedulers and other ‘controls staff’ is recognising their primary role is communication not controls. Certainly they need to be able to gather and process information effectively but this is wasted effort without equally effective communication.

Their challenges include identifying the right people to communicate with (the project manger is only one), formatting the data in a way that can be easily understood by the receiver (without understanding there will be no action) and focusing the information on what matters in the future.

No one can change the past and it is always too late to change the present. The only value a ‘project control tool’ can offer is influence future actions and decisions. This requires schedules, cost plans and the like that are as simple as possible to improve communication and facilitate understanding by the project team.  Only after the project team fully understand the information can you expect them to use the information to make wise decisions about future actions.   Project plans are useful if they are being used!

Project Controls as Communication

Designing a project communication system that works is difficult.  To quote from Peter Taylor’s book, The lazy project manager, reporting is not communicating!  No one important has time to read fantastically accurate and detailed reports – they are too busy doing useful things. But at least some of the detail is important. The ways to resolve this conundrum are:

  • Separate push and pull communications – make the detail available in a repository (eg, a project portal) where people who need the detail can easily retrieve it (pull).  Anything you send out (push) should focus on the important highlights and information that needs actioning by the receiver.
  • Separate history from future.  Reporting what happened last week is of no value to the project unless it contains information that can usefully influence future decisions.  Historical data is needed by accountants and business administrators. The information project leaders and team members need is forward looking focussing on what’s predicted to happen in the future and what needs to be done to improve the situation.
  • Focus on the needs of the receiver. Make sure they get the information they needed to help make the project successful.  Team members need to know what work to do in the next week or two.  Managers need to know what they have to decide.

Achieving this type of communication requires planning and information design. Each element of the overall ‘controls’ system needs to be elegantly designed to support both management decision making and the work of the project – avoid unnecessary complication and duplication.

More importantly, the communication effort needs to be planned to focus on the important stakeholders that influence success; both internally to leaders within the team and externally to decision makers and influencers (more on this later).

Then KISS – keep your communication as simple as possible (but no simpler), and remember Cohn’s Law: The more time you spend in reporting on what you are doing, the less time you have to do anything. Stability is achieved when you spend all your time reporting on the nothing you are doing.

Communicating for effect

Communicating effectively with stakeholder in the ways outlined above is a very resource intensive process. Every project team will have far more stakeholders to potentially communicate with than they have either the time or the resources to manage.

Selecting the ‘right’ stakeholders for a sustained communication effort at the ‘right time’ in a project is not simple; some are obvious and important but others can be noisy but largely irrelevant or hidden and important.  My research over the last ten years developing the Stakeholder Circle® methodology has suggested a three phased approach works best.

Step one is to identify the stakeholders for the project, understand what you need from them and importantly what they want from the success (or failure) of the project. This is called ‘mutuality’ and is critical to understand when you are planning your stakeholder communication effort. If you can show the person they are likely to achieve at least some of their aims, they are far more likely to provide you with what you need. This applies equally to internal stakeholders and external influencers.

Step two is to work out who is important; this requires assessing and integrating at least three aspects for each stakeholder:

  • The most obvious is how powerful the person is. Can they close the project down, force change, are they essential for the work or do they have little direct impact?
  • Power is offset by the concept of ‘urgency’; how much effort is the stakeholder likely to invest in asserting their position or ‘rights’?  Some stakeholders will go to almost any lengths to assert their position; others are really not that interested.
  • The third is proximity.  People actively working on the project have more impact than those who are relatively distant.

Combining these factors in a model allows the relative importance of each stakeholder to be determined ‘at this point in time’.

Step three is to determine the current attitude of each important stakeholder based on how supportive or opposed they are to the project and how receptive they are to your communication. It’s nearly impossible to change someone’s attitude if they won’t communicate with you!  The current situation needs to be compared to a realistic optimum situation for each person. The optimum for some people may be passive opposition (ie, they are unlikely to take any action) others may need to be actively supporting the project.

Now you have the information needed to focus your communication efforts where they can achieve the greatest benefit.  People who already have the optimum attitude simply need ‘business as usual’ communication.  On the other hand, important stakeholders who are assessed as having a less then optimal attitude need heroic communication efforts to change their attitude if the project is going to succeed.

The last piece of the equation: people change – your communication should cause change and people’s attitudes change over time anyway.  Reassessing the stakeholder community on a regular basis is important to ensure the communication plan is working and to update it where necessary. This is also an important lead in to undertaking a project risk review.  A very high proportion of project risks are directly linked to stakeholders, but more on this later.

Conclusion

Using the data generated by project controls systems to provide useful information to the right person at the right time still won’t make your tools into ‘control systems’ – there’s still no direct cause and effect. However, you can make the data into useful information that can have a powerful influence on the future actions of the key stakeholders.  Achieving this objective goes a long way towards making the planning system ‘useful’.

Leave a Reply

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

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>