Massive I.T. projects almost always have time and cost overruns. This was noted, but not discussed, by an expert on megaprojects in his book. All the other problematic megaprojects involved plenty of physical construction, such as building the Sydney Opera House. This nagged me. Shouldn’t we be much better at the virtual? There’s more control. We’re not at the mercy of the weather, construction materials, or supply chain snags.
To learn more, I read Recoding America by Jennifer Pahlka. It is subtitled: “Why government is failing in the digital age and how we can do better.” Pahlka has lots of experience being in the thick of trying to cleanup mega-I.T.-projects gone awry. My responses to what I learned from her book? I was horrified by the examples. I counted myself very lucky (perhaps, very privileged not to be on a low rung of the socioeconomic ladder) not to have experienced these issues from the user end. But I also now have a greater appreciation of the systemic underlying problems. I felt that Pahlka’s analysis was balanced and thoughtful.
The first problem with mega-I.T. revamps is that you’re doing archaeology. You have a legacy system that encodes protocols and data. It has to talk to other legacy systems. Layer upon layer has built up. Expertise in the ‘old stuff’ has dwindled. (Who still knows machine assembly language? I tried to teach myself back in the ‘80s and failed.) Workarounds have proliferated, but as older workers retire their experience is lost. Can’t we just rewrite the code from scratch? Well, yes. But you need to understand what the old system did and it’s a labyrinth, or perhaps a many-level dungeon where you’d better be prepared as you descend. You’re not battling mythical monsters but many a software engineer has been defeated by the opaqueness of inter-dependencies of legacy systems. It’s hard enough debugging my own code – I’d never volunteer to debug someone else’s. You need someone who can do I.T. forensics, a technology archaeologist. Not many people with that expertise.
The second problem is protocol fetish. If you work in a bureaucratic organization, you know what this is. Even if you don’t, you’ve had to deal with ‘red tape’ sometime in your life; hopefully not too often. Why do I have to deal with bean counters and pencil pushers? Why are there more forms to fill out? The frontline workers and systems aren’t to blame. Their jobs are to follow and implement protocol. They get dinged if they don’t. Much of the government apparatus does this because if there’s an inquiry or someone sues, the reflexive response is to check if protocol was followed. Ass-covering is the game here. It doesn’t matter whether you have the right intentions, the moral high ground, or can make a good argument that you followed the spirit rather than the letter of the law. When the gavel comes down, the question is: Did you follow protocol?
Pahlka relays a conversation with a senior technology official as she tries to get to the root of a problem. The official is cheerful and tries to be helpful but oftentimes he would say: “That’s a question for the program people.” Pahlka pushes to understand why he avoids discussing what the system is designed to do. He respondsL “I’ve spent my entire career training my team not to have an opinon on business requirements… If they ask us to build a concrete boat, we’ll build a concrete boat.” Why? “Because that way, when it goes wrong, it’s not our fault.” In a megaproject, Pahlka notes that there are many stakeholders involved and they give “very specific direction to the technical teams, who can then feel as if they’re merely to do what they’ve been told.”
This leads to the third problem: the one-way flow of information and direction from policy to implementation. Pahlka calls this a “waterfall organization” and contrasts it to an agile one. The problem in the hierarchical many-layer top-down approach is that too often, the policy makers think that implementation is someone else’s job downstream. The top dogs think they’ve done their high-level more-valued job, and it’s up to the peons below them to implement. Translating policy to implementation is not as easy as it might seem at first glance especially if you don’t understand the first two problems and you don’t want to hear upstream feedback that makes you look bad. It’s no wonder so many people relate to Dilbert.
Pahlka writes: “The sure sign of a waterfall organization is how the people within it treat data. In an agile, empowered organization, data is a useful tool for adjusting course. The people in the organization not only have access to data and the ability to understand it but have the power to decide what to do based on it. If the compass says you’ve drifted off course, no one summons the inspector general or calls for a hearing. You just turn the wheel. In a waterfall organization, on the other hand, data functions less like a compass that helps you steer and more like an after-the-fact evaluation, a grade you get that says how well or poorly you did on something that has already happened… For people stuck in waterfall frameworks, data is not a tool in their hands. It’s something other people use as a stick to beat them with.”
In a waterfall organization, you have a lot of project managers rather than product managers. Look at the org chart of most I.T. organizations and you’ll see plenty of project managers. (I learned about project management while serving on multiple I.T. advisory committees as a faculty member, and I have a generally good idea how it works.) The key priority of project managers is to get all the requirement boxes checked off. Pahlka writes: “The idea that some choices could be made, and in fact would very much need to be made, was unspeakable, perhaps unthinkable.” User experience isn’t a priority as a deliverable. Isn’t that shocking? I’m not surprised. I’m also reminded that sometimes when I’m very busy I go on autopilot and unconsciously think that if I ‘delivered’ by lesson plans to my students, I’ve checked off the box on teaching them. Instead, I should be constantly managing the outcome or the product. Are students actually learning? Is what I’m doing actually working?
To reduce hierarchy and get stakeholder input, it has become popular to design by committee. It’s one way to put a check on autocratic power. Academia is rife with this approach and it turns out that democratic governments also attempt to do this. That’s the fourth problem, although it’s a problem because of the previous problems. Systemic problems compound on one another when you’re stuck in a system! Why do you have long forms to fill out with all sorts of ‘edge cases’ included? Design by committee! I’m not against wide user input, I think it’s a good thing. But in a committee of ‘equals’ where no one should seem more prominent than the others, policies become bloated. And you’ll be layering them on top of previous policies thereby increasing the bloat and the archaeological layers. I’m likely heretical in academia for believing that more often than not, reaching consensus is overrated, and informed decisiveness is a better approach.
While Pahlka’s book focused on mega-I.T.-projects in government, I think her analysis is very applicable to organizational management more broadly. Her emphasis on the systemic and how one might go about improving the system balances the horrors described with practical good advice. She also celebrates wins and there are examples of how government I.T. expertise has seen improvements and successes. Littered through the book is her exhortation that people in private enterprise should spend a stint in government and that more crossover will be beneficial to everyone. There are significant differences between government and the private sector, and she points the varying consequences. It’s a clear-eyed book that doesn’t avoid the messiness of systems and people. I hope more people read it and that fewer concrete boats are built.
No comments:
Post a Comment