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, 27 December 2014

Happy New Year to all Project Teams

As we near the New Year, it is a time for reflection with your Project Team on what has happened in the year, both positive and negative, with an emphasis on what has been achieved. Then we should focus on what needs to happen to ensure a successful Project completion in the next year. What better a way to do this than with a song - have you ever heard a Sheepdog sing?
Happy New Year

No more issues
No longer in a mess
Here we are, no more stress
We are making good progress
It's the end, of the year
No more mornings where we pray
So unlike, yesterday
Now it's time for us to say...

Happy new year
Happy new year
May we all, have a vision of our team
Of a project, that has reached our greatest dreams
Happy new year
Happy new year
May we all, have our hopes, our will to try
If we don't, we might as well lay down and die
You and I

Sometimes I know
Project status must I RAG
Oh I like, the green flag
But no time to stop and brag
Risks remain, we must check
As we push, for the finish line
Spirits strong, a good sign
Soon to open party wine

Happy new year
Happy new year
May we all, have a vision of our team
Of a project, that has reached our greatest dreams
Happy new year
Happy new year
May we all, have our hopes, our will to try
If we don't, we might as well lay down and die
You and I

A note to ABBA - Thank you for the music, the songs I'm singing, thanks for all the joy they're bringing

Friday, 19 December 2014

Work Package principles can be applied in a number of Project situations

My belief is that the principles of Work Packages can be applied more often than you may initially think in Projects; it is just the formality of definition that may differ in various circumstances. So, sub-contracting a part of the plan to a third party is an obvious use of a quite formal Work Package, but can a request for a team member to undertake a task on the plan be considered a Work Package or even a Meeting?

The most formal Work Package definition

Project Work Package in Action

The most formal Work Package definition could have the following elements:
  • any background information and context
  • description of what is to be delivered - product descriptions in PRINCE2 terms
  • agreement on effort / cost, time for delivery and when to start
  • quality criteria and checking approach which may require independent attendance at some review sessions
  • any other constraints
  • standards, techniques and processes / procedures to use
  • interfaces to be satisfied
  • requirements to be met
  • progress reporting requirements
  • problem processes
Ultimately this Work Package could be linked to a contract with a third party but a similar approach might be adopted for some major deliverables produced by a team reporting to the Project Manager.

Asking one of the team to deliver something in the plan?

When you want someone in the team to deliver a task in the plan many Project Managers will take the informal approach with a a quick chat. I too like the human element of this approach, you can have a discussion, understand risks etc, look the person in the eye and gain a commitment. 

But one of my sayings goes What isn't written hasn't been said. If you actually covered all the aspects of the formal work package in your verbal discussion that would be good but you may miss a point or two and the memory of some team mates can dissipate when under pressure or something more interesting pops up ;-)

So I suggest you reinforce the discussion with a quick email summary, you can provide links to reference material within the Project File which ensures there are no excuses and can actually help the team mate as a reference point as the work progresses. 

You can mention things like progress reporting too, "can you pop me a quick email each Friday morning with progress made, effort to complete, any issues or risks you wish to raise?" In some circumstances, especially when a task is on the critical path, I may set up a zero length meeting request for the person on the Friday morning. This reminds the team mate and reminds me too about expecting an email status update. So if the email doesn't arrive on the Friday by lunchtime, I can chase Friday afternoon.

Applying Work Package principles to a Meeting?

OK, it may be stretching things a little but some of the Work Package principles I apply to meetings:
  • In the Outlook meeting invite I often put some background information and the objective / questions to answer. As well as hopefully allowing participants to think about their contribution BEFORE the meeting, this is useful for me when I am going from meeting to meeting during the day as it helps me get my brain in gear rapidly!
  • I also like to start each meeting with what I call the "warm up" - the analogy here is the audience warm-ups before TV recordings or similar. It ensures that the "audience" is in the right frame of mind for the meeting, understands the context and to set expectations on what is to be achieved - maybe as per the cartoon below :-)
Project Meeting Warm-Up

Monday, 8 December 2014

Do better than the Ancient Egyptians - Have a well organised Project File

Historians have deduced that the Ancient Egyptians must have had very poor filing systems - this is why they chose to write all their history on the walls :-). You need to be careful not to repeat this situation in your Project else the team will have difficulty finding useful documents / information resulting in communication problems, a loss of productivity and a lack of auditability.
Have a well organised Project File
Here is my suggested check-list for establishing and using a Project File

1) Shared File Store

First and foremost you need a Shared File Store which all the Project team can access. The old fashioned way of achieving this was a Project folder on a Shared drive. This can still work although many organisations have SharePoint and you can establish a Project specific site. SharePoint has a number of useful features which you don't get with a Shared drive such as Document Check-Out / Check-In, the ability to make a more interesting site through web-parts etc. 

Please check that this shared file store is backed up, ideally nightly.

2) Create a Project File Structure to aid easy retrieval of Information

