Download - Managing Information Technology Projects in the Public Sector

Managing Information Technology Projects in the Public SectorAuthor(s): William Cats-Baril and Ronald ThompsonSource: Public Administration Review, Vol. 55, No. 6 (Nov. - Dec., 1995), pp. 559-566Published by: Wiley on behalf of the American Society for Public AdministrationStable URL: http://www.jstor.org/stable/3110347 .

Accessed: 03/09/2013 08:57

Your use of the JSTOR archive indicates your acceptance of the Terms & Conditions of Use, available at .http://www.jstor.org/page/info/about/policies/terms.jsp

.JSTOR is a not-for-profit service that helps scholars, researchers, and students discover, use, and build upon a wide range ofcontent in a trusted digital archive. We use information technology and tools to increase productivity and facilitate new formsof scholarship. For more information about JSTOR, please contact [email protected].

.

Wiley and American Society for Public Administration are collaborating with JSTOR to digitize, preserve andextend access to Public Administration Review.

http://www.jstor.org

This content downloaded from 161.45.205.103 on Tue, 3 Sep 2013 08:57:24 AMAll use subject to JSTOR Terms and Conditions

http://www.jstor.org/action/showPublisher?publisherCode=black

http://www.jstor.org/action/showPublisher?publisherCode=aspa

http://www.jstor.org/stable/3110347?origin=JSTOR-pdf

http://www.jstor.org/page/info/about/policies/terms.jsp


Managing informafion Technology Project s in he Public Seor

William Cats-Baril, University of Vermont Ronald Thompson, University of Vermont

Are frameworks developed in the private sectorfor managing information technology (IT) projects appropriateforpublic sector efforts? The management ofITprojects is an increasingly important issue in the public sector, especially as budgetary constraints become more stringent andfailed ITproject implementations receive widespread publicity. Although frameworksforproject risk assessment and project management exist for the private sector, such frameworks do not explicitly recognize the inherent differences between managing in public and private organizations. In this article, the authors use an in-depth case description of the State of Vermont's Human Resource Management System (HRMS) to illustrate many of the pitfalls ofpublic sector management ofITprojects. The project was two years late and more than $1 million over budget, and by early 1995, the system was still experiencing some problems. Unfortunately, the difficulties that surfaced are not unique to this project; nor are they unique to the State of Vermont. The authors propose modifications to private sector project management techniques and identify lessons that can be learnedfrom the HRMS experience.

Public sector organizations are being scrutinized and held accountable for their use of funds, now more than ever. Further, taxpayers are increasingly comparing the public sector to the private sector, demanding better customer service. As an added dimension, public organizations find themselves spending more on information technology (IT), even as their budgets come under pressure. In a situation similar to the private sector, public organizations find a large number of IT projects that are over budget, behind schedule, and producing fewer benefits than expected.

The trend in computing is to migrate from mainframe-based systems to smaller computer platforms, frequently employing Graphical User Interface (GUI) software. Such migrations are proving difficult for private sector and public sector managers alike. The problem is more acute in the public sector, however, because the bulk of the IT management experience in the public sector is with mainframe-based systems. Such experience does not translate readily to the skills needed for Local Area Networks (LANs) and client-server architectures.

Project management frameworks have been developed in the private sector that can provide guidelines, but blindly adopting such frameworks to the public sector can be misleading. What is needed is a workable project management framework that addresses the common ele- ments of risk assessment and project management, while taking into account the unique needs of public organizations.

Our purpose in this article is to suggest a framework that will address the needs of managing large-scale IT projects in the public sector. We first discuss the differences between public and private organizations, with emphasis on IT project management. Next a discussion is offered of trends in human resource management systems (HRMS), providing an introduction to the case. The case describes a specific attempt to implement an HRMS in a state government. The case is followed by the presentation of an IT project management framework. We close with a discussion of the lessons learned.

Public Administration Review * November/December 1995, Vol. 55, No. 6 559



Information Technology in the Public Sector The role of IT in public organizations has been the subject

of numerous research efforts, including a major research pro- gram at the University of California at Irvine (Northrop et al., 1990). The Irvine group argued that many of the intended benefits of IT, such as better information for planning and managerial control, had not been realized. A long-term, longi- tudinal study found that most payoffs from computerization were in the areas of fiscal control, cost avoidance, and better interactions with the public. However, those payoffs were not immediate, and the prospects for future payoffs in these areas were mixed.

