Tag Archives: Project success

Setting up a project controls system for success

A couple of hour’s hard thinking can make the difference between project success and failure!  Far too many projects are simply started without any real thought as to the best strategy for delivery and what control systems are really needed to support the management of that delivery – one size does not ‘fit-all’ and simply repeating past failures creates more failures.  Similarly, far too many control systems are implemented that simply generate useless paperwork (frequently to meet contractual requirements) when what’s needed is effective controls information.

Remembering that all project controls documents have to be used and maintained to be useful; the three key thinking processes needed to help build project success are:

  • First the big question – how are we going to do the work to maximise the opportunity of success and optimise risk??  This is a strategic question and affects procurement as much as anything – off-site assembly needs a very different approach to on-site assembly. This does not need a complicated document but the strategy does need to be agreed; see: www.mosaicprojects.com.au/WhitePapers/WP1038_Strategy.pdf
  • From the strategy, the project management team structure can be designed to best manage the work as it will be accomplished and these people (or at least the key people) can then contribute to the planning process. Pictures are as useful as anything to define the overall flow of the work; see: www.mosaicprojects.com.au/WhitePapers/WP1039_Project_Planning.pdf.
  • Once you know the way the work will be accomplished and the overall flow/sequence of the work you are now in a position to plan the project controls function aiming to apply the minimum amount of ‘controls’ necessary to be effective.  Excessive controls simply waste money and management time. My approach is always to do a bit less then I think may be needed because you can always add some additional features if the need eventuates – it Is nearly impossible to remove controls once they have been implemented.
  • Then you can develop the schedule and other control tools needed for effective management working within the framework outlined above.

This area is what PMI call Schedule strategy and Schedule planning and development. Getting this ‘front-end’ stuff right is the best foundation for a successful completion of a project; this is the reason these elements of project controls have a strong emphasis in the PMI-SP exam.

Conversely, stuffing up the strategy in particular, means the project is set up to fail and implementing control systems that do not support the management structures within the project simply mean the controls people are wasting their time and the time of everyone they engage with.

However, creating a project that is based on a sound strategy supported by a useful project controls system will require some cultural changes:

  • The project manager and project executive will need to take some time to look at strategic options and develop an effective delivery strategy.
  • The organisation and client will need to allow the project controls professionals to work through the challenges of developing a ‘light-but-effective’ controls system and then review/approve the system – this is more difficult than simply requiring every project to comply with some bloated standard controls process that no one uses (except for claims) but should deliver massive benefits.
  • The organisation will need skilled project controls professionals……….
  • And the project management team will need to be willing to work with and use the project controls.

The problem is easy to outline – fixing it to enhance the project success rate is a major challenge.

Some ideas for making project management effective and efficient in 2016

SuccessIt’s a New Year and by now most of us will have failed to keep our first set of New Year resolutions! But it’s not too late to re-focus on doing our projects better (particularly in my part of the world where summer holidays are coming to an end and business life is starting to pick up). Nothing in the list below is new or revolutionary; they are just good practices that help make projects successful.

Most projects that fail are set up to fail by the organization and senior management (see:  Project or Management Failures?).  80% of projects that fail don’t have a committed and trained project sponsor. An effective project sponsor will:

  1. Give clear project objectives.
  2. Help craft a well‐defined project scope.
  3. Remove obstacles that affect project success.
  4. Mediate disagreements with other senior stakeholders.
  5. Support the project manager.

The role of the project or program sponsor is outlined in: WP1031 Project & Program Sponsorship.

Customers or end‐users are critically important to the success of ‘their project’. Unfortunately there is an extreme shortage of ‘intelligent customers’.  A ‘good customer’ will:

  1. Help refine the project scope – no one gets it 100% correct first time.
  2. Convey requirements fully and clearly
    (see: WP 1071 Defining Requirements).
  3. Avoid changing their minds frequently.
  4. Adhere to the change management process.

