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

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!

Conclusion

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

Conclusion

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!

Twitter Delicious Facebook Digg Stumbleupon Favorites More