Making things work - Part the third - The Project Manager Is Your Friend

A good project manager is a jewel beyond price. I've worked on projects where, without the effort and expertise of the project manager, we would never have closed the job. Unfortunately a bad project manager can make the simple jobs next to impossible, and drive the engineers to distraction.

Good project managers keep management off your back, control scope creep, track open issues, sort out the logistics of equipment supply and delivery, handle the resourcing problems (when you absolutely have to have the company expert in "whatever" for 4 straight days if you are to complete the project, and he's already booked to another job), worry about time cards and P&L and other financial matters and prevent you from going crazy by helping you prioritise problems in a sensible way.

Bad project managers agree to everything the customer asks for, regardless of scope, have no idea how to keep an issues log, leave you to sort out your own logistics and resourcing and generally cause more problems than they solve. The character who insists that a team, all of whom are working in the same small room, have several "catch up meetings" every day, with him and the customer's project manager, and then wonder's why work is proceeding slowly. The guy who demands rapid reconfiguration of production equipment in the customer's data centre, to suit his project, but in violation of the customer's change control procedures. The genius whose project schedule doesn't include any time for testing. You do get them.

If you've got a good project manager, cherish them. If you have a inferior model, be prepared to do part of their work yourself, because it has to be done, like it or not. If your project manager is just a bit inexperienced, you can help them be better by explaining what you need from them and why. And consider the fact that a project manager who has only ever worked on software development projects will need your help to get their head around a project that includes a lot of hardware.

Of course, there's always the possibility that you are a relatively inexperienced engineer. Perhaps you've never worked on a big project, or with a project manager before. There was a first time for all of us. So let's step through some basics here:

Scope creep

Every project, large or small, is supposed to have a fixed scope. The scope is the body of work that is to be performed, for example "install Linux on four servers". The customer agrees to pay for that work. There is a contract (or work order, or whatever the local lingo requires). The customer pays $N and the engineers do Y tasks. But if the customer then produces a fifth machine, and asks to have that installed as well, that would be an increase in scope. That's a fairly obvious case, but the thing is that if you are already installing four machines (and you're probably doing them in parallel), doing a fifth doesn't look like much extra work. There's a tendency to agree to it.

Scope creep becomes much more hazardous in a complex environment. Adding one extra web server or proxy server to a load balanced multi-tier network can involve reconfiguring firewalls and load balancing switches, and testing all the changes. That one extra machine can cause hours of extra work, and if it triggers a problem (as under-analysed changes to designs so often do), the whole project may grind to a halt until a fix is found. My basic rule is that I, as the lead engineer, never under any circumstances agree to anything that causes scope creep. All such matters must be referred to the project manager. A good project manager will then say "what could go wrong if we do this?" and "how long will it take?", and make a decision about what to do next. Really little things should be agreed to, but they still need to be documented and tracked in the project documentation. Larger things may require a variation to the scope of work, and an additional charge. And as soon as you talk about extra money, someone on the customer's side will have to approve the additional cost. Sometimes this will cause the proposed change to be halted, because no one is prepared to pay for it.

Be very wary of requests for additional work coming from the customer's operations and support staff: the chances are very high that they do not have the authority to incur additional costs, and they probably don't have the right to vary an agreed scope of work. Sorting this stuff out is the project manager's responsibility, and an too-helpful engineer on the team can make the project manager's life difficult. If you stop what you are doing for an hour to help Larry-the-customer's-engineer get something working, and as a consequence then run late to finish your appointed task, the project manager will be better able to handle complaints about the job running late if he/she can say "as agreed, we stopped for an hour to help your staff fix a problem".

Consider also the financial terms of your project. If it is a fixed price job, and you accept additional tasks into the scope at no charge, you are working for free. If, on the other hand, you are on time-and-materials, and you perform extra work and charge for the time, you will increase the size of the customer's final bill. The first case shouldn't make you happy, and the second case may make them very unhappy, particularly if they are on a tight budget. Spurn scope creep: you are not here to make everything perfect in the customer's environment, you are here to deliver a project. Focus.

Issue logs and customer communications

The issues log should be kept by the project manager. They may call it something else, but its purpose is to record problems, issues and questions, and what was done about them. So when an issue develops, say "not enough power in the data centre to power up the machines", the project manager logs an issue: "Issue 1, 6 additionals 32 AMP power connections needed in the data centre", and the task of resolving the issue is assigned to someone. Then every time someone in management asks why the project has stalled, the project manager can say "we have a open issue that is preventing us moving forward, and it's been assigned to Joe Blogs". This will normally deflect the wrath of management onto Joe Blogs, who in this case will probably be the customer's data centre manager, and capable of taking care of himself (I've never met a female data centre manager).

The issues log also becomes a repository of the project's history. It can be a big help when, six months in, no one can remember why a certain thing was done in a certain way (Why did we set all those subnet masks to 27 bits?). The issue log may remind you of an old, forgotten problem, and what you did to get around it.

It is also vital that all email relating to the project is stored. Hard copy communication normally gets stored by default, but email can get overlooked. You MUST keep it: everything you send to the customer, and everything you get back. Like the issue log, it can remind you of how you got to a particular place. It can also be very useful when disputes arise. So:

Many moons ago, the marketing department of a certain telco decided that they would offer their customer's an application hosting service (this happened long enough ago that application hosting was something of a novelty). Accordingly, their staff did a design, and handed it to my business development manager so that we could price the work. We looked at it, and pointed out that the design called for a separate firewall, router and switch for each new customer, and that, given the equipment specified, they would only be able to fit two customer deployments per rack. In case you are not familiar with the economics of data centres, rack space is expensive, and you try to minimise the number of racks used. So we wrote the customer's representative an email, pointing out that the proposed solution would rapidly become extremely onerous to manage, and that the whole things could be done more cheaply by virtualising the network components. We were trying to help.

What we got back was a curt note stating that the design had been done by "our expert staff" and requesting that we mind our own business and get on with pricing and installing the first set of equipment. The initial deployment was enough for two customers, one rack of kit.

And the BDM said "what do we do now?" and I said "File that email for future reference, and we'll get on with the job", which we did. Job complete, signed off and accounts paid.

Weeks passed, and one day the BDM got a very grumpy email from someone in authority on the customer's side. We had installed a very bad design, they were going to have to buy a new firewall, router and switch for every new customer, the system would soon be unmanageable. What did we proposed to do about it?

In response we sent back a copy of our email, pointing out the deficiencies of the design, and of their response to same. Silence fell. I believe their may have been some blood letting on their side.

Save all correspondence. I used to have a project manager who would print all relevant emails to PDF, and publish them to a web page which belonged to the project. That worked well. If you get a project email that the project manager is not copied on, forward to them. But make sure they are storing the emails somewhere, for later.