Every project team needs expertise – this is frequently provided by external experts. Subject‐matter experts should:

  1. Highlight common pitfalls.
  2. Help rather than hinder decision making.

The work of the project is done by ‘the team’. A committed and motivated project team will:

  1. Buy into the project’s objectives.
  2. Identify all of the required tasks and ensure the schedule is complete and accurate.
  3. Provide accurate estimates.
  4. Report progress and issues truthfully.
  5. Deliver their commitments.
  6. Focus on achieving the intended benefits
    (see: WP 1023 Benefits and Value).

Finally, the project manager

  1. Recognises that there is no “I” in project and works with the team and stakeholder community to create a successful outcome
  2. Resolves issues and risks that may arise from the 18 items above quickly, efficiently and effectively.

Making Projects WorkAlmost all of the items listed require action by people other than the project manager – this highlights the fact that projects are done by people for people and the key skill required by every project manager is the ability to influence, motivate and lead stakeholders both in the project team and in the wider stakeholder community.

For more on Making Projects Work see: http://www.mosaicprojects.com.au/Book_Sales.html#MPW

How to succeed as a PM in 2016

On-the-busProjects are done by people for people and through the medium of social media, people power is growing.  Successful project managers know this and use it to their advantage; they create a team culture focused on working with other stakeholders to create success.

Project managers know when they get this right because their project team will challenge, follow and support them, and each other, in order to get the job done. Not only that, but word spreads and other people inside the organisation will want to join the team or be associated with its success. When a PM achieves this, they know they have created something special and paradoxically are under less pressure, can get a good night’s sleep, and as a consequence are fully refreshed each day to keep building the success. This is good for the people and great for the organisation!!

Developing the skills and personal characteristics needed to develop and lead a committed team needs more then technical training. Experience, reflection, coaching and mentoring all help the project manager grow and develop (and it’s a process that never stops). Five signs that they are on the path to becoming a great team leader are:

  1. They’re well liked. Great leaders make people feel good about themselves; they speak to people in a way that they like to be spoken to, are clear about what needs to be achieved[1], and are also interested in their lives outside work and display a little vulnerability every now and again to demonstrate that they are human. They’ll always start the day with a ‘good morning’, the evening with a ‘good night’ and every question or interaction will be met with courtesy. When the team picks up on this the project area will be filled with good humour and great productivity.
  2. They put effort into building and maintaining teams. Designing great teams takes lots of thought and time – you need the right people ‘on the bus[2]’ and you need to get the wrong people ‘off the bus’. A great project manager doesn’t accept the people who are ‘free’ or ‘on the bench’ unless they’re the right people and they’ll negotiate intensely for the people that they really need, going to great lengths to recruit people into the vision that they have. Once the team is in place, they never stop leading it, building it, encouraging it, performance managing it and celebrating it.
  3. They involve everyone in planning. Or at least everyone that matters! The PM identifies the team members and other stakeholders that need to be involved; creates a productive, enjoyable environment, and leads the process. They want to ensure that they get the most out of the time and at the end have a plan that the team has built and believe in.
  4. They take the blame and share the credit. Great project managers are like umbrellas. When the criticism is pouring down they ensure that the team is protected from it. They then ensure that the message passed down is presented as an opportunity to improve not a problem to be fixed. Similarly, when the sun is out and the praise is beaming down, they ensure that the people who do the real work bask in it and are rewarded for it. When they talk about how successful a project has been, they talk about the strengths of the team and the qualities they have shown, never about themselves.
  5. They manage up well. Stakeholder engagement, particularly senior stakeholder engagement is the key to project success[3]. Great project mangers know they need senior executive support to help clear roadblocks and deliver resources and know how to tap into the organisation’s powerlines for the support they need.

Great project mangers are also good technical managers; they have an adequate understand the technology of the project and they know how the organisation’s management systems and methodologies work. But they also know they can delegate much of this aspect of their work to technologists and administrative experts within their team. And if the team is fully committed to achieving project success, these experts will probably do a better job than the project manager anyway.

