This is the first of several posts on the topic of IT oversight. In this post, I’m going to consider the economic outcomes we might expect from governance, and discuss how thinking about the issue from this angle might lead us to reconsider how we configure oversight.
Note that this post is relevant to both the federal and the state governments I’ve worked with. Both include multiple levels of review from departmental, executive, and legislative overseers.
To start, an assumption and a belief:
- I assume that the objective of IT governance is to improve the likelihood of good outcomes on IT projects. The definition of a good outcome should be cost-effective proposals, end-user acceptance of the result, within the budget, as soon as possible.
- I believe oversight should be responsible for measuring and reporting their effectiveness using the same return-on-investment (ROI) measures expected from the projects overseen.
Imagine a government oversight initiative that is responsible for twenty projects/year and that the average planned cost of each project was $10M/year over two years. In other words, they manage a $200M/year portfolio. If the actual costs come in at $220M/year, a 10% overrun, then the objective of an oversight committee would be to reduce that $20M to zero. This is pretty obvious.
We could also suggest that good oversight would continuously reduce the costs of projects and offer a positive ROI there. Here oversight might constantly push projects to use less expensive commercial products or open source. They might influence proposals to reduce contractor costs. Again, the obvious things.
These activities should be performed against a baseline and measured. Reducing cost overruns can be measured. The cost of compute, storage, software, and services can be measured. The cost of project failures can be measured. In my opinion, these measurements are crucial, as they allow us to focus our oversight where it will have the most bang.
Finally please note that there is a large hidden cost that needs to be added to the picture.
Imagine that for each of $20M projects mentioned above ($10M/year over two years) there is a four-year break-even point. Once the project is live, the organization will gain a $5M/year return on the $20M investment and, after four years, be ahead. Here is the issue, if the effort to get through all of the oversight takes a year then that $5M gain is postponed. Further, if the gain is not so easily monetized, for instance when the gain is that the new system protects the welfare of children, or improves the delivery of health benefits, these benefits are postponed. Delay has a cost that is often unaccounted for and ignored.
So, the first hypothesis of the series is that delay due to the long cycle time to get through the gates from inception to start: technical oversight, business oversight, budget oversight, all repeated at the Division level, the Department level, the Agency level, the Executive level, and the Legislative level are too much. The delays built into this process for each and every program times the cost of delaying the advantages to the public does not justify the governance.
In the posts that follow I will follow-up on this hypothesis and suggest some more:
- I will post more on the impact of delay and suggest methods to get on with it. I will suggest that agile development significantly helps here.
- I will argue that overseers need to account for failures and work to reduce the cost of failure. To suggest that oversight will eliminate software project failure is silly.
- I will argue that agile methods contain a set of techniques that minimize the impact of mistakes. I will point out that agile does not guarantee success. I will argue that agile delivered in a waterfall fashion is more like waterfall than like agile. I will remind readers of the past failures of waterfall methods so that they do not throw the new agile methods out if they fail.
- I will post on methods to reduce costs and suggest that the biggest bang for the buck come from the effective application of modern technology and techniques, and suggest how to look at the market to see these technologies and techniques emerge.
- I will suggest ways to reduce overruns by spending more time monitoring execution performance and less time on imagining that a perfect (waterfall) preface leads to a perfect outcome.
- I will post some tidbits… food for thought.
Wish me luck in managing my muse…