Don't assume that your team will organise things sensibly, they won't! So dictate a sensible structure. Give this some thought, it will pay dividends in the long term. So for example, in IT Projects adopting a waterfall SDLC type life-cycle you might have a Management folder plus one for each major phase. Then I would encourage use of sub-folders below this basic structure.

3) Communicate structure and dictate usage to the team

Make a summary document about the structure and communicate this to the team. If it is a SharePoint site, this introduction to the structure can be made prominent for "new users" of the site. 

Tell the team that they need to use the Project file when drafting new information not just when submitting for review (every heard the story about the person who lost a months work on a draft document stored on the "C:" drive when it failed?).

4) Use link to Project File in Emails

Ensure the team utilise links to documents within the Project File rather than embedding them in emails which wastes space on the organisation's email servers with duplicated copies.

5) Consider document version control practices

In general terms I adopt the following principles on document versions.
  • Drafts should progress through versions 0.1, 0.2, 0.3 etc 
  • When the document is baselined (see previous post on document quality) it moves to the next integer, typically 1.0 for first baseline, 2.0 for second baseline. Ideally I like the evidence of signoffs to be embedded in the baseline document
Some practices will change depending on the technology used for the Project File:
  • Shared Drive - To support configuration management, I like the version number included in the file-name
  • SharePoint - This should be set-up to maintain versions and the version number should always be excluded from the file-name. I have yet to crack using the SharePoint version within the document (let me know if you know how!) so for me the version number embedded in the document change history section is the Master version label

Lastly - Stamp on "poor team behaviour"

You have communicated about the structure of the Project File and how it should be used as above. But you need to acknowledge that your team are humans and humans are set in their ways. Remember my post on Newton's 1st law of motion (People tend to continue travelling in the same direction.....unless acted on by an external force)

So be prepared to call out poor team behaviour (e.g. emailing documents around) and by catching this early you will get the team all pulling in one direction in the use of a well structured Project File which will be a useful asset in your Project execution.

Monday, 24 November 2014

Are you planning for Quality with your Project documents?

Most projects have a myriad of documents produced both Management and Specialist (Technical). If you don't plan and execute proper quality processes for these documents, your project will not have a secure platform for success. A draft document hasn't been reviewed and agreed as fit for purpose so may not be correct and subject to change at any time. In contrast, if the document has been reviewed and approved as being fit for purpose it is a firm foundation to execute the project towards a successful conclusion.

Apologies in advance, this post is longer than my normal length which just goes to show that achieving good quality fully approved documents isn't easy!!
Quality Assured Documents give a more secure Project platform
I have previously spoken about planning and estimating as key activities to undertake and the PRINCE2 Product based Planning technique is a good place to commence with your planning. I then recommend that you produce a Quality Plan for all Products produced by the Project and build those quality processes into your schedule. In this post I am focusing on documents but the same principles apply for non document products.

Terminology - "Draft issued", "Approved", "Baselined" document status

Let us start by defining some terms I will use....
  • Draft issued - the document has been drafted and been submitted into the quality assurance process in line with the Quality Plan
  • Approved - approval evidence received from all approvers for a document
  • Baselined - document version is designated as a baseline version. It should only be changed as a result of a Change Request or a true error i.e.  Off-specification. 
Now you are probably thinking what is the difference between "Approved" and "Baselined". Normally you achieved Approved to achieve Baselined but not always! I reserve the right to Baseline a document which isn't fully approved, often because there is a tricky customer who thinks that by not signing off documents he/she can change his mind at any stage. Sorry, I'm not having that!! Of course such an action creates a Risk but better that than lack of progress or certainty on downstream document production. Of course, before taking such a course of action I will have chased a number of times for sign-off or a reason why it can't be signed off. I'm afraid that is just a fact of life, you are unlikely to get sign-off emails without some chasing. So plan for it!

Quality Plan

So you have identified your PRINCE2 Management and Specialist products, Product Breakdown Structure and Product Flow Diagram (if necessary). In line with your schedule you can populate your Quality Plan which I tend to maintain in a spreadsheet. Below is an extract of some columns from an old project in 2004.
Example Project Document Quality Plan
The key fields of the Quality Plan document (not all shown in the extract):
  1. Product name (Product = Document)
  2. Product Status - one of the following "Not started", "Being Drafted", "Draft Issued" (for review), "Partially Approved", "Baselined"
  3. Product Version - 0.1, 0.2 etc are drafts, 1.0, 2.0 are baselines (so in the example above the PID was on a second baseline)
  4. Author - this person is responsible for putting together the document, issuing for review, updating from review, obtaining approval evidence, reporting status to the Project Manager
  5. Purpose of Product / Comments on status
  6. Quality Process (see below)
  7. Approvers - either a list of approvers and why (the thinking behind who needs to assure quality). Ideally an approver will be part of the review process. Sometimes I will ask a senior manager to approve based on reviews undertaken by a number of staff who report into the senior manager. I'm not keen on "approval based on status in organisation" unless it aids quality in some way!!!
  8. A series of dates which there wasn't room to represent in the example. These are Draft Issued Plan / Draft Issued Forecast / Draft Issued Actual / Issued Days Late (calculated from either Forecast or Actual) and the same repeated for Approved

