|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)
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:
- I set up a folder for each project and create a sub-folder “Open Items”.
- 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”.
- When the topic’s closed, I add “CLOSED” at the end of the folder name.
- 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.
- 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.)
Note #7: I tested this analogy by trying to juggle balloons after I wrote this. Alas, my test was not very successful - you actually can't juggle balloons like balls because they're hard to catch! You have to use a different technique, where you keep tapping the lowest ones upward - more like spinning plates.
Tangent 7A: Balloon juggling is a good activity to teach delegation that I saw in a Scouting training class on Leadership Skills. (Another great part of Scouting: Youth Leadership training! For more on Scouting: My recent blog on Scouts BSA.) You write down leadership tasks on (inflated) balloons and hand them to a leadership trainee. They may be able to keep two or three aloft by themselves, but as you keep handing them tasks (balloons), they get overwhelmed. The point of the exercise is to guide them to find helpers from the class to take some of the tasks from them – allowing the team to do more through delegation.
Tangent 7B: A different version of balloon juggling is also a great activity for kids 5-10. (This one’s battle-tested at Scout meetings.) Define a limited amount of floor space for the game (part of basketball court, the rug in a room, etc.) Each kid gets one (inflated) balloon that they must keep in the air without catching it, while they try to knock their opponent’s balloons to the ground. Players cannot purposefully touch each other – if they do then they are “out.” Players are also out when they step out of bounds, catch a balloon, or if their balloon touches the ground. Games go fast, so those who are out will soon play again.
Note #8: Here is a negative corollary to leveraging yourself: getting over-tasked. I fail here. Often. Inevitably, the task turns out to be harder than you expected. (Because it’s ALWAYS harder than you expect: Link to my talk on this topic, forwarded to the right point in time). Because of the iron triangle, government projects have flexibility in timelines, so they extend longer than planned (See Part 2 of this series). Because projects never end, you are always improving on what you have (See Part 3 of this series). I have so many unfinished projects that I wrote a strategic plan just to document them for the next person, although I am still working on that too…