Project Governance and Definition
Experience with red projects has more value than recovering them—avoiding them is the real objective. This presentation focuses on a number of techniques learned while recovering projects that greatly improve the chances for success. It introduces the concept of a Guidance Team that gets involved with the project at the customer inception stage and follows the project and team through to the project completion.
I need your help. Why is it that as we get older, so many of us lose the desire to learn? Where is the fun in that? A few years ago, I was nearly sucked into it myself—at least for a few minutes. A half-dozen of us were sitting in a coffee shop talking about growing our businesses and conversation turned to Twitter—about its uselessness. As I drove back to my office, I thought, "The six of us ought to go tell the twenty million people using Twitter how foolish they are." With that utterance, I realized how I had been drug into the world of stasis. I spent the subsequent three days immersed in social media, studying Twitter, LinkedIn, Facebook, and numerous other social tools. Now I am perplexed on how to get others to see the value. Let me fill you in on what I have learned about teaching people, maybe you can point out my flaw.
Again, I was chided for saying there are no Information Technology projects. This time, the excuse was that the company built software. I countered my antagonist by asking if the same group that built their software also maintained the account system, workstations, email, and network. "No, that is a separate group." He was missing that his company's production group was not IT. Information Technology is the support group... and yes, they should not be doing anything that fails to directly affect getting product out the door or reducing costs. Every project's goal must be to deliver to the operational needs of the company—selling product—not to the whims and desires of the IT group. If a project fails to address the needs of the customer (directly or indirectly), then it should never see a penny of funding. This seems such an elementary concept, but it is routinely violated by techno-bigots trying to implement the latest toy or tool.
I sent a note to professional organization's program director the other day asking if their group would be interested in hearing about methods to increase project success. The organization was for a technical group that worked with data transformation—a skill set used in every IT project I have ever been on. The reply came in a prompt, succinct, and sarcastic reply:
"We [sic] you please tell me just how this would ever relate to the members of our group. You obviously do not understand that we are not responsible for running the project."
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.
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?
Projects never go bad overnight. It takes time. They slowly drift away from the baseline. Maybe it is a change request that goes undocumented, or a series of tasks that run a little late, or an over-optimistic employee not realizing they are in trouble, or misinterpreted communication. They all add up over time and are very difficult to detect while in the heat of the delivery. It often takes an experienced outsider who is removed from the history and politics to see the issues and make the recommendations that will keep a project on track. The Project Health Check does just that—keeping your project healthy.
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.
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.
People or Process, as the name implies, looks directly at the role of people versus process in a project’s success or failure. The focus on process is a needed component, but does not obviate the need to manage people. Unfortunately, the trend over the last fifteen years has been to focus on process and reduce the project to a checklist of tasks. This has created a culture that neglects the value of a manager with people skills.