Quality Process - Review by Circulation

This is the most often used but is the weakest document quality process. It is weak because for the reviewer / approver it is typically adhoc work beyond the planned activities to be "fitted in" and human nature means that many people will de-prioritise this or ignore it due to volume of email traffic  or skimp in the review when up against a deadline. 

So you, like me, will probably use this a lot but please acknowledge it's shortcomings (and pick which documents you really need something better) and at least put in effort to chase for comments. Negative Option reviewing (i.e. no reply = "it must be OK") is a classic failing and one to be avoided.

Some suggestions to get the best out of this quality process are:
  1. Ensure the document author takes ownership for achieving these suggested points
  2. Pick your reviewers carefully - who will add value to the quality process versus those you are just effectively notifying about a document?
  3. When a document is sent for formal review (rather than some pre-review with a trusted peer reviewer), please include all reviewers and approvers in the email. Be clear in bold and early in the email on the expected time-scales for review and feedback. Be sensible, don't send a 100 page document and ask for feedback the next day (see scheduling)
  4. Explain how you want feedback. Are you happy for email, updates / comments actually in a copy of the document forwarded back or do you want to send out a template for comments which means everyone's comments are in the same format? I personally like the latter approach and have a template where the reviewer designates a severity to each comment from critical to cosmetic
  5. When processing the feedback, make changes to the document with tracked changes against the draft version sent out. If you don't make the change suggested, you need to dialogue with the reviewer as to why (for completeness, the feedback template has a "actioned" column which can be marked and the feedback returned to each reviewer)
  6. Note in the document (within the table of reviewers) who has reviewed and who hasn't.
  7. You may need to chase for feedback from those you expect to sign-off 
  8. Once all feedback has been assessed and processed, the revised document (with tracked changes) can be issued for sign-off by the approvers. Once again, the author will need to set a target date for approval evidence to be received
  9. Typically the author will then need to chase for these approvals. At some point the author may need to escalate to the Project Manager to chase for approvals as a second line. Some people don't like to make the "commitment" of signing off documents, some are sneaky and feel that a draft document allows them to make future changes. Don't let this happen. I will use every attempt to solicit an approval (or a reasonable reason why the approval can't be given) but there have been occasions where I have said "tough, we are base-lining the document without your approval"
You might also want to read a separate post where I have covered some other tips to improve the "review by circulation" quality method.

Quality Process - Walkthrough Review

Walkthrough Reviews come in various shapes, sizes and processes, here I will deal in generalities. The bottom line is that a Walkthrough Review should typically give a better quality review than Review by Circulation. If you want to read more on the subject, I have used the Fagan Review process within IT Projects.

In simple terms the author issues the document in advance but the reviewers gather in a room and the author walks through the document and people feed in comments and discuss. I would say in general terms the review is better because:
  • reviewers are locked away and forced to spend the time to review (if they haven't done in advance which is the ideal)
  • discussion between reviewers can help bounce thoughts around to get to a better conclusion which can then be documented
Walk-through for the finest Quality

Schedule aspects of Planning for Quality

You need to factor in these Quality Assurance processes into your schedule. In simple terms I have a two step plan with a couple of milestones in the schedule:
  • Task 1 - the time for the author to get to a GOOD draft of the document which is ready to be Quality Assured. If the author isn't confident and wants a peer review first, this needs to be built into the estimate
  • Milestone 1 - Draft issued (when the email has been sent with the link to the document being reviewed, this milestone has been met)
  • Task 2 - Quality Assurance process (what ever it is in line with the Quality Plan). This includes dealing with the feedback, issuing a second draft for signoff and chasing down the approval emails. The author may not be working full time in this period but I never tend to plan less than 10 days elapsed here. If you are using Walkthrough Reviews, encourage the author to get the meetings in people's diaries well ahead of time
  • Milestone 2 - Document baselined - all sign emails received and embedded in the document
These milestones can then be baselined and through monitoring, provide a useful means of measuring progress especially in a Waterfall type project life-cycle.


As part of your Planning and Estimating activities ensure you produce a Quality Plan for your documents (and other PRINCE2 products), considering how you will Quality Assure them before Baselining them. This effort which is non trivial needs to be built into your Project schedule.

Monday, 10 November 2014

Every Assumption is a Risk so Manage them!

As you undertake Planning and Estimating you are likely to need to make some assumptions and on occasions, you may need to make a lot of assumptions. Every Assumption should be considered a Risk (that it is incorrect) so you should be active in logging them and closing them down as soon as possible during the Project life-cycle. As I have previously said, Attack the Risks before the Risks attack you!
Every Project Assumption is a Risk

Log your Assumptions as you undertake Planning

As you plan you should document any assumptions you need to make to complete the plan. These can be significant assumptions fundamental to the plan being adopted or quite low level detailed ones.

You should have an Assumption Log, I typically have a separate sheet within an Excel RAIDs workbook. It should be located in the central Project File e.g. on SharePointHere is an extract from a closed Project within a Programme structure (so I introduced a Programme wide log with a Project column).

Project Assumptions Log

Validating your Assumptions

You should validate your Assumptions firstly with your Project team and especially for more fundamental ones, with your Sponsor / Project Board through your Project definition document.

I show any fundamental Assumptions within the body of the definition document and I often put the rest in an Appendix.

Every Assumption is a Risk

Every Assumption could be incorrect and thus affect the Plan. Therefore every Assumption is a Risk. I will log significant ones as specific entries in the Risk Log. As an illustration, here is the detail of the Risk I raised against Assumption #22 for the 11g Project shown above:
  • Description - Jmeter POC is not successful and scripts are not delivered as planned (Ass 22)
  • Impact - Delay if need to evaluate a different tool
  • Management - Accept. Contingency is manual testing, keep going with Jmeter with known deficiencies or stop & evaluate another tool
For the lower level assumptions, I typically have a catch all Risk along the lines of Assumption not specifically raised as a Risk is found to be incorrect

Monitor and close Assumptions and associated Risks as soon as possible

As I have stated in a previous post, Attack the Risks before the Risks attack you!. So look to confirm your Assumptions as soon as possible during the Project life-cycle and through regular review of your RAIDs, close off Assumptions and Risks entries as appropriate.


To produce a Plan is likely to require one or many Assumptions. Any Assumption represents a Risk to the Project as it may be incorrect. Therefore Assumptions should be logged, validated and actively managed until all are closed.

Monday, 27 October 2014

Email within Project Teams - good, bad and ugly

The use of email within Project teams can be an emotive subject. There is increased need for communication during projects so the volume of email traffic is likely to increase over a BAU situation. Does this represent any risks to your Project? What behaviours and practices should you encourage as a Project Manager? Here are my views on the good, bad and ugly practices and what you need to consider doing about them.
Email within Project Teams - good, bad and ugly

Email - Good

  • If you have teams in different time zones then email can be useful to handover status position and ask questions
  • Another proverb I quote is "what is not written has not been said". I am very happy for document reviews to be outside email. "Review by circulation" is known to be the weakest quality technique. However, no verbal approvals please. Approvals need to be committed to an auditable approach and email is useful for this and preferable to the old ways of securing through physically signing some paperwork
Projects - What isn't written hasn't been said
  • One to many communications like key status updates. I would keep the message punchy (no 7 page emails please) but by all means refer to a location on the Project File where more details can be found or to a Blog page etc

Email - Bad

  • Emails that are too long. If it needs to be long at a minimum make sure the key points are put in the first two sentences
  • Not being clear on what response is required when and who needs to give it. So, if you are looking for a response, please state this clearly including when you are expecting this (bold?). The people who you are looking to respond should be in the "To:" field with others that might respond or just need to be aware in "cc:" field  Please give the recipients sufficient time to respond considering the other work they will have and the size of the task you have given them!
  • Having an email with incorrect subject line. Lazy people can sometimes just pick a previous email and start a new conversation with a previous email as a starter. Urg! 
  • Spending lots of time on "email management". If team members are spending a lot of their project day doing email management (e.g. reading, responding, filing emails) rather than undertaking tasks on the project plan then this is bad news! Yes, you may need to find an old email but search tools have improved and encouraging putting something sensible in subject heading can further help via the subject:(keywords) Outlook search facility 
  • Emails can be ignored and often are, either explicitly or via bad email process (as people park and never go back to address). Unless the sender has the rigour to mark the sent email and chase for a response, the whole subject can disappear into the "ether". For this reason, a Project is well advised tracking mechanisms for such questions - a classic way is via a query log for questions so that things don't get lost in in-boxes and can be more easily followed up by regular reviews of the status of the log.
  • Sending big attachments in emails within the Project team. Please have these within the Project File and send a link.

Email - Ugly

  • Having chats on email. Some individuals are shy or lazy or both and engage on "email discussions" when they are in the same office. Get up to get out of their chair and have face to face discussions, it is more productive. By all means confirm the conclusion of the discussion in an email for the record. If people are not in the same office, there are better tools than email such as Instant Messaging
  • Copying in the world combined with Reply/All. Some people like to copy in everyone to their email. And it always seems to be those emails which end up in a debate. Always encourage the team to think before copying "the world". Do the people on the cc list need to know about this email at this time. Can the people be informed when a conclusion is reached? I sometimes use bcc. This allows a senior stakeholder to be informed about a point (e.g. an Issue notification) but not suffer the "million" reply/all consequences
  • Reply/All is surely the worst feature of Outlook! If people had to type in all the email addresses to be copied in a reply, less people would be copied for sure. It is far far too easy to press that button and not modify the distribution list. Hence my use of bcc described above. 
  • Complaining via email. Frankly, if someone is unhappy with someone else's performance, it is the best approach to pick up the phone and have a discussion one to one. The unhappy person, after the discussion, can always escalate to the person's manager as the next step. But they should not start with a "stroppy email" because these often end up with undesirable outcomes. At one end, the compliant can be ignored and behaviour becomes worse as a result of the email and at the other end it can all end up in a discussion with the HR department!


So in conclusion it is worth a Project Manager thinking about Email practices as part of running a Project. However I warn you that it may be difficult to change people's behaviour which is well ingrained (see post on Newton's laws!). 

I have used kick off sessions to talk about "expected behaviours" in general and Email can be included as part of that. During the project you can think about "naming and shaming" really bad offenders but after a quiet word on first offence please. 

Other than that you should aim to best manage around some of the bad and ugly practices described above. So, think about query logs and similar strategies to ensure bad Email practices don't derail your Project.

Monday, 13 October 2014

Forget Stakeholder Management at your peril

In simple terms Stakeholders are people who want something from your Project, who can positively / negatively affect it's outcome and those that will be affected when it delivers. So you should identify them early, work out which ones need more engagement and then start managing them, an activity which will continue until Project close down.
Identify, Understand and Manage your Project Stakeholders

Your most important Stakeholder(s) is your Sponsor and Project Board members

I have previously written about the need to find a Project Sponsor if you haven't been given one. The Sponsor can be augmented by other roles to form the Project Board (e.g. Senior User, Senior Supplier etc). These are your most important Stakeholders as they own the Project, set the objectives, authorise key deliverables (products) and the Sponsor typically needs to deliver the Benefit Case.

1 - IDENTIFY - Brainstorm your Stakeholders

Your first step in Stakeholder Management is identifying who your Stakeholders are! So brainstorm, answering the questions:
  • who will be affected by the Project (positively or negatively)?
  • who should or might want to influence the Project?
  • who will be interested in a successful or unsuccessful outcome?
Your list may include departments in your organisation, customers, various senior managers, customers (internal / external / new / existing), suppliers, public, unions, press etc. Don't forget the Project team, they are Stakeholders too!

2 - SEGMENT - Segment the identified Stakeholders

Having produced your Register of Stakeholders, work through the list segmenting them. This may need some subsequent analysis:
  • who should be consulted about the Project requirements?
  • how much interest do they really have?
  • type of interest - financial, emotional etc? 
  • will their job role be affected, may they lose their job?
  • how much power and ability to influence?
Then map out so you decide what management strategy to use for each stakeholder.
Project Stakeholder Map

3 - UNDERSTAND - Better Understand your Stakeholders

So you have done your initial segmentation, you will probably need to do some more digging to better understand them, especially those in the "Manage Actively" and "Keep Satisfied" segments of your map. I would also do some further analysis of the "Keep Eye On" segment as well. You can do some research but why not be open and have a one to one discussion with them?

Questions to think about include:
  • Are they advocates or opponents?
  • If an opponent, is there a possibility of winning them over, if not to a fully positive position, at least to a neutral stance?
  • If you can't win an opponent over, how best to manage their opposition? 
  • What is their motivation?
  • What is the best way of communicating with them and are there certain communication techniques to avoid? (some stakeholders seem to react badly to emails where as a verbal update can work better) 
After understanding more, update their position within your map accordingly. 

In practical terms I record Stakeholders in an Excel log, here are extracts from the Stakeholder Log and the Communication Log

Project Stakeholder Log

Project Communications Log

4 - MANAGE - Implement your Management Strategy

You should now implement your management strategy per Stakeholder group and tailored for individuals as assessed in the UNDERSTAND step. Keep active monitoring as you move through the Project life-cycle.

Dealing with "difficult" Stakeholders

A bit like the cartoon, some Stakeholders can be difficult angry characters or just naturally obstructive (even when assessed as being neutral to the project aims)! Maybe organisational politics are evident. There is no silver bullet solution but approaches I adopt are:
  • always remain professional, don't be angry back and attack the project point of discussion not the person
  • avoid email to continue such debates even if it started on email, it always seems to make things worse. So go and see the person if possible else pick up the phone and speak 1-2-1
  • use the tools at your disposal - no, you PMs on Construction sites, don't pick up a hammer! I'm talking about using your Project Management toolbox and making statements like "I will need to raise a risk off the back of this conversation", "I need to escalate this risk to my Project Board", "This represents a formal Project issue which will be reported to the Project Board" etc
  • can you get around your problem child? e.g. go up the line and start the discussion afresh and still achieve the same goal
  • you may need to seek assistance from the Sponsor and Project Board members


Your Project Stakeholders should be analysed and managed via strategies devised in line with their segment within the Stakeholder Map. Your most important Stakeholders are usually your Sponsor and Project Board. Ignoring this activity can put your Project at peril!!

Wednesday, 1 October 2014

"Do the Right Project" BEFORE "Do the Project Right"

Project Managers are typically concerned with Doing the Project Right i.e. correctly executing a Project for a given objective. However most organisations don't have limitless funds and resources. Therefore the step before fully committing to Project execution is to establish whether there is sufficient justification against potentially competing initiatives i.e. Do the Right Project. This takes us into the world of the Project or Programme Business Case - hopefully not a world of fantasy as per the cartoon :-) 

Preparing the Project Business Case

Project Manager initial check-list when picking up a new Project

Although a good quality Project Business Case isn't the responsibility of the Project Manager, as a Project Management professional you should be encouraging good practice. Here is my start-up checklist:
  1. Do you have a Sponsor (aided by others to OWN the Project depending on it's scale)? If not, you will need to seek one
  2. You establish there is a Business Case already baselined (signed off by the right people in the organisation hierarchy). If so, confirm whether this is a constraint. When you build your Project Budget as part of Initiation you can validate whether this constraint can be met. If it is not a constraint, the Business Case may need to be modified out of Initiation
  3. You establish there isn't a Business Case created. Then this should be on the list to achieve during the Initiation / Definition phase. You need to be clear that this is owned by the Sponsor but depending on his/her experience, you should be prepared to help author the document. But I will not send out this document for review / approval as ownership for this must clearly sit with the Sponsor

Things to consider in the Business Case

Fundamentally the Business Case answers the question WHY should the Project be undertaken i.e. what business benefits will it deliver to the organisation. Typically I would expect the following as a minimum:
  1. Executive Summary - no more than a page of background, what the project will deliver, the costs and benefits
  2. Cost breakdown - considering what costs can / can't be capitalised
  3. Financial Benefits - with analysis in line with organisation standards. You typically represent money being spent against when revenue will be generated using a Net Present Value (NPV) analysis. Some organisations prefer Return on Investment (RoI) which is basically the same data represented slightly differently
  4. Non Financial Benefits - these can be more nebulous in definition. It is important to establish the Critical Success Factor(s) and Targets with Proxy Measures if necessary. "Make Sydney a city on the World Stage" may have been part of the Business Case for the Sydney Opera House Construction Project? Agreement on how this will be measured (even by a proxy measure / Key Performance Indicator) needs to be developed if not present in the first cut Business Case (via the Benefit Realisation Plan - see below)
  5. Assumptions underpinning the Business Case. This is sometimes where creative benefits are driven so these warrant active review! If the project budget has not been created out of Initiation, there should be an assumption around costs
  6. Risks which may impact the Business Case

Beware the Mandatory "Get out of Jail Free" Card for Project Approval

Many Projects are justified on the basis of being Mandatory so if possible you should go beyond this statement to get to a better business reason. In such circumstances asking the question, what will happen if the Project doesn't get approved? is a way of flushing out the Business Case. 

I have been involved in many IT Upgrade projects for third party products and have seen the Mandatory card used. Better to ask the "not approved" question. If this means no third party support, has this support been used in the last year i.e. what risk is the organisation running? Is it possible to obtain vendor support for the existing Production version at a premium rate? By asking these questions and formulating a Business Case, the organisation may determine it is better to delay the Project (maybe waiting for a major new release) and take a risk and/or pay a additional support cost for a period of time.

Benefit Realisation Plan - the antidote to "fantasy business cases"

If within an Organisation the Business Case is just a mechanism to confirm funding for a Project, then this will encourage the use of too many creative assumptions as there is nobody on the hook for anything.

The most popular approach I have seen to ensure accountability for benefits is for one of the Project deliverables (or Products in PRINCE2 terminology) to be a Benefit Realisation Plan. I have detailed this in another post but the bottom line is that it quantifies who is on the hook to deliver what benefits and exactly how measurement will take place at some defined future date. This applies for both financial and non-financial benefits.

The Organisation needs to have a way of policing this as the benefits of the Project most often happen post closure of the Project itself (see my previous post on Project Success). A good example from one client organisation I have worked with is that as part of the Gate reviews to achieve funding for the next Stage in Project Execution, the latest Business Case is reviewed (i.e. it needs to be refined during the Project life-cycle). There is a final Gate review at a time agreed Post Project completion (typically a maximum of 1 year after completion), attended by the Project Sponsor, confirming whether benefits have been secured in line the Business Case.

Benefit Realisation - the ultimate example

I was involved in a Programme to introduce a variety of IT system improvements to reduce operational costs. A series of enhancement ideas across all IT systems in use were specified, evaluated for cost (effort to develop and implement) against the benefit (for the enhancement sponsor). Before the enhancement went into development the enhancement sponsor agreed to reduce his/her operational budget by the benefit amount. As soon as the change was signed off and went into Production, the enhancement sponsor's operational budget was reduced for the next year of operation. This was the ultimate Benefit Realisation as the Benefit was effectively captured within the Project life-cycle. It put the Enhancement Sponsor(s) on the spot to achieve the head-count reductions in the following year!

Tuesday, 16 September 2014

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. Read on for the explanation why?
Sir Isaac Newton

Organisation Change isn't easy

Project Management is typically all about introducing a change to an organisation. If the end deliverable of the project necessitates a change to human behaviours / business process or if the Project Manager needs to introduce a change to working practices within the Project team, then Newton's first law of motion should be considered.

Remember Humans are typically set in their ways

Humans are typically set in their ways and so will probably need some sort of force or other coercion to adopt the required behaviour or process. I have therefore adapted Newton's 1st law of motion as follows - People tend to continue travelling in the same direction.....unless acted on by an external force. This can be illustrated by this "flock of sheep" cartoon below:
Newton's First Law of Motion - Project Manager version
So give consideration to what the "force" is going to be within your project to achieve the desired behavioural change. A carrot and stick approach is often adopted. 
  1. Consider what Training is required.
  2. Consider giving incentives for examples of good behaviour - this can be as simple as praise or can involve financial rewards
  3. Consider what sticks will be applied if the wrong behaviour is seen, from "Naming and Shaming" through to a negative effect on an individual's performance within the business HR process
So thanks to Newton, we have a good prompt for how best to introduce change within an organisation.

Monday, 1 September 2014

A Resource Plan? Better think "Establishing your Project Team"

Your Project isn't going to deliver it's objectives without establishing a good team with the right mix of skills, experience and structure. This post deals with the planning considerations when Initiating the project. Although you might call it a Resource Plan, it is much better to get into the mindset of establishing your Project team. You also need to start considering a number of human factors, a topic I have addressed in another post.
Establishing a good Project team with the right mix of skills, experience and structure

Resource Plan - Existing resources, new resources, third party organisations or a mixture

When you Initiate a project you need to understand any resourcing constraints / assumptions such as "you will utilise the existing team augmenting as necessary". Utilising existing team members offers some benefits (organisational domain knowledge, often proven skills) but also some risks (do they retain BAU responsibilities which might mean they are not allocated to the project work as planned?)

Then as you undertake Planning and Estimating you will start developing your Resource Plan. I typically use the same spreadsheet which will eventually drive the required budget.

If you are using temporary resources (e.g. contractors) you need to establish recruitment time into planning. Normally rolling off such resources from the Project is fairly straightforward and dictated by contracts established.

Third party organisations may need a longer lead time to negotiate and agree contracts. Hopefully the organisation already has the relationship established (e.g. a master contract) because if you need to search the market first this will be additional time. Third party organisations typically allow some more resourcing flexibility during Project execution (maybe less recruitment headaches) but beware the danger of meeting the "top team" during pre-sales discussion only to be faced with the fresh faced graduates when the list of names for the Project execution comes through :-)

Attitude, Skills, Knowledge and Personality

Attitude, Skills, Knowledge and Personality all need to be considered in building the Project team and I have put them in the order of importance to me - I would rather have someone with the right attitude who will go the extra mile above someone with more skills but clearly there is a balance to be struck! Undertake a SWOT analysis of the emerging team definition and consider how you are going to address weaknesses you see?

Project Organisation

With small project teams (ideally located in one site) you can manage everyone directly. With bigger teams or ones spread over different sites and/or with 3rd party suppliers, you need to introduce a team structure with team leads in particular areas who you can interface to and they manage their teams.

Consider your span of control, the number of people who you can directly interface to will vary with project but I personally doubt you can be fully effective with more than around 10 people to interface to and that is when they are all in one office.

I would recommend that:
  • you define roles and responsibilities for these team leads having clear accountabilities
  • you document this structure in the Project Definition along with the wider Project Organisation (Sponsor, Project Board etc)


You can have the best Gantt chart in the world but Projects are delivered by people organised into a team structure to deliver effective results. So give this a lot of consideration when Initiating a Project.

Sunday, 17 August 2014

Project Scheduling Exercise "Cup of Tea" Workings

In a previous post I have set a simple Project scheduling exercise around making a Cup of Tea. This post includes my workings for the answers to the questions set. If you haven't yet tried the exercise, you might want to have a go before reading this in detail. Do you agree with my results?
Project Cup of Tea

The Cup of Tea schedule not yet levelled

Here is the schedule before any levelling has taken place. The column marked "Crit" shows the critical tasks and the finish milestone is at 14:30

Project Cup of Tea - Un-levelled Schedule

Showing the same information in a Gantt chart, the critical tasks are show in Red

Project Cup of Tea - Gantt Chart Un-levelled

Note that at 10:00 David is doing too many tasks or as Project Manager would say, he is over-allocated. The process to remove this over-allocation is to level the schedule.

Levelling the Cup of Tea Schedule

Most tools have specific views to allow you to manually level the resource over-allocations. Below is a typical view:
Project Cup of Team - Levelling views
It shows the effort allocations for David with a Gantt view below. See the 5 mins of effort by resource David for task "Pour boiling water into Mug".

A example Levelled Cup of Tea Schedule

Below is the schedule after levelling has taken place:
Project Cup of Tea - Levelled Schedule

Most of David's non critical tasks have been moved to be in parallel to the long task "Boil Kettle" (with little effort for David). However there was also over allocation of tasks to David near the end of the schedule and eliminating this has pushed the finish milestone out to 14:50.

Adding resources to the Cup of Tea Schedule

You can only get back to the original duration built from the Critical Path. I would have a team mate "Rinse spoon, dry and return to drawer". This saves 20 minutes and returns the schedule to finish at 14:30. The other levelling of tasks for David in parallel to "Boil Kettle" are retained.

Finally, any other ideas for reducing the overall Project duration?

I have seen people "pour the milk into the Mug" in parallel to "Let tea brew in Mug". This shortens the duration but unfortunately it reduces the temperature of the liquid and thus the quality of the brewing process. Which only goes to show that Project short cuts may get it delivered quicker but will it still meet the Project Quality criteria?

Project Scheduling Exercise "Cup of Tea"

I've been asked a number of times to do a bit of adhoc training on use of Project scheduling tools such as Microsoft Project. In this post I have given some background to modern scheduling tools and have posed a simple exercise which can be attempted by learners and experts alike. The workings for (my version of) the answers are made in a separate Post.
Project Cup of Tea

Some useful history for younger folk!

Critical Path Analysis alongside Project Evaluation and Review Technique were developed in the 1950s as techniques to help model Projects, have a read about them if interested. My first degree was in Civil Engineering and at University I learnt these techniques the hard way, by hand calculation! 

Now software tools do all the hard work but in some you can break the golden rules of the technique so I like to keep things simple and in line with what I learnt was needed to produce a valid network:
  • a Start and End milestone for the Project
  • all tasks in between these two points have predecessor and successor tasks 
Software tools often allow Work Breakdown Structures (WBS) to be documented in the schedule but encourage bad habits like dependencies linked to summary tasks.

(Read down later for definitions)

The Project - Making a Cup of Tea

What better example Project for an Englishman than to make a cup of tea. The Project work area is the worktop around a electric kettle in a kitchen. All non human Project resources are available in the kitchen and to start with let us make the Project Manager (David) do all the real work for a change :-) 

