Interesting report by Mitch Betts in the the January 4, 2010 edition of Computerworld on how The Corporate Executive Board think the corporate IT funding model should evolve.
You know what this is all about - balancing the budget by transferring money from the profits centers to the costs centers (of which IT, and software development, are usually one of the largest). Your organization probably does it in one of three ways:
- usage-based chargeback (which requires detailed cost accounting)
- lump sum payments (based on some arbitrary metric to divide up which profit center pays how much e.g. headcount)
- A mix of the two
The Corporate Executive Board believe that a much better way option for the future is to parcel up all of IT into 12-24 “business services” and assign costs for each one. They recommend that the IT services should be described in business terms e.g. “video conferencing” not network “bandwidth.” Although if video conferencing ios one service, how on earth do you describe It in only 12-24 services.
That brings me to my main point. How would software development fit into these 12-24 services?
My guess is that it would be included in the services that it supports. So if, say, Service A needs to enhanced or modified, the software development cost would be included in the Service A cost to the business. Hmmm. That’s not so easy. Presumably the typical cost of Service A is an operational cost. How would you handle a one-off enhancement cost? Would it be amortized over, say, two years and added to the operational cost? What if the software development included some architectural changes that benefit more than one service? Well you could make some arbitrary decisions about how to divide up the architectural costs among the services. Oh! Wait a minute! isn’t that where we came in?
This is the second in a series of postings providing updates to our book, “The Business Value of IT.” This posting explains in more detail the Business Value Index or BVI. BVI was developed by Intel’s IT organization so it comes with the advantage of having been developed by practitioners.
BVI considers three dimensions of IT value:
- Business Value
Business Value measures both the tangible and intangible benefits of a project on a set of weighted criteria. While there is the advantage of starting with Intel’s tried and tested criteria and weights, there is no reason why your organization could not adjust these to suit its own needs. Some examples include:
- Customer need
- Business risks
- Technical risks
- Strategic fit
- Revenue potential (recognizing that this is not a fixed number is important!)
- Level of required investment
- Innovation
- Learning
- IT efficiency
IT efficiency measures a project’s impact on the IT organization. For example, how well does the proposed project “fit” with the organizations enterprise architecture policy (where we are now) and strategy (where we plan to be in the future). Again, a set of weighted criteria are used.
- Financial Criteria
The model separates business value form financial value. It is possible for a project to have great business value with little or no financial value. Projects with negative financial value can still be imperative for the business e.g regulatory implementations or “must have” competitive features. The model uses Net Present Value, Internal Rate of Return and payback period (see our book for definitions) to assess financial attractiveness.
Intel uses the scores for these 3 dimensions to generate a value visualization of the comparison between candidate projects:
Back in the day, IT was synonymous with flexibility. “Software” meant exactly that - the ability to implement things is a “soft” way that could be easily changed. Nowadays, in many cases, software is as rigid as hardware or even more so. Similarly, the IT group is too often the least flexible department in the organization - “You want what? When?”
Today, we find ourselves in times when businesses are looking to cut back. Strong IT departments can flex their capacity and cost to meet their business needs. Poor IT departments don’t have a plan for changing capacity quickly - they have a gas pedal but no brake.
I was reminded of this important quality of an IT department by a guest editorial by Edge Zarella in the ISACA Journal (Vol. 4 2009). Edge neatly summarized the world that IT Professionals are facing:
- Intense pressure to cut technology costs
- Mandates to improve operational performance
- A need for technology to realign to meet new business needs
- A focus on cash management and a priority around liquidity
It was this last bullet that caught my eye. It’s not enough for the IT department to claim they have “scaled back.” They must be able to hand back cash. How? Much of the cost of IT departments is in the form of people. Surely, head count is difficult to flex up and down quickly, especially if the department is already running lean? This is only true if there are no advance plans to flex size. This has to be an important element of all outsourcing contracts and a key justification for starting an outsourcing engagement if you don’ t already have one.
How can we measure the strength of our IT department for flexibility like this? How about the percentage of budget they could hand back given 3 months notice?
We can take this further. As we climb out of recession of if a terrific business opportunity presents itself tomorrow, we can turn this IT flexibility metric around and measure how much capacity can be added given 3 months notice.
These metrics have to be supported with detailed plans that are reviewed and revised quarterly to reflect changing market conditions.
Writing in the March 2009 print edition of the Harvard Business Review, Susan Cramm listed the following seven “truths:”
- Enhancements often don’t deliver results commensurate with their costs.
- Projects are often too big and take too long, partly because unnecessary functionality is built into applications.
- Previously purchased applications and infrastructure technology are often underutilized.
- Project failure rates are too high.
- Tech teams do not have sufficient incentive to achieve high quality and quality is often not measured.
- Managers don’t know enough about the systems that support their areas.
- IT is too risk averse: ” No one ever got fired for buying IBM or Microsoft.”
For each of these, Susan adds some useful tips for avoidance but she summarizes them best herself in her introduction when she says, “The discipline you develop now will pay off in a big way later.” Superficially, I agree - more discipline is needed by most software development teams. On reflection though, I have a problem with the statement - if we replace the word “discipline” with “system” or “enhancement” and its the very sort of unjustified claim that Susan accuses IT of making. How do we know that more discipline will pay off in a big way later? More discipline tends to mean more process. Is it universally true that more process will pay off in a big way later?
Now, of course, you all know that I am a discipline and process advocate. However, especially when money is tight (when is that not true?), the key is that more discipline/process is not always best. You need just the right amount of process to get the biggest return on the investment, have a business case for more discipline/process and, as Susan says, tie executive compensation to realization of value.
Finally, is it just me or are #4 and #7 oxymoronic? But I know what she means! It is a personality trait ot technical people such as ourselves that can carry off the split personality of the sharp intake of breath whenever management asks us to make a change and the “It’ll be alright on the night” mentality of “90% completeness” and “if we take a bit more time on development, we wont need as much testing time”.
Flicking through Information Week, I came across a couple of obscurely named but absolutely critical metrics to use when consider disaster recovery:
Recovery Point Objective (RPO) identifies how much data can be acceptably lost.
Recovery Time Objective (RTO) identifies the acceptable time for a system to be done (or the time it takes to bring it back up).
Clearly, such metrics require extensive discussion and explanations between the businesses and IT. Both are functions of cost and it would be interesting a useful to ask for a plot of these against cost before making any decisions.
You can find the full, short article by Howard Marks at
Practical Disaster Recovery
In his article in Information Week entitled, “Decision Time”, Doug Henschen writes,
“Companies can’t report their way to great results–though you wouldn’t know it from their accumulation of underused reports and dashboards. Companies that get this critical point are moving away from IT-centric business intelligence programs and toward results-focused performance management.”
It is precisely this movement that led DCG to develop it’s Value Visualization Framework ( VVF ). The key idea of the VVF is that all organizations are constantly operating, measuring and improving with greater or lesser energy and success. Successful prioritization of the application of their energy to achieve more success depends on regular visualization of the state of the organization (or sub-organization) in such a way that managers at all levels can make prioritization decisions.
To read Dougs full article go to,
Decision Time
I was in Europe last week meeting with current and prospective clients. It is interesting to see that the level of commitment to the use of function points for managing outsourcing contracts is growing. Nobody believes that functions points are the whole answer or that they should be implemented thoughtlessly but there is growing support for the idea that managing a software development or maintenance outsourcing contract is very hard indeed without some notion of software size. The sizing methodology that can be most easily accepted by both parties to the outsourcing contract is function points. During the week, I was party to several conversations that illustrated how sophisticated the measurement conversation has become in SOME companies. I was reminded that those companies who have not implemented strong software measurement plans are getting further and further behind. Of course, they are probably not reading this blog either :-).
I was reading Federal Computer Week (from a month ago - I catch up my reading when I can) when I came across a short article by Emory Miller. Apparently, the US governments Office of Management & Budget (OMB) have reported that, “413 federal projects valued at $25.2 billion in 2008 alone need better planning, management and oversight.” Two things struck me:
1. Having worked on small government contracts, the last thing that they need is more bureaucracy. Hence, I suspect some of these projects are so huge that even the participants dont know how to plan and manage them. Perhaps the problem is about getting the projects to be the right size for the planning, management and oversight that the government employees already have in place?
2. I wonder how much potentially wasted money commercial organizations would find in their IT shops if they had an equivalent of the OMB? How would they even start such an analysis? I suggest that a combination of portfolio management and gap analysis by an independent organization against best practices in IT governance, IT operations and software development would be a good place to start.
Miller’s article can be found at the following link:
http://www.fcw.com/print/22_29/comment/153682-1.html
