Skip to main content

The Tectonic Speed of Government, Part 3: It’s Never Over




Recently, I wrote two posts discussing why IT Projects take a long time: one on the Procurement Process and one about Project Implementations.  They were written during a time of three simultaneous projects, and they were therapy for me to exorcise some complaints... and make suggestions for others. From the start, I planned those as two topics – and I thought they'd finish the series.

But this third part was a surprise, and the greatest lesson I learned from those 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.
*********************************************************************************************

“It ain’t over till it’s over” - Yogi Berra on baseball, not IT projects.

Trick Question: When is a software project over?

Answer: Never. 

By “over” I mean the software is unchanging (“steady state” or “unpatched” – according to your point of view), and people who use the system are doing the same actions all of the time.

One reason it’s never over is that vendor software will always have updates to apply, test, and roll out. Another reason is that business needs change over time, so even homegrown solutions must evolve. In my time as a City IT Director, the only situation I’ve seen where you can say “it’s over” was when the software company went out of business. (In that case, it IS over, and you better start looking for a new system.)

In life, but especially in IT, there’s nothing but constant change. The most successful approach is to embrace that, and work with it. With software implementations that means tweaking screens, simplifying forms, and continuing to adapt the software to the people. Happily, improving the software also helps the people to adapt to the new system.

Here’s the big lesson I’ve learned from our recent projects: the best time to make these improvements is in the first 6 months after you “go live” (start using the new software).

This is frustrating because there’s a natural desire to step off the gas once the project goes live. Everyone has just slogged through a very difficult process and spent excessive amounts of time preparing for the new software (while still doing their regular jobs…) and they deserve a break. Also, if there were vendor staff who were on-site for the project, this is the point where they start leaving.

So why is the time immediately after “Go Live” the best time? Lots of reasons:
  1. From daily use, your people will find the inefficiencies they didn’t detect during testing, or will think of data fields and processes they didn't ask for initially.  You need to channel that frustration and find improvements, otherwise it will lead to disillusionment.
  2. It’s natural to cut scope during the project, but now’s the time to revisit items that were trimmed. You’ll have more clarity to prioritize them now; some will become more urgent, and you’ll find that others never need to be done.
  3. Users haven’t developed new habits yet, so nothing is etched in stone. Soon it will become the new “way we’ve always done it!”
  4. Your training might have included how to configure the system – this is a good time to apply those skills before you forget them entirely.
  5. You still may have access to your project team. Even if you don’t, you can develop a relationship with the support team, because the first year’s maintenance is usually built into the price.

The Bad News, with Several Analogies

Question: After the long hard struggle to bring a project to the go-live date, how do you keep the project momentum going for this tweaking phase after go-live?

Answer: By refocusing on the original point of the IT project. (It was to help people use technology to do their jobs better, right?) You've come this far, might as well go all the way.

Look, it takes time to get things right, and your first attempt isn’t always going to achieve everything you hoped. Leonardo Da Vinci used to work on his paintings for years, tweaking and improving. (He carried around the Mona Lisa for almost 15 years doing this, to say nothing of his many unfinished paintings.) So take the long view on these projects – it’s an ongoing process. Like flossing, it's hard and you should do it regularly.

Ouch! So we have to keep working on the implementation... forever? Yes, and moving forward, try to keep this attitude in place with upgrades, also. Upgrades fix issues and provide new features, so embrace change and patch often. (Quick tangent: New features might help address some of your pain points, but you can’t take advantage if you don’t know about them! Read the release notes. As someone who’s written release notes in my past career… if they’re good then by reading them you’ve justified the effort that someone put into them (say a quick mental “thank you” to them) and if they’re bad, then give the company feedback - for the sake of all of their customers.)

Here’s one final analogy. Have you ever spent several hours hand-washing a car, then watched your effort dry into dull, streaky smudges? Do you know what you didn’t do? Wax it. Yep, now that you’ve spent all that effort washing your car, you need to go over every inch of the body again, waxing it. But even wiping on the wax isn’t enough – in fact during the time you’re applying the wax, it looks even worse than before! (What the hell were you thinking smearing that stuff on? In the IT analogy: what the hell were you thinking changing the entry screen and breaking it?) But then you start buffing that wax, and with significant effort you produce a luminescent shine. It takes more work, but your car looks awesome!

