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

Wednesday, 26 March 2014

Attack the Risks before the Risks attack you!

You will improve your probability of Project success greatly if you look to identify the Risks for your project and go out and attack the important ones. There are many manuals written on Risk Management so what I intend to do in this post is give a "whistle stop tour" and inspire you to take this seriously in your Projects using a few Proverbs along the way!
Projects - Attack the Risks before the Risks Attack You

What is a Risk?

Firstly a reminder of what a Risk is. A Risk is an event which may happen which can have a negative (or positive) impact on the project in all it's dimensions - Time, Cost, Quality, Benefits etc.

Yes you can have Risks with a positive impact - an upside! For example, if your Project is to introduce a new public search engine. If you stated a Risk of Google going out of business, this would have an upside on your Benefit Case for sure. I just don't think the probability would be that high and we will return to that point later. But it raises an interesting point on Risk Identification. We all focus on internal risks but we should try and force our thinking to consider external risks too.

Another point you might want to get a sense of early on in the project lifecycle (ideally from the Project Board) is how much risk is acceptable - sometimes a project needs to be very risk adverse, sometimes a more risky, adventurous project is acceptable.

Step 1 - Risk Identification & Recording

The first point to recognise about Projects is What you don't know ..... hurts you!

Project Risks - What you don't know hurts you!

So use your own judgement and that of the team (brainstorm workshops) on what could trip up successful execution of the plan (mainly) and also consider both internal and external factors. You can always put in some standard risks, here are a couple for your Risk Log - Parkinson and Murphy!
Project Risks - Parkinson and Murphy are alive and well - and may be working on the Project

Some other top tips with regard to identification are:
  • every open assumption should be considered as a corresponding Risk, see a specific post on this
  • record in a Risk Log which is easily maintainable and sortable
  • use similar style wording "Risk that <something happens> due to <cause> resulting in <effect>"
  • double check, have you captured both the cause and effect of the risk?

Step 2 - Evaluate Risk

Three dimensions to consider in the Evaluation of Risk are:
  • Probability - for simplicity I use a Low / Medium / High rating
  • Impact - for simplicity I use a Low / Medium / High rating but also have text box to articulate in real terms using the typical project dimensions of Time, Cost, Quality, Benefits etc 
  • Proximity - when is a risk likely to materialise as an issue? Clearly if a risk can't materialise for many months you can focus your immediate attention to those that could hit you next week!
What I do in my Excel Risk Log is to apply a simple scoring system 1 for Low, 2 for Medium and 3 for High. I then multiply Probability x Impact to give a Risk Score and sort the resulting log by Score to give a crude list in order of importance to look at.

Step 3 - Devise your risk management response

What are you going to about each risk. Responses can include:
  • Accept - do nothing specific but continue to monitor
  • Mitigate - take actions to reduce the probability of the risk occurring or the impact or both
  • Prevent - change your plan so the risk no longer exists
  • Transfer - give the risk to some other organisation to manage
  • Contingency - establish a planned approach which can be brought into play if and when the risk materialises
Make sure you assign ownership for the Risk. The owner keeps an eye on the risk (has anything changed re probability, impact and proximity) as well as, in many cases, the response actions (although I recommend that the Project Manager keeps an eye on anything significant)

Step 4 - Ongoing monitoring

Ongoing monitoring and review whether new risks have been identified is important across the project lifecycle. My personal approach is to have a weekly meeting with the sole purpose of reviewing RAIDs (Risks, Assumptions, Issues, Dependencies). However:
  • include the topic in other meetings you have with the team so thinking about risks is embedded in the whole team psyche
  • ensure the Risk owners take their role seriously and keep you posted outside any regular meeting. The person should understand that they will be under the spotlight should a risk materialise and questions will be asked!

Conclusion / Other points

As I said in the introduction, Risk Management is a big topic and this is just a taster to inspire you to take it seriously within your project and not just pay lip service to the topic. So go identify, evaluate and attack the big risks which threaten your project success. Otherwise, there is a fair chance that one of them will come and give you a bloody nose!

Some other points not yet mentioned which need consideration in Risk Management:
  • budgetary impact
  • communications to/from the Project Board

Wednesday, 12 March 2014

A pilot doesn't try and fly a plane without instruments, neither should a Project Manager

A pilot has logged the flight plan and taken off to his chosen destination. He doesn't then sit back and hope for the best, he monitors where he is against the plan and makes controlled adjustments or in a worse case scenario makes a mayday call before he crashes. Guess what, a Project Manager should do the same - it's called Monitoring and Control.

Proverbs to illustrate Monitoring and Control

