Project Rescue and Recovery
Information Technology organizations continually struggle to build systems that meet their customer's needs. They work tirelessly developing solutions that are delivered late, difficult to use, or deficient in key features and functions. This is nothing specific to the last couple decades; it stretches back to the first systems developed. Fredrick Brookes eloquently underscores this in his recount of the 1960's software engineering project to develop the IBM 360 in his book The Mythical Man-Month (1975) and is required reading for all IT executives. For the Chief Information Officer to solve this problem takes a new approach, one, nearly opposite from today's direction.
CIOs have two major responsibilities—keeping IT's lights on (backups, networks, email, etc.) and providing support for business initiatives. Being mediocre at either will make for a short career. Although the respective budgets are normally a 70:30 split, a CIO will be fired in a minute for failing to properly support the 30%. That portion of their budget actually generates the company money. Keeping the lights on is a thankless job. People simply expect networks run, data served, and viruses inoculated. It is expected much as we expect water when turning on the tap. Supporting business initiatives is just as thankless since 60% of projects seem to always be in trouble.
Yes, I am on that soapbox. Ensuring that maintainability and adaptability are part of a system is a "best practice," extensibility is not. To the extent that a highly structured system is extensible, that is the end of any commitment to building for the future.
Adding hooks and stubs for something that may not happen, confuses and clutters the design of the resulting system. Building and running prototypes wastes time. Making a system extensible adds significant undefined scope. The reason is that no one knows what the future will bring. Furthermore, how can it be tested if the systems it is interfacing with are not defined?
The other day while preparing for an interview with Fortune Magazine, a junior colleague asked, "When recovering a failing project, what are the role differences for various people in the organization?" Great question! I had never sat down and captured that aspect of project recovery. After all, failed projects are a hodgepodge of lost leaders, perplexed project managers, and trampled team members. Without defining everyone's roles early and continually refining those roles, you will struggle establishing calm in what is otherwise a very stressful situation.
The first ingredient in recovering any project is trust. The team must trust the recovery manager, the customer must trust the supplier, team members must trust each other, and so on, until all permutations are exhausted. Without trust, all is for naught. Therefore, to have a successful recovery, or project for that matter, it is a requirement to thoroughly understand trust and how to foster it.
The costs of failing projects are huge. Roger Sessions estimates the cost in the US alone to be $1 trillion annually. The impact, though, goes beyond monetary; it includes reputation, the organization's morale, consumption of resources, and missed opportunity by postponing other projects. Fortunately, there are also many unrealized benefits to glean from troubled projects. To reap those rewards, companies must adopt a culture to exploit failure and learn from it. More often than not, people just want to get the project behind them.
Walking onto any troubled project, guess what I hear? We are spending too much money, we cannot miss the due date, we need everything we are asking for, and it is "their" fault. My job is telling them the bad news—we need more money, we are cutting scope, and the project is still going to be late. Those are the unavoidable facts and the stakeholders need to accept them. Worse than that, I am not going to blame anyone. Blame is counterproductive. So, how does this compare to the situation with the United States Congress? In short, they do not get it. They need an apolitical, outside entity to build the recovery plan—just like we do anytime we are recovering any project.
The project was out of control. Within a two-week span, the project manager reported a slide of at least six months. To put the postponement in perspective, the original project plan was a total of nine months. Accusations came from everywhere. The customer complained about the project manager, requirements analysts were frustrated with the customer, the project manager was pushing on his leads to close requirements gathering, there was infighting within the team, and management did fnot know whom to believe. The organization was in mayhem and the only solution was to hire an external auditor to sort out the facts.
Have you ever had a boss that simply wants to stand in your way? They avoid making even the smallest decision, never providing enough information to understand their objections. It is more common than most of us would imagine. In fact, this behavior is the central to every sales interaction. Even though you may be repulsed at thinking of yourself as "selling" to your boss, that is exactly what is required with any idea you are pushing. Therefore, it makes perfect sense to employ the same techniques used to sell large systems. If you think this is rubbish, as one of my esteemed readers once eloquently said, I will posit that you are already using sales techniques, just the wrong ones—the ones car dealers use. Changing this approach will subdue your unruly boss
Change is difficult. Regardless of who you are, it is tough. Recently, I challenged readers of this blog to improve how they tie their shoes. I can confidently wager that a large majority have stayed with their old habits. It takes significant force to reprogram out brains, affect the cultural inertia, and gain acceptance to change, tolerance of occasional mistakes, and, eventually, achieve an organization steeped in transformational principles. Nowhere is it more apparent than when delivering projects that alter the way people perform daily tasks. The reason is that, all too often, the goal is to deliver the project; it is someone else's job to gain adoption.