First time visitors read!

If you are new to this Blog, read about it's purpose and how to get the best from it

Free Project Management Training

Go through the site content in a structured manner to teach you Project Management or improve your success rate

No English?

Can't speak English? No problem!!

Why the Sheepdog Analogy?

A Project Manager is a necessary evil. Why? Well, the PM doesn't produce anything - write code, lay concrete or whatever. However, don't have one and see what happens!

Always telegraph your Punches as a Project Manager

Sometimes as a Project Manager you need to throw a "Project Manager punch" but not a literal one please!

Isaac Newton's contribution to Project Management

Newton's laws, especially his first law of motion, should be as important to a Project Manager as it is to a Physicist. Why?

O Sponsor, Sponsor! wherefore art thou Sponsor?

You are given a project to run. Amongst your early questions should be, "who is the Sponsor?"

Always remember the Human side

It is very easy to get hung up in the technical and management side of Projects and forget that they need to be delivered by human teams. So "Always remember the human side" is the key phrase!

Why writing a Project Status Report is not a chore

I've met several Project Managers who view writing any Project status report as a chore. I think the opposite.

Planning is the key Project Management discipline

I have been asked a few times, "What are the top xx things to focus in on as a Project Manager? If pressed, I always fall back to Planning

Friday, 24 April 2015

Good communication within Projects is vital - consider how to improve and risks

Communication is important in many ways during the execution of a Project. There are risks of miscommunication to be mitigated and several areas of communication to focus on which I will cover in this post with a few Proverbs thrown in to help reinforce points.

Requirement Gathering

Most projects involve agreeing some business requirements. The ability to agree a set of requirements that the business and delivering teams both understand (and is non ambiguous) is a real skill and has many risks as can be illustrated by this cartoon  
Projects - Communication doesn't always result in correct understanding

Also as a good analyst you need to probe the subject matter as a user may naturally not volunteer information.
Project Communication - A user will tell you anything you ask but nothing more
Also, I'm sure that most of you are aware of the tree swing analogy re communication breakdown. 

So the requirements need to be echoed back in some written form and validated by the users but sometimes this has a risk of misinterpretation. Analysis techniques such as UML with Use Case Diagrams are designed to reduce the risk of such communication breakdowns - as the saying goes  ""A picture is worth a thousand words"

[For IT Project Managers, it can be difficult for users to articulate detailed requirements in some circumstances and this is where Agile methodologies are useful]

Written communication

Firstly remember the Proverb "What isn't written hasn't been said". So while face to face verbal communication is important the formality of some written audit trail is essential to ensure underpinning detail is agreed [note that an Agile methodology will reduce this]
Projects - What isn't written hasn't been said
So your project is likely to have a whole raft of documentation which needs to be able to properly communicate with an audience of reviewers and approvers as well as other people in the team. Having templates (or PRINCE2 product descriptions) can aid structuring the document correctly for understanding (and ensuring all subject matter is covered). However, the individual producing the document still has a role to set out the content in a sensible fashion to aid communication.

Of course, topics such as configuration management and ease of finding documents in the Project file also come into play. Tools such as SharePoint can help here although you still need to structure your Project file correctly to aid communication.

Stakeholder communications

You should understand who your stakeholders are and how best to communicate to them, see my post on Stakeholder analysis.

For Project updates, a Status Report (Highlight Report in PRINCE2) is a good way of regularly communicating project progress and issues to several groups. Additionally for the project governance group (Project Board in PRINCE2) you should organise formal meetings at least monthly. 

Your Sponsor deserves special consideration. A weekly status report is something which can be read at leisure to keep up to date and with the Project Board meetings for formal monthly updates, this is fine if things are broadly going to plan. But if things have gone awry and you need to convey some bad news, I strongly recommend picking up the phone to explain things rather than other communication approaches and especially before the status report is published!!
Projects - The best way to communicate bad news to your Sponsor

