 |
| Picture Credit: Found on the web, and people credited Chris Bolin (so I will, too!) |
This “Tectonic Speed” series of blogs is about why Government IT Projects take a long time - and ways to deal with that pace of change. “Tectonic” is the adjective because (like the earth’s plates) sudden shifts can change the landscape… but this post is not about that part. This one’s about the other aspect of Tectonic speed: the excruciatingly slow process when the plates’ movement is imperceptible and create nothing but friction.
Other “Tectonic Speed” posts explained the slow pace of Government IT by focusing on procurement (part 1) and project execution (part 2 and part 3). These phases are frustrating, but worse yet is the process that comes before any of them: coaxing a project from its genesis as an idea, through the growth of support, and to its manifestation as a budgeted project. (Note #1 - notes are below)
Part 4 of this series discussed the effort to overcome inertia and build momentum on projects, but glossed over the difficulties in steering that momentum. In that piece, I was blinded by my analogy (and the picture I love) of pulling a stopped train forward on its track or launching a pinball down the chute. The flaw in both metaphors is the idea that there is a track/chute – so steering isn’t needed because momentum is enough.
Since I write these posts as cathartic meditations, and I’m in the midst of coaxing several long-term efforts, I am returning to this phase of building – and steering – momentum for projects.
**********************************************************************
Disclaimer: 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.
**********************************************************************
COVID-19 created a tectonic shift for Government IT, there’s no doubt about it. (Luke Stowe wrote an excellent piece on this in Government Technology: https://www.govtech.com/computing/Looking-Ahead-to-the-Long-Term-Effects-of-COVID-19.html and I also touched on this topic in my presentation from the Code For America summit.)
The Tectonic Speed metaphor says that this change creates opportunity – and in this case it generated some funding, too. Our job as Government IT leaders is to seize that opportunity and move things forward. Moving projects from ideas to reality is my focus right now, but working from home I’m even more aware of the frustrating pace of Government IT change.
From home it’s hard to execute projects, so I’m spending my time building momentum on new projects – tasks that are a good match for email and online meetings. Spending my pandemic workdays on these slowly moving efforts, I’m struck by how little I can do on any one day to move them along. Mostly, it’s lots of waiting for others to do their parts, with short bursts of activity from you. (It is a weird way to work… see Note #2).
The Project Surrogate
Guiding a Government IT project in the right direction while it develops from a desire/wishlist to a budgeted project is an important phase. It requires understand the needs, researching options, determining a likely price (essential for budgeting!), building consensus that change is worth the effort, and struggling against the instinct of the organization to keep doing things the way we’ve always done them.
It’s incredibly frustrating. Government is already slow, but the goals here are daunting: implementing new IT projects can take person-years of effort, impact hundreds (or thousands) of workers, and often requires large teams doing project work beyond their normal duties. (Note #3)
Who guides this process? At least one person must make it their mission, or it won’t get done. It could be the future Project Manager – and this person is a great choice when it’s possible. Another option is a Project Sponsor, which I define as a person who wants the change AND has the authority to make it happen (a Department head or similar executive.)
Sometimes the person is neither of these. “Project Surrogate” is my proposed title for someone who gestates the project but won’t necessarily be involved once it starts, because the role involves sustaining the project during its development over many months. (I mean no disrespect in this analogy! It’s an honorable role – and often unsung.) I played this role on a multi-year effort recently, and I’m excitedly counting down the days until the project starts… and becomes someone else’s problem.
Pushing Jell-O and Sweeping the Rock
Let’s assume you’re the person who’s making the effort to get momentum started on a project. How do you coax long-term Government IT projects forward?
Here’s my first analogy: Imagine trying to move a six-foot cube of Jell-O. (Note # 4) Push too hard and your hands will squish in and ruin it. Government change is like that: pushing too hard can be detrimental to your cause.
A different, but better analogy: think about tapping a floating balloon. Your pressure causes it to move – but not always the direction you want. Government change is like that, too: pressure can cause erratic movement and a constant need to course-correct.
The best approach comes from the sport of Curling. I’ve never played (“Curled?”), but every four years I wind up watching Curling in the Olympics because it’s great TV. The speed of the game has a Goldilocks level of perfection - neither too fast nor too slow - and there’s exciting drama when a final well-placed shot can knock an opponent out of scoring position to steal the game. (From the 2018 Olympics: https://youtu.be/WiQeLGqBfcs?t=129)
In Curling, one player pushes the “rock” forward on its path, much like an IT Project can be launched. What’s more relevant though, are the two Sweepers who use brooms to help smooth and guide the rock’s path forward. (If you're not familiar with this, see the YouTube link immediately above...)
Like the Sweepers, advancing an IT Project through its early phases is about clearing the path, looking forward at the goal and making minute adjustments to impact the future progress of the project – all without touching the rock itself.
Takeout Shots
One last part of the Curling analogy applies: even if you’ve done all you can to clear a path and leave yourself well-positioned for success; your rock can still be knocked out of scoring position by a takeout shot.
With Government IT projects this could take the form of a change of priorities, last-minute objections by other stakeholders, or missed steps in the process that come back to bite. I had two recent efforts that were both culminating in agreements with tight windows to be signed, and each was almost knocked out by a need for pre-approvals from other entities whose timing was outside of my control. In both cases, I had not paid enough attention to the pre-approval processes, an ineffective sweeping job that required furious broomwork at the end!
Take a lesson from me here – the art of sweeping is keeping an eye on possible issues and taking proactive action to smooth the path. On IT projects this means knowing all of the steps on the critical path, and making sure you start on each with enough time to complete it before it’s needed.
It’s also important to accept that some events are outside of your control. Not all projects succeed – and there are an infinite number of ways they can fail to reach fruition, both expected (lack of budget) and surprising (global pandemic).
Accept also that it’s impossible to plan for everything that can possibly go wrong – and exhausting to try. Instead, accept a balance of doing your best efforts… and having a Plan B.
Plan B
Every project (deadline/effort/plan) - large or small - needs to know the Plan B. Simply put: Plan B is what you’ll do if Plan A doesn’t work.
When the project involves change, Plan B can be as simple as sticking with the status quo. For example, software replacement projects that fail to take root simply mean that users will keep doing what they’re already doing.
However, sometimes the status quo isn’t acceptable. What if the current software is no longer supported, or no longer meets regulatory needs?
Plan B doesn’t need to be as fully developed as Plan A – but you need enough detail to turn it into a fully operational plan should the need arise. Often, it’s enough just to have some brainstorming sessions to decide on Plan B (and C, D, and E… just in case) and sketch out some details. No matter how good your Plan B is, it’s never right and you’ll need to change it when you execute it. (“No plan survives contact with the enemy.” -- Helmuth von Moltke the Elder). Even a bad Plan B is infinitely better than not having thought about it at all. Knowing your Plan B helps you sleep at night. Things will go wrong (here’s a cheat sheet) and all you can do is keep sweeping.
Notes
Note #1: I never appreciated this in my former career as a project consultant, because by the time I was involved the project was underway. Public Sector sales representatives are probably the only people, outside of government employees, who can appreciate the months (or years!) of elapsed time needed to move big projects forward.
Note #2: A tangent to mull the modes of work:
For some jobs, work happens in discrete moments. One summer I was a cashier at a Burger King in a beach town. Lunchtimes were busy, with a stream of customers for me to ring up. Each transaction was separate, and I didn’t think about past or future customers – just the one in front of me. Once I clocked out, there was nothing I could do about my job until I was back behind the counter – so between shifts there’s no reason to stress (or even think) about work. Lots of service industry jobs are like this: when you’re not on the clock, there’s no work that you can do. The work can be mindless, but your downtime is your own.
Other jobs (teaching, sports, medicine) are a combination of performance during an event, and tremendous amounts of preparation before them. These jobs can provide a thrilling moment of success when your preparation pays off in performance. My roles as a software demonstrator and movie-theater operator taught me that focusing on details ahead of time helps the execution run smoothly - and I saw the highs and lows of success and failure in those peak events. Unlike Burger King, these are jobs you carry home with you at night – and they’re stressful because you can always practice/learn/organize more. If you take pride in your work, you may never feel that you’re prepared enough.
Most jobs in the “Knowledge Economy” do not fit either of these descriptions. (If you’re not sure what the Knowledge Economy is, but you’re reading this on LinkedIn, then you are probably part of it!) Knowledge Economy jobs can be the worst of both worlds. Like Burger King our jobs can be a series of repetitive transactions, but there are overarching responsibilities that weigh on us even when we’re not working. Like doctors and teachers, our jobs require constant effort to learn and prepare ourselves for new challenges, but we lack the exhilaration of successful execution in the moment: when the patient recovers, or we witness a student’s understanding flicker on like a neon light.
Note #3: Alas, even reaching the project’s go-live rarely results in a rousing success – and inevitably is the beginning of a new set of issues from the combustible mix of people and any new technology.
Note #4: For the Monty Python fans out there… I’m envisioning a giant blancmange from the Flying Circus sketch: https://www.dailymotion.com/video/x35sc0z