Projects are done by people for people and the great project managers know how to lead and motivate[4] ‘their people’ to create a successful team that in turn will work with their stakeholders to create a successful project outcome.
[1] For more on delegation see:  http://www.mosaicprojects.com.au/WhitePapers/WP1091_Delegation.pdf

[2] In the classic book Good to Great, Jim Collins says, “…to build a successful organization and team you must get the right people on the bus.”

[3] This is the focus of my book Advising Upwards: A Framework for Understanding and Engaging Senior Management Stakeholders, see http://www.mosaicprojects.com.au/Book_Sales.html#Adv_Up

[4] For more on leadership see: http://www.mosaicprojects.com.au/WhitePapers/WP1014_Leadership.pdf

For Stakeholders, 2×2 Is Not Enough!

The world loves 2×2 matrices – they help make complex issues appear simple.  Unfortunately though, some complex issues are complex and need far more information to support effective decision making and action.  The apparent elegance of a 2×2 view or the world quickly moves from simple to simplistic.

One such situation is managing project and program stakeholders and convincing the stakeholders affected by the resulting organisational change that change is necessary and potentially beneficial.  As a starting point, some stakeholders will be unique to either the project, the overarching program or the organisational change; others will be stakeholders in all three aspects, and their attitude towards one will be influenced by their experiences in another (or what others in their network tell them about ‘the other’).

The problem with a simple 2×2 view of this complex world is the assumption that everyone falls neatly into one of the four options and everyone categorised as belonging in a quadrant can be managed the same way.  A typical example is:

power-interest

Power tends to be one dimension, and can usually be assessed effectively, the second dimension can include Interest, Influence, or Impact none of which are particularly easy to classify.  A third dimension can be included for very small numbers of stakeholders by colouring the ‘dots’ typically to show either importance or attitude.

The problem is you may have a stakeholder assessed as high power, low interest who opposes your work, who you need to be actively engaged and supportive – ‘keep satisfied’ is a completely inappropriate management strategy.

The Salience Model developed by Mitchell, Agle, and Wood. (1997) introduces the concepts of urgency and legitimacy.

Salience

Urgency refers to the degree of effort the stakeholder is expected to expend in creating or defending its ‘stake’ in the project, this is an important concept!  However the concepts of ‘legitimate stakeholders’ and non-stakeholders are inconsistent with stakeholder theory[1] and PMI’s definition of a stakeholder – anyone who believes your project will affect their interests can make themselves a stakeholder (even if their perception is incorrect) and will need managing.  This model also ignores the key dimension of supportive / antagonistic.

The three dimensional Stakeholder Cube is a more sophisticated development of the simple 2×2 chart. The methodology supports the mapping of stakeholders’:

  • Interest (active or passive);
  • Power (influential or insignificant); and
  • Attitude (backer or blocker).

Ruth_MW

This approach facilitates the development of eight typologies with suggestions on the optimum approach to managing each class of stakeholder (Murray-Webster and Simon, 2008[2]). However, the nature of the chart makes it difficult to draw specific stakeholders in the grid, or show any relationships between stakeholders and the activity. However, as with any of the other approached discussed so far, the classifications can be used to categorise the stakeholders in a spreadsheet or database and most of the key dimensions needed for effective management are present in this model. The two missing elements are any form of prioritisation (to focus effort where it is most needed) and the key question ‘Is the stakeholder in the right place?’ is not answered.

Information needed for a full assessment

The factors needed for effective stakeholder management fall into two general categories, firstly the information you need to prioritise your stakeholder engagement actions; second the information you need to plan your prioritised engagement activities.

