This month’s dilemma | Behn’s solution | Previous dilemmas

Failure and the Big IT Project
Readers Respond

Here are readers’ ideas for coping with this month’s Manager’s Choice dilemma. To post your own ideas, see the instructions at the bottom of this page.

CREATE A REAL TEAM

People from both departments should be brought into the project, a leader(s) should be "initiated," and a real team needs to be created, but this six-month, 360-degree feedback thing sounds counterproductive.

The team is not the issue; completing the project is the issue. It would be a disaster if the team fell apart after six months because of internal criticism. The team leader(s) must keep the members on track and productive. Points five and six are good and should be implemented.

Focus on the goal and don't let the players tear each other apart. If a real team is assembled and they are committed, the contribution issue will fade away.

Michael Derrick
Technical Support Supervisor
Shoreline Wastewater Management District
Shoreline, Washington

SOMEONE HAS TO BE IN CHARGE

The school solution (if you would), hit lots of important points on the head. Some additional issues/concepts that need to be considered in how the school solution is implemented:

1. "Project" does not equal contract. A project might be 5, 10 or even 15 contracts, each individually tailored to accomplishing a specific, usable, (even) self-standing deliverable. In too many cases, the practice is to do the whole thing at once, which is where your mission creep becomes the swamp. Agencies are afraid of multiple contracts. But, there is real safety in having to stop, re-affirm where you have come from and where you are going, and then get back on the track, several times.

2. A team, or more likely a series of teams, is necessary. But, somewhere, some one individual has to be in charge. And that one individual has to be a state employee and has to be responsible to, in your case, the secretary of the West Dakota Department of Social Services.

You might also form an executive sponsorship team that deals with high-level issues. For instance, the secretary of the West Dakota Department of Social Services, secretary of the West Dakota Department of Administrative Services, secretary of the West Dakota Department of Health and/or Children's Services and/or Education and/or Corrections, the state court, a representative(s) of the county social service agencies, a representative(s) of the juvenile court system(s), the West Dakota comptroller (or however that is done). But these are the big guns, who will both make and break the outcome.

But in the end, there has to be a "project manager" who runs the project. They may have all kinds of help from a separate, or several separate, contracts that provide risk assessment, project management and other services, but someone has to be in charge. And, it cannot be the secretary.

3. The teams involved need to be special, but they cannot be isolated. 360-degree feedback is great. But, in the end, the intake worker in the smallest county, with the slowest computer, on the slowest phone line, who is also responsible for ordering supplies, keeping the office clean and answering all the phones in the office, needs to be able to understand and use the system from the beginning. There is a tendency to want to build the system for the developers (both agency employees and contractors--the people with the vision). But it is the people without the vision who need to use it, and who will bring it down--because they can't use it, or won't use it.

4. Time is not on your side. Especially in the last five years, if there is a solution today, it is not the solution in six months, or even maybe six weeks. That makes it even more critical that things be done in smaller chunks, that produce defined results.

5. Standards, even the "law," is a moving target in big projects. Because of time, expectations, changes in perception, nothing will stay still for long. And, no more than technology changes very quickly, so does the law (especially when you do not want it too) and expectations and perceptions.

6. Whatever the results, they will not be what was envisioned when it started. That is not a negative statement, just a factual one. But that needs to be understood at the beginning. Then you can manage expectations and perception more intelligently.

Paul Stembler
Assistant Director, Materials Management Division
Minnesota Department of Administration
St. Paul

CONSIDER A CONSULTANT

I'm not sure if Bob Behn literally meant five people or five types of people for a team numbering more than five, but in my experience, to co-chair a five-person team comes with a built-in weakness. If two-fifths of the team are directing the process, you have increased the workload (co-chairs need to meet before the meetings) and decreased the accountability ("he said/she said"). If the organization can't find someone on staff that is able to straddle both sides if the fence (IT and CSE), then an outside consultant may be called for.

One of the advantages of an outside consultant is that they are free from the local turf-protection wars that invariably creep into such a group. IT managers have favorite technical approaches and case managers want unlimited flexibility with the program instrument. A consultant can step outside of the boxes and take a more neutral position. For instance, an Internet-based ASP solution may be called for rather than a client/server model, but the IT managers might feel threatened with the loss of control.

