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

Sunday, 27 December 2015

Considerations for picking up an in-flight Project

As a consultant I've had the telephone call a few times "Can you come and pick up this in-flight project?". Sometimes the client mentions the word "recovery", sometimes not, but if you assume the worst you typically won't be disappointed! In any event I always look to assess the health of the project within the first few weeks and in this post I'll take you through the approach I take.

Start with the Project Definition

My first reference point is to read the Project Definition document as this is the foundation of any Project. Checks I make include:

Look for the Business Case too

  • Is there a Business Case?
  • What is the linkage between the Business Case and the Project deliverables e.g. specific requirements to be met

How has the Project progressed against the plan as stated in the Project Definition (Evidence of Monitoring & Control)?

Evidence of Project Governance happening?

I will look for evidence of good Governance processes in place
  • Are there future Project Board meetings in the diary?
  • Is there evidence of previous meetings - Project Board Packs and Minutes/Actions?

Above all - listen to people

You should organise meetings with various stakeholders and key Project team members, fire some open questions and listen to how they respond. This should reveal useful information and views about the status of the Project as well as attitudes and the human side in general

Conclusions and an Example

You have made your assessments and you need to need to decide what remedial actions are required, if any. Sometimes you may need to have some hard discussions with your Sponsor and Project Board. You need to do this in the first few weeks before your "honeymoon" period has ended.

I remember one in-flight IT project I picked up for a new system development and assessed there wasn't a 1 in 100 chance of making the "planned" delivery date even with remedial actions despite the project being reported as on track. I had "the hard discussion" face to face with the Sponsor to say this and stated that I would replan, descope some functionality to deliver the remaining key functionality as soon as possible (I gave him an approximate date and confirmed within 2 weeks) and essentially prove the team could deliver something versus cancelling the whole project. 

Clearly he was not happy at all but eventually agreed to this approach. Based on good evidence of progress towards hitting the delivery date (which we did), he agreed the additional funding to deliver the Release 2 (the remaining functionality which was de-scoped from Release 1). So a (reasonably) happy Sponsor in the end and a Business Case that was not too badly compromised.

Sunday, 13 December 2015

And now, the end is near, And so I face the final curtain

"And now, the end is near, And so I face the final curtain" to quote the song "My Way". A Project is a temporary endeavour with a start and end point. So what are the things to achieve as you approach the "final curtain" with the team leaving the "stage"?
Project Closure - the final curtain

Any Remaining tasks for the team?

Check if there are any remaining tasks for the team, for example:
  • Are transition to BAU operations activities needed and if so, have they happened? If not, they need to.
  • You should have a lessons learnt session and prepare the lessons learnt output either as part of separate to the Project Closure Report
  • Are there points which need to be addressed which it is not practical to keep the Project going for? If so, owners need to be found to take these forward (see Closure Report below)

Roll-off Team

In many Projects your team cost money booked against the Project Budget so as you enter the Closure phase you may have already rolled off a number of the team (with maybe some call on their time for lessons learnt sessions etc). So you should look to finish the roll-off plan including you as Project Manager. Forecast the last week you will charge costs to the Project and thus you can finalise your Project spend against Budget. For other roll-off considerations see this post

Closure Report

The measurement of the success of the Project has two dimensions and the Closure Report is, in part, an assessment of the Project Team dimension ("Project Performance"). The sections I would expect to see in a Closure Report are:
  • Background, key objectives and summary of Business Case (links to documents with more detail).
  • Summary of Project Approach adopted.
  • Key Products delivered including purpose, version status and links to location in the Project File.
  • Team Member details (the BAU team may want to confirm a point of detail at some time in the future).
  • Performance - Time. Table showing key milestones (ideally those published in the Project Definition augmented by any added during the Project), the Baseline date and the Actual date achieved with comments as appropriate. Normally there is one or several primary milestones defined in the Project Definition objective, these should be highlighted (e.g. in IT Projects it might be Production System Release Date(s)).
  • Performance - Scope. Was the baseline Scope delivered or was some of the scope removed or potentially additional scope delivered (identified via Change Control)?
  • Performance - Quality. Quality metrics should support any statements, for example in IT Projects this might be the number of Post go live "warranty incidents" which needed resolving.
  • Performance - Costs. Comparison of actual costs spent versus the baseline in the Project Definition.
  • Performance - Benefit Case. Has the benefit case changed at all through the Project life-cycle?
  • Change Management - was what the effect of Change Requests during the Project life-cycle (link to Change Log)
  • Risk Summary - are there any open risks to be monitored by BAU Operations?
  • Issue Summary - are there any open issues to be resolved by BAU Operations?
  • Post Project activities - this is an important section stating activities which need to be completed post Project closure and who owns these actions. Ideally this list will be policed by some residual body such as a PMO. An examples might be Benefit Realisation steps / checkpoints .
  • Summary of key lessons learnt with a link to the full report