The two basic elements needed to identify the important stakeholders at ‘this point in time’ are:

  • Firstly the power the stakeholder has to affect the work of the project. This aspect tends to remain stable over time)
  • Secondly the degree of ‘urgency’ associated with the stakeholder – how intense are the actions of the stakeholder to protect of support its stake? This aspect can change quickly depending on the interactions that have occurred between the project team and the stakeholder.

I include a third element in the Stakeholder Circle® methodology[3], how close is the stakeholder to the work of the project (proximity) – stakeholders actively engaged in the work (eg, team members) tend to be need more management attention than those relatively remote from the work.

The next step is to assess the attitude of the important stakeholders towards the work of the project.  Two assessments are needed, firstly what is the stakeholder’s current attitude towards the project and secondly what is a realistically desirable attitude to expect of the stakeholder that will optimise the chance of project success?

Attitudes can range from actively supportive of the work through to active opposition to the work. The stakeholder may also be willing to engage in communication with you or refuse to communicate[4].  If you need to change the stakeholder’s attitude, you need to be able to communicate!

From this information you can start to plan your communication. Important stakeholders whose attitude is less supportive than needed require carefully directed communication. Others may simply require routine engagement or simple reporting[5].

If this all sounds like hard work it is! But it’s far less work then struggling to revive a failed project. This theme is central to my new book, Making Projects Work, Effective stakeholder and communication management[6]. You generally only get one chance to create a first impression with your stakeholders – it helps to make it a good one.

Making Projects Work

[1] For more on ‘stakeholder theory’ see:
https://mosaicprojects.wordpress.com/2014/07/11/understanding-stakeholder-theory/

[2] For more information see www.lucidusconsulting.com

[3] For more on stakeholder prioritisation see: http://www.stakeholder-management.com/shopcontent.asp?type=help-4

[4] For more on assessing stakeholder attitudes see: http://www.stakeholder-management.com/shopcontent.asp?type=help-6

[5] For more on the ‘three types of stakeholder communication’ see: http://www.mosaicprojects.com.au/Mag_Articles/SA1020_Three_types_stakeholder_communication.pdf

[6] For more on the book see: http://www.mosaicprojects.com.au/Book_Sales.html#MPW

Project failure revisited

Project-FailOver the holiday period there has been a couple of interesting discussion on project success and failure. The consensus of the many commentators was that the simplistic measures of time, cost and scope are inadequate but there was little consensus on the solution.  This post poses some of the questions that need a considered answer:

Firstly, the APM website posed the question which of the following projects was successful?

Two organisations decided to undertake identical projects with a normalised value of  $1million.
–  Organisation A assessed their project and set the project budget at $800,000
–  Organisation B assessed their project and set the project budget at $1,200,000
Organisation A’s team did their best to ‘meet the challenge’ and achieved an outcome of $900,000 – a cost overrun of $100,000 nominally a project failure.
Organisation B’s team did ‘a good job’ and achieved an outcome of $1,100,000 – a profit of $100,000 nominally a project success.

But which project is really successful??  The one that cost $900,000 or the one that cost $1,100,000 to produce the same output.  This example is simplistic, the numbers are given and the problem is demonstrated, but nowhere will you ever have two identical projects run against different baselines.  How can you assess the ‘project risk’ caused by soft or hard targets??

Similar issues arise when allocating the blame for ‘failure’ to different parts of the ‘performing organisation’.  Many so-called project management and project leadership failures are likely to be either unavoidable consequences or symptoms of far more significant underlying issues (for more on this see: Project or Management Failures?).  Focusing on the superficial (and blaming the project manager) prevents a more thorough ‘root cause analysis’  of the real issues and problems in organizations.  I will take 2 examples and borrowing from Toyota’s ‘Five Whys’ ask ‘why’ a few times:

  1. Failure of PM leadership. The project manager failed to lead, relate or communicate, with stakeholders. But the project manager did not appoint him/her self , some of the unanswered questions are:
    1. Why did the organisation appoint a PM lacking the requisite skills?
    2. Why did the organisation fail to support/train the PM?
    3. Why were the failings not picked up and resolved during routine project surveillance?
  2. Failing to use recognised techniques such as risk management. Some of the unanswered questions are:
    1. Why does the organisation allow sub-standard practices to exist?
    2. Does the organisation have proper templates, processes and support in place to support the practice?
    3. Does the organisation provide adequate time, training and resources to implement the practice?
    4. Why were the failings not picked up and resolved during routine project surveillance?

