November 15, 2010Doug Hadden
While working on my upcoming seminar at the Financial Management Institute conference in Gatineau (“The Emperor has no Clothes” – Risk and Results in an Increasing Transparent and Government 2.0 World), I began to reflect on the IT governance gap. Many governance methods are predicated on generally accepted axioms. Or: “what should work“.
My point in the upcoming seminar is that traditional IT governance structures that work in government for mature technologies need to change in order to take advantage of the Government 2.0 transformational promise. After reviewing Treasury Board Secretariat guidelines on IT governance, it occurred to me that this governance gap may exist with more traditional projects. That’s not to say that TBS governance guidelines are somehow antiquated – far from it, when compared to established IT methodologies.
IT professionals often live in a world where technology is abstracted. We hold many concepts dear to our hearts. We use conventional open-loop thinking rather than systems thinking for governance and risk management. This is described fully by Dr. Pallab Saha and team in a Microsoft funded project on Advancing the Whole-of-Government Enterprise Architecture Adoption with Strategic (Systems) Thinking. What struck me was the view that conventional thinking is fragmented (Believing that really knowing something means focusing on the details) , rather than holistic (Believing that to know something requires understanding the context of relationships.)
The IT governance gap comes from specialization or, what Dr. Saha describes as “factors” and “straight line” thinking. The overall effect of any IT project comes from the relationship to other IT projects. Here’s where we see a gap in traditional IT projects, when we use conventional thinking like:
- Leveraging a proven software vendor with a large installed based and $Bs in revenue reduces risk.
- Large software vendors have proven ROI.
- IT Shared Services will save money.
- It’s only possible to meet requirements through customization
- IT failure is caused by process – it’s the client or integrator’s fault – not the software
We encounter this gap frequently where facts collide with strong axioms. Government 2.0 provides a compelling event for IT professionals to reconsider some of these axioms. IT governance can follow the ceremony of process yet fail to meet objectives because the project technology premise was faulty. How should IT governance adapt?
- Ignore vendor success stories (it’s marketing, not reality)
- Connect with practitioners to determine what works and doesn’t work
- Use technology analysts to identify issues and opportunities, but don’t take their word for “what should work” – remember, vendors have influence here
- Question the technical premise behind the project at the beginning – this could reduce the IT governance overhead
- Small projects first, avoid the “big bang:
Latest posts by Doug Hadden (see all)
- The (IT) Project was a Success, but the Patient Died [Part 2] - September 21, 2016
- The (IT) Project was a Success, but the Patient Died [Part 1] - September 20, 2016
- Have we over-complicated the ‘smart’ in smart government? - September 8, 2016
- Why PFM reform is integral to smart government - September 8, 2016