Email Susan@My-Project-
Management-Expert.com
Website http://www.My-Project-
Management-Expert.com
Date August 2010
Version V1.0
Approved Yes
Page 1 of 14
Page 2 of 14
When you start a project it is extremely tempting to rush head long into
realisation that most of the problems encountered later on in the project were
all arguments over things such as change requests and scope issues.
I quickly realised that spending some time at the beginning of a project detailing
the key project management stakeholders and Project Sponsor would resolve a
Page 3 of 14
Now you’re probably reading this and thinking, “if I’ve written all that
Well it’s certainly the first thing I want to know when I am brought into a
company to turn around a troubled program or projects. I have lost count of the
number of times I have discovered that all the key project stakeholders have
different views of what will constitute a successful project despite there being
Now sometimes this can work to your advantage especially if your project is
technology platform you could claim that your project was completed on time
when all the servers were deployed, rather than at a later stage when all the
software needed to be installed and all the existing applications migrated over.
simply lead to numerous arguments later on with your boss and project
sponsors /stakeholders. It will also probably cause your project budget to run out
of control as this is one of the major causes of scope creep, which is hard to stop
once it starts.
Page 4 of 14
I would bet that if most people were asked “what do you think a project manager
Now it’s true that being able to write a project plan is a key ability for any project
manager to have. However often in the rush of getting a project of the ground and
delivered, having a coherent project plan written and approved is often forgotten. This
then leads to deadlines being missed because key stakeholders were unaware of their
existence.
Now the key thing as always is not to go mad with your project plan. A 1,000 line
plan may look very impressive but who do you think is going to be stuck late at night
So remember to write a plan, keep it short and sweet, and most importantly, make
Page 5 of 14
If you don't identify and control project risks and issues, then they will control you
and ultimately, the project. A risk is a potential problem that could affect the delivery
of your project if it materialises. Basically a problem that hasn't happened yet, and
which you'd like to keep it that way [Wiegers, 1998 1]. An Issue is basically a Risk
which became a reality and which you now need to actively troubleshoot.
Risk management has been identified as one of the most significant best practices for
software development [Brown, 1996]. Simply identifying the possible risk factors
isn't enough. You also have to evaluate the relative threat each one poses so you can
focus your risk management energy where it will deliver the best result.
The key to all of this is to ensure you keep a manageable list of Risks and Issues.
After all you may feel that having 400 risks in the RAID log, but will you really have
the time to manage them all, without taking your eye off the really important
So follow the 80/20 principle and you’ll find that you manage the project risks, rather
1
Wiegers, Karl. "Know Your Enemy: Software Risk Management," Software Development, vol. 6, no. 10
(October 1998), pp. 38-42.
2. Brown, Norm. "Industrial-Strength Management Strategies," IEEE Software, vol. 13, no. 4 (July 1996), pp. 94-
103
Page 6 of 14
As part of your project planning activities in Tip 4, you will need to ask your team
leads and resources for estimates for delivering tasks. Now most resources like
providing these estimates in terms of calendar time ie 5 days. However this doesn’t
help you much as a project manager particularly when working in a matrix managed
As such I prefer to get estimates in terms of effort ie the actual hours it will take to
complete the task and then translate this into calendar days. This allows you the
flexibility to take into account the fact that key information required for that task
might take a week to appear, but since the task itself will only take 3 hours that’s not
The other key point of working in this way is that project manager’s always over-
estimate how many hours resources actually spend on their task. They always assume
it is 100% of the time, whereas in reality most resources only spend 50-60% of their
time working2. The rest of the time is spend in paperwork, admin and let’s be honest,
So remember, get estimates in terms of effort rather than calendar timeframes, and
don’t assume in your project plan that your resources will devote 100% of their
3. Wiegers, Karl E. Creating a Software Engineering Culture. New York: Dorset House Publishing, 1996
Page 7 of 14
It can be really daunting to look at your project plan and realise that few of the tasks
are ticked as complete. As such it can be extremely tempting to start ticking tasks as
After all if lawyers often operate on the principle of “I was thinking about your case
this morning therefore that counts as billable time”, it’s not surprising to find your
key resources following similar thoughts processes along the lines of “well I was
thinking about that algorithm in the car and I reckon I’ve got a solution. So that
probably means I’ve completed about 70% of the task since the solution part was the
toughest bit”.
Now the big problem is when loads of your resources start thinking in this way. This
can sometimes be due to over-confidence; often it’s due to resources having too
much work to do and trying to fob you off. Either way you’ll rapidly find out that a
project which on paper looks as if it’s bang on track, in fact isn’t. and is rapidly
slipping as a result.
So the golden rule is that if you ask someone whether their specific task is actually
complete and they answer “yes…………except for……” then it’s not done and you
I’ve managed numerous big projects and programs for over 13 years now and in that
Page 8 of 14
Actually that isn’t completely true. There was one project manager who managed it,
but she had a tiny little project which she micro-managed by working 18 hours a day
and driving her team resources insane. At the end of it they had to ship her off abroad
So you should assume that your projects will never go precisely as you planned.
Contingency risks happen. Everything from swine flu to rail strikes to resources
resigning can and does happen. That is why I wrote the article,
Now there are a variety of ways to get around this. You can use your project risk
analysis to estimate possible schedule impact and include that as a contingency buffer.
An even more sophisticated method uses critical chain analysis which pools
However the way I personally use is to always include contingency into your plan
from the outset. You don’t need to put this in as a separate item, just increase the
length of certain tasks you deem the highest risk and see what you can get away with!
Last year I wrote an article which proved controversial to say the least titled,
3
4. Zultner, Richard. "Project Estimation with Critical Chain: Third-Generation Risk Management," Cutter IT
Journal, vol. 12, no. 7 (July 1999), pp. 4-12.
Page 9 of 14
Yet the reality is that it is becoming a common ploy by project manager’s to cover up
the real situation a project is in. Now this may be due to the pressure caused by the
global economic crisis which is contraining project budgets, but certainly it is occurring
In fact just this year I’ve been approached to manage two large programs which have
been in a crisis situation for months now, but no-one realised because those in charge
were extremely economical with the truth. Further none of the Executives felt able to
check the reality because the report was usually presented as a 70 slide deck!
So you need to ensure you report accurately but without panicking you project sponsor.
If you can see the project is heading for trouble do not hesitate to put your project status
into RED. Just make a serious attempt to resolve it before pressing the panic button!
At the end of the day you are only going to be remembered for having delivered
Page 10 of 14
had to do it with few resources or worse still, with the incompetent resources. As
such it makes sense to get the best and most experienced resources you can
working on your project because they will make your life much easier in terms of
Now you may wonder about my comment about incompetent resources. Well as
in life, not everyone is the same. You will find some resources who are absolute
gems. They go that extra step to help you, they deliver on time and they don’t
give you any problems. Then there are others who are clueless and extremely
difficult to manage.
All you need is one of these on your team and you will spend all your time
firefighting their incompetence whilst trying to ensure the rest of your team
doesn’t get sucked down by their attempts to divert attention away from their
deliverables.
So ask around, and ensure you find a way to get the best resources working on
your project. That will certainly make managing your project team easier whilst
Have you ever been in the situation where you simply cannot see eye to eye with
Page 11 of 14
In this instance it’s really easy to simply decide to ignore them completely. To not
invite them to meetings, to make decisions without their input. This is a fatal mistake
which will come to bite you later on especially when you get into the change request
process.
So if you are unfortunate enough to end up in a Dilbert situation as above then, try
everything you can to work with your project stakeholders. If that fails talk to your
boss and ask their advice on what you should do. You’ll find that unless you are
perceived as being a difficult person yourself, that others will have been in the same
Useful Links
Page 12 of 14
http://www.my-project-management-expert.com/project-manager-duties-1.html
http://www.my-project-management-expert.com/how-to-manage-a-project.html
http://www.my-project-management-expert.com/how-to-write-a-project-plan-
1.html
http://www.my-project-management-expert.com/six-sigma-projects.html
http://www.my-project-management-expert.com/project-manager-
certification.html
Contingency Approach
http://www.my-project-management-expert.com/contingency-approach.html
http://www.my-project-management-expert.com/project-quality-
management.html
http://www.my-project-management-expert.com/change-request-
management.html
Page 13 of 14
http://www.my-project-management-expert.com/how-to-write-a-project-
charter.html
http://www.my-project-management-expert.com/project-management-
report.html
http://www.my-project-management-expert.com/managing-and-controlling-
scope-creep.html
http://www.my-project-management-expert.com/managing-project-risk.html
http://www.my-project-management-expert.com/estimating-project-costs.html
http://www.my-project-management-expert.com/managing-project-teams-1.html
Page 14 of 14