Other research has focused on the control of information resources (including IT) at the state level. A national study of state governments investigated new organizational structures, planning processes, and policy formulation activities relating to the acquisition, use, and management of IT (Caudle, 1990). The study concluded that although the focus remained on IT management, public sector management was increasingly considering information itself as an important resource to be managed.

Another study was designed to test the basic premise that management of IT in public organizations differs from that car- ried out in private sector firms (Bretschneider, 1990). Using a sample of slightly more than 1,000 public and private sector organizations, the study presented a list of potential differences between public and private organizations that could affect the capacity of an organization to manage IT effectively. The differences identified by Bretschneider included the following (MIS stands for the management information systems function in the private sector, and PMIS for the public management information systems in the public sector):

1. PMIS managers must contend with greater levels of interdependence across organizational boundaries than do private MIS managers.

2. PMIS managers must contend with higher levels of red tape than private MIS managers.

3. Criteria for the evaluation of hardware and software, which ultimately lead to purchasing decisions, are different for PMIS and private MIS.

4. PMIS planning is more concerned with extra-organizational linkages, while private MIS is more concerned with internal coordination.

5. PMIS tend to place the director lower in the organizational structure than private MIS.

Although these and related studies (such as the one conducted by Rosenthal [1989]) are very helpful, none deals directly with the management of IT projects within the public sector. The focus of this article is specifically on IT project management, and this topic is of interest to many state and local governments. For example, in 1993 the State of Vermont Legislative Council formed an ad-hoc committee to investigate the process of large-scale IT procurement and project management, with three specific projects serving as the focus of attention. One of

The bulk ofthe IT management experience in the public

sectoris with mainfiame-basedsystems. Such experience does

not translate readily to the skill needefor LocalArea Networks.

these was the Human Resource Management System, referred to as the HRMS project (Cats-Baril and Thompson, 1994).

The State of Vermont HRMS Project During 1987, the Director of Payroll for the State of Ver-

mont, who reported to the Commissioner of Finance and Man- agement, began to express concerns about the existing payroll system. The system was inflexible, complex, and expensive. The estimated costs of running and maintaining the system were $250,000 per year.

About the same time, members of the state's personnel department began voicing their concerns over the lack of an automated human resource management system. The manual process of data collection and management and report generation was very inefficient.

Over the next eight years, a major systems project was undertaken. An outside consulting firm was hired to help with the HRMS project. The project experienced many difficulties along the way, resulting in major deadline extensions and cost overruns. By mid-1994, only a subset of the planned system had been implemented, and many state agencies were com- plaining that they were being charged heavily for a system that was not completely operational. In 1995, the system was still experiencing some problems; the W2 tax forms for state employees were delayed.

The Government of the State of Vermont

The government of the State of Vermont is similar in structure and reporting relationships to governments found in many other states. The Agency of Administration contains the Department of Finance and Management, the Department of Personnel, the Department of Taxes, the Department of State Buildings, and the Department of General Services.

Each of these departments is managed by a commissioner, who is appointed by the governor of the state. Commissioners are appointed to two-year terms and change frequently. On the other hand, state middle management and other state employees typically have long tenures, and they get to know each other and their jobs fairly well. It is not unusual for employees to transfer to different departments during their careers, and even to return to a department where they were previously employed.

Information Systems for the State

The state information systems (SIS) division was responsible for operating and maintaining the major information systems used by the various state departments and agencies. SIS viewed

560 Public Administration Review * November/December 1995, Vol. 55, No. 6



Though such systems were still relatively new, it was

believed that by working closely with software vendors and

consultants Vermont could have a system which would be

tailoredfor the unique needs of the state, and also take

advantage of emerging technology.

its role primarily as providing a service for the rest of the state government and tended to respond to requests from user departments, rather than initiating new projects. When a potential new systems development project was identified, SIS determined whether or not they had the expertise in-house and the staff available to commit to the project. If not, external development sources were investigated.

SIS ran major state information systems on an IBM mainframe computer located in Montpelier, the state capital. Approximately 1,200 terminals were connected to the mainframe, providing access to on-line systems. SIS also operated numerous batch programs, updated data files, and distributed reports to the users. Recently, they implemented various Local Area Networks (LANs).

