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, 18 June 2014

The Ancient Greeks called it correctly - "Everything changes and nothing stands still"

In 500 years BC Heraclitus, the Greek philosopher, stated "Everything changes and nothing stands still". He could have been speaking of most Projects. If you were to bring the quote into the 21st Century you would say, "Some change is inevitable....except from vending machines" :-)
Some change is inevitable - except from vending machines

So with some requests for change inevitable during the project, as a Project Manager, you need to have a process to manage these requests else face chaos. PRINCE2 has a Change Management process but I tend to utilise a cut down version. In PRINCE2, every Request for Change (RFC) is supposed to start with an Issue but I believe this is a little excessive. 

Simplified 4 Step Process

I run a simplified 4 step process:
  1. Submission of a Request for Change (RFC). Ideally have a form for this so it is clear who is requesting (sponsoring), what the change is (a new or changed requirement?), the business case for the change etc and I always like a section regarding the impact of the RFC being rejected (is there an alternative approach, maybe a manual workaround in the IT world)
  2. This RFC is logged (in the Change Log) and allocated a unique number
  3. The RFC is evaluated for impact on the project e.g. Effort/Cost, Impact on baseline plan etc
  4. The RFC impact then needs to be approved by the Change Authorisation Board. This could be a separate body working under the Programme / Project Board or the main Board themselves (explained later)
If approved, the RFC then needs to be implemented and appropriate products updated accordingly.

Can't the Project Manager approve the RFC in some circumstances?

Some suggest that a Project Manager can approve a RFC as long as he/she is not forecasting going outside cost and time tolerances. I believe that this is bad practice. Tolerances are provided against risks identified by the Project Manager not to handle changes. In principle, the Project Owner (Sponsor or Project Board) should have or obtain additional funding for changes. Clearly if the forecast spend is really healthy I will be happy to use baseline budget but not typically contingency funds. In terms of timescales, even if I believe that a change can be delivered within the baseline delivery milestone I will likely highlight increased risks to the Change Authorisation Board i.e. if you approve this RFC, it should be delivered within the baseline milestone but will increase the risk of slippage.

What is the Change Authorisation Board?

In the simplest projects this will be the Sponsor. It can also be augmented by other members of the Project Board where one exists. In more complex projects or Programmes (especially where a higher number of Change Requests are anticipated) a specific Change Authorisation Board is recommended with timetabled meetings established. This will ideally have the Sponsor in attendance but will have other participants from the business and the project team and the meeting makes the decision (but with the Sponsor having the ultimate say, if present)

Some Golden rules of Change Management (especially within IT Development projects)

  1. If you don't have some baselines in place (e.g. scope, requirements etc) you don't have the basis for a change control process. I have come across the odd business user who thought they could resist signing off anything and thus be free to change their minds many times. Safe to say, that got escalated to the Sponsor / Project Board pretty quickly!
  2. The cost & impact of a change is greater the later in the Development cycle it is made
  3. You need to consider many dimensions in your impact assessment - e.g. Time, Cost, Quality / Scope, Business Case, Risk, Products to be updated
  4. Running a change process takes key individuals away from doing other planned work to ensure requirements are understood, estimate and aid the Project Manager (PM) in impact assessments. Therefore even if every RFC is rejected, the actual change process can derail a project. A sensible PM makes some allowance for running a process with the odd RFC but if the volume gets too great, this should be taken back to the Project Board. I also have adapted the process to cope with higher volume situations, a subject I will return to in a future post.

And finally...

A Project is all about delivery of something to achieve a benefit case and too many changes of direction can put the delivery and thus the benefit case at risk. If you detect this could be occurring, this is one to flag in bold and discuss at with your Sponsor or Project Board. As you might expect, I have a Proverb to explain....
If Project scope is allowed to change freely - the rate of change will exceed the rate of progress

But if you are still faced with lots of Change Requests being raised (which the Project Board agree that the Project needs to handle), you should consider optimising the process from that described above which I have covered in this post on Change Management for high volume scenarios.

Tuesday, 10 June 2014

Defining a Project - Remember the Kipling poem

A good written definition of a Project should be produced as soon as possible to ensure you have understood the project brief correctly and can agree with the owners of the Project that you know where you are heading and are set up for success

This post is a check-list of what I would expect to see in a document whether that be a Project Initiation Document (PIDin the PRINCE2 world or Project Management Plan (PMP) in the Project Management Professional world.

In production of these documents I suggest that you keep in mind a Kipling poem:
Project Definition - I keep six honest serving-men (They taught me all I knew); Their names are WHAT and WHY and WHEN and HOW and WHERE and WHO
I keep six honest serving-men (They taught me all I knew);
Their names are WHAT and WHY and WHEN and HOW and WHERE and WHO.
I send them over land and sea, I send them east and west;
But after they have worked for me, I give them all a rest.

Note that in the check-list below I have used PRINCE2 terminology e.g. the document is referred to as PID.

What? - the Project Brief

I would expect to see the following in the PID:
  • Objectives
  • Major deliverables / desired outcomes
  • Scope (in and out sections)
  • Method of approach
  • Key Assumptions
  • Constraints
  • Quality and Acceptance Criteria

Why? - the Business Case

Depending on the scale of project I prefer this to be in a separate document - see a post on this subject

When, How and Where? - the Plan

Who? - Project Organisation, Governance and Stakeholders

Other

Conclusion

The Project Definition is the contract between the Project Manager and the Project Owner. It is important to establish as early as possible in the project life-cycle to give a stable foundation for execution of the Project. It will be used to judge one dimension of project success. So if you can't find six honest serving men, take these roles yourself and get defining!

Twitter Delicious Facebook Digg Stumbleupon Favorites More