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, 25 January 2016

Is Project Manager Authority - Earned or Given?

A Project Manager requires enough authority to control the project but is this 
authority EARNED or GIVEN? I believe a bit of both is the answer but the ability to earn it is ultimately more important. 
Project Manager Authority

Firstly, what authority is required?

The Project Manager (PM) can't control the project without some authority. This authority may be to form the team but if the team is a given at least it should be to direct and control the allocation of tasks within the team. 

The other authority which I always will argue for is control of the allocated Project budget. I remember my old boss at AXA many moons ago saying "this is your money to spend as you see fit - as long as you deliver the project within the Time, Cost and Quality targets!!". I typically have never seen such total freedom since but within some bounds, budget control is important.

Sometimes while you don't have direct authority as per the cartoon but you should have strong influence and if you don't, the team don't need to know this ;-)

Authority you are GIVEN

Examples of Authority you are GIVEN are:
  • your job description
  • control over project funds
  • status within the organisation
  • control over information flow to the team

Authority you EARN

Example of Authority you EARN are:
  • skills you demonstrate whether these be technical or management
  • track record (e.g. as demonstrated on LinkedIn)
  • ability to negotiate
  • ability to resolve conflict
  • doing what you say you are going to do
  • building alliances
  • building a good rapport with your Stakeholder community for the Project


You need sufficient authority to effectively manage and control the Project. Some of the this authority you can be given but much of it you need to earn especially if you come as an external consultant.

Monday, 11 January 2016

Modifying a vanilla Change process to handle a higher volume of Change Requests

I have previously spoken about the need for a solid Change Management process within your Project. Although undesirable, sometimes you are faced with a Project that has to cope with high level of change requests. In such circumstances, I tend to modify my vanilla 4 step process to give you the best chance of coping without totally derailing project progress.
Projects - Coping with a High Volume of Change Requests

Simplified 4 Step Process for most Projects

Before going onto address a process for Projects with high volumes of change requests I want to recap on my vanilla 4 step process which I explained in a previous post and should be suitable for most Projects up to say 4 Request for Change (RFC) a month on average. The 4 steps are:
  1. Submission of a Request for Change (RFC)
  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

Key Messages regarding Projects with High Volume of Change Requests

Firstly, let me remind you of some key messages re high volume of Change Requests:
  • 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 across all lifecycle phases. Therefore even if every Request for Change (RFC) is rejected, the actual change process can derail a project. A sensible PM makes some allowance for running a process with a low volume of RFCs but if the volume gets too great, this should be taken back to the Project Board / Sponsor
  • A Project is all about delivery of something to achieve a business 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 your next Project Board meeting
  • So in summary, remember the proverb "If project scope is allowed to change freely, the rate of change will exceed the rate of progress"
If Project scope is allowed to change freely - the rate of change will exceed the rate of progress

So after these considerations you still need to handle the high volume of Change Requests - I recommend optimising the vanilla 4 step process. I should note that this process is tailored to IT projects although the same principles apply to other project types.

Nominate your Change Champions

Nominate three people empowered by the Project Board as Change Champions who, with the PM, will handle new RFC load on a daily drip-feed basis:
  • Change Requirement Champion, someone from the business who has best overall understanding of the requirements (Senior User?)
  • Change Technology Champion, someone from technology who has best understanding of the technical work to meet requirements e.g. architect
  • Change Business Champion, either the Sponsor themselves or more likely a proxy who can represent the Sponsor. This person has their eye on the Business case
Although these are 3 separate roles, one person can take more than one role which can make it easier. So a good example might be the Senior User covering Requirement and Business champion roles in the process.

Revised Process using Change Champions

  • Step 1 – Filter out the obvious ones. The Change Business Champion validates the Business case against where the project is within the project life-cycle and the criticality of the RFC. Reject if not valid and thus minimise wasted effort on impact assessments
  • Step 2 – Change Technology Champion undertakes a fast and high level “initial impact estimate” of the RFC involving the Change Requirement Champion and others as necessary but the effort should be no more than 1-2 hours
  • Step 3 – Change Technology Champion works with Project Manager within this couple of hours effort to quickly assess the RFC against the Project criteria (Note: this is not a committed estimate/ impact assessment, it is just intended to give a scale of the likely impact e.g. trivial or it will derail key milestones)
  • Step 4 – Change Business Champion makes a decision based on the “initial impact assessment” whether this is a RFC which is important enough to probably be approved at a Change Board even considering the likely impacts or would be rejected / postponed (e.g. to a future release for example)
  • Step 5 – Only if the Change Business Champion authorises a RFC for a full impact assessment, a more detailed and committed impact assessment is produced for consideration and approval in the next Change Authorisation Board. In emergency “time critical” situations in the project life-cycle where, say, time impact will be greater day by day until a decision is made, the Business Champion may authorise work to commence on the change based on the initial impact assessment. A full impact assessment is produced in parallel to the work commencing


This enhanced process should give you a better chance of coping with the high volume of Change Requests - but much better to not be in this position at all :-)

Twitter Delicious Facebook Digg Stumbleupon Favorites More