The HRMS Project

To address the perceived needs of the personnel and payroll departments, a study group (later called the HRMS Steering Committee) was formed in 1988 at the urging of the Commis- sioner of Finance and Management and the Commissioner of Personnel. The original group, comprised of a variety of indi- viduals from across the state government, concluded that an integrated payroll and human resource management system was critically needed.

The HRMS Steering Committee decided early in the process that it wanted a system that would take advantage of new devel- opments in HRMS systems (Knapp, 1990; Miller, 1990) and be able to satisfy the needs of the state for a number of years to come. For that reason, it supported alternatives which employed Graphical-User Interface (GUI) software (similar to the Windows operating system from Microsoft) running on a client-server hardware architecture. Broadly speaking, client- server computing distributes application processing and data management across networked computing resources. The implementation of human resource information systems on client-server was still relatively new at the time the project was instituted (Hunter, 1992).

Although such systems were still relatively new, it was believed that by working closely with software vendors and consultants Vermont could have a system which would be tailored for the unique needs of the state, and also take advantage of emerging technology. Although some members of SIS wished to develop expertise with these technologies, the committee

determined that SIS did not currently have the expertise nor staffing available to implement HRMS in a timely and cost- effective fashion. SIS did not play a leadership role until later in the life of the project.

The cost of the system was to be recouped through annual charges to each respective agency or department budget, based on the number of employees. The charge for the first year was $570,000, and testimony to the state legislature indicated that the total system cost would be about $2.6 million.

A Request for Proposals (RFP) was prepared and distributed to prospective vendors. The steering committee unanimously chose the bid from Worldwide Consultants (information consulting services) and Human Systems (developers of the software supporting HRMS). The proposal called for customizing the Human Systems software programs using a personal computer (PC)-based database management system from PCDB,I running on a PC-based client-server architecture.

This recommendation was based on the premise that any PC hardware investments would not be wasted if it was later deemed necessary to use a more powerful server for performance considerations. Worldwide Consultants were purported to be experienced with Human Systems software, and the joint proposal called for Worldwide to complete the customization for Vermont's unique needs and also to complete the installa- tion.

The proposed systems were not only new for Vermont, they would have been considered novel for most organizations at that time. The infrastructure for the network would require fiber-optic cabling, and client-server systems were quite new. The PCDB database management system had only been available on the market for a few years. Although it was well received by technical specialists, it was not a leader in the indus- try, and PCDB acknowledged that at the time their product service and support were not up to par with their competitors. At that time, Human Systems had only a small number of installa- tions of their product.

Work on the project began in July 1990, with the original intent of completing the project within 12 months. As one member of the team later stated: "At the beginning we didn't know how much customization would be necessary. The 12 month schedule was somewhat arbitrary; we knew we would have to get into the project before we could come up with rea- sonably accurate time estimates."

The emphasis for the first 6 months was on defining Ver- mont-specific requirements. Most of the state members of the project team had full-time responsibilities in their respective departments and could only give limited attention to the HRMS project. Therefore, Worldwide became the primary force in determining user needs and establishing what changes were required to the Human Systems software. There was no direct interaction between state employees and Human Systems. The general approach was to determine how tasks were currently performed, identify differences between the procedures used by the state and those programmed into the Human Systems

Managing Information Technology Projects in the Public Sector 561



system, and then work on modifying the software to fit the existing procedures.

Initially, it was assumed that most of the Human Systems software was going to be used as a shell, and only those modules that were inconsistent with state policies and procedures would be modified. For example, the software did not accommodate expense accounts for payroll, which were used by the state. However, as the project went on, it was discovered that much more of the software needed to be modified than had been anticipated.

Changing of the Guard

The project schedule was revised and extended several times. In late 1990, the commissioners decided to "wean ourselves from outsiders" in project management areas and to bring more control and accountability over the project in-house. Relations with Worldwide were slowly severed, and a different firm was hired to provide contract programmers experienced in SQL (the database query language) to carry out most of the coding.

In January 1991, a new administration came into power in Vermont. New commissioners were appointed for finance and management, and for personnel. The new commissioners assessed the progress of the HRMS project. The amount allo- cated to pay for Worldwide's involvement in the project was almost all gone, and the project was far from being completed. There had been disagreements between the state departments involving issues such as who would control the data, who would determine what data was confidential, and who would be responsible for updates.

