Mongo Monday is back! Business Reporter’s resident U.S. blogger Keil Hubert illustrates what happens when you try to manage projects for a deaf and destructive tornado in human form.
Back in June, I introduced a fellow called Mongo that I’d named the terrifying colossus from Mel Brooks’ movie Blazing Saddles. Mongo has been a fun character to write about, since he inspired an amazing amount of fear in his employees, all while inspiring an equally amazing rationalization effort from his fiercely-loyal apologists. Like the character in Brooks’ parody of classic Westerns, the real Mongo was a character of more depth than his normal demeanor would lead you to suspect. Like a Chieftain tank, he had an unfortunate tendency to trample people underfoot without noticing their objections. And finally, like a costumed supervillain, his business decisions seemed more capricious and arbitrary than considered and measured.
When I started working in Mongo’s outfit, my boss briefed me that my primary purpose was to help him bring order and focus to the department. The organisation had grown organically over the years under the short-lived banners of several different cloud service providers. The remaining tech support team members were immensely talented and dedicated. They were also cowboys: they attacked every new problem with gusto, but without any sort of consistent methodology. The organisation had processes, policies and other written doctrine, but they didn’t actually use any of it. Their doctrine only existed to satisfy outside auditors. Everything was done seat-of-the-pants, with no thought given to long-term consequences.
I validated this early on when I was invited to a discussion with the security department about a new draft edition of a security incident response process guide. I’d spent years working information security with the military and had stood up our service’s first digital evidence response team, so I spoke the security guys’ language. The draft guide had been written for and by the security guys without regard to how our guys in the support department did business. I was able to convince the key stakeholders that the guide needed to be re-written to de-conflict some critical reserved terms so that our two departments could interoperate smoothly. It worked. We created a solid, sustainable guide that both groups could work from without all of the confusion and drama that had been associated with the previous edition. Everyone involved considered it a ‘win’.
This early experience fit my understanding of my job. My title was simply ‘senior consultant’. I had no formal job description. According to my boss, I was hired specifically to advise the leadership team on how to get organized. I was expected to build them tools to regulate work, to help management gain oversight, to help them establish priorities, to revise all of their doctrine and to support continuous process improvement. I liked the idea; the work was right up my alley.
At first, I thought of my role on the team as being something like Errol Flynn’s role in the classic Western movie Dodge City. Flynn played a cowboy who reluctantly agreed to become the sheriff of a lawless, anarchic cattle town in the Wild West in order to bring order and justice to a chaotic and deadly society. In business as it is in cinema, a champion of positive change is a classic hero. Not that I thought of myself as a gunfighter. Rather, I hoped that I could bring some structure, perspective and consistency into a setting that seemed to really need it. That was the idea, anyway.
My early victory with the security regulation re-write effort gave me a false impression of the organisation’s willingness to embrace change. Not long after, I was told that I was going to become the project manager over a huge initiative. I was expected to get a new overseas tech centre stood up and to integrate it with our other international operations. During my orientation brief, I learned from Mongo himself that most of the key milestones had already been set in stone and that he’d briefed the timeline to the executives… before the project had actually been planned.
I took the notes that I’d taken on Mongo’s expectations and tried to sketch what needed to happen in order to meet his deadlines. I built a basic Gantt chart to try and see where the crucial obstacles were likely to be. I quickly realized that we were screwed from the get-go. We were expected to bring up a complete IT plant (cabling, PCs, phones, transatlantic connectivity, etc.) in a country that our division had never done business in before. We had no historical data for how long it would take to clear the logistics requirements, let alone what weird bureaucratic obstacles lay in our path.
I briefed Mongo and his senior directors on my analysis and showed them the crude work breakdown structure that I’d created. I explained that we were in danger of failing to meet his target for initial operational capability (IOC) if we didn’t get all of the key support departments aligned under one central authority who had the power to settle arguments and set priorities. I also told Mongo that we needed the project manager to be stationed on the ground at the project site so that management had eyes-on for all of the construction and systems integration work. Three things came out of that meeting that made me realize that the initiative was doomed:
First, Mongo snarled that he was absolutely not going to give me any authority over his managers – let alone over the external service providers that we were absolutely dependent on. If we needed to influence a sister division to make something happen, then he would handle it. Mongo’s promise was ludicrous, since the first executive who had joint authority over all of the players (e.g. long-haul circuits, procurement, security standards, country clearance, et al) was the CEO himself.
Second, Mongo refused to put a manager on the ground to oversee the effort. He announced that he would fly over periodically to inspect, and that some of his favourite subordinates would get to visit, but that none of the project management team would be alowed to go. Not even an orientation visit to learn the lay of the land. Us little people had to handle everything remotely.
Finally, Mongo looked at my Gantt chart and demanded to know why ‘all the dates were wrong’. I explained that he’d only given us hard dates for the milestones (e.g. terminate all of the US East Cost employees on Day 30) whereas all of the inferred supporting tasks (e.g. get HR to finalize severance packages for the East Coast employees five business days prior to the termination announcement) had to be guessed at since we had no performance targets to work with. I asked Mongo to either give me actual, meaningful dates and effort ranges for key events, or else to put me in contact with someone who could. He refused to do either, leaving me stuck with my WAGs. [1]
I left the presentation feeling grim. I had no authority over any of the players, no leverage over the critical suppliers, and no actionable data to plan with. Even though I had far more of a ‘plan’ taped to my cubicle wall than Mongo had had when he promised upper management that he could pull off the operation, my plan was – at best – a weather forecast. I felt like Errol Flynn getting the Sherriff’s job in Dodge City, only to be told that he couldn’t wear a badge, carry a gun or arrest anyone. I had all of the responsibility with none of the commensurate authority. Things couldn’t possibly end well.
As you might expect from a Mongo story, things quickly got worse. A week after I presented my proposed plan to the senior staff, Mongo told me to send him a copy to present to his boss. I sent it to him… and immediately got a complaint back that it wasn’t complete. It only covered three months’ worth of effort. I agreed; when Mongo had pressed me into service as his project coordinator [2] I’d had to mock up the Gantt chart in Excel since my company PC didn’t include a licence for Microsoft Project. Given the inherent limitations of using a spreadsheet as a calendar tool, and given the god-awful 1366 by 768 resolution on my bargain-basement company laptop, it had been a heroic effort just to get three months’ worth of data charted. Mongo grudgingly allowed me to get a Project license from IT in order to ‘finish’ my planning.
I saluted and drove on. By the end of the week, I’d transferred all of my initial data into a real project plan and tried to sketch out how long it would take to hit all of Mongo’s milestones from activation to IOC to full operational capability (FOC). Based on the hiring rates alone, I projected that it would take until nearly November to declare the mission complete. I knew that Mongo wanted FOC no later than June… but there was just no way that HR could meet his targets unless a miracle occurred. Even then, Mongo’s targets assumed that all of the difficult engineering work would get done on time and within budget. The odds of success? Pretty close to zero. Either the plan had to change, or our approach to the project had to. I advised him to pick one.
Two weeks later, I got a snippy message from Mongo demanding that I re-send him the project plan. He said that he couldn’t open it. I did as I was told, and reminded Mongo that there wasn’t a native version of Project for his Mac; he’d either need to install Project on his Windows Virtual Machine (which I knew he had installed; I’d seen him use it) or else use the browser-delivered version of Project from Microsoft’s Office 365 service. Or just use a Windows box. We had lots.
A week later, I got the exact same complaint from one of Mongo’s directors. This guy, too, had gotten special permission from IT to use a Mac instead of a fleet-standard PC as his only computer and couldn’t open the plan. I gave the director the same recommendations that I’d given to Mongo, all the while wondering why I was having to explain elementary PC use to a bloody director in a cloud services company.
A week after that, Mongo demanded that I send him the project plan in the form of a document instead of a data file. I did what I could; ‘printing’ a Gantt chart in PDF form resulted in a 36-page report that had to be pieced together like a jigsaw puzzle. The output was effectively useless.
A week after that, Mongo sent me a blistering directive to stop using Microsoft Project and go back to using my original Excel spreadsheet version. ‘It’s just too hard for everyone to read,’ he said. ‘Everyone needs to be able to review the plan so that they can supervise you.’ I was aghast, but saluted and drove on. I rebuilt the entire plan in Excel – now six times larger than it had been in the initial build – and printed it out on the office printer. It took nearly an hour to make a ‘poster’ version out of taped-together sheets of US letter-sized paper. I hung the output in my cubicle and waited to get ‘supervised’.
Nothing ever came of it. I spent 40 straight weeks ‘coordinating’ the operation. I led a meeting every Monday and filed meeting minutes with all of the stakeholders. I participated in a minimum of three international conference calls per week. I filed two different end-of-week reports, one with Mongo and one through Mongo with his executives. I filed ‘special alerts’ every time a major change occurred that couldn’t wait for the next meeting.
As for the giant Gantt Chart of Doom… the original bodged-together version stayed taped up in my cubicle for the rest of the year. No one every came by to look at it. No one ever asked about it. I kept the electronic version updated for my own purposes, but never filed it with Mongo or his directors again for the life of the project. No one cared.
In the end, the project went about as well as you could expect for an endeavour that had been launched without any prior planning. We only declared IOC milestone thanks to a technicality; we didn’t actually achieve IOC until two months after we were required to hit it. We didn’t reach a sustainable state with the new tech centre until nearly six months after our FOC target date. Did the work get done? Sure it did… kind of. Personally, I allocated 50 per cent of all my work hours for a year to the effort and achieved a number of next-to-impossible victories in the struggle to get outside agencies to cooperate. Mongo’s thanks came in the form of a layoff notice at the end of the year. He didn’t even have the decency to tell me to my face.
In the end, my grand adventure in Mongo’s Wild West division wasn’t anything like it was supposed to be. To be fair, I did introduce structure, direction and order to the operation, but none of what I introduced ‘stuck’. I never had any authority to compel or to sustain meaningful change. The people that I struggled to influence claimed to be on board with my proposals when I briefed them, but wouldn’t implement any of them after our meetings broke up. My experience was less ‘Errol Flynn’ and more ‘Amelia Earhart’… an enthusiastic launch without a happy landing. Over and over.
The thing is, it could have been completely different. We could have implemented systemic reforms. We could have pulled off the grand European tech centre project. We could have added structure and clarity that paid off in more effective service delivery. We could have done a lot, had Mongo only delegated some authority, enforced some performance standards, and trusted his experts. Instead, Mongo chose to run his operation like a cartoon supervillain: he scared the hell out of his employees, made random change of direction, contradicted himself constantly and didn’t listen to anyone else, ever. Not so much Dodge City, then, as Mogadishu. No room for heroes or reformers; just a few shell-shocked survivors and a ton of collateral damage.
Not what I’d signed on for by any stretch.
[1] WAG, in military parlance, stands for ‘Wild-Arsed Guess’.
[2] That’s ‘coordinator’, not ‘manager.’ Project managers have to have some power over the operation in order to be effective. All Mongo wanted was an observer and administrator.
Title Allusion: Michael Curtiz, Dodge City (1939 Film)
POC is Keil Hubert, keil.hubert@gmail.com
Follow him on Twitter at @keilhubert.
You can buy his books on IT leadership, IT interviewing, and Horrible Bosses at the Amazon Kindle Store.
Keil Hubert is a retired U.S. Air Force ‘Cyberspace Operations’ officer, with over ten years of military command experience. He currently consults on business, security and technology issues in Texas. He’s built dot-com start-ups for KPMG Consulting, created an in-house consulting practice for Yahoo!, and helped to launch four small businesses (including his own).
Keil’s experience creating and leading IT teams in the defense, healthcare, media, government and non-profit sectors has afforded him an eclectic perspective on the integration of business needs, technical services and creative employee development… This serves him well as Business Technology’s resident U.S. blogger.
