Case studies of successful government projects
In a recent survey conducted by the Project Management Institute (PMI) Government Specific Interest Group (GovSIG), 52% of respondents expressed interest in learning more about successful government projects. To this end, this paper outlines the theoretical background that supports the interactive session “Case Studies of Successful Government Projects”, which will take place on September 22, 2003 at the PMI Global Congress 2003-North America.
In this session, participants will be provided with detailed information about real-life situations from public sector projects. All related circumstances, issues, and actions of persons involved will be carefully described. Participants will then study and analyze the situation as presented. This paper describes the methodology used to conduct these case study interviews with project managers and project teams in public sector organizations that successfully completed complex information technology (IT) projects.
To add a broader foundation to the interview approach used to develop the case studies, this paper also provides a larger context of trends in successful IT projects. This includes defining “success”, identifying the unique constraints faced by public sector projects, evaluating the reasons projects fail, and discussing project management tools and standards in use today. The final section of this paper provides industry recommendations and lessons learned for reaching successful project completion. Actual case studies will be provided to participants at the PMI Global Congress.
Case Study Methodology
During the case study interviews, we identified situations that required the project team to resolve difficult issues that may have put project success in jeopardy, e.g., issues relating to the project budget, schedule, resources (either internal or contractor), quality, and scope. We emphasized challenges that make public sector projects different from other industries, e.g., limited funding structures, distinct “silos” within the organization, interaction between various elected and appointed officials, procurement requirements, etc. In summary, the goal of this presentation is to present a detailed description of each specific situation with enough detail to draw participants into a complex discussion. These are not situations with a single, obvious “right” answer, rather real-life dilemmas that separate the experienced government project manager from the novice.
Interview participants responded to the following Case Study Questionnaire:
1. Please describe your project, including the objective, estimated size, scope, cost, participants, vendor, etc.
2. How was success defined and evaluated? Was the project considered “successful”?
3. What were the critical components and attributes for successful IT project leadership (e.g., specific resources, team structure, etc.)?
4. Were there significant planning activities? How did the early planning phase of a project set the ultimate success in motion?
5. What was the governance structure (e.g., steering committee membership, review teams, QA, etc.)?
6. What were the implementation planning (e.g. design and specifications), procurement, and negotiation strategies? How did they contribute to the success of the project?
7. Were there any specific resource assignment and collaboration tools (e.g. MS Project, issue tracking, etc.)?
8. How were budget, schedule and scope controlled?
9. What were the key risk factors? What mitigation strategies did you develop to address these?
10. Did the fact that this was a public sector project add any specific constraints or risks? Any specific advantages or benefits?
11. Please describe one or two specific situations where the project team faced major challenges to project success. What where the circumstances, issues and actions of persons involved? What would you do differently in hindsight?
12. What lessons learned would you recommend for future project managers?
13. May I mention your specific department and project in this case study? May I use your name in the list of interviewees?
Interview participants included project managers, technical leads, user support managers, project sponsors, and vendors. All have substantial experience working on government projects and direct experience working on the project case study. A partial list of participants is included in the References section of this paper. Please note that some participants did not choose to include their name on the list.
In addition to the interviews, the case studies directly draw upon my own experience working as a management consultant on some portion of each project (e.g., developing user requirements, negotiating the vendor contract, conducting a risk analysis, etc.). Also, I have worked closely with at least one member of each project team at some point during the past 6 years. This allowed me to begin discussions with a frank understanding of the players involved and the project objectives. Finally, with more than nine years of experience working in the public sector on IT implementations, including projects with municipalities, counties, and state and federal agencies, I have a very clear understanding of the risks, constraints, and measures of success used today.
Definitions of Successful Government Projects
What is a “successful project”?
The definition of project management is “to meet or exceed stakeholder needs and expectations from a project”, which involves balancing the competing demands among scope, time, cost, and quality (PMBOK®®, 1996, p.6).
Unique Constraints in Government
As all seasoned project managers know, “meeting stakeholder needs and expectations” is much more difficult than it may seem. The greatest risk to public sector projects is that when scope, time, and cost are considered fixed, it is quality that must suffer.
In my case study interviews, project managers nearly always received direction from their executive sponsors to “make it happen” with a fixed project budget, limited number of partially dedicated resources, immovable deadlines, and supposedly final scope (that of course changed significantly during implementation). While similar constraints may be found in the private sector, the mechanism for obtaining approval for additional budget and resources is much more cumbersome.
Michael D. Nevin, a San Mateo County CA Supervisor, stated in a recent interview that one of the biggest misconceptions about county government “is the idea that it has more financial flexibility that it really does. With limited authority over revenue raising and budget allocation, county governments are constrained by regulations and guidelines that are controlled by entities at levels of government outside of the county” (Nevin 2003).
In fact, on government projects at every level of government, both budget authority and scope control are delegated outside of the department implementing the system (Valdez 2003). Managing unfunded mandates can be a significant task for the project manager.
Harry Ovitt, a San Luis Obispo CA County Supervisor states that one of the biggest misconceptions about counties is that they have all the funding necessary to carry out their federal and state mandates (Ovitt 2003). Furthermore, with the emphasis on electronic government and enhanced security, the effect on technology projects is very great. Managing project scope becomes one of the most significant issues for any project.
In 1995, Congress passed the Unfunded Mandate Reform Act (PL104-4) that requires the Congressional Budget Office to report on any proposed bill that would impose at least a $50 million annual cost on state and local governments. Since 1995, however, the Congressional Budget Office has only found 42 items out of a total of 4,097 that exceeded the $50 million threshold. The cumulative cost of the remaining unfunded mandates is significant (Kettl 2003).
To contain costs, some enterprises are moving away from a “budget entitlement” mentality for ongoing programs. Instead of automatically giving them the greenlight to continue, they are subjecting all IT initiatives to a scrupulous evaluation and approval process that looks at cost containment and return on investment. This forces IT departments to look closely at the projects they decide to pursue (Langer 2003).
Why do projects fail?
Many factors cause IT projects to fail. Key problems that can prevent a project from being successfully completed included the following (Coplan & Gainer 2003):
- Inadequately defined project requirements.
- Lack of risk and quality management plans.
- Negotiating team with no experience with IT acquisition and implementation contracts.
- Vendor staff with inadequate training or implementation experience with the system being provided.
- Pressure to convert, implement and accept the new system too quickly.
- Failure to divide the project plan into specific measurable deliverables, one key way of controlling (i.e., monitoring, detecting and preventing) problems that could prohibit the project from achieving its intended objectives.
- Failure of the vendor to fulfill the many requirements defined in the RFP (e.g., delivery of required software functionality).
- Inadequate acceptance test period to determine whether many of the application functions operated properly.
Failed projects can be prevented. When the project management team adheres to project management standards, has cohesive requirements against which to validate the vendor's products and services, and has comprehensive and workable standards for controlling and measuring compliance, the possibility that the vendor can “work around” or “misunderstand” the specifications will be greatly reduced.
Project Management Tools and Standards
One example of a comprehensive Project Management Information System, FOUR is found at the COPLAN AND COMPANY web site http://www.coplan.com/ under Tools, Click for Demo. This includes a requirements management tool, procurement tool, issue tracking database, and document management system.
Interview participants noted many tools they designed to manage project scope, risk, quality, and schedule, including databases, standard forms, templates, business-entity diagrams, state-transition diagrams, process models, hierarchy charts, etc. Using standard tools improves the general management of the project (MacRae 2001).
In addition to the standards provided by PMI®, some agencies are beginning to use supporting standards such as the Software Project Management Plan from the IEEE Computer Society® (IEEE 1998) or the ISO Quality standards such as ISO 9001 (ISO 2002). These publications provide guidelines and lessons learned to the project team. The core project documents that support the PMI® and IEEE® standards include the following:
- Project Overview – An overview of the purpose, scope, and objectives of the project, the project assumptions and constraints, a list of project deliverables, and a summary of the project schedule and budget.
- Project Organization – The communications and reporting relationships to organizational entities external to the project, describing the project's internal organization structure, and a definition of roles and responsibilities for the project.
- Managerial Process Plans – The project management processes for the project. This includes the start-up plan, risk management plan, work plan, control plan, issue resolution process, and closeout plan.
- Technical Process Plans – The development process model, the technical methods, tools, and techniques to be used to develop the various work products, plans for establishing and maintaining the project infrastructure, and the product acceptance plan.
- Supporting Process Plans – The supporting processes that span the duration of the software project. These plans include configuration management, verification and validation, software documentation, quality assurance, testing, reviews and audits, and subcontractor management. In particular, the roles, responsibilities, authorities, schedule, budgets, resource requirements, risk factors, and work products for each supporting process are specified.
- Additional Plans – Additional plans required to satisfy product requirements and contractual terms with the vendor. Additional plans include: a Security Plan for the safety, privacy, and security requirements; an Installation Plan that includes special facilities or equipment; a System Design Report Plan (i.e., a description of customizations to Commercial-Off-The-Shelf software); a User Training Plan, an Integration Plan; a Data Conversion Plan; a System Transition Plan; a Product Maintenance Plan with the vendor; and a product Support Plan with the IT staff, if any.
- Annexes and Indexes – Definitions, indexes, and reference documents such as the Project Team Directory, Plan Index, Lists of Tables and Figures, Definition of Terms, Reference Documents, and Change History.
Recently, the Center for Digital Government honored 12 New York government agencies for their outstanding information technology leadership and innovations based on criteria such as collaboration between agencies, the innovative use of technology, and the improvement of services to citizens or state employees (Gamble-Risley 2003, 4). The winners responded to a standard set of questions regarding the challenges and solutions they faced. In summary, the top lessons identified by participants in this report include the following:
- 67% said it is important to communicate via e-mail, telephone calls and especially face-to-face meetings. For major projects, team leaders held meetings “without fail” every day. Staff cited this as the number one reason that the project was well done and completed on time to avoid penalties. Meetings also paved the way to better coordinate technical requirements. Meetings were cited 33% of the time as playing a critical role in project management.
- 42% suggested that a positive approach and attitude about collaboration and teamwork played a central role in the success of their projects.
- 25% said it was important to be flexible and prepared to change management methodologies.
- 25% also stated that approaching a project incrementally or through a pilot helped create a successful final project.
In addition to strategies that take place during implementation, the planning and acquisition phases of a project set the foundation for success. During the planning phase, it is important to focus on essential processes needed to support the system (Valdez 2003)
The contract should be built with both the flexibility to allow measured changes to the approach used to meet requirements, but provide the necessary controls to assure that projects are successfully implemented. Examples of contract terms include the following (Coplan & Gainer 2003):
- Specifications – Detailed specifications should be completed before implementation begins. The vendor should understand that it will not be paid if the delivered system does not comply with the specifications.
- Payment Schedule – Payments to the vendor should be tied to project completion milestones. A substantial portion of the total purchase price should be held back until final acceptance criteria are met.
- Performance Criteria – Acceptance criteria should include throughput measurements. The system should perform so that screens are refreshed and data are transmitted within specified time periods.
- Vendor Personnel – The contract should require the vendor to assign an adequate number of qualified personnel to complete the project successfully, on time, within budget, and with required functionality.
- Post-Implementation Support – The contract should require the vendor to correct post-implementation design and programming defects within specified time periods. Tiered response levels should require prompt attention (typically within an hour) to critical defects while allowing longer time periods to correct less critical defects.
And remember, in today's market environment, risks to project stability do not only come from the public sector, but also from the private sector partners. When picking a company to work with on a major IT project there are four major areas to review, product, people, processes, and financials (Hagland 2003). Most projects focus their review on the product. It is important to include the other areas, financial stability, market strategy, and the senior management team.
In summary, there are good examples of successful project management. Both new and experienced project managers can learn from case studies of successful government projects. They key is managing scope, schedule, and budget without compromising the overall quality of the project.
2003 Digital Counties Survey. (2003) Retrieved August 14, 2003 from The Center for Digital Government web site: http://www.centerdigitalgov.com/center/03digitalcounties.php.
Coplan, Scott & Gainer, Randy (2003, Draft August 14,), Liability of Hospitals and Their Officials When Technology Projects Fail, forthcoming in Bureau of National Affairs Health Care Policy Report.
Demonstration of Project Management Information System FOUR, Retrieved July 31, 2003 from COPLAN AND COMPANY web site http://www.coplan.com/ under Tools, Click for Demo.
Gamble-Risley, Michelle, (2003, July). New Report Cites Best IT Projects, Leaders in N.Y. Government [Electronic version]. Retrieved August 14, 2003 from The Center for Digital Government web site: http://www.centerdigitalgov.com/center/media/best-of-ny-third-draft.pdf.
Hagland, Mark (2003, June) Choosing a Vendor, Healthcare Informatics, Vol. 20 (6), 87-88.
Hinshaw, Chris, (Interviewed 5/22/02) Assistant Manager, Wireless Services Unit, Communications Division of the San Diego County Sheriff's Department (formerly Regional Communications Service Project), email@example.com, (858) 694-3953.
ISO Central Secretariat. (2002) ISO 9001 for Small Businesses, Geneve, Switzerland: International Organization for Standardization.
Kettl, Donald F. (2003, August) Mandates Forever, Governing, 16, (11), 12.
Langer, Jennifer (2003, June) Prioritizing IT Projects, Healthcare Informatics 20 (6), 87-88.
MacRae, K. (2001, October) The Agency IT Manager, Government, Business & Technology Expo (GBET), Los Angeles, California, USA.
MacRae, K. (2001, October) HR Issues in Managing IT Professionals, Government, Business & Technology Expo (GBET), Los Angeles, California, USA.
MacRae, K. (2001, October) Project Management Methodologies and Tools: Planning, Definition, Acquisition, Implementation, Government, Business & Technology Expo (GBET), Los Angeles, California, USA.
Munro, Curt, (Interviewed 5/22/02) Manager, Wireless Services Unit, Communications Division of the San Diego County Sheriff's Department (formerly Regional Communications Service Project), firstname.lastname@example.org, (858) 694-3903.
Nevin, Michael D. & Ovitt, Harry (2003, March/April) In Their Own Words – Learn About California County Supervisors from a Close-up, Personal Point of View, CA County Journal of the California State Association of Counties, 19,(2), 8-10.
Project Management Institute. (2000) A guide to the project management body of knowledge (PMBOK®) (2000 ed.). Newtown Square, PA: Project Management Institute.
Project Management Institute. (1996) A guide to the project management body of knowledge (PMBOK®) (1996 ed.). Newtown Square, PA: Project Management Institute.
Software Engineering Standards Committee of the IEEE Computer Society. (1998) IEEE Standard for Software Project Management Plans (1058-1998). New York, NY: The Institute of Electrical and Electronics Engineers, Inc.
PL104-4 (1995) Public Law 104-4. Retrieved from http://thomas.loc.gov
Riggin, Stan, (Interviewed 9/17/02) Accounting and Fiscal Control Director, Auditor and Controller, County of San Diego (retired).
Valdez, Joseph (Interviewed 8/15/03) Project Manager for the Administrative and Financial System Redesign (AFSR), Branch Chief for the Project and Business Analysis Branch, Administration Division, Department of Motor Vehicles, State of California, email@example.com, (916) 657-6340.
Proceedings of PMI® Global Congress 2003 – North America
Baltimore, Maryland, USA ● 20-23 September 2003