I have listed the Project tasks, durations, effort and task predecessors as follows. I don't mind you criticising my scheduling skills but please don't criticise my approach to make a good cup of tea except that I should really be using a teapot! 

Project Cup of Tea - Task List
However when scheduling the Project I am going to use Minutes rather than Seconds for Duration and Effort to make the schedule more visible in most tools.

Other Project information is:
  • Start date is 1 January 2015 at time 10:00
  • There are no periods of non working to account for
  • Remember to enter task duration & effort in minutes not seconds
  • All tasks are carried out by one resource named David (to start with)
So please get scheduling and answer the questions below

Questions about Cup of Tea Project Schedule

Your questions are as follows:
  1. What task numbers are on the critical path for the basic network?
  2. If there is no consideration of over allocated resources, what is the earliest finish time of your Project?
  3. If you remove the overallocation of tasks to David, what is the earliest finish time of your Project?
  4. If you bring in as many team-mates as you like to help David, reallocating some of the tasks to these folk (but nobody is over-allocated work), what is the earliest finish time of your Project now and how many people did you require? 

Definitions and other Help

Here are some definitions and general help for you:
  • Task - a specific item of work
  • Milestone - an event; it has no duration or effort. Typically used to denote a significant event such as the completion of a phase of the project or of a set of tasks
  • Duration - the elapsed time to complete a task
  • Effort - the amount of actual work required (in time units) for a particular task. A good illustration in the example "Cup of Tea" plan is the task "Boil Kettle". The effort required is minimal (basically to throw the switch) but the duration is governed by the amount of water, the temperature of the water poured into kettle and the capacity of the heating element
  • Task Predecessor - A task that must be started or finished before another task or milestone can be performed
  • Over-allocated Resource - a resource has been allocated more work in the plan than can be achieved in the available time 
  • Resource Levelling - process to remove the over-allocation (and ideally under-allocation) of resources and as far as possible avoid peaks and troughs in the resource schedule. Some tools allow this to be done at a click of a button but I have never had much success with this and prefer to do by hand guided by specific views setup. In a real-world project I will allow some over allocated resources (within reason) because estimates may not be correct and overtime can be used
  • Work Breakdown Structure - decomposition of high level project deliverables into tasks and sub-tasks
  • Critical Path - typically the path through the schedule of tasks which determines the shortest duration for the project. If any task on the critical path is delayed this will delay the completion of the project.


The answers for the questions posed above are:
  1. 1,14 (start and end milestones) and in terms of real tasks, 4, 6, 7, 8, 11, 12 
  2. 14:30
  3. 14:50
  4. 14:30 with one extra person

Twitter Delicious Facebook Digg Stumbleupon Favorites More