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 strategies to keep project timelines under control.
PS - there was a surprise Part 3 of this series later!
************************************************************************************************
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.
************************************************************************************************
Why Government IT Projects Take a Long Time
Actually, this one is easy! The answer is the Iron Triangle of Project Management. The three sides of the Iron Triangle represent cost, quality, and speed. The rule is that you only get two of them. Want it cheap and fast? Then you get poor quality. Want it to be fast and well-made? That’s going to cost more money. And ultimately the scenario we face in local government: want it cheap and good? Then it’s going to take more time. And that is why IT Projects take longer than you expect: we don’t have money to throw at projects, and we need to do them well because we don’t have the luxury of re-dos.
End of story? Well, yes. Sorry, but the Iron Triangle isn’t going away. (And - at least here in Illinois government - neither are cost constraints.)
Costs aren’t just vendor payments. Local government does a lot with internal staff, so we’re spending people's work capacity, forcing a trade-off against other tasks. Unlike the private sector, governments lack the ability to quickly rearrange or increase staff – so throwing people at a project isn’t a viable option. (Note 1 - notes appear below) The result is that a 4-month project may take a year or more if you’re only getting 1/3 of someone’s time.
On cost there are some options (at least you can request more money), but quality is non-negotiable. Most of our systems have direct impacts on our citizen's lives. New systems must work well; with so many outdated systems to fix, any new one (even one that's not working well) isn’t getting replaced soon.
Reinforcing the effect of the Iron Triangle is an attitude within government that deadlines are malleable. This is likely a conditioned response to the Iron Triangle itself; given hard decisions between cost and quality, the natural inclination is to take the easy path of extending deadlines. (Note 2)
For the foreseeable future, IT projects will continue to take a long time, but here are three strategies to ponder. Execute them well and you can shorten projects, save costs, and improve quality – all at the same time. You may not be able to break the Iron Triangle, but you can shrink all three of its legs at once.
Own the Data, Rent the System
I’m simplifying things, but there are essentially two types of software solutions, which I’ll call “COTS” (for “Commercial off-the-shelf”) and “bespoke.” (Note 3)COTS software is used As-Is, meaning that you don’t change the software programs. After installation, you will configure it by making data changes only. For example, you might use an online screen to define payment approval rules based on the dollar amount of the check.
Bespoke software is customized for you, either by starting from a product and modifying the program or by creating all new logic using programming tools.
Speaking generally, local governments can’t afford bespoke software, because after you pay for the programming, you also pay the long-term costs for maintenance. Constant effort is needed to adapt to future needs and to keep it functional after upgrades to its components. For example: If you create a public-facing website, you must keep it compatible with popular browsers – now and in the future.
Bespoke software is an older model, dating back when there weren’t as many mature software products available – and systems were mostly for internal employees, not the public. Now, government entities use bespoke solutions because they have unique needs (e.g. the federal IRS tax processing system) or think they do (just about everyone else).
You can probably tell where my preferences lie. At the municipal level, if any set of users “needs” a custom system then the onus is on them to demonstrate why COTS software won’t work. These days there are dozens of systems of every type available. In fact, choosing among systems sometimes takes longer than implementing the solution!
Here's my advice: Find the best software you can afford, and then change yourself to adapt to it.
That’s what I mean by “rent the system” - think about it as your temporary home. This mindset gives you freedom to move to other software, which might be needed if the vendor is acquired, goes out of business, or increases your price too much. (Bespoke software clients are trapped like boiling frogs in a pressure cooker.) Full disclosure: adapting to the software is the hard part – see my next two sections.
This concept of “renting” the system has a downside: the consistency of data over time. Systems change, but the need to maintain data can be forever. That’s why the other important mindset is to “own” the data, because it’s more precious than the system it came from.
In almost every case, switching software solutions means making tough decisions about your prior system’s data. The biggest decision is if you want to invest in the effort to bring your data forward, which requires field-by-field analysis and mapping. There is no magic answer to this question, it’s a lot of “it depends.” Some thoughts:
- Bring records forward if the users’ business process depends on access to old data. For example, police records showing a history of interactions with an individual should be brought to a new records system so that they appear as a result of a name search.
- Put records in a queryable “data warehouse” if you need to access them, but don’t need them in the new system. Examples are old payroll data, housing permits, etc. Take the time to map and assign meaningful names to data tables and columns – don’t leave them with the cryptic names from the source system. Also, create logical joins for the data, or at least a data map of the relationships. Someone (maybe you!) will need to access it in the future.
- No matter what, don’t leave the data so it's only accessible by signing into the old system. Assuming the system will still run in the future (not a certainty, by the way), you’ll need to train new people on the old system if they need to extract data to fulfill a FOIA request or do historical analysis. Better to pull it from the old system and put it in an easily accessible format, like CSV files. Do your best to gather documentation (like data layouts), because this scenario could turn into the data warehouse mentioned in the last bullet.
Use Technology to Conduct Meetings, but Don't Sacrifice Communication
It seems redundant to say, “use technology for an IT project.” But it’s been a revolution to use tools that let people collaborate virtually, like groupwork sites and web conferencing, because vendors don’t need to travel to your location – saving thousands of dollars a week for projects.The City of Urbana had three projects recently where vendor staff worked remotely at least part of the time. Let me clarify: any IT project not built in-house is a remote project to some extent because most consultants work at the client site for only some of the time. But we have one project where we’ve never even met the person who’s been helping us for the past 18 months! Compare this to my experience: as an IT consultant in the 1990s, I worked at the client’s office 5 days a week and lived in their city, relocating three times in my first five years. Of course, those were different types of projects; we were heavily customizing mainframe software for State governments with project teams that numbered in the dozens.
Once web conferences replaced airplane flights as the consultant’s tool for meetings, these experts can dedicate many more hours to the actual work each week and reduce nights slept in airports, too. (However, I feel bad for these consultants, who must work on several projects at once... so many details to keep track of!)
OK, remote communication increase productivity and saves travel costs, what’s not to like? Well, there’s a huge trade-off: the communication is harder. Keep in mind that the software contract was already signed before the project begins. It’s not “what software will best meet our needs?” anymore. Now it’s “how are we going to use what we already bought?”
Showing my bias as Business Analyst, I believe that the key to a successful IT implementation is understanding both the user’s needs and the system’s abilities – and matching them up, while resolving the gaps between them. (Note 4) This is the role of the Business Analyst: talking to the users, understanding how they do their jobs, and helping them adapt to the new system. (Note 5)
Understanding both people and software, identifying points of disconnect, and reading people’s reactions are key goals of these discussions, and you can’t do that as effectively on a conference call, even with video. And that’s the nut of the problem: communication is key, but remote communication is harder
Ultimately, a mix of remote and in-person meetings is necessary to make the right progress. Make sure that you’re balancing your desire to save travel costs against the loss of effectiveness you can expect from remote meetings.
The People You Need On Your Project are the Hardest People to Get
During the discussions described in the previous section, the people who need to be there are the ones who really know what’s going on. Not the managers, but the people who do the work, who will be the users of the new system. The most successful projects are the ones that include the key end-users in the implementation.
And that’s the problem – the people who do the work are… DOING WORK. They don’t have time to sit in long meetings to talk about configuring a new system. They’re being pulled in 30 directions already, and they’re usually hard to back-fill. You might want someone to dedicate 50% of their time to the new project, but you’re lucky to get 20% of their time - so a project phase that’s supposed to take 2 weeks balloons to fill 5 weeks.
It’s not just having these people in the room; you need them to actively participate in the discussions. In an ideal scenario, these people are excited about the new system and are eager participants in the replacement process. What’s more common, however, are mixed emotions. Change is occurring, and no matter how much they complain about the old system… it’s still the devil they know. These people, who are the experts in the old system, will be starting as beginners in the new one, not to mention concerns about how their responsibilities are going to change.
Here are some tips on getting the right people to be active participants:
- Before the project begins, set expectations with them and their managers that preparing for the new system is going to consume at least 25% of participants’ time – so see what other work can be delegated or left incomplete.
- Meetings should occur on a repeating schedule, so people can plan around them. During peak times of a project (like acceptance testing), schedule working time in meetings rooms, so these people can get away from their desks to focus on project tasks.
- Get buy-in through discussions about the big picture: the new software is soon going to be their everyday reality. This is their chance to make it fit how they want to work (or at least make it not suck.)
- Don’t forget to recognize people. I'm old school... I like project coffee mugs for everyone involved. ($10, and worth it many times over.) Bring in food for key milestones. Write thank you notes and send e-mails to their managers acknowledging their extra effort.
A few final thoughts about Project Management. Your organization may be different, but our City didn’t have any Project Managers on staff when I started. Since then, we’ve had several different people get some experience at it, but it’s like any other skill –you need to go through the whole project cycle a few times to really get it, which can take years.
Remote projects make the role of a local Project Manager more critical than ever. In between remote meetings, your local people need to do tasks related to the project. Someone needs to follow up on those items and nudge people to complete them. (In general, not hearing anything from them is BAD news.)
The Project Manager is the task-master who follows up with everyone on their action items, and sometimes must be the heavy who forces people to make decisions. While configurable software is a wonderful thing, configuring means making decisions. You need to start choosing settings early because later decisions will be guided by your previous ones.
People tend to avoid decisions because they’re scary – you are committing yourselves in ways that will impact the downstream project. But not deciding is more damaging, so sometimes the Project Manager must be the one who locks everyone in a room to make the best decision you can with the facts in hand.
So treasure your Project Managers (and not just on Project Manager’s Day.) Like a traffic cop or a flight attendant, they have a thankless job making sure that everyone gets where they’re supposed to go, while taking a ton of abuse in the process.
Notes:
1) Nor is it a good solution. Brook’s Law applies here, which states “Adding human resources to a late software project makes it later.” As he wonderfully explains it: "nine women can't make a baby in one month."2) The willingness to extend project timelines shocked me when I switched from the private to the public sector, but it makes sense. In my private sector experience, there were financial penalties for missing deadlines – not to mention the embarrassment of failed projects. I've found that rigid deadlines are rare within government. This was a pleasant surprise at first, but I ultimately wind up somewhere in the middle. Projects need deadlines to focus people, not just to coordinate tasks.
3) To clarify my definitions for people who want a cleaner break: I draw the line based on what happens when restore a backup of your database into a completely baseline installation of the software – as you would in a disaster recovery situation. If you can continue working with no issues, then it’s a COTS system. Reports are a little different; you’d need to import a report, but then it would function.
4) Just to reiterate: functional gaps are best resolved by changing the process to meet the software.
5) Matching process and software is hard for several reasons. In government, the most knowledgeable users have been there a long time and have been using the old system for a while. (It might be the only system they’ve known!) Processes and systems grow intertwined, so changing one means changing both. Also, the end users often weren’t involved enough in the selection process, so they’re in a defensive crouch from the start because the new system is being inflicted on them. Finally, in 100% of the situations, their actual needs for the system weren’t accurately depicted by the RFP specifications, so there are going to be issues along the way.