Technology and government and Waldo
Before you read the paragraphs following this first one, please first click over and read Jim’s post on Technology and government. I want to add to his thoughts.
Ok, you’re back. Perhaps unsurprisingly, since Jim and I like to teach together, we have similar beliefs about running successful, collaborative projects. Co-teaching is a collaborative project as are the large technical/software projects that Jim describes. In my corporate life, I certainly experienced what Jim talks about as the process-focused projects, and I didn’t enjoy them as a member of those technical teams. This was not because I felt that I was just a cog in the machine, but because I believe process should be in service of the project’s goal. As a software developer on a large technical project, I knew I had a job to do, and a good process made my job easier and my good work more impactful to the project overall. Yet, it was when the process (or the latest software technology) became more important to our daily discussions than the project’s goal that I became worried.
Jim talks about his Magnificent Seven approach — great movie, by the way. We saw this approach used in the development of the ARPANET and the BBN IMP. People matter, and the best projects result from a small team that believes they’re responsible for delivering the best solution to the problem at hand. You want good people with uniquely appropriate skill sets, and you want them to care about the result. And you need a management team that listens to this team. The technical team can’t make every decision (i.e., run without oversight or constraints), but it knows things that management doesn’t.
Even more important, the intended user base “knows” things that neither management nor the technical team does. In the (successful) software projects I ran, we spent a lot of time gathering feedback from the user base and incorporating that feedback into our design and system documentation. Successful software projects aren’t imagined, they evolve. Jim mentioned “soft launches” in our discussion. You can gather all of the use-case information you can possibly gather by talking to potential users, but you quickly learn that users don’t actually know what they want. Things often look very different when you put something concrete in front of them. Telling the user that that’s what they asked you to build doesn’t matter one bit to them when they say they don’t like what they see.
So back to eGovernment. In a dean in academia, I have had to fight the natural inclination of the faculty to want to debate a topic to death and then craft and pass the “perfect” motion. It’s a lot of work to get the faculty to a point where they want to vote on a resolution. Faculty are trained to be critical; many move up in prestige by writing criticism. We’re good at arguing. Unfortunately, this is not the same as being good a delivering what is needed. Our first attempt at our current Gen Ed program is one example. We needed a real 5-year review because we didn’t get it right the first time. (Taking seriously your 5-year review is better than not having one at all, but it is not equivalent to a soft launch approach.) My worry is that government is more like academia than successful technology companies. Lots of arguing and then one big vote. Lots of requirement writing and then a big software development and then one big launch. The result has to be right because legislators argued for many hours. Sorry, it is right when users can successfully use it.
Two paragraphs back, I talked about incorporating user feedback into our designs and system documentation. This is something that I can’t emphasize enough. If you’re going to iterate your design based on constantly gathered user input, and you’re working on a large, multi-year collaborative project, you’d better make sure the lessons learned are documented somewhere. And the lesson must include the context in which the lesson was valid. New software engineers and new managers need to know the lessons of the past if they want to avoid repeating them in the future. Process in service of the project’s goal.