The two commissioners decided that the project team needed someone to resolve disputes and force closure on design issues, so they created the position of project manager. A local consultant, who had previously assisted with the generation of the RFP, was hired to fill the role. Because of a state regulation, however, the consultant did not have the authority to directly supervise state employees. His role evolved more into acting as a liaison between contractors and state employees, providing recommendations and tracking budgets, and the implementation schedule.

In March 1991, a project status report was issued by the HRMS project team. Major problems were identified, and the budget was revised and increased to a total of about $2.9 million. In August 1991, Worldwide's involvement came to a close. SIS assumed system development and full network management responsibilities for the HRMS project.

As SIS assumed the entire system development function, it was realized that the majority of the design/code completed to date was not usable and had to be rewritten. The majority (80 percent) of the position control/applicant tracking module was implemented the following month, about 2 months behind the revised schedule.

In October 1991, the HRMS project budget was increased to approximately $3.3 million, and the final implementation rescheduled again until July 1, 1992. At this point, the focus

In May 1992, the commissioners decided to scale back and

slow down the project because of the inability to predictably

meet project milestones regarding application development,

system performance, Human Systems support, and the wide

area network." remained on the personnel portion of the project. In May 1992, the commissioners decided to scale back and slow down the project because of the "inability to predictably meet project milestones regarding application development, system performance, Human Systems support, and the wide area network."

Short-term objectives were established, and it was agreed that they would address only completing the applicant tracking module and terminating the fiber-optic cable, which had been run in Montpelier and nearby Waterbury. The remainder of the personnel component would be put on hold, while design efforts shifted to the payroll component.

The Commissioner of Finance and Management wanted the project team to rethink the development approach. As he put it, "The basic question is whether you change the way people work to match the technology, or do you change the technology to match the way people work?" In commenting on the design and conversion efforts for the personnel portion of the project, the Commissioner of Personnel stated, "In retrospect, I'm not convinced that the approach of changing software to automate existing procedures is advisable. From my perspective, the Department of Personnel should have perhaps done a more thorough job of seriously questioning procedures that could very well be inefficient or ineffective."

In June 1992, the project team issued a third project status report, which recommended that a single, state project manager be given interdepartmental oversight and the authority to make decisions. The report also noted that consideration should be given to changing database software and server hardware to address the issues of system performance. Human Systems rep- resentatives had suggested that moving to a different database management system running on a minicomputer could alleviate computer performance concerns.

Although the budget was now about $3.3 million, the commissioners notified the state legislature that it probably would total $4 million before completion. The Commissioner of Finance and Management was becoming frustrated with the seemingly endless changes and modifications. Still, the problems with the existing payroll system would not go away. In January 1993, the state payroll system malfunctioned (it became overloaded), and approximately 300 state employees did not receive paychecks until three days after the normal pay period. Also during this month, the Commissioner of Personnel left state government to return to the private sector.

The Commissioner of Finance and Management thought




Though it is sometimes embarrassingfor information systems (IS) managers and consultants to

admit, the problems of cost overruns, delayed implementations, andfailed systems are very common.

that stopping the project at this point was unrealistic, since the old system had literally begun to fail. The only course of action appeared to be to forge ahead as quickly as possible, get some kind of payroll system operational, and then worry about other refinements.

By early 1994, considerable progress had been made on the HRMS project. The fiber-optic backbone network was operational and several state departments were running applications on the network. The personnel system was operational, although some minor adjustments and fine-tuning still remained.

The focus had shifted to the payroll portion of the system because the project team had been given an "ultimatum" deadline of June 1, 1994, for implementation. The decision had been made to move to a minicomputer platform for the HRMS, using a different database management system, and the initial benchmarking had looked very positive. The June 1994 deadline was met, although not all features of the system were complete. Problems continued to plague the project; in early 1995, the system was unable to produce W2 tax forms for employees, necessitating some emergency modifications.

Information Technology Project Management

The case described above is more the rule than the exception in implementing IT projects. Although it is sometimes embar- rassing for information systems (IS) managers and consultants to admit, the problems of cost overruns, delayed implementations, and failed systems are very common. Despite more than three decades of experience with large-scale IT applications, these problems have not disappeared. By one estimate, 20 percent of all IT projects get scrapped before completion, and 80 percent of the ones that are completed are finished behind schedule, over budget, and with lower functionality than expected.