What about the Benefit Realisation?

The other dimension of Project success is reaching the target benefits and these typically are realised post closure of the Project. Hopefully it is clear who is accountable for these and when they will be reported (and who will this report go to). See my post of Benefit Realisation

Project Celebration

Hopefully you have had a successful Project and have a happy Sponsor. Ideally there is sufficient Project budget (or raid a BAU budget) to allow for a celebration event for the Project team. Discuss this with your Sponsor to agree the format, formal or informal, does the Sponsor want to make a speech etc? 

If you are appropriately skilled (or find someone on the Project team) why not have a Project Song which everyone can sing at the celebration event! I play the piano and have done this a few times now. One of my best attempts at this was for the celebration of the Risk Reward Project (concerning optimised Energy Trading). I managed to work in some key names from the Project team, operational teams affected (with business terminology introduced such as R-R-B, the Risk Reward Band) as well as mentioning that the Sponsor, Fran├žois, was happy a few times :-) [if you want to watch, ensure you are displaying captions to get the lyrics]




Risk-Reward, Risk-Reward
Risk-Rewards' on the drawing board
Ricardo does deduction, Pete does the construction
Soon there is a system good to try

Risk-Reward, Risk-Reward
Risk-Reward has really scored
The Board are most contented
Objectives now cemented 
Francois is a really happy man

Everybody knows the R-R-B
All of Risk will smile when we keep inside it
Maybe, you can never be sure
We exceed it, then
CHPO have the cure!

Risk-Reward, Risk-Reward
Risk-Reward has really scored
The Board are most contented
Objectives now cemented 

Francois is a really happy man

Tuesday, 1 December 2015

Rolling off Projects - After the Lord Mayor's Show

Near the end of your Project (and potentially at various stages before that) you may need to "roll-off" team members. This post considers the planning and execution of this including consideration of a potential anti-climax for the team members concerned - as we British call it "After the Lord Mayor's Show"


After the Lord Mayor's Show?

"After the Lord Mayor's Show" is a British proverb for anti-climax. The Lord Mayor's Show is a colourful and historic parade to welcome in a new (city of London) Lord Mayor each year. There is a long precession of marching bands and floats which travel through the streets of the city of London each November. After the parade has passed, bringing up the rear are cleaning vehicles to remove the horse manure. So in the Project context the proverb is saying "after working on a Project with excitement, pressure and achievement what an individual may face may be considered boring"

Consider impact on individual being rolled-off

I have observed several times when team mates have been rolled off near the end of a major Project a feeling of anti-climax of going back to a Business as Usual (BAU) role. It can stimulate thoughts of
  • "Let me take the experience of the Project and move onto another organisation"
  • "I don't feel motivated by going back to my old job"
While this isn't strictly in the Project Management remit, I like to brief the line management of what I consider are BAU Risks for them to own and as I always say, Attack the Risks before the Risks attack you. So proactive action may stop the loss / de-motivation of staff moving back into a post Project BAU world.

Planning considerations

As part of your ongoing Project monitoring and control you should be assessing if and when resources should be rolled off the Project. Projects differ in their funding arrangements with the most stringent (in terms of the focus for a Project Manager) being where all resources are funded by the Project budget. If you are in this stringent environment you should take a look at my post on Cost tracking

So at least once a month, look and plan ahead for resource release dates and / or resource extensions should a previous arrangement / booking no longer be correct. And for those of you running IT Projects, don't forget the vital non human resource of Environments which are known to kill Projects! So, for example, do you need to extend an environment booking because testing is not due to complete on time?

You need to consider local processes for rolling off people which may range from a quick email to invoking a termination clause in a contract. So work backwards so that you can establish the time to press the Go button to achieve a release date in line with the plan execution. Don't forget the human side, so have a discussion with the individual concerned about leaving the Project. You never know, they may give you a very good reason why you should delay the roll-off process!

Conclusion

As part of your monthly monitoring and control activities on your Project you need to consider whether to initiate processes to roll people off at some point in the near future. Please consider the human side by having a good exit discussion and brief line management about the risks that come "After the Lord Mayor's Show" 

Twitter Delicious Facebook Digg Stumbleupon Favorites More