Using the “Jack” Approach

**Featured in LinkedIn’s “Project Zone” discussions: here

I have, pretty much since series1, being a 24 fan and have been known to ask myself in time of desperation: “What would Jack do?” Alas, the answer would – had I gone with the suggested action – resulted in me being arrested for numerous crimes.

 Jack: Armed for Risk Assessment 

However, there remain certain traits of “Jack Bauer” that can – and should – be considered in managing projects. Now, I say all of this a little “tongue in cheek”, but am somewhat serious as well. Allow me to explain.

… previously on (Project) 24, …

At any given point; with the possible exception of the immediate beginning of the project (“day” in Jack’s case!) there should be an obvious sense of urgency across the project organisation; “CTU” if you like.

The immediate needs are defined by those in the field (project team) and fed back to where they can efficiently be resourced, analysed and fulfilled (the PMO). Those in the field manage the relationship with those that are ultimately paying (with money in the case of customers for those on projects; and with their life for fugitives on the “run”) and filter through the volume of information that comes in; directing the useful information again to those that can efficiently process.

Talking of efficiently, when it came to “meetings”; these would be replaced with “interrogations” where as to derive any and all missing information that was required for an effective delivery. Can you imagine the quality of any “discovery” information that would come in if there were knee caps at risk? There would be little need for minutes as most points needing action would be more than clear. No need to note Actions; these would be hammered home at gunpoint!

In the event that good quality discovery information could not be obtained and while knee-cap bits are being mopped form the walls; a “Plan B” would kick in. In executing (emphasis on the “executing”) Plan B; we would move straight to implementation given that it’s better to do it than to talk about it – this saves time, money and effort.

A field unit would be mobilised for an en-mass hit. Taking up position on customers sites, where a military operation would disseminate user communications via tannoy, not via email that some would inevitably “not get”. “Logoff and step away from the computer immediately”; would reverberate around the immediate vicinity. Laptop and desktop would be replaced, cabled, powered and anyone caught moaning would be subject to Sensory Deprivation for 30 mins; just after a quick dose of Sodium Thiopental (truth serum) to derive any and all passwords, mobile device inventory and “essential file” locations.

Each desktop change would be exactly 7 mins; before the field unit would fall back in formation, removing old kit for secure disposal. Any VIPs that were knocked out to prevent “stress” would be woken with smelling salts by their PAs and handed a new Blackberry.

This Project Approach would negate the need for extended user communication; reminders and “I am sorry, I have a yoga class Friday, can we do it next month?”, and save 2/3rds of implementation costs. Those, that in the space of 11.5 minutes since Tech Refresh” that have forgotten their passwords would be subject to a lobotomy and sent to make small toy cars in a remote island; due to being useless.

Given the lack of need for a delayed project start, a militarised planning phase, a condensed execution (& literal execution is extreme cases); and little need for VIP “hyper-care”, cost savings would be extensive. Run costs would be reduced as the useless people would have been disposed of. Remaining headcount would exude increased motivation due to the presence of an armed post-migration floor walker (SAS Nutter with anger problems). Productivity would be up.

Additional costs would be saved during implementation as the Military Field Unit used recruits in training with the only live ammo being held by the Senior Field Engineer to which Escalations (stupid people!) would be (fed) handed.

Jack would prepare highlight reporting at the end of each implementation stage / gate (operation) outlining Build & Run metrics, any exceptions and the % of service improvements made (stupid people “reassigned”)

Lesson Learned would be short. Very short.