Many functions in government are guided, if not driven by checklists. For example, federal information technology management has many checklists for enterprise architecture reviews, capital planning and investment control, IT acquisition reviews, configuration management, systems development life cycle, IT security (FISMA), Privacy, Section 508, and more.
One of the frequent criticisms is that these functions are just compliance-based and are not focused on the real-world task at hand—whether it be planning, governing, executing, servicing, securing, and so on. For example, many have said that FISMA needs to be amended, because our IT security staffs are so busy with their compliance checklists and reports that they are not adequately focused on strategically or operationally securing the enterprise from attack. Similarly, EA review boards have been criticized for being an almost thoughtless checklist of architecture alignment to the FEA and not of real planning value.
Yet, inherently we know that checklists are valuable and that is why they have been so heavily mandated and incorporated into our processes. Without the checklists, we know from past experiences with failed IT projects, poor IT investment decisions, and security issues that many of these could have been prevented if only we had thought to ask the right questions, and so these questions got codified—and we learned from some of our mistakes.
With regard to this, there was a fascinating book review in the Wall Street Journal on a book called “The Checklist Manifesto” by Atul Gawande.
The author:
Mr. Gawande makes the case that checklists, plain and simple, save lives and we need them. He cites examples of “how stupid mistakes in surgery can be largely eliminated through pre-operative checklists” and how “checklists first became the norm in aviation, where pilots found that minor oversights in sophisticated planes led to tragic crashes.”
Overall, the book’s author maintains that “checklists seem to be able to defend everyone, even the experienced against failure in many more tasks than we realized. They provide a kind of cognitive net. They catch mental flaws.”
The reviewer:
The reviewer points out the important flip side to checklists as follows: “Bureaucracy is nothing but checklists. That’s part of what’s wrong with government—officials go through the day with their heads in a rulebook, dutifully complying with whatever the lists require instead of thinking about what makes sense.”
The reviewer makes the point that someone in authority needs to use judgment and that means: “relying on individual creativity and improvisation—the opposite of a checklist.”
The review goes on to then try and address the seeming contradiction between the need and value of checklists and the stifling effect that it can have by pointing out that “The utility of formal protocols [i.e. checklists, standard operating procedures (SOPs), etc.] varies with the nature of the activity—some activities are highly systematized, like engineering and other dependent on the judgment and personality of the individual. Spontaneity and imagination are important in many jobs.”
So there you have it—checklists—are helpful in defined, routine, almost mechanized areas where we can identify and itemize the necessary tasks, they are common to its performance, and they are proven to help avoid frequent oversights and mistakes. But where agility and innovation is called for, checklists can lead to either bureaucracy and/or missing the mark in getting the job done.
So are checklists helpful or hurtful with technology?
On one hand, technology is a fast-changing, innovative field that drives organizational transformation and thus it cannot primarily be a checklist function. Technology requires visionary leaders, talented managers, and customer-driven staffs. There isn’t a checklist in the world can inspire people, build meaningful customer relationships, and solve evolving, large and complex business problems.
On the other hand, there are common IT operational functions that need to get done and well-known pitfalls, and for these areas checklists can help us not make the same dumb mistakes again and again. For example, we can check that we are not making redundant IT investments. We can verify that appropriate accessibility for the handicapped has been provided for. We can safeguard people’s privacy with appropriate assessments.
The place for checklists in IT is pretty clear:
· STRANGLEHOLDS—Checklists cannot be a stranglehold on our business performance. They are not a substitute for thinking and doing. They cannot replace dedicated, talented, hardworking people addressing challenging and evolving business requirements with new and improved processes and technologies.
· SAFETY NETS—Checklists are safety nets. They are codified best practices and lessons learned that help us in not making routine, yet costly mistakes again.