One other player that needs to be at the table is someone with a good overview of current IT solutions in the field (this could be the same consultant mentioned above). Why reinvent the wheel with a staff of highly paid individuals? Your team might be struggling to design specifications for products that are "off-the-shelf." In fact, a review of current commercial solutions might provide a framework for the team's approach to the design specifications.

Butch Giusto
Stargate Productions, Inc.
Augusta, Georgia

GET THE GOVERNOR’S BLESSING

I basically agree with Bob Behn's approach to this project. However, I would add the following other suggestions:

(1) For a project this large that will involve a significant financial outlay of funds, I would attempt to get the governor's blessing of this project up front. In fact, under his auspices, I would even recommend that he name a task force made up of high ranking individuals from Social Services, DAS, and his own office to promulgate the overall goals and objectives of the project. In addition, the task force could also serve the purpose of obtaining initial funding for the project under the approval of the Governor and State Legislature.

(2) Knowing in advance that there will probably be communication difficulties between the users of Child Support and the Technical people of DAS, I would contract out for the services of a consultant. The consultant would serve to gather all user area requirements and then put this information in the format that the technical people could use to begin developing the system applications needed. In addition, using their expertise, they could also assure that all requirements needed by child support were included in the development document. I would suggest that all requirements be defined before a development project plan was issued.

(3) For this project, I would also appoint three project leaders: One member from child support, one member from DAS, and the consultant. These leaders would lead the project team in activities to be performed and in maintaining the project log. In addition, they would also serve as liaisons between the project team and the members of the Governor's appointed task force.

The overall management of the project from development, to installation, to testing, and to final acceptance would be the responsibility of the project team leaders. With appropriate assistance and support, they should be able to bring the project in on time.

Perstein Cave
Fiscal Manager
Department of Banking
Hartford, Connecticut

FOCUS ON EXECUTIVE STRATEGIES

Creating a competent and cohesive design team is truly one of the principal ingredients in a successful IT project. The measures you recommend are critical to creating and enabling such a team. Large scale projects require a delicate balance as the team must feel that it is both an extension of the agency as it leads the way, and, yet, not fall into a pattern of isolation from the daily workings and community.

The first five factors are associated with team construction and synergy, while the sixth is an example of crafting "executive actions, or strategies" intended to help ensure the work of the team reaches fruition. My belief is that no matter how well you have performed the work around team building and maintenance, their prospects for success are greatly diminished unless you have done as good a job on developing the sixth factor.

Either as a prelude to creating the team, or as an exercise with the team leads, the executive must create the framework within which the design and the development will take place. This framework is usually a statement outlining the objectives of the project (cost savings, increased service, accountability, etc.), source of funds, funding constraints, and any imperatives regarding timeframe for completion.

The team leads and initial team members can then create a high level view of the new business practices and process design, desired outcomes, reporting requirements, and performance measures required to be met. This can be translated to a similar technical design. This process requires the business and technical staff to learn to communicate before they, or a vendor, start to build. The design(s) are then presented to the executive for approval. This process can also facilitate the procurement of hardware, software, and vendor services.

If there truly are time imperatives associated with the project, then the design and scope of the project must be limited to fit the time available. With the parties in agreement as to time and design, there is less likelihood of the project escaping its limits. All too frequently "scope creep" is blamed as the cause of project failure, when it is actually the all too natural result of inadequate up front preparation and planning.

Charles McGlew
Connecticut Department of Labor
Unemployment Insurance Benefits Director

STOP ‘TECHNOLOGICAL APARTHEID’

“Civilian control of the military!” That is what comes to my mind when I read this dilemma. West Dakota has established a separate Department of Administrative Services, answerable to the Governor, to provide IT support to other departments and agencies.

Child Support Enforcement (a small part of the Department of Social Services) may not be a big priority in the overall scheme of things. While it may be argued that West Dakota gets “more bang for its buck” by consolidating computer services, hardware, software and staff, each individual agency loses the ability to take care of its own needs--and develop in-house expertise.

Data warehousing may save on equipment costs, lead to better standardization and improved data communication across agency lines, but it also leads to a technological “apartheid” whereby individual agencies lose control over computer programming staff, and ultimately lose control over their own IT destiny.