There are four serious deficiencies in practice that account for most of the implementation problems: (1) failure to assess the risk of failure for the individual project at the time a project is funded, (2) failure to determine whether the level of risk is counterbalanced by a commensurate benefit if implementation is successful, (3) failure to recognize that different projects require different managerial approaches, and (4) failure to con- sider the aggregate implementation risk of the portfolio of projects under development by the IT group.

Numerous techniques, guidelines, and frameworks have been proposed by academics, consultants, and practitioners for managing project risk in the private sector. An approach that we have used with success consists of the following six steps:

Step 1: Evaluate whether or not the project that is being proposed is aligned with the mission and objectives of the organization. The more aligned the project is with the departmental objectives, the easier it is to justify the project, and the greater the political support for the project. This first assessment is basically an assessment of what can be expected if the project runs into trouble.

Step 2: Evaluate the benefits that the project will bring to the organization. These benefits can be tangible (e.g., greater efficiency and therefore reduced expenditures as in less overtime pay) and intangible (e.g., political good will with the state legislature because of faster response to their requests). It is important to do a formal evaluation of these benefits before deciding whether to implement a project and to review the list of benefits as the project evolves to confirm that it continues to be a good idea.

Step 3: Evaluate the risk inherent in the project by examining three dimensions of a project to assess its risk up-front (Cash et al., 1992). These dimensions are project size, experience with the technology, and project structure.

Project size refers to dollar expenditures, staffing levels, elapsed time, and the number of departments affected by the project. As with the other two dimensions, project size is a rela- tive concept. A million-dollar, 12-month project could be relatively small for a very large organization that has extensive project experience, or very large for a smaller, less-experienced company.

Experience with the technology is also an important consideration. Because of the greater likelihood of unexpected technical problems, project risk increases as the project team's and organization's familiarity with the hardware, communication channels, operating systems, database management systems, and application development language decreases.

Project structure refers to how well the outputs of the systems project can be identified and defined at the outset. If all parties involved have complete agreement on the content, for- mat, and timing of all systems outputs at the beginning of the project, then it is classified as "well defined." A project with low structure (poorly defined outputs) increases risk substantially because there will likely be disagreements over requirements of the system, necessitating frequent changes and delaying implementation.

By assuming two levels for each dimension of risk, this framework suggests eight types of projects (Table 1) ranging from projects with a very low level of risk (i.e., easy to do) to very high level of risk (i.e., very hard to pull off).

Step 4: Cross-reference the expected benefits from the project to its inherent level of difficulty or risk. One can think of four general possibilities as shown in Figure 1. Only projects




considered to be blockbusters (go-for-it) or high-wire acts should be performed.

Step 5: Assuming that the decision has been made that the benefits to be accrued from implementing the project balance its risks, decide how to manage the project to maximize the probability of successfully implementing the project. The management strategy depends on the evaluations of the three project dimensions listed above. The basic idea is to match the appropriate project management strategies to the individual project. There are four generic tools to manage the risk of projects (Cash etal., 1992).

1. External integration tools, which include organizational and other communication devices that link the project team's work to users at both the managerial and lower levels;

2. Internal integration tools, which are coordination controls that ensure the project team operates as an integrated unit;

3. Formal planning tools, such as project charting techniques, which help to structure the sequence of tasks in advance and estimate the resources the team will need; and

4. Formal results-control mechanisms, such as periodic reports and reviews, which help managers to evaluate progress and to spot potential discrepancies.

The appropriate combination of tools is dependent on what sources of risk are present in the project. For example, a project that is highly structured, small, and for which the project team is familiar with the necessary technology, is defined as low risk (i.e., very doable). Because the outputs are well defined, there is less need for external integration tools (formal links with the users). Because the project is small, internal integration tools (links within the project team) are not that critical. With a large-size project, there would still be a need for formal planning tools and results-control mechanisms.

Another management decision in this fifth step is the type of leadership appropriate for the project. For example, a project that requires relatively high technology will require a project

Table 1 Project Risk Assessment

Project Size Project Structure Project Technology Project Risk

Proven, known Low Well defined

Unproven, unknown Medium Small

Proven, known Medium Not well defined

Unproven, unknown High

Proven, known Medium Well defined

Unproven, unknown High Large

