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

Saturday, 31 May 2014

Humour, Proverbs and Pictures are good memory joggers

Humour, whether visual or Proverbs (and ideally both) can provide useful memory joggers for a Project Manager to apply at work whether undertaking a PM discipline or interacting with team-mates or even senior stakeholders. I am a great proponent of this approach as my project team-mates will testify!
Humour, Proverbs and Visual Images aid Project Manager Memory
You will find such humour across all my Be a Better Sheepdog blog posts but hopefully with some useful messages too.

Keeping good Project Management principles in the forefront of your memory

Most Project Managers are time poor and need to think on their feet so I am a strong believer that Proverbs, Pictures and Humour can help you retain good principles in your head. I have even looked at the science of memory which I believe backs my theory. I expanded on this within a post I wrote for the Association for Project Management.

Humour can also help in your Project execution

Considering the Human side of Projects, Humour can help during your Project execution in that:
  • It creates a common ground other than pure work related matters and thus aids team spirit
  • It can help diffuse stressful situations

Alternative Proverb and Cartoon based Project Management Manual

I have put together an alternative Proverb based Project Management manual for those of you that find the PRINCE2 manual or PMBOK rather long and dry reads. So if you want to see lots of cartoons, proverbs and few words, have a look. Enjoy!

Friday, 23 May 2014

Remember the Hanrahan Principle for IT Data Migration Projects

If you are ever running an IT Data Migration Project you should always remember the Hanrahan principle which will need a little of explaining for anyone who isn't British and older than 45.
Remember the Hanrahan Principle for IT Data Migration Projects
The principle is that you should do checks on record counts in the source system and the target system to ensure they are explainable after the migration process. In some projects not all data will be migrated, it depends on the business requirements. But always check that the requirements have been well specified and met in test and live runs. So there should be counts of records that meet the migration requirements and counts of records which have been rejected because they don't meet requirements. The sum of these should match the total record count in the source system.

Why Hanrahan principle?

Brian Hanrahan was a BBC correspondent who is probably most famous for one quotation when reporting on the Falklands War in 1982. He was on the aircraft carrier HMS Hermes and was not allowed under Government reporting restrictions to say how many Harrier jump jets had departed on raids. However he wanted to reassure the public that there had been no losses.

The clever phrase he used was:
I'm not allowed to say how many planes joined the raid, but I counted them all out and I counted them all back

Wednesday, 21 May 2014

Project Success - there are two dimensions to consider

Project Success is what we all strive for - but how do we define it? In this post, I propose there are two dimensions to consider in terms of success criteria - one for the Project Team and one for the Project Owner.

The Project Triangle is the classic view of a project's success; have the project objectives been delivered to Time, Cost and Quality / Scope criteria? However, while this is appropriate for measuring the success for the project team it doesn't take account of the key reason why the project should be undertaken - the benefits.

The Benefit case is the responsibility of the Project Owner (typically the Project Sponsor) so this is his/her success measure. The Benefit case should be part of the initiation of the project and kept under review during the project. Ideally a Benefit Realisation Plan should be produced during the project to make this more specific and determine how and when it will be measured. Measurement can be many months after the project is closed down.
Project Success - there are two dimensions to consider
A project which fails in one dimension can still succeed in the other. A good example of this is the Sydney Opera House construction project. This project failed spectacularly on the classic TCQ dimension of success. But in terms of benefits delivered, there is more positive news. In strict financial review terms the picture still doesn't look great but what is difficult to quality is the contribution of the Opera House to establishing Sydney (and some say Australia) on the world stage through this iconic structure and world class performing arts centre. 

Success should be measurable

In a race, the winning line should be clearly marked and the same applies to both dimensions of Project success.

For the Project Team, the definition of success should be agreed within the Project Definition in a SMART way. This is likely to involve the Time, Cost, Quality/Scope triangle in some way. If all 3 factors are defined, I will always look to define the priority order. So if the project is under pressure, which factor does the Sponsor really want to achieve at a possible (slight) loss to the other factors? A classic example in IT Projects is that the implementation date of the new system is the critical success factor and the Sponsor may reluctantly accept some reduction in scope or maybe a slight overspend to achieve this.

For the Project Owner, the definition of success starts with the Benefit Case. However, this may need augmentation by a Benefits Realisation Plan, created during Project execution, to more specifically define who and how the benefits will be realised and thus concretely define the Success line.

An Analogy to help understanding

Cook is captain of a sailing ship and crew. Captain Cook has been asked by the Government to deliver some living animals to a remote island in 1770 which are intended to breed and then support a colony on the island in 2 years time. He needs to deliver the animals alive on the island in 2 months time navigating the difficult waters to get there in his sailing ship.

In terms of Project roles:
  • Project Owner => Government
  • Project Manager => Captain Cook
Captain Cook and his crew of merry men can consider the project successful if they deposit the animals alive on the island within the next 2 months. However the Government will only deem the project successful if the animals breed sufficiently to support the colony in 2 years time i.e. the benefits have been realised.

