It never ceases to amaze me how quickly a major technology initiative can go off the rails, especially when you can demonstrate regular, clear communications amongst all business stakeholders regarding project status.
Leaders with significant experience have likely faced this situation, and I would imagine that you have started to envisage the likely root causes! Nonetheless, for those who might not have learned this the hard way, I would like to share a recent, career ending, example.
Scenario
Our scenario involves an initiative to replace a poorly performing, sales facing, data entry application that is a major, chronic source of salesforce frustration. The software tool in question is a 3rd party off-prem tool that supports an industry mandated business process. The goal of the initiative is to replace this 3rd party tool with a bespoke on-prem (and cloud) application which leverages the benefits of business-wide platform integration; that runs 30X faster than the 3rd party tool; that saves seven person years’ of salesforce labor across the business; that drives end-to-end transaction processing times down from 2 weeks per transaction to 1-2 days maximum instead; that reduces transaction error by 80% or more; that cuts back-office labor per transaction by at least 60% per transaction; with an application that is easier to use and has the look and feel of the broader platform. The initiative is a high-profile effort that has the backing and the mindshare of the CEO, CFO and other C-suite leaders. The effort is being spearheaded by the right IT team and the primary business user heads the back office team that runs the platform to serve the needs of the salesforce.
Project Summary
At a high-level, the project goals are pretty clear (replace the 3rd party tool). As you might imagine, the broad functional requirements are pretty clear (replace what the existing tool does). The project runs on an Agile methodology. As previously mentioned, the business owner of the initiative leads a back-office team that processes the transactions entered by the salesforce. A business PMO oversees the effort and the scrum master is an IT resource.
Project Execution
The first few sprints are pretty rocky and the number of defects per sprint are quite high. The business PMO is aggressive and seeks to determine why the IT team is performing so “poorly”. Comparisons are drawn to other IT teams, working on other initiatives, where the defect rates and story points completion statistics per sprint are far better.
The fractious relationship endures for about 9 months, even as IT adapts and performance statistics improve. Costs run higher than expected and at the 12-month mark, the project reaches a major confrontation over missed deadlines. Two levels of IT senior management are exited from the firm. The business PMO leader and Product Owner are exited from the firm. Project deadlines are extended and the work continues.
What went wrong and a list of warning signs and steps to avoid a similar outcome
There were two primary root causes for why the project did not deliver on time or budget. The first was lack of alignment on the business side between C-suite goals and Platform Owner goals. The second primary cause was poor communication by me (SVP of the IT team) between myself, my IT CIO and the business EVP, compounded by a poorly designed monthly project status procedure.
On the Business side, the primary goal was the improvement in Broker satisfaction with the marketing email tool (the data entry application mentioned in the Scenario). However, the Product Manager was far more interested in how the new tool would impact his ability to perform the marketing email reviews. Thus, the entire 1st year of the sprints were dedicated to back-office improvements to help insure that when brokers got their hands on the new application, the back office team would be able to handle the volume of transactions. This in and of itself is not an issue, but due to the next problem described below, C-Suite business leadership was never informed that the date for broker use of the platform was moving further and further away (because Sprints were dedicated to back office processing, not the broker interface.
This problem became known to me too late for me to be effective about it. That said, I was not effective in garnering the necessary buy-in on the IT CIO side to approach the business EVP to explain the situation. The consequence was a loss of confidence in my ability to deliver and to manage my team. A bitter pill after 4 years of superior performance, but a valid criticism nonetheless. “What have you done for me lately” sealed my fate with this employer.
The ancillary issue I mentioned in passing is still not yet resolved and continues to jeopardize others in my position. Namely, all the of the meetings with the CEO regarding major projects are attended only by business leaders familiar with the initiative. As such, it was not until my fate was sealed that I became aware of the strategic misrepresentations being made by the project owner, who was indicating there was substantial progress to achieving the goals of the primary business users of the application, when in reality no work on their story points had yet even started.
Moral of the Story
While it might seem obvious, the moral of this story is to insure that what you are actually working on is identical to what the C-Suite knows is being worked on. One obvious lesson learned is to produce a separate status report geared to consumption by the C-suite as to the IT view of progress towards goals. A goal heat map which would have shown zero progress on end user goals and instead progress on back office goals, would have clearly outlined the disconnect in priorities. That coupled with a formal meeting including the IT SVP would have solved for this miscommunication.
There are other morals, but they get into motivations and I don’t want to go there!
this is interesting and relevant