Proven, known High Not well defined

Unproven, unknown Very high

Adapted from Cash e al., 1992.

leader that understands the potential difficulties to be encoun- tered in implementing that technology. In general, the leader of the project should have the skills to understand and address the most important sources of risk.

Step 6: Decide whether or not the organization has the necessary skills, and whether or not the environment is propitious to develop the project. The decision can range from developing internally to outsourcing the project to shelving the project for the time being.

Lessons from the Case With this background, let us revisit the case described above

and explore some lessons that can be extracted from that experience.

Lesson 1: Make sure the project is strategically aligned.

The more aligned the project is with the departmental objectives, the easier it is to justify and the greater the political support for the project. In the HRMS case, although the budget had to be revised upward several times, the political support for the project remained strong because of its clear organizational importance.

Lesson 2: If the operation is critical, minimize risk.

The payroll component of the project was critical. The existing payroll system was rapidly nearing the end of its useful lifespan, and state employees (as with any employee) become very upset if they are not paid on time. The personnel component was less critical, since the department could continue to operate, albeit less effectively, without the new system. The telecommunications backbone was very important for future IT infrastructure advancements, but this component was less critical to day-to-day operations of the state. Why expose a core activity like payroll unnecessarily? Break large projects into smaller modules if possible, prioritize them in terms of importance of function, and manage them accordingly.

Lesson 3: Know your capabilities.

Another important point is the fit (or lack thereof) of internal management capabilities with the project technology and scope. SIS has been predominantly involved with mainframe systems that support individual departments. The decision to outsource some of the initial development and implementation made sense. It was the management of the outsourcing relationships that broke down.

Lesson 4: Unbundle projects into modules if possible. For assessing risk (Table 1), the project should be "unbun-

dled" and each component (payroll, personnel, and network) considered separately. For payroll, the project structure is probably well defined, although the complexity of the state's environment might lead us to argue otherwise (numerous separate bargaining units with numerous overtime possibilities, tax




structures, withholding items, and so forth, resulting in over 100 distinct combinations of payroll characteristics). Personnel is probably less well defined, since many of the features in the new system do not exist in the old, and it appears that the Per- sonnel Department is asking for changes. The structure for the network is probably not well defined. When all three compo- nents are considered together, the structure is not well defined.

The same type of analysis should be conducted for technology, and for each of the three modules, the technology is unproven and unknown. Size is an interesting issue. Although SIS has modified and maintained relatively large mainframe systems in the past, these have been used almost exclusively for a single department. This will be the first major project that will cut across numerous departments, adding substantially to the project scope. This type of analysis would lead to the conclu- sion that the overall project risk is high, or possibly very high.

Lesson 5: First reengineer, then automate.

Do not adapt software to obsolete or inefficient practices. In the HRMS case, much time and effort was wasted trying to rewrite the software to match existing procedures, rather than examining procedures and changing those that were inefficient or ineffective. Although the concept of reengineering processes goes against the prevailing culture in many public sector organizations, the perceived need to reduce government bureaucracy is forcing cultural changes.

Lesson 6: Make sure employees realign their priorities.

In Vermont, commissioners change frequently (often every two years); the workers tend to be in place for very long peri- ods. Also, state employees seldom leave; they may move from one position or department to another. Although a commissioner may feel a sense of urgency with a specific project or pro- gram, long-time employees may not. They have seen commissioners come and go; priorities change along with administrations. If a given project is truly important, it will be

Figure 1 Doability Grid

Go-for-it High-wire act

Why bother? Forget-it

Lowe High Project Risk

necessary to get employees to back it; they have learned to duck and wait for a change in administration.

Lesson 7: Leadership; impossible to succeed without it. One of the most effective ways to manage risk is to have a

project leader with the necessary skills to match the project needs. Without an appropriate project manager, projects tend to fall apart; at the first sign of trouble, participants run for cover. The Commissioner of Finance and Management should have worked with SIS to identify a suitable internal project leader who would be responsible for the project from the time he took over as commissioner until completion. As the project became more and more mired in controversy, finding a leader became more difficult. Who would want the job? The risk of failure was high, the rewards for success were low. Nevertheless, having a single leader with clear responsibility and authority to mediate disputes between agencies and departments was critical.

Lesson 8: Politics contributes to risk. Although obvious, this point is worthy of repeating. Getting