To quote another American folk hero:

“Wax on. Wax off.” – Kesuke Miyagi on cars, karate, life... and IT Projects.

Popular posts from this blog

The Tectonic Speed of Government, Part 1: Procurement

This post is my reaction to conversations about how hard it is to create change in government, and how government projects (and IT projects in particular) take so long from genesis to completion. This is part 1, about procurement; part 2 will address project implementations . PS - there was a surprise Part 3 of this series later! Warning : what follows is an “inside baseball” discussion of government IT procurement. I’m not trying to dissuade you from reading it, but if you’re not enmeshed in this world you might want to consider reading my articles on lighter topics like organizing your electronic life , the greatness of Abbey Road , or the story behind The Room . If you ARE enmeshed in this topic, then please don’t overlook my call to action at the end! Changing the process will take a group effort, and I’m hoping to get feedback on my scheme to create a library of reusable software specifications. By the way, this post’s first title was “The Glacial Speed of Government” bu

How To Videos: Lucity Queries with Microsoft SQL Server and Excel

What follows is not a blog, but some suggestions on using Microsoft SQL Server "Views" to query your Lucity data using Excel.   This information is intended to assist Lucity software users, and not for any nefarious purposes. I recommend watching the videos in Full Screen view and with HD resolution.  They're not as blurry as they look on this page!!  Each of these about two minutes long, but the original actions only took 50 seconds each.  (After recording them, I decided to slow them down to make them more watchable.) 1. How to create a SQL Server "View".   The video shows how to create a new View from the core Work Order table.  (WKORDER - see the data dictionary here .)  The video first shows the simple method of creating a view with all fields, then shows the more effective method of including only needed fields, and re-labeling them with their on-screen names. Music: "A View to a Kill" - Duran Duran 2. How to Connect to the Vi

Why the Tectonic Speed of Government?

The original name ("Glacial Speed of Government”) is both cliché and inaccurate, as it implies a faster pace than it used to. I decided that “Tectonic Speed” is more accurate because change in government shows tremendous resistance and moves slowly, but when it happens progress can occur in significant outbursts - and in those moments, there is great opportunity!     Click on "Read the Whole Thing" to access these links: Part 1 |  Part 2   |  Part 3  | Part 4 | Wait there's a Video?!  

Get Your Shit Together: Work Edition

  Photo Credit: Jeremy Keith - https://www.flickr.com/photos/adactio/5757457657 Three years ago, I wrote a piece about organizing your personal electronic life ( https://blog.tectonicspeed.com/2017/09/personal-archiving-get-your-shit.html ), which I sub-titled “Get Your Shit Together” in an homage to George Carlin’s routine about the last two minutes of your life. ( https://youtu.be/LkIqccMRTNo?t=93 ) Recently I’ve been thinking about the equivalent process at work. We are dealing with an over-abundance of electronic files on our shared network drives - and I'll wager that it’s similar for most workplaces. ( NOTE 1 , notes at the end.) ************************************************************************** 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. ************************************************************************** Extra Disclaimer: I want to g

The Tectonic Speed of Government, Part 4: Momentum

https://www.themoscowtimes.com/2019/11/20/meet-ivan-savkin-russias-human-mountain-a68246 This “Tectonic Speed” series is about why Government IT Projects take such a long time. The name refers to tectonic plates, rubbing against each other. No visible movement for a while then… CRACK! Government change is like that; it can take a long time to build, but when it happens it can be intense.  For more on that here is my 20:50 speech on this theme from the Code for America Summit 2020 , which turned into a virtual event. (I can tell you that it’s 20:50 because of the PechaKucha-ish format: 25 slides for 50 seconds each.) ************************************************************************** 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. ************************************************************************** One impact of the COVID-19 pandemic is a shake-up of p