Lessons from managing a $7-figure project – Part 2

If you haven’t already seen it, in Part 1 of this blog series I covered off my initial thoughts on ‘Project K’ and blogged about knowing your limits, prioritisation and the importance of knowing who’s the chief Indian (on the client side that is).

All project managers will inevitably come up against what I have affectionately termed ‘the bulldozer’. It’s a situation where no matter how hard you try, it seems you can’t make somebody see common sense and/or to take the correct course of action. At one point, Project K seemed to be one gigantic bulldozer. Alright, maybe that’s a stretch of the truth but sometimes it can feel that way, and quite often it’s probably only down to a key individual. We had one in particular on this project – a middle-manager on the ‘client’s client side’ – who liked to think they were an expert at everything and always had to have the last say.

Suffice to say, when this individual starts questioning every move you (and your team) makes at every stage of the project, it doesn’t go down well. Before you know it, one of two things happen. You either roll with the punches, give in to the all-seeing, all-knowing client and lose control of the project (pity the fool and what becomes of the project) or, you can…

 

Hold your ground

Isn’t there a reason why your company won the tender? Didn’t you survive the dot-com crash of 2001 (when many businesses your size didn’t) and are you not surrounded awesome people who are very specialised and talented in their field? You’ve designed and built websites like this previously, and you know that web design is not art, it’s science. There is no mystery in what you build – chances are you actually know what you’re on about!

Nobody is an expert in everything. When a non-web professional (or even worse, an IT industry jack-of-all-trades!) starts questioning the Information Architect about why they built the navigation a certain way… has strong opinions with the Senior Designer about the colour they chose for a button… or grills the Lead Developer over a particular technology… as Producer / Project Manager, you need to stand tall and back up your resources.

Your colleagues are EXPERTS in their field, as you are in yours. With confidence you should not be afraid to assert your authority in these situations. Listen to the client when they are talking about something that they are an expert of, but chances are if they knew how to build a successful website, they wouldn’t be coming to you to build it for them. The client doesn’t always know best, and even if you have no hard evidence to back up your decisions, the fact that you are an expert in your field should render even your instincts and opinions valid.

 

Measure twice, cut once

Scope it right the first time. It’s so important. Change is cheaper at the beginning of the project and you need to make sure your client is aware of this. One analogy I’ve used to get the message across relates to the blueprints for constructing a house. Once you’ve signed off on the plans and the builder has quoted on the job, you can’t just turn around and make changes without expecting to incur costs/delays to the project. “What’s that? You want to move the power-point from here to there? That’ll be an extra $500…”

Development as a general rule should be about 60% of the whole project, and that leaves a good chunk of time dedicated to discovery, requirements definition and graphic design. Bringing  a developer into the mix early on is a great idea if you want to head off problems at the backend of the project, as they can collaborate with the designers so that everybody is on the same page.

If the scope does change (the client will inevitably attempt this at some stage, unintentionally or otherwise) make sure every change is documented with a change request (CR) and that you keep on top of additional billing. It’s NEVER fun having to trawl through months of emails as you attempt to justify the chunky variance invoice you threw together at the end of the project, which the client is now pushing back on!

 

Reward thyself, and those around you

Good or bad, every team leader has a different style of leadership. Personally I tend to maintain a low-touch, self-managed approach, shrouded with a general sense of ‘we’re all suffering through this together’. Nobody likes to be micro-managed and everybody has their eyes on the prize.

What to do when the client throws you the odd curve ball? Or when you receive the dreaded 4pm email or phone call about the issue that is so important, it just can’t wait until tomorrow. Everybody is already putting in some seriously long hours, everybody is dangerously close to burning out.

I’ve always found incentives work wonders. One day in particular I was close to losing it (a rare occasion) over a JIRA ticket that had been sitting in the ‘too hard basket’ for weeks, and nobody wanted to touch it. It’s amazing what a $250 bottle of Dom Perignon will do… Instead of blowing up, I emailed around, offering the incentive to the first developer who could solve the problem. They had less than 24 hours to do it or the prize was forfeit. When the problems was solved, the cost of the bubbly was tiny compared to what it would have cost us in dev hours with further procrastination on the issue.

I also think it’s good to let people know when there are clear opportunities to earn overtime. Not every developer wants to be working late or on weekends, but then, not every client is going to tell you ‘cost is no barrier’ either. A lot of dedicated employees will work back to get the job done as required, but they’ll put in some super hard yards when they know it’s not in vain and the bank balance reflects that.

Don’t forget to reward yourself. It can be as simple as making sure you get out in the sunshine during the day. If you’re really needing to stay back doing 16-17 hours in a day, nobody is going to begrudge you if you take an hour out for lunch and go for a swim or a run (if that’s your thing).

 

Test, test, test! There will ALWAYS be bugs

When you create an idiot proof system, the world creates a better idiot. You will NEVER have a 100% fool proof, bug proof system. All you can do is aim to please most of the people most of the time. In saying that you need to test thoroughly and when you think you’ve exhausted all options, get somebody else to test it for you.

After all, why be in a hurry to look like an idiot? No better advice was given to me by a former boss. Incidentally he turned out to be an a**hole, but I’ll always remember the day he told me this, and I was certainly reminded of it during Project K – multiplied!

Deployed locally? Test it. Deployed to staging? Test it before telling the client it works. Deployed to Production? Test it before the general public stumbles through and realises it doesn’t work. You WILL save time in the long run by testing upfront, though I acknowledge it’s extremely hard to stay on top of and it always takes longer than people seem to allow when they estimate project costs.

I’ll cover my final thoughts on Project K during part three of this blog.

Meanwhile, I’ll leave you with this awesome Spinal Tap clip, which was circulated by one of our developers in response to the client raising countless support tickets in JIRA – at a consistently top priority level of 10/10. “If only JIRA could go to 11”…