The answer to these questions may go back to organisational culture, the overall organisational ability to effectively manage and support its projects (the strategic management of projects)  and/or ultimately the governance of the organisation.

Certainly some projects will fail for project related reasons; projects and programs are innately risky and this means project related failures are to be expected – minimising this cause of failure will be valuable. But, simply measuring performance against cost and time targets is influenced by the way the initial target was set in the first place.

project-failure-2The problem is compounded by the lack of ‘root cause’ assessments. I expect a proper study of the root causes of many so-called ‘project failures’ will show many projects are effectively set up to fail by the organisation.  Allowing executive management to continue with these types of practices is ultimately a governance failure. Addressing the ‘root causes’ of failure hidden in executive management practise, culture and governance are likely to generate significantly greater benefits than simply trying to ‘fix project management’; but you cannot see the failures without proper data.

One initiative aimed at working towards a standardised assessment of project failures is a series of articles being published by Proff. Alan Stretton in PM World Journal, see: http://pmworldjournal.net/article/series-project-success-failure-deficiencies-published-causes-project-failures/  (registration is free).

Given the general management mantra of ‘you cannot manage what you cannot measure’, developing a measure of project failure that is valuable and consistent would be a good start in developing the data needed to allow management improvement across the board.

As Alan concluded the referenced article:

The above deficiencies in current data all point to an urgent and obvious need to develop comprehensive data on causes of project failures – preferably validated by appropriate and agreed criteria as to what constitutes success / failure, and covering the widest possible range of project types and project management application areas.

A suggestion (or challenge) here is for global project management organisations (IPMA, PMI, apfpm, etc) to jointly create a framework to develop and share project success / failure data, covering the widest possible range of project management types and application areas. This would include

  • Developing and agreeing common criteria for project success / failure;
  • Collecting and sharing validated data on success/ failure rates;
  • Researching and sharing validated data on success drivers / failure causes.

If you agree support Alan and start lobbying your PM association of choice. Defining the problem is easy, solving it elegantly is not!

Opportunity Lost

RICSThe first edition of the RICS / APM guidance note on Stakeholder Engagement is a missed opportunity. Hopefully the second edition will plug many of the glaring gaps.

The guide is built around ten principles:

  • Principle 1: Communicate
  • Principle 2: Consult early and often
  • Principle 3: Remember they’re only human
  • Principle 4: Plan it
  • Principle 5: Relationships are key
  • Principle 6: Simple, but not easy
  • Principle 7: Just part of managing risk
  • Principle 8: Compromise
  • Principle 9: Understand what success is
  • Principle 10: Take responsibility

All sound principles but in a strange order

Any complex endeavour needs a clear understanding of its objectives and then a plan to achieve the objectives before starting work, but ‘Understand what success is’, is at #9 and ‘Plan it’ at #4.  Surly the whole point of engaging stakeholder is to enhance the probability of success. Which means #1 understand what success is, #2 plan how to achieve success and then move into implementation.

But implementation needs focus, completely missing from the guide is any practical guidance on ways to understand the stakeholder community, prioritising the stakeholders so the communication effort is focused where needed and then managing the overall engagement effort for maximum effect. The best the guide can offer is a simplistic 2×2 matrix. My methodology, the Stakeholder Circle® is one of several that recognise the multiplicity of dimensions needed to understand a stakeholder, the outline is available free of charge from http://www.stakeholdermapping.com/stakeholder-circle-methodology/