Other Communication considerations

  • Balance of listening versus speaking!
  • Consider the use of Email within the Project
  • Consider whether access to the Status report is sufficient communication with your Project team? A forum for two way conversations about progress is beneficial. Options here are to use your meetings with team leads to convey information which is then cascaded down to all team members with feedback coming back up through the next meeting. Also you can tap into existing "whole team" meetings or establish your own Project or Programme Town hall meetings to allow a two way dialogue directly with all team members periodically. Maybe consider a weekly Blog for a more informal style of team communication than the Status Report?
  • Consider the personality of the recipient, for some you should wallow in detail, for others it needs to be really punchy "what is the so what?"  
  • Consider the use of jargon in communication as per this cartoon showing poor Project Manager - Sponsor communication!


I know I have only scratched the surface of a discussion on Communications within Projects but hopefully it is sufficient to inspire you to consider this topic carefully both when Initiating a new Project and continuously during the execution.

Friday, 10 April 2015

Manage External Dependencies or face the Risk of a "dropped baton" in the relay race

External Dependencies need to be carefully managed to ensure they don't trip up your Project and cause you to cross the finish line late. In this post I suggest how to manage with tips and templates.


First a definition! What I don't mean is task dependencies (i.e. you can't complete task a until task b is complete). What I do mean is things you need to deliver your project which aren't part of your project scope and need to be provided by others, often a different project. This is very common in Programmes but can be seen in other scenarios.

Projects - Bad and Good External Dependency Management

Identifying External Dependencies

When you are working through your Project Planning you should identify anything which you need to deliver your scope which isn't part of your scope, who you believe is providing these items and when you need them. You have now found your External Dependencies which should be clearly marked within your schedule (typically I have these as clearly marked milestones "EXT DEP:<description>").

The first thing to note is that just because you would like an external dependency to be satisfied by date "x" doesn't mean that the provider can or will be able to achieve this.

Managing External Dependencies

The process I adopt for External Dependencies (especially within a Programme setting) is as follows:
  1. Establish a common Dependency Log / Register and every Project Manager should log Dependencies as soon as possible, then firm up on details and dates
  2. Until the "dependency provider" actually agrees to your dependency request, you have a big risk that it won't be provided when you need it. So this is stage 2, get agreements that these dependencies have been built into plans from the providing project (or BAU activity)
  3. Then you move into "Monitoring Stage". Within a Programme I like to have a regular (weekly) RAIDs review meeting. At this I will review the Dependencies for whether we have "non agreed" dependencies and for the agreed dependencies, how does the supplying Project Manager rate being on track to provide each one at the agreed date with some form of RAG status 
  4. When the dependency has been met, mark the dependency appropriately in the log. Eventually, every one in the Log should be either cancelled or marked as "Met"

Dependency Log

A good Dependency Log / Register is important in the management processes described above. Below is my standard dependency log held in Excel.
Project External Dependency Log
The fields are:
  • Raid Nr - Unique ID
  • Description - As specific as you can make it. It is OK to start vague but you need to firm up before it is marked as "Agreed"
  • Date Raised
  • Date Dependency (as per description) is to be met
  • Who requested (project and contact)
  • Who is satisfying dependency (project and contact)
  • Dependency status - Request / Agreed / Met / Cancel
  • RAGB status where Red = not on track to meet the agreed date, Amber = at some risk of meeting the agreed date but still expect to achieve, Green = on track, Blue = have met the dependency request
  • Position - allows for comment updates preceded by date stamp


External Dependency management is really important within a Programme of Projects but often in other scenarios too. A 4 step management process is suggested built upon a good Dependency Log but of course, it all relies on good planning first.

If you don't plan, agree and manage external dependencies, the baton may be dropped in your Project race resulting in a delay as your external contacts quote you the old saying "Your inability to plan does not become my emergency"!!

Twitter Delicious Facebook Digg Stumbleupon Favorites More