At first glance, there’s something about the HP board saga that doesn’t ring true. On one side, you have a chairwoman who was a student of governance, suffering a lapse of judgment that could find her (and others) in legal jeopardy. Meanwhile, a dissident board member whose success was frequently built by throwing away the rules proved the one who blew the whistle.
What’s wrong with this picture?
An article in yesterday’s Wall Street Journal documenting the dissention and politics on the HP board provided good insights on a culture that allowed the situation to careen out of control.
You could spin the saga in any number of ways: the outsider battling against entrenched interests, the innocent being set up, the woman of the year battling to be taken seriously in a highly macho boardroom culture, or the need to vet board nominees more thoroughly.
But reality is hardly black and white. Although the smoking gun has yet to be uncovered, it’s clear that the pretexting occurred because project leadership lost sight of the big picture.
To recap, the investigation began in the wake of boardroom leaks during debates over former CEO Carly Fiorina’s future. Based on a solid premise that boardroom leaks compromised corporate governance, at some point, the investigation veered off course once somebody cleared the use of legally questionable tactics to flesh out phone records of suspect board members.
Consequently, a project conceived with the goal of sound governance ultimately compromised it. Governance broke down when somebody at the top authorized the pretexting, or failed to adequately manage subordinates to keep the process on hard ground.
While the consequences of the HP case may prove far more severe than a blown budget or project schedule, the scenario should still look rather familiar to any seasoned IT professional. Put another way, how often do project teams get so wrapped up in the details that they lose sight of the overall goals?
Consider the case of a major global investment bank’s compliance project. In this case, one of the bank’s compliance strategies is building systems that adequately separate and document risk. And, as part of the development cycle, IT is documenting the business requirements so that the system delivers the right performance, supports the necessary scalability, maintains appropriate security levels, and contains the right functionality.
Unfortunately, in the quest to document requirements, the team has found itself being evaluated on its progress in feeding those requirements to a tool that manages them. Yet, there are either no metrics in place, and nobody taking ownership for vetting the accuracy, reliability, or quality of the requirements. Ultimately, if the system is built on faulty requirements, compliance will prove problematical.
The consequences of project tunnel vision could become exacerbated as IT organizations get serious about adopting best practices frameworks such as COBIT for governance; ITIL for service management; or ISO 17999 for IT security. The goals may be admirable, but as the HP board learned the hard way, the devil is when the details block the big picture.
About the Author
Tony Baer is a Senior Analyst at Ovum, covering application lifecycle, SOA, and IT Service Management. Tony is a well-published IT analyst with over 15 years background in enterprise systems and manufacturing. A frequent speaker at IT conferences, Baer focuses on strategic technology utilization for the enterprise. Baer studies implementation issues in distributed data management, application development, data warehousing, and leading enterprise application areas including ERP, supply chain planning, and customer relationship management. As co-author of several books covering J2EE and .NET technologies, Baer is an authority on emerging platforms. Previously chief analyst for Computerwire's Computer Finance, Baer is a leading authority on IT economics and cost of ownership issues.