Some of us enjoyed success, because the right elements were in place on the right project at the right time, albeit in the absence of a proven project management methodology. Some of us enjoyed success in spite of government bureaucracy, and others in spite of limited or no technical expertise. Christine Rozek, project director for an information system for the License, Inspection and Environmental Protection Office in St. Paul, Minn., observed, "It can be an overwhelming responsibility. In the absence of technical knowledge and prior project management experience, there are no tools to support qualitative judgment and decision making as one deals with the vendor community."
SETTING A STANDARD
In August 1995, Government Technology magazine reported on the remarkable success of the Oklahoma State Department of Human Services' SACWIS project. It enjoyed unparalleled success in meeting federal timelines for the statewide implementation of the child welfare information management system known as KIDS. Taken at a high level, the project's overall management approach could create a template for other government projects. The key factors to KIDS' success were identified and reported on after the project was completed.
There were several critical factors in KIDS' success that could have led to failure -- issues that have been blamed for contributing to the failure of other projects:
* The project director's position in the reporting hierarchy;
* The lack of prior experience in managing large IS projects;
* Externally enforced time frames for completion;
* A functional rather than conceptual transfer of the base system;
* Use of new technologies;
* Use of new hardware/software architectures; and
* Significant change management issues.
These were significant negative issues to overcome. They had little impact on the KIDS project, however, because there were other elements in place of such importance that their influence overshadowed the negatives.
CAN THIS BE REPLICATED?
Of course! Other government agencies can point to success stories for many of the reasons identified in the Oklahoma project. In the same environment, however, other projects might have failed or been marginally successful. This means that, without a formal methodology to guide the project management process, the probability of success is still happenstance. It means there is a great risk that success is dependent upon coincidental factors coming together at the right time and for the right reasons. It might also mean that success is dependent upon a very capricious factor: the personality of the individuals assigned to the job at the time.
Larry Harmon, the Oklahoma Department of Human Services' associate director for administration, was a member of the KIDS Steering Committee. When asked to describe the characteristics of a good project manager, he stated, "Most leaders don't make good project managers, but a good project manager has to be a strong leader ... . A good project manager doesn't mind doing anything to get the job done."
Tom Llewellyn, the former project director for a public assistance system in West Virginia, said, "When we had a problem, it didn't matter who or what caused it. We set about determining our options for fixing the problem and establishing a process to assure that we wouldn't repeat it."
Today, that is exactly how a successful project is realized. We in the government marketplace, to the advantage of all parties, need to formalize and institutionalize an effective project management methodology for government IS project managers. The methodology should cover the major issues of designating leadership authority and defining roles, spelling out the characteristics of a project manager, defining how to prepare project management personnel, and laying in place methods for managing, controlling and correcting projects.
WHY AREN'T METHODOLOGIES IN PLACE?
Since large-scale technology development projects have been so rare, the public sector has not needed to develop in-house skill sets. A single state department, like a DMV, might develop one or two of these in 10 years. In the human services, three major systems efforts have dominated both IS and operations attention over the last 20 years, perhaps giving some states the opportunity to replace the earliest of these systems. This rather rare need for specialized skill sets has driven states to seek the services of third-party vendors to assist with planning and oversight. While this "as needed" support adds a level of project management resources and knowledge that would not have been accessible within the state or local environment, these vendors have not consistently guided agencies toward success.
The problems may occur because a new, large-scale project is typically managed as though it is the first. It is unusual for a government IS project manager, groomed by the risks and hazards of a prior project -- successful or not -- to be reused within the same government environment, thereby enabling him/her to build and apply skills and lessons learned from project to project. Seldom does an agency conscientiously document the lessons learned into a "dos and don'ts" template to guide future project management efforts, in spite of budgets of tens of millions of dollars -- and hundreds of millions of dollars in some cases.
By comparison, in disciplines outside of this environment -- construction, transportation, engineering, communications -- project management is a science. Project managers are groomed through apprenticeship, incremental levels of learning and responsibility. Under the protective tutelage of experienced project managers, analyst-level personnel are afforded a safety net as they first take on one narrow aspect of a project development effort, then another. These new project managers are armed with methodologies and tools to assure that they can effectively manage scope, timelines, resources, budgets and outcomes. Project managers in these sectors who have demonstrated success will typically be identified as a valuable, reusable resource.
Over the past 10-15 years, our government IS projects have funded the training and skill-building of what should now be a cadre of state and local project managers -- managers who have earned reputations for the delivery of successful projects. Unfortunately, private-sector firms, recognizing the value of this prequalified resource, have been snatching up these individuals as government completes their on-the-job grooming.
This competition for resources is occurring as the use of advanced technologies and the need for information management systems is becoming pervasive in our government business centers. More and more government projects, coming under the heading of "large scale," occur more frequently as we seek to integrate services, move closer to a paperless environment and enterprise-wide operational models, and extend intranet and Internet services to colleagues and clients. Vendors have set a remarkable value on this limited resource -- individuals who know both government operations and now know information system project management.
Without the ability to retain experienced project managers, and in the absence of project management methodologies, government is risking even greater failures as the level of complexity increases in operational relationships and the need for connectivity increases. The most well-intentioned development vendor, and the most skilled third-party oversight vendor, can't fill the chasm of inexperience and lack of preparedness on the part of government.
There are lessons learned from prior successes and failures alike, which offer an opportunity to shape a template for successful project management. This is a correct step toward developing a project management methodology focused on achieving continuing success.
POTENTIAL FAILURES CAN BE IDENTIFIED EARLY
To effectively manage a project, it is the responsibility of the joint leadership/project management team to ensure that expectations are clearly understood by all. In discussions with vendors and government personnel alike about the issues seen in problem projects, they are clearly evident almost from the beginning. In projects that fail or enjoy only marginal success, the following are indicative of a rocky road to implementation:
* The administrative/organizational leadership lacks time or fails to fully understand the risks and potential benefits of a project.
* The administration has a disconnected or infrequent leadership relationship to the project.
* The project steering team fails to include key financial/budgetary managers.
* Timelines, resources and budgets do not match the business need.
* Political visibility generates errors in judgment -- i.e., the wrong decisions are made for the wrong reasons.
* The RFP tends toward specification of technology solutions rather than measurable business and functional results.
* The organization spends more time in debate on technology decisions than it does on business/functional decisions.
* The RFP fails to clearly state the business case for vendors.
* The RFP fails to elicit proposals or vendor quality that match expectations.
* The model contract provisions fail to support expeditious negotiations.
* Cost proposals appear to be out of sync with functionality expectations.
* Cost proposals are sufficiently disparate to force selection of the lowest bid without the probability of success being factored into the cost.
* Identification and dedication of needed resources is an on-going problem.
* Project sponsors disappear in mid-project.
* In mid-design, it becomes clear that there are differing opinions about the project's business purpose.
* There are insufficient government-side resources to review the first deliverable.
* There are disagreements about whether the first functional deliverable meets the users' requirements.
* Deliverables fail to be completed on a timely basis, irrespective of which party is responsible for the delay.
* The government project leadership expresses intent to "hold the vendor's feet to the fire."
Failure by the administrative leadership and the project manager to establish expectations and manage those expectations at the government and vendor level sets the stage for problems to propagate. These problems later may become a checklist for why a project had problems and thus failed.
The issue then appears to be three-fold:
* Administrative leadership,
*Projectmanagement experience, and
*Projectmanagement methodology.
WHEN DOES PROJECT MANAGEMENT BEGIN?
Projectmanagement doesn't begin when a contract is signed. Successful project management begins when the organization determines there is a business need. It begins with the business case that says why a new solution -- business support approach, not technology -- is needed, by when it is needed, what outcome must be realized, and at what cost. The business case also establishes the consequences of failing. This simple exercise establishes the framework for successful project management. The project management plan flows from the business case.
Replacement construction of the Los Angeles freeway section destroyed in the earthquake of 1994 is an excellent comparison to use when measuring the strengths and weaknesses of many technology projects. Both the project and the outcome were considered "mission-critical." The project was completed in record time. While there were innovative procurement methods also employed in this effort, the key factors were clear need, leadership and expectation.
The Oklahoma KIDS project exhibited many of the same factors. A sense of urgency and understanding the consequences of failing to act were important drivers in the business case. Two disparate disciplines, two disparate business cases, both shared the same elements that led to unparalleled success.
Key to the business case, and subsequently to the project management approach, is an early risk analysis. The administrative leadership, the project manager, the project management team and the vendor must be in common agreement as to the consequences if the project does not meet expectations, its timeline and its budget. If there are no consequences, one must question the business case and the rationale for the investment.
In KIDS:
* The project sponsor set the expectation for the organization and the vendor as to the deadline and budget for successful implementation.
* An informal, but personal, contract for performance was developed between the project sponsor and a single individual, establishing that the individual was willing to accept responsibility/accountability for meeting the business goals of the state within the time frame established.
* The individual assumed a very strong leadership role. Achieving the outcome expected within the time frame required would be the project manager's personal measure of success.
* The project manager was a highly intuitive government manager who knew how to plan and how to work the plan to accomplish a defined objective.
* The project manager assumed personal responsibility and accountability for the state's success; conversely, of course, the individual assumed the same level of accountability for anything less than success.
* The project kept sight of its business goals and was not deterred or sidetracked by technology debates.
* The statewide project team ran a "tight ship," meaning the project manager and project team had a readiness to make the hundreds of daily decisions required to stay on schedule and avoid the consequences of marginal success or failure.
* The project manager and the project team had a clear understanding of the value of such readiness and a clear understanding of the impact of failing to participate in making the right decisions.
* The vendor team was assured that it could rely on state project management leadership, direction and state project team support.
* Administrative expectations were made clear to the vendor team from the outset. The vendor was made a partner in successfully meeting the business objective within the time frame required at the budget expected.
BUILD A TEMPLATE
In the short term, government agencies can create their own IS project management template using the elements discussed herein. Those factors that have demonstrated success as well as the factors that demonstrate potential for marginal success or failure can be developed into a checklist to evaluate, analyze and make corrections in current and future IS projects. The size, scale and visibility of today's mission-critical systems projects, combined with the public's expectation that they will see government services soon demonstrate greater efficiency and effectiveness, demand no less. From a taxpayer's perspective, the amount of risk and the long-term impact of projects that enjoy only marginal success or outright failure can no longer be ignored.
Rita Kidd provides commentary and analysis on human services and other large-scale automation efforts in state and local government, and she is the former deputy director of Merced County, Calif.'s Human Services Agency. She is now a government reengineering consultant residing in Cathey's Valley, Calif
Dicy Perry was the project director for the KIDS project in Oklahoma. After 20 years in state government, she now consults about project management issues.
May Table of Contents
