SQLServerCentral Article

Lessons from my first Project as a Project Manager



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


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


  • 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


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


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".


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.


You rated this post out of 5. Change rating




You rated this post out of 5. Change rating