Information technology projects too often can be fraught with pitfalls, lost directions and missed opportunities. Yet if tackled with a systematic mindset and a positive “can do” attitude successful technology enabled delivery of government information and services can yield results that create better and more efficient ways of doing the government’s business. This ultimately can lead to a better engagement or re-engagement with citizens. Implementing an information technology project provides a context by which government can attempt to do a new thing or to do an old thing in a new and better way. “Better” is usually defined as doing something more efficiently or at a higher level of quality. Breakthroughs in government processes from either an efficiency or quality standpoint are referred to as “innovations.” An innovation must first be envisioned, but envisioning an innovation is only the first in a series of complex steps along the pathway to an IT deployment. A vision that is not executed is only a dream. It is Easier to Block Innovation Than to Implement it but Strong Teams Can Overcome Resistance To bring a project from the idea phase to the product phase requires a vast array of distinct skills. These skills do not reside in a single individual or “star” but instead reside in many people. For this reason projects are always team efforts. Being able to effectively lead and work within teams are essential to the success of any government project whether it is repairing a bridge or 1000s of computer systems and sub-systems as demonstrated by organizations that successfully confronted and solved the Y2K dilemma (REGENTS SAY Y2K A $20 M PROBLEM, BUT LEAVITT RECOMMENDS ONLY $5M) . There are several lessons to be learned from IT projects that have succeeded and failed and many lie within the arena of functional and dysfunctional teams. Most project executives are confronted with several dangers as they attempt to guide projects. Some challenges may include:
-
- Teams that can’t get started;
- Teams that have “lost their way;”
- Teams whose members work at cross purposes to other members of their teams;
- Infiltration of the team by “saboteurs.”
Over forty years ago Kurt Lewin wrote about how to help create organizational change (Kurt Lewin http://en.wikipedia.org/wiki/Kurt_Lewin). Bureaucracies must first be “unfrozen,” then “changed” and then “refrozen.” Unfreezing makes organization susceptible and ripe (Mike Leavitt has often said that ideas must be ripe for change to be feasible) to new ways of accomplishing old ends or of doing new things. “Re-freezing” allows for the changes made to be institutionalized and thus preserved. New laws, executive orders, rules and regulations when carefully written can both unfreeze, help support and sustain positive change. These methods, as described by Lewin, are as fresh today as when they were written. Prospecting For Champions Should Always Be High on the List of Duties In any CIO Job Description Project teams require a critical mass of project champions possessing the correct skills mixes and whose unwavering persistence can overcome confusion and resistance. The reality in government is that people who work within these organizations have very different opinions about the nature of change and whether a proposed change will be worthwhile, or will instead lead to chaos that only makes things worse. This state is magnified by the fragmentation of government organizations. Thus, projects must counter balance the tendency of individual agencies to carve out their own turf rather than reaching across organization barriers to work to together to achieve common ends. Strong executive buy in, formal direction and collaboration backed with incentives can help projects succeed. Without these mechanisms many good projects are soon stopped dead and later abandoned. Successful team projects can be inspirational and can create pathways and models to how to do the next “repeat performance.” Conversely, a series of botched projects or ones that never get started lead to cynicism in the very employees who will be called upon to carry out the next solution. Loss of a Key Stakeholder Can Doom a Project While a Key Supporter at the Right Time Can Enable Success During the Leavitt administration two cross organizational IT projects provided two night and day examples of successful and unsuccessful IT projects. The OneStop Business Registration (OSBR) was a successfully implemented project that allowed new businesses to get started with all the paperwork needed by government located online and in one place (Utah OSBR https://secure.utah.gov/osbr-user/user/welcome.html). During a similar time frame Utah government also tried to implement a comprehensive electronic procurement system that failed to achieve its goals. An IEEE paper that describes the OSBR cross agency collaboration and the lessons learned is included below (IEEE http://www.ieee.org/index.html). Ultimately, the e-procurement system was never able to gain the support from the vendor community. Vendors preferred to go to various state agencies to sell products through their own catalogs as opposed to going through a central procurement interface. One astute government observer summarized the failure when he said: “Suppliers don’t like being disintermediated from their customers.” When a significant stakeholder fails to play and fundamental issues are not solved then IT projects rapidly grind to a halt. Assigning Foxes to Guard Hen Houses is Often a High Risk if not Foolhardy Endeavor One IT health and human services project became mired in inaction. A fundamental mistake was made when individuals opposed to the collaboration were selected to lead it. This strategy is sometimes used by executives who attempt to convert the opposition by trying to win them over and give them responsibility for leading a project.
This strategy is a high risk one since the executive does not know whether the project lead will make the choice to become an advocate or will instead sabotage the project. Rolling the dice is not very often a good leadership approach under these circumstances. You May Outsource Tasks But You Should Never Outsource Governance Government entities can have very successful outsourcing experiences or get into enormous difficulties at all stages of the process. Outsourcing projects require lots of decisions at the strategic and managerial levels to be successful. There can be a tendency to see outsourcing simply as a method to reduce the number of employees of the government thereby making government look “lean and mean.” If this is the underlying focus the project is probably already in trouble from the strategic level. This is not to say that staff should not be reduced because one of the goals of outsourcing ought to be either cost savings, service improvement or both. What outsourcing projects need most is a strong and reliable hand in project governance. Governance should never be outsourced and to do so is nothing less than irresponsible. Legislatures frequently complain about the lack of oversight of quasi-governmental agencies and yet at the same time have often removed executive branch oversight of these entities. It is very difficult for a legislative body to assume direct oversight of government outsourcing that is frequent and sustained enough to be effective. Lack of executive branch involvement in oversight can lead to legislative oversight after the fact in the form of legislative audits. Nevertheless it is clear that government should not be in the business of developing its own spreadsheets or other desktop applications or building computers from spare parts, so there is clearly a place for IT outsourcing. Having the right level of state employee oversight of IT projects is essential to their success no matter how big of a brand name the IT vendor might have. Finding the right staffing for such projects is difficult.