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” but that title i…

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 View with ExcelWith a view …

Why the Tectonic Speed of Government?

The original name was "The Glacial Speed of Government” but that title is both cliché and inaccurate, as today it implies a faster pace than it used to. I decided that “Tectonic Speed” is more accurate because you can push very hard, but change in government shows tremendous resistance.  However, when change happens it can occur in significant outbursts - and in those moments, there is great opportunity!

Part 1Part 2  |  Part 3  | Part 4 | Wait there's a Video?!

Tectonic Speed of Government, Part 2: Why do Government IT Projects Take So Long?

This is part two of my series on why government IT projects take so long. Part one complained that the Purchasing process is tough to navigate because methodically describing what you want to buy - and documenting your decision making - takes effort. That blog helped me vent some frustrations about parts of my job, although I admit that it was a little dry. (But please, this is Government Procurement.)

With part two I’m on my home turf: the process that starts with the purchase of an IT tool and ends with its everyday use by people. If the process was successful, users are doing their jobs better than they did before. (A less successful outcome that also occurs: it’s harder to do their jobs, but at least their managers have better data.) This process, which I’ll refer to as the “Implementation” or “Project,” can take months or years for any organization - let alone a government.My first section explains why government IT projects take a long time, while the other three suggest str…