As an aside, after the ship set off, the Government determined that there was an island 100 miles away from the original identified island that would better support life. A carrier pigeon was sent to the ship with the change of plan and the Captain sent one back saying it would take an additional two weeks to get there. He achieved this revised target. This is project change control in the 1700's!!! 


While the traditional TCQ triangle is a relevant criteria for establishing successful project delivery by the project team there is, dare I say, an even more important dimension to establishing whether a project has been successful and this is whether the stated benefits have been realised. This latter dimension is the responsibility of the Project Owner and can often only be measured some time after the project has closed down. Remember that the success line should always be measurable!

Thursday, 8 May 2014

Structuring Go/No-Go Meetings and good preparation make sure you get the right decision

Your whole project plan is often geared to a key decision point - the Go / No Go meeting which agrees whether the project move into implementation and roll-out. This meeting is normally very close to the planned implementation and often has a large attendee list with senior stakeholders which are difficult to reschedule. Therefore it is important that good preparation occurs and the correct decision is made. I'll take you through my approach in this post.
Project Implementation Go / No Go Meetings - achieving a GO with Caveats

Outcomes from Go/No-Go Meeting

You might think that the meeting outcome is binary but in my Go/No Go meetings there are 3 possible outcomes and this is often useful to keep the project on track.

My definition of the 3 outcomes is as follows:
  1. GO - The meeting agrees that the project can proceed into implementation
  2. NO GO - The meeting agrees that the project cannot proceed into implementation for reasons which are minuted. When these points are addressed another meeting needs to be scheduled for consideration. With most projects, a no go decision is likely to create delay to the key go live milestone
  3. GO WITH CAVEATS - The meeting agrees that the project can proceed into implementation if minuted points (caveats) are closed off in a set time. The meeting delegates the determination of whether these have been closed off to the Project Manager and no follow up meeting is required

Establish criteria by which a decision will be made

Well in advance of the meeting, agree the criteria by which the decision will be made. This gives you a definite framework for running the meeting and stops a "free for all" discussion. The exact criteria may change between projects but if you can make it less subject to interpretation then that is what you should strive for. Here are some example criteria from IT system Go/No Go meetings I have run:
  • Testing complete? - evidenced through a signed off test completion report
  • Business Readiness complete? - evidenced through sign-off from person responsible
  • Implementation Plan fully approved & resources for implementation event secured?
  • Post implementation enhanced support plan agreed - evidenced through a signed off document
  • Any Issues or Risks to highlight? - this allows me to highlight things to the meeting such as residual project risks, implementation risks or indeed an issue which might impact the go decision
  • ITIL change process approved? - normally by approval of a record in the particular change management system
As this meeting is an example of a Gated Entry meeting, you might also want to read my post on the general concepts of these meetings

Try and secure the evidence in advance of the meeting

If you can secure the evidence against each criterion in advance of the meeting you are well placed for a Go decision. So in the example above, secure the appropriate sign-offs of the Test Completion Report and there should be no discussion on testing in the meeting. If the report highlights some residual risks then this should be included in your risk assessment part of the meeting.

Create a document with RAGB statuses against each agreed criteria

Create a document with a RAGB status against each criteria based ideally on an objective assessment else make a judgement. Blue is a colour I use to indicate complete, Red, Amber, Green depending on how much concern the item is for the Go decision.

Use this document to manage within the project team as you approach the Go / No-Go meeting - the trick is where things aren't Blue or Green to have side discussions in advance of the meeting.

The you should formally issue the INPUT document to the meeting attendees in advance of the meeting
Project Implementation Go / No Go Checklist

Running the Go/No-Go meeting

Walk through the document criterion by criterion and allow any discussion although for completed items you shouldn't expect much. Once you have been through the whole list, you need to populate the voting section of the document. I always like to start the voting and by so doing, lead the meeting.

I try very hard to be objective and not just say Go as I believe demonstrating a proper objective view gives confidence to other stakeholders. Going live and having a host of problems not highlighted as risks at the meeting won't be good for your reputation. Again, the trick is to work hard before the meeting to ensure you are in the best possible position to say Go although my reputation is that I always vote "Go with caveats" as there is often a sign-off or two still to be chased down!

I always like the sponsor to finish the voting and frankly this the most important vote which should prevail in 99% of meetings. The sponsor can listen to the other votes and where necessary make a judgement call.

Project Implementation Go / No Go - Recording Votes

After the Go/No-Go meeting

Send out the updated criteria / voting with the outcome from the meeting. If the outcome is Go with caveats or No Go, document and send out the actions arising from the meeting.


The Go / No-Go meeting is a critical milestone in your project plan. Good planning and preparation can give you the best opportunity of getting the correct decision. I commend the framework described here as an effective approach which I have used for many years now. On one project with many roll-outs I was having up to 3 such meetings a week but it worked effectively to get the right decision and equally important, obtain buy-in from key stakeholders.

Twitter Delicious Facebook Digg Stumbleupon Favorites More