Redwoods credit: PBlackstaffe
This article was first published as a LinkedIn post; March 19, 2017
Update November 14, 2011 – Estimated 3.5 Billion dollars over the next 5 years to fix the Phoenix pay system.
update April 5, 2017 – Link: (Executives in department overseeing Phoenix pay system took home $4.8M in performance pay. It would be my suggestion that a full review of how projects are rolled out, from supplier evaluation, project management practices, change management, sustainability, and project governance are performed at all levels. Are there ‘best practices’ being performed?)
Maclean’s Magazine wrote an article in January about the Canadian Government Phoenix Pay System that has been plagued with issues, exceptions and poor results. The impacted numbers are mentioned in the article, a remarkable 82,000 payroll cases brought forward last summer with approximately 8000 remaining cases as of this January. Bear with me as I break down my thoughts on a section of the article about the project, and yes, it does relate to change management because I believe change management has a bigger role to play in projects.
A quote in that article caught my eye and gave me pause…
“In projects like this, especially with an organization like ours, when you have the equivalent of 100 companies implementing a system … there’s going to be … multiple points of failure,” said Marie Lemay
The quote left me uncomfortable for two reasons:
- it seemed to justify an expectation of multiple points of failure
- with 100 companies implementing, I wonder about fragmented deliverables and project stream silos.
Multiple Points of Failure
In large, complex and technology dense environments, collaboration is a key element to understanding the impacts of a technical roll-out. I don’t have the inside scoop on why 100 companies were integrating or what went wrong with the project, but I can surmise a few points.
First, let me note that if this implementation was a critical infrastructure with human safety at its core, the due diligence would be such that NO point of failure would be acceptable, period.
With large impact and complexity, a person in charge must have the courage to ‘own’ when a project is under-resourced, too fragmented, or the impact has not been fully tested or analyzed. That courage has to come from someone who is more concerned about final results and quality than budget, scope, and schedule (even if their role is on the line). With something that big, RESULTS matter. Budget, scope, and schedule become minuscule when, at the support end of the project, costs to fix the system rise astronomically. This project reached a critical failure for poorly managing a project to sustainability (likely in multiple areas). Add to that the PR nightmare and the pain it has caused hard-working employees, the realization is that technology is never about technology, but rather, the use and impact it has on people. In something this far reaching, expecting points of failure should never be an expectation! Mitigating risks should be.
Fragmented Deliverables – ‘it’s not your scope’
Anytime you have multiple streams of development occurring on a large, complex project, there is a great deal of work to be done to ensure collaboration. I won’t say it is easy, but I will say it is necessary. Whenever project or development teams on a large project are divided into separate streams, and they do not have a history of on-going collaboration, you increase the risk for points of failure. But to expect it rather than pull together work-stream fragmentation is a recipe for disaster. In the case of 100 companies with separate scope and deliverables, this fragmentation needed to be managed very carefully and dollars spent on coordination.
Collaboration efforts are important for identifying gaps. How, you might ask? Well, when tech teams are buried in their work as specialists and subject matter experts, they can lose sight of the forest and get stuck in the trees they know best. Someone neutral or from a different specialty or competency can often see the gaps far better than specialists can see from the inside. But, teams must be open to letting them in.
Collaboration does not happen magically, it needs help and nurturing.
Organizational Change Management for the Project Team?
The two points above line up very well with the most common areas of concern we see in failed complex technical projects.
- Failing to mitigate ALL risks and impacts for both the technology and the people impacted.
- Fragmented development where the project team is split into separate subject matter areas focusing on deliverables in a separate stream and who are infrequently brought together to collaborate in rich action-oriented sessions.
In the case of one of my clients, there was continual resistance that the technical team gave me – they considered it “butting in” when change management for project workflow was recommended. They wanted to know why I was being included in all technical meetings and decisions. In a recent conversation with a member of that technical team, I was told that because of my insistence we broke through silos and collaborated better as a team, and the project was successful as a result. He said he is now sold on the concept because he has seen it work. Why?
Because change mangement is about ‘people strategy’ and project teams are made up of people, too!
Managing change isn’t just an exercise you toss in at the end of a project to ‘make it nice for the end users’. Change management is a highly researched and well-developed competency that involves many activities to mitigate risk and realize success in adoption and sustainability. When a good change management person, who understands technology and development, is included throughout the entire project, they bring strategies and tactics with them that facilitate team cooperation and collaboration.
So in the case of the Phoenix Pay System, I wonder what kind of change management was supported, resourced and applied to the implementation of the technology, but moreover, what kind of support was there for a change management team to help mitigate the risks during the project itself?
Organizations have to stop seeing change management as a ‘soft skill’ afterthought that gets applied only to build out a communication and training plan at the end-user stage.
It is high-time that companies realize project managers and change management leads work best as equal partners to provide a rich and well-delivered technical project. The more highly complex and technically dense, the more important it is that a technology/human combined solution is supported at the senior sponsor level.
Focus on collaboration and quality requires the same amount of attention that budget, scope, and schedule do. After all, successful projects are successful when they positively impact people, that is what results are all about. Organizations need to pay attention to critical systems such as this and put dollars into the human side of change when resourcing and do so at the beginning of the project.
The quote gave me pause and made me think, perhaps it’s time we look at a different way of managing projects, especially when they are as complex as the Phoenix Pay System. Deep dives into impact analysis and the benefits of using a full change team partnering with the technical team may have made a difference here.
More articles on the Phoenix System issues:
Protest Against Phoenix Pay System
[PostFooterP]