Nailing a cloud project without killing Bob boils down to not being a tool

Management, devs, ops, Bob too... just be freakin' reasonable

Got Tips? 16 Reg comments

Don't be like Bob. You remember Bob, right? Tasked with building the company's cloud. Sinking in a quicksand of managerial buzzword bingo and ever-changing requirements, burdened by a lack of resources. Bob was under pressure, which produced tension at home, and Bob quit the job resulting in the company's cloud project floundering.

Let's cut to the point. Every job has stressful parts and stress is a useful thing in small doses, but in larger amounts, stress can be deadly. Learn from Bob.

How do you avoid getting into a Bob-style situation?

Key to the cloud project is realism. Everyone wants an all-singing, all-dancing orchestrated cloud or equally ill-defined project but you need to be realistic in both goal and getting there.

The company (management, Bob and his manager, and everyone else's manager) need to agree on what is reasonable and what is achievable. Achievable and realistic are not the same. Targets and objectives need to be very well specified, measurable (are we delivering what we promised we would?) and come with proper deadlines.

The best approach for a project of size is little and often. In other words, setting realistic targets around what can reasonably be achieved. This is, to my mind, one of the areas that upper management seem to not understand. Small and frequent helps keep a project on track. It also comes with a level of satisfaction for those at the virtual coalface as and when parts are completed.

Bob had none of these good feelings. Bob's world was a changing mass of requirements that were large, unfiltered and changes in design where made ad-hoc. Given enough time it could drive anyone crazy. Just keep it little and often. It works well for developers, right? We call it agile. Why would it not work for the ops guys? After all, infrastructure as code is the latest buzzword.

Stick to the plan!

Once you have this, you must set everything down with a plan that is documented.

I know, I know. A lot of Bobs suck at documentation. As one developer once told me: documentation is like cod liver oil... tastes like crap but is good for you.

Use the document to set specific delivery items and when they are expected, and all parties need to agree to it otherwise it is pointless.

Some will, at this point, lock out any changes to the plan – introducing in essence a change freeze on the deliverables. Doing this helps prevent feature creep or changes that can seriously drag the project into the weeds, and produce headline-grabbing project and cost overruns.

But, as German military strategist Helmuth von Moltke noted, no plan survives contact with the enemy, and so it is in technology projects. Changes are needed as plans hit reality and unforeseen circumstances. This is where having a well-documented plan has another upside: it helps to cement agreed changes. You can see what must be updated, compare it to the original, recalibrate dates, resources and other factors accordingly, and get general buy-in.

Those items, once agreed on, must be babysat. This is where you need one of those project management people. The title is a giveaway. These are the people who pull together all the bits and manage all the moving parts efficiently, managing both upwards and downwards. A skilled project manager can is difference between success and failure.

A good project manager will also handle several important items essential to a less stressful project: project plans, charters, risk analysis and so on.

It's good to talk

OK, you've got the people and project specifics but it'll be for naught if you don't have good communication.

Part of the issue with Bob's scenario was that communication was always an afterthought and something to be shied away from. Good communication is vital to the health of a project. It can include statuses, project milestones, steps to be implemented, by whom, for when, meeting minutes. In other words keeping everyone informed and on their toes.

With good communications come adequate resource. On the latter, I'm looking at you, management, but the former also applies to Bob.

No project is perfect from start to finish but us techies tend to be poor at communication. My advice is if something is causing slowdowns or issues, don't sit on it. Make that project manager work for their grotesquely huge salary and flag up problems as they arise, not later at the weekly meeting.

Now, managers: resources. One of Bob's main stresses was that no matter how useful he was, there was just one of him. This was bad for a number of reasons. Being largely on his own meant Bob was a single point of failure and this meant that if something happened to Bob, then the project would stall.

On a more fundamental level relying on a single person meant they were overloaded, hence burn out, while the project suffered from a lack of skills and knowledge.

What this means in real terms is that your implementation team needs to not just be suitably staffed but that the team members are also trained in the technologies they are expected to use and implement. Doing this early on means responsibility for the deliverables doesn't fall to one individual and that there's a better chance of delivering a suitably polished cloud.

Third parties can help

Some companies prefer to get around this using third parties to do the heavy lifting. That is fine but there needs to be skills transfer and a ramp up period of learning of those in house.

Before entering into any project with a third party, ensure it includes knowledge transfer and documentation.

Getting the experts in will not be cheap but it provides the blocks on which to build. Doing this will also (hopefully) help the company realise what can be achieved with the resources at hand. All too often companies jump on the wagon without realising that no matter how hard they shout, it ain't gonna be done any quicker due to either time or money.

Experts in human performance reckon the human being is best running at no more than a 45-hour working week. After that, performance starts to drop at an alarming rate. We don't want that. Management doesn't want that. Bob doesn't want that. That's why while some of what I've just said might sound like something for the suits, I'm talking to you, Bob.

So my final advice to you, Bob, is be true to yourself. Managers might think they know everything, but they don't. It isn't always immediately obvious when you need help. It's up to you to notify the powers that be when you need help. Asking for help shouldn't be seen as a bad thing. On the contrary it is you being responsible to the people involved in the project.

That project manager would much prefer a controlled holiday rather than a Bob who is off sick with stress thanks to the overwork of a badly running project. ®

Go on, Bob. Be awesome to yourself. ®

Sponsored: Webcast: Simplify data protection on AWS


Biting the hand that feeds IT © 1998–2020