Tectonic Speed of Government, Part 8: Walking Through Water

on

 

Picture is from https://www.canningtonphysio.com.au/blog/hydrotherapy

I am always searching for metaphors to explain the “tectonic speed” of government IT projects, the process of moving a technology solution from idea to reality. I have described this as dragging a stopped train, stepping onto a glass floor, and the sport of curling. However, those blogs all related to the ongoing process of creating and guiding momentum over a long-term project. (Note #1, notes are below)

Now I want to slice time more granularly and focus on the micro-steps, the process of guiding events day by day. These micro-steps aren’t sexy like signing a contract or going live, but they are the reality of project management.

******************************************************************************

All of the ideas expressed in this article are my personal statements and opinions, and do not reflect the opinions/statements of the City of Urbana.

******************************************************************************

With remote implementations, we experience these micro-steps mostly as a series of emails that trickle by, through which the tasks of a project are slowly completed. A common example from my work life:

  • The vendor sends a question about the solution we are implementing.
  • I will translate the question into options for our end-users (Note #2)
  • A flurry of emails occurs, or we schedule a meeting (I’m old school) that takes several days to line up.
  • Whether we meet or not, more emails ensue.
  • Once we have our users’ answer, I translate that into something the vendor can use and answer the question. 
  • More emails may be needed until it’s resolved.
  • Days later another question comes up and the cycle repeats.

Because many projects are now physically remote (online meetings and emails) and the vendor’s people are working on many projects at once, there are always gaps in the timeline for responses. (Note #3) A non-trivial amount of my time is spent following up on open threads of discussion, because with so much communication it’s important to track and close each topic. (Note #4)

My frustration with these micro-steps is this: I can clearly envision the end goal and even how to get there, but moving forward takes more effort and time than you expect. It's like standing in chest-deep water at one end of a large pool. You can clearly see the other side and you know that all you really need to do is just walk there. But the problem is that you are in chest-deep water, so it’s a slog to move forward with each step. (Note #5)

That is the problem with these slow-moving Government IT projects. (Note #6) Even if you have a clear vision of the project goal, you know that it will take many months (or years) to make it happen. It is a frustrating way to make change.

However, on another level this speed is necessary. Government IT is limited by resources – not just money but people, and more specifically: hours of available effort. If our work were not slowed down by the natural pace of government, I do not think Government organizations could manage that much change at such a rapid speed.

So to end on a positive note, here are three ways that the speed of walking through water helps:

1.   You can leverage your work across many areas. Here is a different analogy: balloon juggling. It’s hard to juggle three tennis balls, but it is easier to juggle three (inflated) balloons because they move more slowly. (Note #7) And so it is with IT tasks. At any given time, I am managing at least six different initiatives – and sometimes twice that. (Note #8)

 2.   Obstacles, threats, and opportunities move slowly, too. This helps you see things coming at you in advance so you can deflect threats. Not quite this, but close: https://youtu.be/T9GFyZ5LREQ.

 3.   The slower speed lets you focus on technique, like an athlete who trains their form by running underwater. When that athlete gets on land and applies the same skills, they will feel like they are gliding. With IT projects, the extra time to react lets us focus on making the right decisions since quality is the one inflexible side of the iron triangle. (See Part 2 of this series)

Notes

Note #1: “Long-term project” is redundant: ALL projects are long-term or at least take longer than you expect.

Note #2: This is the key skill of the business analyst; lubricating the communication between the end-users and the solution developers. (My talk on this topic - jumping to the right moment...)

Note #3: My experience working on big implementation projects in the 1990s was different. On those projects, we moved into space at a client’s office – and big in-person meetings were the norm. Decisions could be made quickly, but those projects were huge waterfall development efforts to customize enterprise software, so they were slow for other reasons.

Note #4: Here’s my method for tracking these emails:

  1. I set up a folder for each project and create a sub-folder “Open Items”. 
  2. Each new thread becomes a sub-folder in Open Items that is prefixed by year and month (for chronological sorting) and topic, e.g. “2023_03 – Configure Label Printer”.
  3. When the topic’s closed, I add “CLOSED” at the end of the folder name.
  4. Periodically, I review open topics in a project by looking at the folder and move the folders for closed topics into different folders, which are usually organized by major area.
  5. Having a view of open items is crucial here, as I’ll periodically review the open topics and do a nudge on those that need movement.

Note #5: To tie up loose ends in the metaphor: you cannot swim there because you have a monkey on your back: https://hbr.org/1999/11/management-time-whos-got-the-monkey

Note #6: Another redundant phrase. ALL Government IT projects are slow. (That's the genesis of this whole series.)