The city's ambitious plan to spend $120 million to overhaul its tech systems was one of the first big stories I covered when I started on the Philly tech beat at Technical.ly Philly.
"This is a historic moment in Philadelphia's history, where we're going to spend $120 million to modernize the city," then-CIO Adel Ebeid told me in the summer of 2012. "We're not going to have this chance again," he added.
I reported the story without much skepticism. I was young and naive. (Don't hate.)
We've since learned that many of the projects under that initiative have gone over budget and are years past their proposed completion date. I'm not surprised.
Five years of tech reporting later, I now know that a project as sweeping as that one was doomed to fall short. That's what happens to huge IT projects, and it's not unique to government — these problems plague the private sector, too. We just don't hear about them as often.
Here's how city government can do better:
Think small. Stop looking for "one ring to rule them all" projects, says Azavea founder Robert Cheetham, who started his career as a city employee and now leads a tech company that works with governments. Narrow your scope and develop products that do one thing very well. The bigger the project, the longer it will take, and the more you run the risk of technology becoming outdated, a new mayor getting elected, or a new vendor acquired, all of which could damage your chances of success. The federal government's 18F digital service agency is leading the charge on this kind of approach.
Do what startups do. Yes, this line is getting old and there are definitely lots of things tech companies do wrong, but when it comes to developing software, startups have it down to a science. Build a working prototype, known in startup circles as a "minimum viable product." Get user feedback and apply it. Repeat as necessary. When governments execute tech projects, they often favor one big release, which leaves no room for evolution along the way. Startup-style development builds support among users (whether city staffers or the public) and a sense of ownership. Software development shouldn't be a one-way street.
Recognize what's working. The team that's redesigning Phila.gov, led by chief data officer Tim Wisniewski, has been following that iterative startup development process: It released an "alpha" version of Phila.gov, sought feedback from actual Philadelphians and used that feedback to rework the site. Could other city tech projects follow their lead?
Develop ways to get new talent in the door. Another promising project from Wisniewski's team is a short-term fellowship that brought designers and content strategists inside City Hall to work on city projects. This could be a model to replicate with procurement and tech upgrades.
Fix the RFP process. The current process favors companies that know how to apply for 250-page RFPs, rather than those that know how to build software. Several Nutter-era staffers were particularly focused on this problem and on fixing procurement in general, but Michael Nutter's administration ended before many of the projects could have a lasting effect.
Fight the culture of shame. City government needs to own its failures and, more importantly, learn from them. That's hard to do if leaders are getting shamed for projects that fall short. I'm especially thinking about this from a journalist's perspective. It's important that we hold city government accountable and speak up when the city has wasted taxpayer dollars, but I'm not convinced it's always productive if it means that city staffers fear the prospect of failure. Failure is an important part of the software development and innovation process. The key is to make sure those failures aren't enormous.
Realize that this is a systemic problem, not one limited to the Office of Innovation and Technology. City Council is quick to criticize failed projects like these, but you don't hear Council taking responsibility for its role in a system that perpetuates big tech project failures. Budgeting, for example, is a major cause of procurement failures, and Council is a powerful force in that process. One reason that governments plan huge one-shot IT projects is because they're worried they won't be able to secure the money for more projects down the line. So they try to do everything all in one go, which, as we've seen, often doesn't work.
Juliana Reyes is a freelance journalist and leads editorial product at Technical.ly.