The end result is a disagreement as to who is in the driver's seat, the agency or the IT people. While West Dakota may not be able to rectify this overnight, it would be a step in the right direction to outstation computer programmers/data communications specialists in the agency to be served. Place them under direct supervision of the CSE people. Let them battle it out close at hand, communicating their needs (CSE) vs. technological feasibilities (IT).

Yes, it will be uncomfortable for both groups at first, definitely not a touchy-feely Total Quality Management scenario (with the sound track of “Up With People” playing in the background)--but each side needs to learn something from the other side. And the final product has to be something that Willy the Mailboy (to borrow him for a moment from Dilbert) can operate without six days of training.

J. Timothy O'Toole
Internal Control Officer

New York State Office of Children & Family Services

ENSURE ACCESSIBILITY

One more thing is necessary to ensure that all users can access your new system. Is the system going to work for people with low vision, who are blind or who have other disabilities? Will those in your current workforce be able to continue their present work assignments. Technology exists to ensure that all can be accommodated. At my agency, we have had complaints from state workers that a new computer system had virtually left six people from one agency on the lurch (with our assistance this was rectified) and in another agency, a professional could no longer do his job and has filed an Americans with Disabilities Act complaint against his employer.

Lorraine Greiff
Massachusetts Office on Disability

SHARE SUCCESSES AND FAILURES

In our division we had the same dilemma. Very similar. And right now we are in the rebuilding stages of the first IT project of 5 years ago. My approach would be:

1. Get input from stakeholders, customers and users of the IT project. We need to know what are their expectations before we even start writing a specification document. You can get the input through surveys, facilitated meetings, etc.

2. Map the processes that will be involved in the IT project. It is very important to understand the system.

3. Hire a professional project manager, or have someone internal be the project manager. It is important to keep track of the project and coordinate all the logistics of a big project like this one.

4. Create a team. The team should have owners of the processes that would be impacted by the project. That way they will have a say and will be committed. They all will share the success or failure of the project (this includes IT people).

5. The team should be given a real commitment from management and should have the necessary resources to complete the project.

6. There are different ways of hiring contractors to complete a project like this one. One option would be to bid the project in parts. Another option would be to bring individual contractors to your workplace. That way you can work and communicate with them on a daily basis. Look for creative ways to get the best.

Cesar Zapata
Environmental Supervisor
Ohio Environmental Protection Agency
Columbus, Ohio

MASTER THE TRIANGLES

The development of a statewide IT system for a social service area needs more than the interaction between IT personnel and field practitioners (end users) with a 360 degree feedback loop. There is something more fundamental but often ignored: a sound conceptual framework based on current theory and methodology in a given field. The conceptual framework provides the "master mind" that provide the reason, logic, and purpose of an IT system. An IT system without a solid conceptual framework (not IT system architecture) is like a traveler without a map: you don't know where you are and where you are going. Therefore, another player, a research expert in a given field should be at the table.

In this perspective, the development of a successful IT solution involves working with three triangles:

(1) Theory, Methodology, and Data. Theory defines the "why," methodology defines "how," and data defines "what" in an IT system. We need to have a clear picture of how the data will be utilized to answer what questions, with what types of validity before the construction of the database. The logic model and data integrity need to be built in the database to assure the validity of data. Too often we have data collected and then try to check the validity and figure out how to interpret the data. Garbage in, garbage out. Collecting garbage is the biggest waste of money, staff time, and valuable IT resources.

(2) IT professional, field practitioner, and researcher. The three have different mind sets and talk in different languages. They dialog but not truly communicate. The fact of the matter is each side holds a piece of the puzzle. A successful IT system requires the three sides to work together. Taking a holistic approach and treating the IT development as a mutual learning process is a promising approach to work with this triangle. Utilized a participatory model, Pennsylvania organized a work group consisting of case workers, research expert, and an IT subcontractor and successfully developed an Outcome Based Case Management System, which has research based outcome measures, utilizes state-of-art software technology, and meets the information need of the caseworkers.

(3) Process data, assessment data, and secondary data. Process data relates to Who, What, Where, When, and How often services are provided. Assessment data refers to periodical data collection on service needs, benchmarks and indicators measuring performance and outcomes. Secondary data is archival data collected by a third party but are relevant to your service area. Since each type of data tells only part of the story, a good IT system must integrate all three. To effectively manage this triangle, we need to understand the complete process from data acquisition through data utilization.

