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

It’s been a long, long time between blogs, and don’t I know it! “We need leads” began the shrill cries, followed by incentives left on desks and then generous rewards for those who managed to find the time to put pen to paper (or fingers to keyboard). Then came the less subtle hints, such as the personal email out-of-office Rob left me one day… ‘Matt - write a blog’. The continued inaction must have rubbed, as things quickly escalated – name and shame emails, office Nerf wars, even a drive to get everyone to sign up for Google+ profiles under the pretence of contributing blog content to feed into the new Wiliam website. In the end it was almost as if the procrastination was purely to find out just how long I could hold out under fire.

But here it is, after nearly 18 months I’ve emerged from behind my dual monitors, refreshed from a holiday break and finally with a bit of time up my sleeve. As I claw my way back into redemption and clear my ‘blog debt’, the reason for my recent lack of contribution has become the source of inspiration for what will now become a multi-part series of articles. And so begins “Lessons learned from managing a 7-figure project – Part 1”.

 

About the project

Unfortunately I can’t tell you who it was for, since the end recipient is one of those large corporations that makes everybody sign NDA’s and thinks that the world will collapse if anything is not passed by their marketing and legal departments first. Having spent 18 months on this beast of an application, it’s a little disheartening that Wiliam still aren’t allowed to publish the details of this amazing project our portfolio, despite the fact that it’s been in the public domain for 3 months now. Suffice to say, we worked for a large financial organisation that has been a loyal client of Wiliam’s for a number of years, who were in turn delivering a complex payment solution for a ‘household name’ brand – which is currently being rolled out directly to more than 5 million consumers across Australia and the world. For the purposes of this blog series, we will henceforth refer to it as “Project K”.

 

It was by far the single largest project ever undertaken by Wiliam, and certainly the biggest single job I’ve ever had the pleasure to project manage. Two out of every three Wiliam employees were involved at some stage; at the climax we had nearly the entire development team working full-time. As a producer / project manager, it’s the kind of project that you dream of for your CV. In fact, if you can pull it off, you can basically throw away your resume as you won’t need it anymore. The experience and knowledge gained is incredible, as you push yourself harder than you’ve ever had to before. That’s not to say you don’t make mistakes – and having learned a few lessons, I’d like to share some of my insights here.

 

Know your limits

When you take on a project of disproportionally large size – larger than anything you’ve ever done before – chances are you’re going to need help. One thing I should have done much earlier in the piece was to put my foot down and demand some assistance on the project management front. This project didn’t land on my doorstep as the monster it became, it gradually grew into one. Your average producer at Wiliam can handle dozens of clients and, if they are organised, a good half dozen active projects at once.

As soon as I realised that the budget for Project K alone was exceeding the total combined budget of my existing client portfolio, I should have raised my hand and unloaded a few clients. Instead I worked harder and longer and as Project K chewed more of my time, the great service that I was providing to some of my favourite clients was slipping to only good service, and then to average. It wasn’t until I started actually under-delivering that we began to make the right moves to offload some clients, and as much as I loved working with all of my clients (we really, really do at Wiliam) it was unfortunate that we didn’t recognise this earlier. We may not have dropped the ball on a few occasions and saved face. Better to acknowledge that you’re too busy to serve everybody, than to keep promising things you can’t deliver. There is only so much time in a day for you to spread the love around.

I have now been reduced from eight active clients to having just one, who I basically work full-time for. Wiliam (now) also has a policy that when a project has four or more developers, we automatically make moves to assign additional project management resources. And it should be pretty obvious to anybody who is regularly working 16-17 hour days, that they’ve got too much on their plate. It’s amazing how many people will just put up with this however, and not delegate as much work as possible.

A key lesson learned is that when you have a budget exceeding seven figures (a million dollars) you cannot micro-manage the whole thing. You might be able to get away with that on a smaller project. As somebody who has a mild case of OCD and likes to have the time to give attention to detail, this is a very hard truth to come to terms with, but it’s the only way to survive and turn the project into a success.

 

Know Who’s in Charge

We had the pleasure of working with a huge organisation and some lovely people. But as Project K grew and grew in size, when the final requirements document was finalised, we realised just how many facets there were to the project and organisation. We went from having a cosy, friendly working relationship with a core group of people in the North Sydney office, to quickly meeting numerous new faces who surfaced from numerous departments, most that we didn’t even know existed previously. We were being bombarded out of the blue by emails from executives and employees all over the globe (including the head offices in the UK and US), and given very little context as to who these people were and where they sat in the pecking order.

Added to this were the employees not of the financial organisation, but their client who we were delivering the solution for, and they were just as big again. So we did what we had to do and compiled a hierarchy diagram of everybody we were introduced to, discovering their full names, locations, contact details and job roles. It’s something that I’d never had the need to do on smaller jobs previously, as you could often fit the web project delivery team in one decent sized board room. Not in this case – you would have needed an auditorium!

In an organisation of 1000’s of employees, with staff scattered in offices around the globe, you quickly discover that one person doesn’t have the same priorities as another. We had five major components of the overall project being delivered simultaneously, and each project manager was quite blunt when it came to prioritisation. You didn’t need a crystal ball to know that each person was absolutely only concerned with the delivery of their own small part of the bigger picture. At a time where we were still negotiating additional resources to meet the workload, prioritisation often came to a head and we had numerous meetings where we had to inform people that their deliverables were being delayed so we could focus attention on something more pressing. Especially when one of the five PM’s on the client’s side quit suddenly, and some senior executives started pulling the strings, we needed to know who was in charge of setting priorities. So we went as high as we knew we could go up the hierarchy, explained the situation and once it was clear that we had some communication and prioritisation issues, both sides worked on improving the relationship and we were forever more comfortable in making decisions on priorities and all of a sudden it wasn’t so scary having to head into a meeting and read the riot act. We knew the client’s IT Director had our back and could put out any spot fires internally.

The key lesson here is that you need to know who’s the boss. When you’re a lone PM on the agency side, in constant communication with five PM’s on the client side who all couldn’t give a rat’s about anybody else’s deadlines… go one level higher and have a candid conversation which will result in a solution. Nothing will make you look more incompetent than continuously failing to meet deliverables because you keep letting people shuffle your priorities for you. It’s hard not to pander to every email request, but knowing when to put your foot down and keeping your eye on the prize is crucial. Especially if you want to keep your developers sane, as nothing will piss them off more than constantly changing priorities.

 

Next time…

Plenty more insights to come but that’s enough for today. Part 2 will cover off my thoughts on teamwork, the changing nature of the IT industry and the importance of keeping a cool head.

Stay tuned!