Detailed planning and analysis could have greatly diminished the likelihood of the Phoenix payroll debacle
The long-running story of the ailing Phoenix payment system is a critical case study for CIOs contemplating overhauling complex applications in the portfolio of systems supporting their organization. Phoenix started with good intentions to update the Canadian federal civil servants’ HR/payroll system and save operating costs.
Here’s a synopsis of the circumstances that led to the fiasco. These events occur too often in most organizations and lead to similar devastating debacles.
How complicated can this be?
Often, organizations have only a superficial understanding of the complexities an information technology project will encounter at the beginning when projects are green-lit. This lack of knowledge leads to underfunding and under-resourcing projects.
 |
| Related Stories |
| Want to be an effective project sponsor?
|
| Is your IT project about to crash and burn?
|
| How to determine if your project will enjoy success, or failure
|
Projects typically encounter issues rarely listed in the project charter document that describes the basis for project approval. The surprise issues include:
- Unexpected business process changes.
- Much more effort for people change management.
- Difficulties with vendor management.
- Significant gaps in data quality.
- Unanticipated complexity in integrating the new system with other systems in the portfolio.
The Phoenix project appears to have been surprised by the appearance of all these issues.
The better way to proceed is to:
- Allocate more effort to detailed planning.
- Consider a prototype or test rollout before committing to implementing the new system.
- Stage the rollout of the new system by department or region.
- Always avoid a single organization-wide rollout.
The business case proved to be a mirage
In many organizations, information technology projects require a significant or astounding business case to achieve approval. This expectation leads to an overestimation of benefits and an underestimation of costs in project charters.
The Phoenix project was no exception. The business case included the following:
- Significant reduction in HR/payroll staff required to operate the system.
- More modern information technology to reduce software maintenance costs and better support HR/payroll business requirements.
- Improved timeliness and accuracy in paying civil servants.
The Phoenix project achieved none of these business case elements. Costs increased, and the timeliness and accuracy of civil servant pay decreased.
The better way to proceed is to:
- Split the business case into tangible benefits with estimated amounts and intangible benefits without amounts. Don’t accept numeric estimates for intangible benefits.
- Ask yourself if you’d still find the business case appealing if the estimated costs double. Base your approval – or disapproval – on your answer.
- Recognize that some projects must be undertaken regardless of the business case or risk. Examples include rationalizing the application portfolio after a merger or responding to a new regulatory requirement.
Who is making decisions?
In many organizations, it’s unclear who will make which of the many project decisions that must be made. Governments place considerable emphasis on consensus decision-making. In governments and many larger organizations, it’s considered prudent for middle management not to be identified with significant decisions, especially when they can be assessed as wrong later.
Drawn-out decision-making and ducking decisions added billions of dollars to the cost of the Phoenix project.
The better way to proceed is to:
- Appoint a project sponsor with genuine authority.
- Appoint a steering committee of business leaders to support the project sponsor.
- Appoint a project manager with sufficient experience.
- Resource the project team adequately with business and information technology staff.
- Explicitly agree to support these individuals as an executive team.
Business complexity results in errors
In many organizations, senior management is not aware of the operational complexity of their businesses. As a result, they are highly skeptical about seemingly high costs, long estimated elapsed time and excessive proposed resource consumption of project proposals. Knowing this phenomenon, middle management tends to submit highly optimistic project plans and sometimes bludgeons the IT department to accept unrealistic estimates.
After approval, the Phoenix project discovered that many federal employees had been paid inaccurately for many years because:
- Of the high complexity of the provisions in various union and bargaining agreements. Different HR/payroll groups across Canada interpreted these complex provisions differently.
- The old HR/payroll system could not support the high complexity of the payment agreements. This reality caused HR/payroll groups across Canada to make various simplifying assumptions to ensure civil servants were paid at least some amount.
The resulting pay anomalies and inequities have caused civil servants to launch a class action lawsuit. The federal government subsequently signed a damages agreement.
While most organizations won’t face lawsuits, the better way to proceed is to ensure all stakeholders understand that the guiding project principles include:
- Simplifying business processes. It’s not adding more complexity to business processes.
- Revising business processes to those expected by software packages. It’s not changing software packages to conform to existing business processes.
- Recognizing that projects cannot solve all problems and that some scope must be deferred to start benefits sooner.
It’s rarely about the technology
Too many organizations view information technology projects as technology projects that the IT department can handle with little or no departmental or executive involvement. This misunderstanding leads to technically superior systems with poor support of the business requirements and inadequate data.
The Phoenix system encountered performance issues as the number of staff hired to fix a mountain of data issues consumed more computing resources than planned.
The better way to proceed is to:
- Avoid emerging information technology that hasn’t yet been tested and proven in a real-world implementation.
- Ensure the project focuses on business processes and people change management issues.
- Veto the desires of techies who want to play with the latest technology.
- Accept the computing infrastructure recommendations of the experts.
The lesson from the Phoenix project is that detailed planning and analyzing the complexity of factors significantly reduce risk when overhauling aging systems. Despite their name, information technology projects are usually about business transformation. As such, these projects require continuing management guidance. Good intentions are not enough.
Yogi Schulz has over 40 years of information technology experience in various industries. Yogi works extensively in the petroleum industry. He manages projects that arise from changes in business requirements, the need to leverage technology opportunities, and mergers. His specialties include IT strategy, web strategy and project management.
For interview requests, click here.
The opinions expressed by our columnists and contributors are theirs alone and do not inherently or expressly reflect the views of our publication.
© Troy Media
Troy Media is an editorial content provider to media outlets and its own hosted community news outlets across Canada.
