SQL Clone
SQLServerCentral is supported by Redgate
Log in  ::  Register  ::  Not logged in

Lessons from my first Project as a Project Manager

By David Poole,


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


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.

Total article views: 5746 | Views in the last 30 days: 1
Related Articles


PROJECT LIFE LESSONS - # Not The GDPR News Mark Williams and myself will delivering a seminar cal...


Managing Report Project Deployments & Version Control

What lessons have we learned about managing report projects and what are the best practices? Sin...


Failure Lessons

Steve Jones would like to see more disclosure about what works and doesn't work when deploying new s...


Project Management Management

The state of project management for technology projects doesn't seem to be keeping up with technolog...


Lessons from my first Project as a Project Manager

Comments posted to this topic are about the content posted at http://www.sqlservercentral.com/column...