The last omission is considering the path to stakeholder management maturity. The path to maturity is mapped at: http://www.stakeholdermapping.com/srmm-maturity-model/

I had hoped stakeholder engagement was moving beyond the soft ‘fluffy’ platitudes of the past into a pragmatic management process, allied to risk management, focused on maximising the aggregate benefit from a project to all of its stakeholders.  These ideas are in the RICS Stakeholder Engagement guide but unfortunately the guide lacks any guidance on how to achieve these objectives, with the exception of the CASE model in Appendix 3.

Hopefully the 2nd Edition will not be too far away.

The 1st Edition is available from http://www.rics.org/shop

Mind your language

Communicating ideas effectively to another person needs a common language, and a common understanding of the meaning of the symbols used in the language. While this sounds simple, language can take many forms including images, sounds and writing. This post is going to focus on the design and use of images as the language for communication.

The use of images as a language stretches back to the Ancient Egyptians. They developed a written language based on stylised pictures whereas the civilisations in the ‘fertile crescent’ developed cuneiform text.

1.hieroglyphics

Whist we may not be able to read the Egyptian script, many of these hieroglyphs are easily understandable.

2.cuneiform_script

Whereas the cuneiform script is completely indecipherable. However, just because we can identify a goose at the top of the third column of the hieroglyphs, it does not mean we understand its meaning!

A simplified graphical language can provide a really useful way of communicating complex information but when you use the language, you need to be sure the people you are communicating with have the same level of understanding you do and ‘see’ the same message.

One of the first attempts to stylise complex information and to make it accessible and easy to understand was the development of the London Underground map.

The London Underground Map

The London Underground is one of the most complicated systems in the world.  By the middle of the 20th century the map was becoming too complicated for easy use.

1930 Underground Map.

1930 Underground Map.

The concept of the topological map we all know and use was developed by Henry Charles Beck. ‘Harry’ Beck was an English engineering draftsman at the London Underground Signals Office. He developed the first ‘topological map’ in his spare time, based on an electrical wiring diagram.

London Underground was initially sceptical of Beck’s radical proposal and tentatively introduced to the public in a small pamphlet in 1933. It immediately became popular, and the Underground has used topological maps to illustrate the network ever since. There is even a book on the map: Ken Garland’s, Mr Beck’s Underground Map (Capital Transport Publishing 1994). The book describes the enormous care, craft, thought, and hard work of Harry Beck that went on for decades (exactly what it takes to do great information design).

4.underground_london_Beck original-drawing1

Beck’s version of the 1930 Map.

This style of communication has carried through to modern times but is not without its problems – you can easily get to the station you want, but there is no indication of how close or how far apart different stations are ‘on the surface’ – particularly if the stations are on different lines.

The current London Underground Map.

The current London Underground Map.

Success is contagious; most transport maps world-wide follow Henry Beck’s lead and a new universal language has been created.

Part of the new Melbourne Tram Map, using a version of Beck’s language.

Part of the new Melbourne Tram Map, using a version of Beck’s language.

The Melbourne map uses the same style as the underground map – lines are vertical horizontal or at 45 degrees, but unlike the underground stations, tram stops are not shown; the designers believe the street names and route numbers are more important.

Part of the Stuttgart Metro map.

Part of the Stuttgart Metro map.

Based on your knowledge of the London or Melbourne maps, you do not need to be able to read German to have a good idea how to navigate the Stuttgart metro from the Hauptbahnhof to the Zoo. The language of transport maps has become fairly standard world-wide.

However, design of the communication is still important; the designers of each map need to decide what is important (eg, the route numbers on the tram map), what is emphasised, what is suppressed, and what is left out – bad design can reduce the elegance of the communication and block understanding. Whereas innovation can enhance it – the Tokyo train system has its trains painted the same colour as the line used on the transport map – the orange trains follow the orange route and you get to the right platform by following the orange signs!

