Uncategorized

Thieves of Time: Part 1

Robin Newborg, Sr. Transformation Consultant

 

Thieves of Time: Part 1 of your long answer to the 1-second question, “Have a sec?”

Most IT leaders are very familiar with the Thieves of Time, enemies of the project schedule. They’re the co-worker who stops by to ask about a failing hard drive in the storage array, or the manager, who promised the VP this grand new feature that isn’t even on the backlog yet. They are the person who IM’s, texts, or asks you face-to-face, “Have a sec? It’ll take five minutes.”

These interruptions are known by many names. It’s unplanned and unreported uses of time. They sap away your employee’s ability to provide productive value, yet these tasks regularly focus on keeping the lights on and the customers happy. While there are many different names for these time thieves, today we’ll focus on four of them. These four thieves take away time from a project, time you won’t get back.

We will highlight four thieves of time known to be lurking within some of our customers. These four have been highlighted by Gene Kim in the popular DevOps book entitled “The Phoenix Project” and Dominica Degrandis in her book entitled “Making Work Visible: Exposing Time Theft To Optimize Work & Flow”. Each of these authors have highlighted similar names of these time thieves outlining the same effects, they drain available time from your IT Project.

Before we begin solving world peace, let’s take the first step towards more effective time management by identifying four known thieves of time.

 

 

Conflicted Priorities

A thief suffering from multiple personality disorder, they will continuously change the critical tasks based on who is yelling the loudest. Let’s go back to the 1990’s and the movie Office Space where Peter is venting to his hypnotherapist about having eight different managers at work.

Your key resource on a project may suddenly have multiple “managers”, all with high priority tasks needing to be done to support their projects. A yelling contest continues until tasks are completed, whomever has the highest rank, or yells the loudest, wins the battle and you lose the war.

An example from the field:

  • A large investment company has merged with another and has resulted in newly combined teams, but leadership has yet to combine their thoughts on a single path forward, as a result, your new managers provide you their priority tasks which happen to contradict each other leading to confusion, misunderstanding, and additional work/rework.

 

Work-In-Progress (WIP) Overload

The “eyes-are-bigger-than-their-stomach” thief attempting to steal the gold from Fort Knox in Kentucky. Let’s take a page out of a classic movie Goldfinger, he knew it was too much work to steal the gold in the time he’d have, so he adjusted his plan to meet the timelines required to be successful. James Bond may have put a damper on his actual success, but we can’t argue with Goldfinger’s appropriate WIP workload.

Probably the most elusive in the realm of projects, rarely visible at proper levels, WIP are tasks not yet completed but still using time. PMs review their favorite project plan, are 55% complete waiting on X. Not wanting idle hands, they assign “temp” tasks. Both tasks overlap each other and overwhelm a resource.

An example from the field:

  • A 3rd party vendor comes into the organization and speaks with a project deployment team who are already 100% utilized. The 3rd party vendor requests meetings with key team members which equates to putting their other tasks on hold, leading to a build-up of WIP.

 

Unknown Dependencies

Known to always be lurking in the shadows and only showing up when you begin to execute your plan. Think of newer film Ocean’s 11 when they are about to blow the vault to stay on schedule and get to the millions of dollars behind the door only to discover no one ensured the batteries were still good in the remote to activate the next step.

Comical on the big screen, but it can derail projects of any kind. Within an IT project, this could be a parallel networking project being completed while you’re deploying network-reliant services to your customers. In this case, the siloed workstream supporting user service deployments was not aware of the networking upgrade until they began to execute their tasks.

An example from the field:

  • A customer supports a large SAP environment which has evolved over the years to be a “one-stop-shop” for their needs, only to discover a decade of adding to the SAP modules so tightly coupled it created a multitude of unknown and untracked dependencies which popped up during multiple migrations into an x86 infrastructure.

 

Unplanned Work

The thief known to wing it due to need, but not always a bad guy in the end. Does this sound weird? Let’s take an example from The Italian Job. Charlie and team create the perfect plan to steal millions of dollars of gold in Italy. Unfortunately, the fragile relationship with Steve was broken during the heist and the gold was lost. This rippled into months of unplanned work from Charlie’s team to finish the tasks to attain the end goal of getting the gold.

Within an IT project, these can be fire-fighting activities caused by legacy applications or fragile hardware. Unplanned work can originate in many areas. In “The Phoenix Project” unplanned work was the cause of ‘Technical debt’ not being paid down over time. Unplanned work can become very expensive as it takes away from paid project work. In the long run, there will always be some unplanned work, but we’ll get into those details in part two of this blog.

An example from the field:

  • In the year 2014 a large retail company implemented a year long project to become more lean and agile to support the ever-growing demands of new era shopping, but while priority tasks were being worked, multiple times their Point-of-Sale (POS) servers running on Intel Pentium III processors (yes, 2014) continued to go down. The fragile hardware had been running for over 12 years and time had to be diverted to repair these systems costing days of time because spare parts were nearly impossible to find if it was hardware issue or the OS was so out of date no one had any knowledge on how to resolve it. This unplanned work led to taking a step back and prioritizing the POS upgrades first.

 

Identifying the thieves can be a difficult task in itself, and more and more are lurking in the shadows of IT every day. If you were able to identify some of these within your project or organization, congratulations, you’ve taken the first step. In part two of this blog we’ll take you through the next step of the journey by expanding upon ways to make time thieves more visible to your workflows with measurable impact you can use.

 


Robin Newborg is a Senior Transformation Consultant with VMware Advisory Services.  Robin has over 15 years of IT experience, specializing in Digital Transformation, Process Refinement, IT Service Integration and Project Management.