The latest thinking on the development of IT solutions for social service sector is the concept of Knowledge-based Information Technology (KIT) solution. Such a solution: (1) provides a science-based conceptual framework (theory); (2) offers a comprehensive solution, ranging from data collection to data utilization; (3) embodies abstract knowledge and wisdom in a concrete and tangible technology; (4) functions as an information-management system, an evaluation/quality-control tool, and a knowledge base for decision-making; and (5) updates the knowledge base continuously while adapting to changing environments.

Involving researchers, software developers, and practitioners in the development process, each KIT solution creates a circular conversion process: Theoretical Knowledge is converted to Tangible IT Technology, which when used by field practitioners contributes to solving Real World Problems. The experience gained in dealing with these problems is then converted into Organized Data, which can be mined for Information for Decision-making. This information helps to produce Theoretical Knowledge that is even more accurate and insightful.

Xiaoyan Zhang, Ph.D.
President, KIT Solutions, Inc.
Pittsburgh, Pennsylvania

DESIGNATE A HIGHER AUTHORITY

I don't disagree with the proposed solutions, with the possible exception of the paired leadership. But even if I have staff from both the business side and IT with the requisite capabilities, I think two elements are missing that would contribute to the success of the project: visible, engaged and committed executive management and an independent project manager--probably contracted--both of whom are accountable.

If this is truly a critical system, with all the political and financial baggage indicated, I think a very senior executive must make the commitment to be an active participant on the steering committee as a visible indicator of top agency involvement. The diffusion of authority and responsibility evident at midlevel in a typical bureaucracy--particularly with shared leadership--will muddy accountability and make momentum and design clarity difficult to sustain over a long project.

Second, IT or operating line managers alike often lack the process skills--project discipline, external perspective and independence--to help keep the project on track and the people focused on the established goals and outcomes desired. Either as a direct report to the executive or as a contractor working as project manager or as a consultant to the team, this person can be of great help is separating realities from perceptions, derailing irrelevant side trips and avoiding turfish decisions.

Without clear authority, defined goals, solid process and top-level commitment, the only question is how badly the project will fail, not if it will fail.

John Lally
Chief Information Officer
Minnesota Department of Human Services

USE AN OPEN BIDDING PROCESS

I agree with most of Bob Behn's solution. I suggest the following ideas to go with his solution.

1. I agree. In addition, I would have an Executive Sponsor, either the Department Executive or someone on their senior staff who has the "power/authority" to resolve any conflict that may come up. This person must also be a champion of the project. This is the person ultimately and publicly responsible for the success of the project. The project manager should make monthly detail reports to the Executive Sponsor.

2. I believe only one person should be in charge and that person should be from the CSE group. It is their problem that is being solved. The IT people, and the other specialists, are resources to solve the CSE problem.

3. I agree. In addition, I would train the full team in project management (3 days). This could happen now or after step 6. I like after 6 better and I would include the contractor in the training.

4. I haven't tried this idea, however, it sounds good.

5. I agree absolutely. Legal, procurement, public relations, and any other required specialty, should be full participating members of the team from the start.

6. This assumes the work will be out-sourced, which I agree is the best method. I would follow the following steps.

Establish bidder qualifications, make a list of qualified bidders, develop an RFP in conjunctions with them, have a required public pre-bid conference, ask for sealed bids, require an oral presentation as part of the bid, give the team members a copy of all returned bids to examine and evaluate, have the bidders present to the team, have the team rank the bidders on about four criteria such as, company capabilities, history of performance in similar situations, availability of resources to take on this project, compatibility with team members, select the best bidder by a secret ballot.

Providing a ranking process and having each team member be a part of the selection will get "buy-in" from all the team members. After the results are known, make the rankings public to the team. (The team member should be told before the rankings that this step will happen).

Have the successful bidder return and meet with the team to work out the details of the contract (scope, budget, and time frame, dollars, etc.).

Do the project management training and start the project.

Bill Roselius
Consultant
Oklahoma Department of Transportation
Oklahoma City, Oklahoma