A similar convergence of communication style has occurred with in-car road maps. Most books and electronic sat-nav systems use a stylised language similar to the map of North Sydney (below) – another language designed for a specific purpose.

North Sydney

North Sydney

For the purpose of navigating a car to the ‘Aiki Kunren Dojo’, this ‘simplified road map’ is far more useful than the 100% accurate photograph of the same location!

North Sydney

North Sydney

The style of the road map above has been taken ‘virtual’ and global by several organisations including Tomtom. You do not need to be able to read the street names or understand the spoken advice ‘turn left in ……’ to follow the map – the pictures say it all and are just as effective in Shanghai and Munich as Sydney or Melbourne.

10.TomTom

When designing a graphical communication language, useful, accurate and fully detailed are not synonymous! Both of the mapping languages discussed so far are really simple to use provided you have learned to ‘read the language’ and interpret them correctly. But as we all know North Sydney looks like the Google Earth photograph (not the map) and Melbourne’s geography only has a passing resemblance to the tram map – but we have learned how to read the ‘language’ and can then use that knowledge of the language to understand similar maps in different cities.

Project Maps

The same challenge applies to project dashboards, reports, and artefacts such as bar charts and CPM diagrams. Creating an appropriate level of understanding in a person’s mind about the true situation of the project and your intended work plans requires appropriate information to be communicated in a language that is understandable to the stakeholder. In this context, ‘appropriate’ does not mean complete or fully detailed; selecting the right level of detail is in itself an art form.  The bar chart below may be fully detailed and precise but it is not a good communication tool!

11.CPM

And while preferred by many project controls professionals, the CPM logic diagram below is even less likely to work as a communication tool for stakeholders.

12.cpm

These specialist languages are useful to trained project controls professionals and some experienced project management professionals but are too complex for most communication needs.

As suggested above, effective communication does not need fully detailed or accurate representation. What is needed is ‘useful’ information that can be used!  You do not need to be an expert in directional boring to understand the plan for this project (all that is missing is the timing for each stage):

13.storyline

Simple is good, simplistic is dangerous! One of the popular options for reporting project status is using simplistic ‘red-amber-green’ (RAG) traffic lights such as these:

14.RAG health_image

We know there is a scope problem but there is no real indication of the seriousness of the situation or how far into the ‘red zone’ the project actually is.  Rather than the simplistic 3 point RAG scale, the same information can be displayed using more insightful tools:

15.Beter option

Any of the ‘gauges’ will tell you where within each band the project is situated, add in a simple ‘change’ report and the trend becomes apparent as well. The art is knowing how much information is enough.

Conclusion

From the hieroglyphs of the Ancient Egyptians to the Tomtom road map, the art of using pictures for effective communication is creating a set of symbols that communicate your ideas and information simply and accurately, and then taking the time to teach your stakeholders how to read the language.

Effective communication, focused on obtaining the understanding and buy-in from a stakeholder needed to deliver a successful project requires:

  • Understanding who are the key stakeholders at ‘this point in time’ that you need to influence;
  • Understanding their needs and the best way to communicate with them (the Stakeholder Circle® methodology is designed for this purpose);
  • Communicating the appropriate amount of information in a way that can be understood by the stakeholder; and then,
  • Taking the time to help the person reach a proper understanding.

The communication challenge is recognising that some concepts will be easy to communicate in some communities of stakeholders, others will be more difficult; and people are frightened of things they don’t understand.

Designing an effective communication strategy requires the project team and project leaders to firstly derive a common understanding between themselves, then determine what the key stakeholders actually understand, then determine how to communicate effectively with the key stakeholders to build their understanding to the level needed to get the ‘buy-in’ required to make the project successful.

Effective communication is the tool that builds understanding, reduces opposition based in ‘fear of the unknown’ and generates a framework for success – for more on effective communication see: http://www.mosaicprojects.com.au/PM-Knowledge_Index.html#PPM07