Technologies Role in Project Failure

Projects build in technical debt and maintenance groups remove it—if your organization has a maintenance group. Technical debt accrues in any product, whether or not it has a technical component. It is the result of taking shortcuts when building the product. Sometimes it is the result of not having enough time, on other occasions it is due to not having the right tools. Anything from the implementation of the software component to light fixture can have technical debt. Promises are made to correct it later, but later never comes.

Recently, I surveyed a dozen or so students at three Portland area universities. Three-quarters of them replied. An adequate response, since the questions were open-ended, requiring a written answer. The students were all business majors and a majority of them in Management Information Systems (MIS). Although anonymous, I knew the group of northwest students well enough that the optimistic, upbeat tone of the responses were no wonder. The surprise was what was missing.

Friday brought news of another company outsourcing part of their IT. The details are sketchy, but it appears that all the COBOL programmers (many counting days until retirement) are going to have their jobs moved half way around the world. Soon after, it sounds like the IT infrastructure and operations will follow. Friends lamented about more jobs going overseas. I had to ask what other options management had. I did not hear any alternatives.

To the dismay of my cohorts and their potential pink slips, I am less concerned about outsourcing the administration of servers, networks, and base applications. For most companies, those are not the systems unique to their mission. These days, those functions are utilities. However, outsourcing customized systems that are at the heart of how a company does its business and distinguishes itself to its customer, is very risky. It may be the only option now; however, it could have been avoided.

Not too long ago I had coffee with fellow tweep, Peter Kretzman, at the Zeitgeist Coffee in Seattle. We had a wonderful conversation and shared stories, philosophies, and impressions. In the process we stumbled upon a common literary love—The Mythical Man-Month by Frederick Brooks. I read it for the first time last summer and Peter reads every few years. We both extolled the virtues of the book and lamented at the fact that so many of the items Brooks brings up continue to plague us today.

Maintenance does not belong in projects. Combining the two violates the definition of a project, mixes deliverables with opposing triple constraints, and sets the stage for scope creep. Maintenance needs to be performed by a dedicated group that can quickly implement changes. Project teams should focus on completing enhancements that will provide additional value to the customer.

It happens hundreds of times a day around the world, the CIO calls an urgent IT Management Committee meeting. She has heard that one of the projects in the portfolio, a seemingly simple project doing a routine upgrade, is projecting a 20 percent cost overrun and will be three months late. How can a project go that far off track since the last week's executive team meeting? Managers scramble to get their stories straight, determine who to blame, form opinions and alibis, and pummel the project manager for failing to manage the project correctly, even though he has been saying the project is in trouble for months. The project has drifted from its initial intent and now the ultimate goal is to find someone to blame.

"Technology... is a queer thing. It brings you great gifts with one hand, and it stabs you in the back with the other." This quote, delivered by C. P. Snow, is one we should all live by. Mr. Snow was a physicist, a novelist and a bit of philosopher. Technology brings about great benefits that many of our projects rely upon. We are using it right now. However, take pause to reflect on how technology is also our nemesis. It haunts our projects with its false promises and lures us into implementing superfluous functionality.

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."