IT Governance: Spock Got It Right in the Nuclear Reactor
Think back to the Star Trek scene where Spock goes into the USS Enterprise nuclear reactor to save the crew and ship, and Kirk and Spock exchange a tearful goodbye: "The needs of the many, outweigh the needs of the few." Watching the 30 second clip on YouTube should be standard training for anyone who participates on IT Project Governance boards.
There was no politicking when Spock ran in to the reactor core. He did what he needed to do looking out for the best interest of the rest of the team. He didn't think about his next promotion or how someone above him could make his life difficult for not being a "yes" man. Spock did it with risk, but knowing the outcome was far better than the alternative. IT Governance should, but doesn’t always, follow step with looking out for the greater good. Using poor information and bad judgement could likely lead to your ship exploding.
I had a project where a business unit in a global company needed a better way to store critical documents. Business units were autonomous to making most of their own strategic IT decisions (this was a tip off to the real issue), so global solutions were not standardized at that time. With the current solution, security was limited and the inability to track changes was a high risk. There was no way to maintain audits of the documents and the risk of anyone without authorization changing critical information was high. Additionally, the problem involved significant time and cost to search through old documents when queries were requested. The Governance Team decided to determine budget for the project based on high level estimates of similar initiatives. This forced the project team to use a top down approach to find a solution that fit the available budget. A better document management solution was needed, but high level functional requirements were all that was available to make a decision to move forward with identifying potential solutions.
An alternative analysis was conducted on several potential solutions, including a customized, in house application. When costs were investigated from the baseline initiative, several inaccuracies were identified within the baseline cost model. Also, after interviewing several project participants from the business side, many agreed the baseline solution was too cumbersome and inefficient in meeting their ongoing needs. Additional threats were also identified although leadership was pushing to validate the value of the in-house solution as being the end all response for a document strategy. From bloated costs to potential misappropriation of charges, the similar initiative used as the baseline cost model was identified as not being valid by the project team. The search for a solution became a political hotbed with multiple layers of C-suites posturing and distracting from the real value of one of the solutions, rather than focusing on meeting the business need. Needless to say, the baseline project team tried several different tactics to distract from the questions regarding their cost model, and the executives who originally sponsored the initiative seemed none the wiser to the muddy details.
After several formal alternative analyses were completed and favored a different solution over the in-house solution, the issue became highly visible and slowed down due to political pressure with the project being put on hold indefinitely while value for the in-house solution was being debated and struggling to justify relevance. The project team that managed the baseline initiative was not completely transparent in the costs within their project, became defensive when challenged on the project financials by our outside team and invalidated. Credibility was lost.
Ultimately, a valid cost model with the baseline solution would have ensured transparency in the selection process of the IT solution. Additionally, open communication around expectations (certain members of IT leadership insisting to use one solution over another rather than using an alternative analysis to meet business expectations) would set the path forward with the business unit on what solution to use and why.
In the end, due to the futility of office politics the business did not get any solution at that time and the money allocated to their initiative was reallocated elsewhere. In essence, the business' core reactor melted and the ship blew up.
So if your project is in competition with another already in operations, a sidebar with the executive sponsors will help you identify challenges early and garner support for action and oversight when discrepancies arise. The real value is at the governance level, those stakeholders are Spock.
While some might argue that Spock's actions were the result of his human emotions breaking though, his sacrifice was logically based on accurate information. If he did not stop the reactor, forfeiting one life, an entire crew and ship would be lost. Don't let emotions caused by political posturing drive your project. Rather, it's your duty at the governance level to keep the organization's best interest in mind by using accurate information to drive decisions.