It's not the technology, stupid — lessons rise from the ashes of Phoenix

Yogi Schulz has more than 40 years of information technology experience in various industries; his specialties include IT strategy, web strategy and systems project management. His forthcoming book, co-authored by Jocelyn Schulz Lapointe, is “A Project Sponsor’s Guide for Projects: Managing Risk and Improving Performance.”

The long-running story of the ailing Phoenix payment system is a critical case study for executives contemplating an overhaul of applications in the portfolio of systems supporting their organizations.

Phoenix started with good intentions to update the payroll system for Canadian federal civil servants 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.

Often organizations have only a superficial understanding of the complexities an information technology project will encounter at the beginning when projects are green-lighted. This lack of understanding leads to underfunding and under-resourcing projects.

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; and
• 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; and 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 a benefits overestimate, and a cost underestimate in project charters.

The Phoenix project was no exception. The business case included the following:

• significant reduction in payroll staff as well as the number of employees required to operate the system;
• more modern information technology, to reduce software maintenance costs, and better support business requirements; and
• 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, which have numbers, and intangible benefits, which do not have numbers. Numeric estimates for intangible benefits, therefore, should not be accepted.

Ask whether you would still find the business case appealing if the estimated costs doubled. Base your approval — or disapproval — on your answer.

Clear decision-making authority needed

In many organizations, it remains unclear who will make which of the many project decisions that will need to be made.

Governments place significant emphasis on consensus decision-making. In governments and many larger organizations, it is 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; and
• 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 of 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 were paid inaccurately for many years because of the high complexity of the provisions in union and bargaining agreements. These complex provisions were interpreted differently by various payroll groups across Canada.

Moreover, the old payroll system could not support the high complexity of the payment agreements. This reality caused 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 led civil servants to launch a class action lawsuit. The Government of Canada subsequently signed a damages agreement.

While most organizations will not face lawsuits, it is worth ensuring all stakeholders regard simplified business processes — not more complexity — as a guiding project principle.  Similarly, another guiding principle should be the revision of business processes to the meet needs of software packages — not changing software packages to conform with existing business processes.

Successful implementation is 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 problems consumed more computing resources than planned.

The better way to proceed is to:

• avoid emerging information technology that has not yet been tested and proven in a real-world environment;
• ensure the project focuses on business processes and people-change management issues;
• veto the desires of techies that want to play with the latest technology; and
• accept the computing infrastructure recommendations of the experts.

Organizations, in overhauling the systems that support their business, must do detailed planning and strategizing upfront, not simply allocate financial resources without considering the complexity of factors involved in implementing new systems.

As the Phoenix case shows, good intentions are not enough.

R$