Introduction
Around this time last year I mentioned to my boss that I was interested in Project Management. I had worked for the company for two years as the principle DBA and felt that project management was the next career step for me.
Well be careful what you wish for!
I thought that I had become suitably world weary and cynical. Not quite up to
Michael Moore standards, but getting there.
I felt ready for the task ahead but my first project in the role of project manager was an eye opener.
I thought I would share with you the main lessons I learnt on my first project.
Lesson One
A customer has certain expectations of their project.
If the project is worth $50,000 then the customer is likely to have $60,000 worth of expectations.
If, through budgeting that $50,000 project gets pruned to,
say, $20,000 then you will find that the customer still has $60,000 worth of
expectations.
A project that has been gutted in this way at the start is
called a Death March. Read "Death
March" by Edward Yourdon for further details.
Your first job will be to enter a bartering process with the
customer to set priorities for the tasks within the project and to work out
what you can deliver for the $20,000. This leads to lesson two.
Lesson Two
Put everything in writing.
Make it clear that actions are only carried out against
written and agreed tasks.
The temptation is to slip things into the project to act as a
sweetener, particularly if you know that you are going to have to give the
customer some bad news. However, if
these sweeteners are not written down then
- You have no written proof demonstrating you flexibility.
- It raises false expectations in the customer and things will get ugly later on when you have to say "no" further down the line.
- You will be penalized for project creep when time taken implementing the sweeteners has detracted from the time spent on the meat of the project.
If you have a concern that needs addressing i.e. the spec of the
server is too low for the task it is expected to do then you need to put this
in writing. This leads to lesson three.
My boss told me that he always volunteers to take the minutes
of any meeting because he always knows that the points that he makes will
be recorded. No-one can
overlook the points that he raised because he always records those items.
Of course someone could suggest that something be struck from
the minutes after the first draft is issued, but it is unlikely to happen
because
- A written reminder tends to prompt peoples memories.
- Anyone who wants something struck off is faced with having to
explain why they want to do so to all attendees of the meeting.
Lesson Three
Keep a project journal.
This will tell you not only when things happened but
give you the chance to keep a narrative of why they happened.
If a customer continually puts off a major decision then it
helps if you document the date/times on which you chased them up for that
decision.
If you raised a concern with an aspect of the project i.e. you
expressed concern that your data warehousing project is going to be run on a
low spec server that is doubling as a web server, then not only the concern,
but the response to this concern needs to be recorded.
This is to help you keep track of your project. It is serendipity that this also acts as
protection in the event of project failure
The journal will also be vital in preparing for a project post
mortem.
Lesson Four
Keep an issues log
We keep a simple Word document with a table that lists
- The issue.
- The date it was raised.
- Who raised it.
- Who is responsible for dealing with it
- The resolution.
- The date it was closed.
This document is a global document that is circulated to all
members of the project team and to the customer. It acts as a forum for all and sundry to raise their concerns.
Lesson Five
Face to face meetings are relationship builders. The rapport that you build with your
customer will help in weathering the ups and downs of the project.
There are things that you can say in a meeting that you would
never put in writing and you would be very wary of saying on the ‘phone. This doesn’t contradict lesson two.
You still write everything down, but you sanitize it for general consumption.
Within the constraints of time and budget you need to meet
with the customer often enough to keep abreast of how the customer perceives
the progress of their project.
You should also aim to have a project post mortem on
completion of a project. This is
usually the time when you ask the customer to sign off the project as being
complete and accepting your final invoice.
Lesson Six
A project post mortem is supposed to be a constructive affair
in which both the positive and negative aspects of the project are examined
from both yours and the customer’s perspectives.
In many ways it is like an annual employee appraisal. It is not an excuse for the
employer/customer to give the employee/project manager what we British call "a
right bollocking".
If it is seen in this light then really the issues at stake should have been raised and dealt with earlier in the project.
There is the danger is that this final stage will degenerate
but frankly there is little to be gained from such an experience.
Lesson Seven
Talk to your project team members.
Have you ever, as a developer, had a conversation with a
project manager and asked them "you promised the customer what"?
If you are asked for a delivery time for a technical aspect of
the project that is outside of your experience then agree to get back to the
customer after consulting your developers.
Don’t improvise unless you absolutely have to, you are asking for egg on your face. This is the 21st
century. You should be able to 'phone someone on your team during a meeting recess.
This is a variation on "be nice to the people on your way up,
you are sure to meet them again on your way down".
Summary
They say that good judgment is the product of experience and
that experience is the product of bad judgment. Well shall we say that I gained a lot of experience on my first
project. I was fortunate that a couple
of my bosses are the sort of project managers that developers volunteer to work
with and they really helped me through it.
I’ve learnt that there is nothing soft about "soft"
skills. Sometimes you have to smile and
shake the customer’s hand when you would sooner break his/her fingers.
Would I do it again? I would have to say yes. With a good team behind you and a fair minded customer it is challenging but fun.
Much as I enjoy the problem solving aspect of DBA'ing my experience is that techy jobs tend not to earn much respect in the boardroom. My observation would be that technicians tend to have tasks thrust upon them where as people managers have at least some flexibility to control their own destiny.
