Interview

How has government software been pushed into the modern era and what are some of the drivers of that movement?

Alan Katawazi: 

In the healthcare.gov situation, we had a law that was passed that created exchanges that people could purchase their own healthcare insurance, which is wonderful. The issue arose when the government allocated large amounts of money to this project and about 54 subcontractors all got contracts to develop the site. I believe the original budget was $96 million. Later it ballooned to about $840 million. For a website to cost $840 million, it's just astronomical. If you have 54 subcontractors all developing their technology differently, so some of them are using mainframes, some of them are using .net or Java, and then they're all expected to intercommunicate with each other, and on release day, it's supposed to scale up to the millions of people that need to use it, it will be problematic. A large budget doesn't always translate into a successful project. And perhaps the inverse is true, where smaller budgets can result in a better output because you're creating a more simpler solution.

What are some of the challenges that government IT leaders face and why have those challenges been so difficult to overcome?

Alan Katawazi: 

The government has unique challenges that don't exist in the private sector; namely, you have your legislatures that are creating laws. At the federal level we're looking at 100 plus laws per session, and those laws can be thousands of pages long. And then once they get to the agencies, the individual agencies are to have to implement these new changes into all their software and IT infrastructure. And those laws are interpreted as regulations. Under the 2009 to 2017, there were roughly 20,000 new regulations created. And each regulation is a little piece to some person's business logic in their application that needs to be modified. The government is spending about $75.6 billion to the federal government on IT projects every year. That's according to the Brookings Institute. There is a lot of money being put into the system in order to be able to meet the requirements of these regulations that are constantly changing. Typically, IT systems have been around for a while in government, like 10, 15, 20 years, even with their mainframes or their older legacy technologies. And I believe that the IT director at an agency, their constant challenge is ensuring that their technology stack is staying current because their needs are changing and they don't want to be in a position where their workforce retires and they have no ability to hire new people to take over.

Why do government agencies and jurisdictions need to rely on outside consulting help? 

Alan Katawazi: 

From a government perspective, they have a clear definition of what they need to produce. They have a legacy product usually, and they have clear government regulation indicating what needs to occur. From the agency level, if their IT projects can be broken up into small pieces, well-defined, and then the talent appropriately applied to produce a solution, it is possible. The major challenge, again, that the agency is facing is that their existing workforce, their employees, their W2 employees, are people who are what we would call maintenance developers. They're maintaining the existing system that's using an older technology stack. And this is why, a lot of times, contractors are brought in or a contracting agency is brought in to bring talent that has very specialized skills in the newer technology stacks. They can produce a solution in tandem with the employees, so that they're able to develop the skills to be able to maintain the next system that comes. I've seen that be a very successful formula for being able to successfully complete these projects.

What are some of the blockers or barriers that tend to slow down government IT departments? 

Alan Katawazi: 

There's this real myth that governments can't move quickly or get things done rapidly, and it's really not true. There are instances where the government has been able to move quickly to get projects done. If we look at Kurt Lewin's force-field model of change, which dictates that  when you're attempting to implement any kind of change in an organization, there are forces that are acting against that change, you have a lot of buy-in from those people with deep institutional knowledge that want this thing to succeed, so there's enough pressure that everybody's decided, "Yes, this system is antiquated, it's old, it doesn't work. We need something new." And that eliminates a lot of that potential risk.

What's your background?

Alan Katawazi: 

I am a best-selling author in the field of software development, and I have also done work for the government for about 10 years. I've worked in a number of different high-profile agencies and tasks and have been able to successfully complete a number of projects.

What's been the experience with government agencies leveraging outside consulting help?

Alan Katawazi: 

Well it varies widely, and of course no 2 agencies are the same. Yes, they have a lot of the same challenges, and yes they may partner-up and engage in long term efforts to share costs and benefits, but still - it's unique almost every time. But outside consulting help is really important at times and can really make all the difference. It's critical however, that the right approach is taken because without a good strategy you're going to waste money and restart projects sometimes many times over and again. It's tricky, because each little municipality, each state government, each federal agency has their own specific needs and requirements. Some IT directors will look to, perhaps, an organization like IBM or Salesforce, and they'll think, "Hey, we can use their platform and then customize it to our needs." But the reality is that the extent of customization needed to do the business logic that they need to meet those regulations is extensive. And those developers for IBM and Salesforce are very expensive, much more expensive than what you would get for your traditional contractor that would build you a solution based on established software development languages or architectures like .Net or Java.

How hard can it be for government clients to land on the right platform or technology? 

Alan Katawazi: 

Very hard. They often fall into the same traps as every other IT shop out there. The larger the company the more traps there are to fall victim to. There really is not any getting away from it. It is going to be a lot of work for a lot of different IT teams, but at the end of the day, it's really no different than what companies may experience. Every company is unique with its own unique business requirements. And I've seen a lot of initial failures because governments will allocate millions of dollars to, perhaps, not to pick on Salesforce, but Salesforce or IBM, to produce a product for them. But it turns out that the maintenance of that product, requiring those very specialized developers to make the enhancements, is cost-prohibitive.

How do some of these government agencies look ahead, beyond just the next election cycle, to really invest over a long period of time? 

Alan Katawazi: 

I mean, it really depends on the agency. Because you have a wide variety of Government agencies out there in each one is very different. I did also makes a big difference when you’re dealing with critical infrastructure versus more procedural or schedule driven infrastructure. If a system goes down, it may not bother anyone for a month, but if another system goes down, everyone gets out of bed and rushes over to their laptops. 

What sort of software development practices and methodologies work best with government agencies?

Alan Katawazi: 

Waterfall. Ya… You don’t want try to do agile in the government IT projects, unless you really are committed to it. I mean, it really would take a highly organized, concerted effort to successfully achieve a large software development project with an agile methodology in place for a government institution, because it just requires so much iterative and repetitive practices that these agencies are just not used to. It’s like a fundamental, culturally diametrical oppositional force that you’re gonna be dealing with. So that’s why I think waterfall for them tends to work really well actually. And another reason might be that it’s tied to the request for proposal process. If the requirements are pretty much well known at the beginning, the RFP is set, the budget is approved, the vendors are selected, the entire process sort of lends itself really well to the waterfall methodology, and it’s measurable in chunks. And these chunks are just basically milestones that any and every vendor can adhere too. So there’s really no reason why that wouldn’t work. The only thing that comes back to haunt you of course is the reality of the waterfall methodology where, as soon as you write the specifications for anything, it’s immediately obsolete and you have to go back and update it with change orders perpetually.