multiple departments to agree on project specifications is a major task; again reflecting on the private versus public issue, different departments often try to protect their turf, and compromise tends to be limited. Department managers have learned from bitter experience that if they give something up, they may never get it back. Subsequently, the environment tends to be one of confrontation rather than compromise. The departments and agencies tend to work toward optimizing local goals, rather than trying to work toward optimizing global (state) goals. Issues such as who controls interdepartmental databases cause conflict because departments can be in a position where they are legally responsible for the confidentiality and integrity of the data.

The case also illustrates how the financial burden of the HRMS project continued to increase. Because individual agencies and departments had no control over how much was charged to their budget for HRMS, and yet their overall budgets continued to decrease, the political environment became very hostile. Implementation of a project in such an environment is obviously much more difficult.

Conclusions A useful methodology for managing IT projects in the pub-

lic sector needs to recognize the inherent differences between public and private sectors. The main differences are: (1) given the greater interdependence across organizational boundaries, the need for clear project goals, leadership, and specific responsibilities is increased; (2) given the turnover of top level admin- istrators and the constraints imposed by red tape, the need to convince employees to change the existing organizational processes is greater and the difficulty to implement change is increased; (3) given the incremental nature of governmental decision making, the criteria to justify radical technological innovations are more stringent; and (4) given that MIS direc-




tors tend to have less authority than their private sector coun- terparts, the careful choosing of a project leader with both technical knowledge and political clout is essential.

Risky projects will always be difficult projects to manage. However, using a methodology that allows the project to be managed proactively increases the probability of success. The methodology described in this article addresses the idiosyn- crasies of the public sector and should be effective in determining appropriate project management strategies.

William L. Cats-Baril is an associate professor of information and decision sciences at the University of Vermont's School

of Business Administration. He has had several visiting appointments including stays at INSEAD and the London School of Economics and Political Science. He has published over two dozen articles and book chapters on a variety of topics in information technology, chargeback mechanisms, and decision-making models, and is the author of Systems to Support Health Policy Analysis (1992).

Ronald Thompson is an associate professor of management information systems in the School of Business Administration at the University of Vermont. He has published articles investi- gating the adoption and use of information technology and is co-authoring Information Technology and Managementwith Pro- fessor Cats-Baril (to be released by Irwin in 1996).

Notes

The authors gratefully acknowledge the support and cooperation of several key personnel within the State of Vermont (the Commissioner of Finance and Management, the Commissioner of Personnel, and the Legislative Fiscal Analyst), as well as the independent consultant who acted as project manager for the HRMS project.

1. The names of the consulting company, the human resource management system software vendor, and the vendor of the personal computer database management system software have been disguised.

References

Bretschneider, Stuart, 1990. "Management Information Systems in Public and Private Organizations: An Empirical Test." Public Administration Review, vol. 50, no. 5, 536-545.

Cash, James I., F. Warren McFarlan, James L. McKenney, and Lynda M. Applegate, 1992. Corporate Information Systems Management: Text and Cases, 3d ed. Homewood, IL: Irwin.

Cats-Baril, William and Ronald Thompson, 1994. "State of Vermont Human Resource Management System (A & B)." University of Ver- mont's School of Business Case IS-1092-1 and IS-1092-2.

Caudle, Sharon, 1990. "Managing Information Resources in State Govern- ment." PublicAdministration Review, vol. 50, no. 5, 515-524.

Hunter, Terry L., 1992. "How Client/Server Is Reshaping the HRIS." Per-

sonnelJournaZ vol. 7, no. 7, 38-46. Knapp, Jeffrey, 1990. "Trends in HR Management Systems." Personnel, vol.

67, no. 4, 56-61. Miller, Marc S., 1990. "New Directions in Mainframe HRMS Software."

Personnel vol. 67, no. 9, 16-27. Northrop, Alana, Kenneth Kraemer, Debora Dunkle, and John King, 1990.

"Payoffs from Computerization: Lessons over Time." Public Administra- tion Review, vol. 50, no. 5, 505-514.

Rosenthal, Steven R., 1989. "Producing Results in Government: Moving Beyond Project Management and Its Limited View of Success." Journal of Policy Analysis and Management, vol. 8, no. 1, 1 10-1 16.




Download - Managing Information Technology Projects in the Public Sector

Top Related