INCLUDE THE CUSTOMER

I do not disagree with other responses that I skimmed, but I would offer the following suggestions to ensure a successful team endeavor, without addressing some of the more technical aspects of the project.

Forming a project team is a good idea — but consider the following to increase the likelihood of success:

  • Select the right members. As suggested, include the program and IT folks, an attorney, management types, and others in the organization. But don’t forget other stakeholders, most prominently the customer, or an advocate. Remember that this is a child-support enforcement system. Who are the users of the system’s output? Local law enforcement? Social Service agency caseworkers? Ultimately it is the mothers/parents who depend on child support payments. Include the voice of the customer.

  • Get team clarity about their roles in the customer chain. Make sure the team understands the inverted pyramid. That is, the program folks are the customers of the IT folks, and they both serve customers outside the organization. It may amount to telling the IT people that they do not run the show.

  • Collectively develop a team mission that is clear on who benefits from their work. The resulting mission would help bring a common focus to the team and would avoid the cited problem of a previous project where “the program team’s tendency to expand the scope of the requirements and expectations frustrated the IT people.”

  • Build the team. These folks are in for the long haul. Make sure the team is balanced not only in terms of area of responsibility, but in team style as well. Seek a balance of temperaments. Use the MBTI (Meyers-Briggs Temperament Indicator) or a similar tool.

  • Get clear on team member responsibilities. If this project is important enough, make sure that team members are unencumbered by other responsibilities. If it means pulling folks off regular work for a year, so be it.

  • Study the Process: Don’t assume that the service processes are optimal: This project should not simply be about automating an existing system. The team ought to define customer needs and preferences in the design and then build a better process.

  • Employ an experienced team facilitator or project leader to keep the team on the straight and narrow and to manage the team process. Someone not invested in the outcome would be best.

  • Identify a team sponsor to seek out when guidance is needed. The sponsor could be an individual or an executive team. Check in regularly to avoid surprises or catastrophic course corrections.

    Pete Williams
    Project Manager, Innovation in Government
    Office of Governor Gray Davis
    Sacramento, California

    AVOIDING THE LOW-BID BLUES

    Bob Behn described "Six Ways to Success" to the secretary of the West Dakota Department of Social Services for the Child Support Enforcement System. Bob's points were right on the mark. I would like to elaborate a little on the last one, "Don't rely on low bid."

    There are several things you can do during the Request for Bids (RFB) process to ensure you don't have to accept the lowest bid from an organization you're sure can't deliver a quality system.

    1. Explicitly state in the RFB that cost is only one consideration of award. Explicitly include other criteria such as references, prior system development comparable to current project, ability to deliver in the time frame desired, consistency with existing architectural platform, etc.

    2. Explicitly state in the RFB that incomplete bids will not be considered. Therefore, if the low bid is incomplete in any way, it can be thrown out.

    3. Use five-year costs for the cost of the project, not just development costs. It is suprising how many systems' development costs are low, but are not low when considering maintenance and support over five years.

    4. Require that the bidder have a proven success record in the area that is being bid. This eliminates sharp new organizations, but requiring a proven success record is the "safest" strategy.

    5. Ensure the RFB clearly state the business requirements of the desired system. If bidders can't deliver all of the functionality, they can be declared unresponsive. However, be careful that you don't have requirements that are impossible or that will be prohibitively expensive. A way around this is to include mandatory requirements and optional requirements. Make sure that costs are itemized so the state can pick and choose which of the optional requirements are selected and put in the contract with the bidder.

    By doing all of the above (and I'm sure others will have more tricks), this will allow you to award the bid to the lowest "responsive" bidder, which is rarely the lowest bid.

    Bob Wilson
    Applications Manager
    Mecklenburg County Department of Social Services
    Charlotte, North Carolina

    Agree or disagree? If you think you have a better way to deal with this month's Manager's Choice dilemma or would like to expand on the approaches presented here, share your thoughts with other readers. Send your solution to mailbox@governing.com. Please include your name, location, government or business title or job description, and a daytime phone number (for verification purposes).

    Copyright © 2000, Congressional Quarterly, Inc. Reproduction in any form without the written permission of the publisher is prohibited. Governing, City & State and Governing.com are trademarks of Congressional Quarterly, Inc.