Sure, we all want our IT initiatives to succeed. We regularly evaluate our projects, in-flight or upon completion, looking for tangible lessons to learn. We apply these strategic and tactical takeaways in hopes of increasing the chances of success for each subsequent initiative. We seek approaches that work for different industries, organizations, teams, and technologies.
But looking back at the many IT projects I’ve been a part of in my career, I can’t help but notice a common theme associated with success: people who genuinely care tend to find a way to get it done.
Secondary success factors get all the glory.
In trying to set up IT initiatives for success, organizations often focus on “best practices” which are actually secondary factors:
- Management and sponsorship models. Some say the IT department, as the guardian of technology, should drive IT initiatives. Others say the business units should be responsible. Either one can work.
- Methodologies and frameworks. Agile, Waterfall, Lean, devops, enterprise architecture, PDCA—they all can be deployed successfully. I know people who still swear by the Balanced Scorecard. There are stellar examples of these methodologies saving the day. But we have all seen these same methodologies fail.
- Tools. Using the right tools to automate management, administration, testing, and other activities can ensure clockwork execution of an IT initiative. Tools enable transparency and improve accountability. On the other hand, we have seen initiatives where everything was tracked in Excel or done manually, yet they were clearly successful.
After looking more carefully at these various, valid (sometimes contradictory) approaches, we can observe that some may be correlated with successful initiatives, but they are not the driving factor.
The primary success factor is an owner who cares.
The factor that overrides all others is a leader who cares about the success of the initiative.
A few years ago, I was a part of a project where a contracted PM ended up being the one who cared the most. The CIO thought the effort was too risky and backed off. At first, IT managers reluctantly paid some attention to it. But the PM involved them in the planning effort, so they ultimately bought in. Then the PM won over the CFO by aligning project activities with business benefits. This convinced the CFO to make sure the business units lived up to their end of the deal. The project was a great success, despite the CIO being MIA during the cutover. (He still didn’t believe it was going to happen and wanted to stay as far as he could from it.)
Right now, we are monitoring a global enterprise resource planning (ERP) rollout for an international organization. An enterprise model of the software is being deployed to over 200 countries. On paper, the IT PMO is in charge, but it is the Finance department that cares the most. In fact, the finance team created a new position to oversee the rollout. This is a career-building position. And let me tell you—the guy really cares. He makes sure the initiative gets all the support, attention, participation, and money that it needs. As a result, the initiative gained momentum and is running on all cylinders.
Here is a contrary example: a mid-sized company recently took on their largest IT initiative ever. The business case was very compelling, and the team consisted of all-star experts in both the business and technology. As the initiative moved forward, the VP of IT overseeing it got a promotion and took on greater responsibilities. As a result, he didn’t have the bandwidth to pay attention to this initiative. The president of the division attended the project meetings, but never made any decisions—he deferred responsibility to IT. When the new technology was implemented, it severely disrupted the business and caused losses amounting to almost as much as the cost of the initiative itself. A lessons-learned exercise pointed out major misses, such as a weak change management campaign, omission of automated volume testing, and flaws in the SDLC process. But the truth is these lessons were symptoms of the fact that none of the stakeholders truly cared. It was bound to fail.
Tweet: Who really cares about your IT initiative? #ITleadership #Abraic https://ctt.ec/ceNdu+
Let the owner draw in the details.
The passionate project owner should be the one who makes final decisions on the reporting structure, methodology, and tools. At the end of the day, it doesn’t matter if a given initiative is run by the business or IT. As long as the effort is spearheaded by someone who sincerely cares, it has a great chance to be successful. The same goes for the methodology and tools. They each have pros and cons, and the potential to work well, as long as there is a caring leader at the helm.
First, find someone who cares.
If you are about to take on a major technology initiative, you are probably looking for the best way to approach it, and the right people to manage and contribute to it. My advice is to first find someone who truly cares about the benefits and success of the initiative. Once you do, the other pieces will fall into place.
(And if you can’t find anyone who genuinely cares, the initiative is doomed no matter how you approach it!)