I love a Proverb or two and this one illustrates why you should get some good monitoring and control in place to avoid that embarrassing Project Board question! 
Project Proverb - How do Projects slips? Answer One day at a time

So what monitoring should you have in place? The following Proverb warns of the dangers of percentage complete as a monitoring metric.
Project Tasks progress quickly until they become 90% complete then remain near 90% complete for many weeks

Estimate to Complete (ETC) is a better basic task monitoring approach considering both effort and duration. Certainly for tasks over a couple of weeks maximum I am looking for alternative metrics. This could be some interim milestones or metrics specific to the task at hand - remember the Proverb If you can't measure it, you can't manage it!

Example - IT Software Migration Technical Analysis Phase

Here are some real example metrics from two IT project phases.

In this first example, there was a long task to analyse a number of existing objects within a database. This "analysis not started" plan graph per database was used to monitor progress over a long task length (progress against plan has been removed for clarity).

Project Progress Monitoring - Use of Metrics

Example - IT Software System and Integration Test Phase

In a software test phase I would first look for a "run plan" measuring text execution. As per the graph below you can map the cases executed (not necessarily passed, it could be failed but at least the defect is identified)


Project Progress Monitoring - Test Case Execution over Time

In a tabular form, a point in time could be:


You also need to have metrics around the defects status - are they getting fixed at a good rate, any priority defects (which are blocking test case execution), are we past the hump of outstanding defects that you tend to get.

Project Progress Monitoring - Test Defect Status Metrics

So this table can be replicated for each functional area being tested and a a stacked graph created of defects owned by "Development" (Open, Analysis and Being Fixed statuses in the above example).

In Conclusion....

So once you have your plan in place and get into your cockpit to fly your project to it's destination, please ensure you have working instruments as well as securing your seatbelt!

Saturday, 1 March 2014

"Planning & Estimating", the "Bonnie & Clyde" partnership of Project Management

There are many great partnerships in world history, Bonnie & Clyde, Batman & Robin, Lennon & McCartney Morecambe & Wise; the list is extensive. Planning & Estimating is the great partnership of Project Management and they need to work together to give you a credible plan.

Estimating focus of this post

I've already spoken of Planning in a previous post so Estimating is the focus of this post. 

Try not to be influenced by "plan expectations" when undertaking estimating, the classic "We really need to get this task done in 2 weeks - umm, yes I think this will be possible". Come with an open mind to the estimating process and be prepared to call out a large estimate as per this Proverb.

Project Estimation - Good estimators aren't modest - if its huge they say so

If possible estimate from different standpoints

I must admit to be a fan of bottom up estimating whenever possible. Decompose a task into lower level items which can be better estimated and then aggregate up.

But top down estimating can also be useful especially as a phase check. In IT waterfall software development projects, a classic approach is to perform a bottom up estimate on the likely construction effort and then "expand from construction" to give estimates for other phases using industry (or even better locally derived) effort percentages across phases such as:
  • Initiation 6%
  • Analysis 8%
  • Design 15%
  • Construction 25%
  • System & Integration Testing 28%
  • Acceptance Testing 12%
  • Implementation 3%
  • Post Implementation 3%
Project Estimation - Estimators do it in groups - Top Down and Bottom Up

From the Proverb above you can also gather that it is good to get several people involved in estimating rather than rely on 1 person. This is particularly important when asking an "expert". I prefer to have separate estimates prepared by a couple of experts rather than have two experts in the same room as I find that one will often defer to the other and you won't get the possible contrast.

Sometimes you may need to make assumptions in estimating. Please document and ideally close off as many as you can during your estimating phase. Every open assumption is a risk to be assessed.

Confidence in estimates

It is good to assess confidence as part of the estimating process, you may assess
  • have we done similar things before?
  • is this completely new to the organisation?
It is often beneficial to focus the team on coming up with a range of estimates (although this can increase the effort required):
  • pessimistic worst case estimate
  • optimistic best case estimate
  • realistic most likely case estimate

Some common mistakes

  • Politics - estimating to meet a project deadline / cost constraint
  • Lack of experienced people in the subject matter being estimated
  • Haste - cutting corners in your estimating because you are under pressure to deliver something
  • Estimating assuming an expert is doing and then asking the new recruit to undertake
  • Sand-bagging - over estimating for an easy life
  • Super-optimistic - assuming is it always going to go perfectly
  • Quality - forgetting to estimate for quality processes
  • Incorrect scope and/or work breakdown
  • Not writing down the rationale for the estimates, what is included and any assumptions

And Finally...

When you have done your estimating and reflect this back in the plan beware the temptation to add too many resources to achieve an end date as illustrated by this Proverb

Twitter Delicious Facebook Digg Stumbleupon Favorites More