What CFOs should ask their software development leaders

Executive WhitepaperMarch 2010

What CFOs Should Ask Their Software Development Leaders

Peter Spung Director, Strategy, IBM Rational Software

“Without changing our patterns of thought, we will not be able to

solve the problems we created with our current patterns of thought.”

- Albert Einstein

Discussions between chief financial officers (CFOs) and heads of IT

departments most often center on the the funding of projects, or need to

continue funding, as if a simple commodity-based relationship existed between

fiscal outlay and value received. But this “pattern of thought,” to use Einstein’s

term, hinders a much more productive mode of discussion that these two

business leaders might engage in. In this paper, I will illustrate a new way of

thinking about the funding of IT software projects, one that considers funding

in terms of investment, and value as an expansive, longitudinal variable.

Let’s begin with a scenario you may find familiar.

After an already long day of meetings about budget over-runs, our CFO

Jim faces the prospect of yet another monthly drain on his software project

expenses, not to mention his personal stamina. On the monthly agenda are

budget requests typical of projects in his software development leader Mike’s

organization: upgrades gone awry, projects behind schedule, enhancements

needed to existing systems so they perform as expected, and the like. Through

his connections and regular dialogs with other CFOs in the region via their

industries’ association, Jim knows this is not unusual, and Mike is no villain. If

he is, so is every other software development leader in this part of the country.

But something gnaws at Jim as he trudges to the meeting room, contemplating

the upcoming discussions with Mike. He intuitively knows the software and

systems Mike creates and maintains are important. At their core, Mike’s

projects are fundamentally worthwhile endeavors that allow the organization

to operate more efficiently and, in some cases, more effectively reach new

customers and pursue business opportunities otherwise not possible.

3 What is the missing context for

these discussions?

4 Projecting financial measures

5 Costs and benefits of the

investment, and associated risks

6 Software project investment

models involve multiple cost and

benefit streams over a long life

8 The investment value of a project

changes over time, and could

improve through a better

understanding of its past

performance and future risks

10 Investment models reflecting cost

and benefit ranges that factor in

risk, and the time value of money

(eg, NPV) look promising

12 Now, the questions a CFO should

ask the software development

leader

12 Call to action

13 Further Readings

13 About the author

14 Key concepts covered in the

narrative

Contents

Executive Whitepaper


HighlightsYet for some reason, they never talk about that in the monthly meetings.

Instead of discussing the intended purpose, priority, and benefits of the

various projects, and how to realize those benefits or trade them off among

projects, Jim and Mike get mired in the struggles of the project teams to

deliver and the expense required to get them back on track. Sometimes a

project’s additional expense requests have increased over long periods with

little to show for them, making future requests necessary and painful. It

also calls into question Mike’s understanding of the value and reliability

to deliver. Even if the projects do finally complete and deliver, it’s still not

clear they met their intended purpose and value to the organization.

What is the missing context for these discussions?The plight of Jim the CFO and Mike the software development leader may

resonate with you — these problems are common. At their essence, the

meetings between these two leaders are point-in-time conversations about

a project underway that is incomplete, over budget, and requires additional

expense to remediate problems so it can continue to completion. As a CFO,

Jim understands that there is a richer context here. For example, the proj-

ect in question has a track record, a history of expenses consumed. At the

outset, it also had an expense budget, with expected objectives and benefits

when completed. Yet in the conversations with Mike, all that is missing.

Instead, the conversation is always about the additional funding needed,

the cost of the set of remaining activities and equipment. And the associa-

tion between the additional budget and completing the budget is direct and

causative. In other words, it’s as if Jim and Mike behave as though there’s

an iron-glad guarantee that the additional funding will complete the proj-

ect, with certainty, despite all experience to date. The more you reflect on

this, the more you realize this pervades the thinking around these projects;

you have similar projects and thinking in your organization. Even from

the beginning, the budget was a precise figure, guaranteeing a fixed set of

returns and benefits for the project. Is that the way it really works? Jim has a

hunch it is not.

Sometimes additional expense

requests have increased over long

periods with little to show for them,

making future requests necessary

and painful.

From the beginning, the budget was

a precise figure, guaranteeing a fixed

set of returns and benefits for the

project. Is that the way it really works?

Projecting financial measuresAfter returning from the meeting with Mike, Jim phones up Susan from

his team, to see if she can meet about some of the work she’s doing around

project performance. She agrees, and while waiting for her to arrive, Jim

considers her background and role. Susan’s a recent hire who has brought

some new ideas with her from her from her previous organization, where she

took a novel approach to measuring and profiling software projects. She col-

lected data on expected and actual project measures for expected inputs such

as expenses, and for expected outputs such as schedule, quality, and require-

ments implemented as a rough proxy for the intended value of the project.

Jim recently asked her to do a similar retrospective analysis of the com-

pleted or canceled software projects in Mike’s organization. Susan arrives,

and she is visibly anxious and eager to meet. Something’s clearly gnawing

at her, too, and before Jim can ask, she describes her findings. Susan found

that some of the project managers were diligent about keeping data on their

projects. Not only did they have actuals on the key measures for the projects

that had ended, they had “snapshots” of the planned measures at monthly

intervals. Jim thinks that’s at least one benefit of the monthly meetings with

Mike. Susan plotted them over time and against some of the key measures

such as expense budget. What was surprising was not the gap between the

initial project estimates and the actuals, but that for the collection of projects,

(a) the bigger the project’s budget or number of requirements, the wider the

range between estimates and actuals, and (b) over the life of the project, the

ranges narrowed. Now that’s an insight. Jim thanks Susan for her work thus

far, and asks her to keep going, to see what else she can find.


Highlights

What was surprising was not the gap

between the initial project estimates

and the actuals, but that for the

collection of projects, (a) the bigger

the project's budget or number of

requirements, the wider the range

between estimates and actuals,

and (b) over the life of the project,

the ranges narrowed. Now that's an

insight.

Costs and benefits of the investment, and associated risksI suspect that this scenario so far resonates with you. These projects and

their profiles are like an investment. In fact, early on at inception, they

are treated and discussed as such. The benefits and value of the project are

considered in light of the expenses, and there’s healthy debate among the

senior executive stakeholders about the return on that investment. Occasion-

ally, one of the senior executives on your team will ask questions related to

Susan’s findings: What’s the likelihood the project will return what’s esti-

mated? What are the underlying risk factors and assumptions that could

affect that outcome? What have we learned from prior, similar projects that

could help our understanding? Susan and Jim are onto something - trying

to contemplate the risk/reward profile of the project, and reason about how

to act to reduce the risks and increase the likelihood of the return. Those

discussions can be difficult, because conventional wisdom and thinking is

that it’s hard to quantify and monetize the expected benefits, and combine

that with the estimated expenses and value to develop a clear and complete

ROI outlook for the project.

Here’s another insight from Susan’s findings: Estimates behave like ranges and

typically narrow over time. So treating them as point estimates doesn’t reflect

reality, nor does fixing them at one point in time. Just like an investment in say

a stock or bond, you’re spending money now to get a return later. In some ways,

a project estimate works like an option: You spend money now for the option to

make an investment later — to finish and deliver the project. And despite point

estimates of “an average 7% return,” you know well that there’s a range of pos-

sible returns and a standard deviation that expresses the risk, or likelihood, of that

return. They narrow over time as more information is learned about the project,

and more certainty is gained about key inputs, risks, and assumptions underly-

ing the project. Not only is there investment risk/reward thinking required here,

there’s statistical measurement and thinking as well. How could those insights be

used to manage the projects more effectively?


Highlights

Occasionally, one of the senior

executives on your team will ask

questions: What's the likelihood the

project will return what's estimated?

What are the underlying risk factors

and assumptions that could affect

that outcome? What have we learned

from prior, similar projects that could

help our understanding?

Estimates behave like ranges and

typically narrow over time. So treating

them as point estimates doesn’t reflect

reality, nor does fixing them at one

point in time.


Jim realizes that the way he’s been thinking about Mike’s projects is not

conducive to managing them in reality, to improving their likelihood of

success in the long run as they progress. He also realizes he has an overly

narrow, “point-in-time of a point-estimate” perspective on the estimates,

actuals, and time period for Mike’s projects. After a restless night and

morning commute contemplating the gap before them, Jim calls Susan into

his office for a discussion. He describes his mental gymnastics since their

last meeting about her findings.

Software project investment models involve multiple cost and benefit streams over a long lifeSusan can relate. She mentions that at her last organization, they were

zeroing in on a couple of key ideas that seemed promising. One was that

a software project has a long life, as it includes development, operation,

maintenance, and upgrades over many years. They should establish a

funding or investment model over that entire period that treats the costs and

benefits as several quantified and monetized streams that, when summed up,

yield the elusive return on the investment in the project. That’s clearly the

value of the investment. Sure, it’s hard to do, but they’ve recently stumbled

on some approaches to measure just about anything in business, including

intangibles, that seemed promising. For example, investment models are

used in other parts of the business to calculate returns using financial

equations such as Internal Rate of Return (IRR), and Net Present Value

(NPV). Jim sits up, completely engaged with all synapses firing. He says

that makes complete sense; it’s investment thinking. Then he asserts that

they should combine these with the idea of risk from her findings about

Mike’s projects. The streams of costs and benefits over time are ranges and,

jumping up to white board, he draws a quick graph of the cost stream over

the life of a typical project.

Highlights

A software project has a long life.

You should establish a funding or

investment model over that entire

period that treats the costs and

benefits as several quantified and

monetized streams that, when

summed up, yield the elusive return

on the investment in the project.

That's clearly the value of the

investment.


Jim and Susan have a healthy discussion about the profile of these lines at project

onset, and how they look at various points in time. Development is more risky

and less predictable and requires more people, so the lines on the Cost of Project

axis are higher, and farther apart. Operations and maintenance are less risky

and more predictable, require fewer people, and extend over a longer period of

time, so the lines on the Years of Time axis are closer and narrower. They know

instinctively they’re on to something. If only they had a similar view of the ben-

efit streams, and could combine them to see the expected return and associated

risk for the project overall. If only they could make a similar calculation at any

point in time, as the project progresses and more information is gained about the

assumptions and risks. Clearly excited, Susan says she’s wants to do some more

thinking and research on this. She leaves Jim’s office, both of them smiling and

thinking about what’s next.


The investment value of a project changes over time, and could improve through a better understanding of its past performance and future risksWhen you reflect on software projects, you see that they have the characteris-

tics Jim and Susan are discussing. They have a long life: from project incep-

tion, acquisition and customization (or design and development), validation,

and quality certification; through deployment, 24x7 operation, support,

periodic maintenance and enhancement, and finally retirement. For some

software applications and complex systems, this can be a span of 10, 20, or

30 years. A complete forward looking view of the expected costs and benefits

would reflect the long life span, as would a backward looking accrued view.

The forward looking estimated costs and benefits vary among the team mem-

bers and leaders who have an expert opinion about them. When discussing

this with them, you’ll often hear, “In the best case it will be (this) amount,

and in the worst case (another) amount. My best guess and most likely is that

it will be an in-between amount.”

The cost curves that Jim drew for Susan on his whiteboard, resembling a

curvy tube that expands and narrows as it moves up and down, reflect this

range of estimates throughout the life of the software. The width of the tube

is a reflection of the risk or uncertainty in any and all important aspects of

the software project. When asked, other experts on the project would have

slightly different curves reflecting the same overall profile, or shape, with

different widths and timing reflecting their view of the risks and when those

risks will be a factor in the project. “Averaging” or “summing” them in some

way would give the best estimate possible. As you move through time in

a project and look backward in time, the tube would become a single line,

showing the actuals. Looking forward from any point in time, you’d expect

the estimate tube to be narrower, especially closest to the current date. More

information is known about the project and software through real experience,

and more of the risks and assumptions have been considered and dealt with

through the development of the software and its operational procedures. The

benefit tubes, or financial streams, will be similar in nature. Summing them

up and averaging them in some way to give an overall financial value, or

investment value if you like, is no small matter. Although as we’re about to

see, Susan has some promising ideas about this.

Highlights

A complete forward looking view

of the expected costs and benefits

would reflect the long life span, as

would a backward looking accrued

view. The forward looking estimated

costs and benefits vary among the

team members and leaders who have

an expert opinion about them.


The next day Susan is just hanging up the phone after a discussion with one

of Mike’s project managers when Jim appears at her door. She asks him to

come in, and he steps to the whiteboard, about to pick up the eraser when he

notices what Susan has drawn. He stops and asks what it is.

Susan explains it’s a typical benefits curve or profile for one of Mike’s soft-

ware projects. Early on, when the curve shoots up, the range is very wide,

reflecting initial deployment and the risk or uncertainty of the benefits or

value of software that’s not been developed or deployed yet. Then it steps up

among several short plateaus, and the range narrows, reflecting the fact that

once the system is operational, the benefits are more certain with each set

of enhancements and maintenance, which follows since that’s that phase we

know is more predictable and less risky. This resonates with Jim, and vali-

dates some of the calmer discussions he’s had with Mike in previous months.

The budget conversations about maintaining the existing systems, especially

the ones that have been operating successfully for a few years, are always

simpler and more routine, reflecting the lower risk profile and relatively large

amount of information that’s known about those systems.


Investment models reflecting cost and benefit ranges that factor in risk, and the time value of money (NPV) look promisingThen Susan asks Jim to have a look at a spreadsheet she’s developing for one

of Mike’s projects, which she has just finished discussing with one of Mike’s

project managers. She’s captured several cost streams: cost estimates over

time for development, operations, maintenance, etc. She’s also captured a

couple of benefits streams: monetized productivity improvement estimates for

the sales people that will use this system, and additional customer business

the sellers can win by using it. She’s calculated the NPV of each financial

stream, and added them together. Jim’s stunned: the project has a negative

total NPV. The costs outweigh the benefits; it has no value, and is not worth

investing in. Not wanting to fall back into his old “point estimate” think-

ing, he asks Susan about her findings related to ranges and risks, and she

smiles. This calculation uses the project manager’s worst case estimates for

the streams.

Susan shows Jim two other NPV totals: one using the best case estimates,

and one using the most likely case estimates from the project manager. The

first is very positive, and the second just better than break-even. Susan and

Jim realize that these are crude calculations; risk based financial calcula-

tions such as these require factoring in the distributions of the range of

estimates from experts. For example, the costs stream actuals could end up

being a mix of most likely and worst cases, and the benefits actuals a mix of

the most likely and best cases. Susan mentions that she’s researching Monte

Carlo Simulation and Bayesian probability techniques to expand her think-

ing about the crude calculations in her model, and to capture more experts’

estimates. Jim encourages her to search widely — they might be able to find

something on the market for this.

Highlights

The costs stream actuals could end

up being a mix of most likely and

worst cases, and the benefits actuals

a mix of the most likely and best

cases.

There’s one last question on Jim’s mind, and he asks Susan where the

monetized estimates of benefits in dollars over time came from, since this is

considered difficult, often a conceptual block for development teams. Susan

smiles again. She told Jim that when he arrived at her office almost an hour

ago, she was on the phone with one of Mike’s project managers. Mike’s been

encouraging his organization to start estimating the benefits quantitatively

and monetarily as often as possible to really push the envelope on this way of

estimating throughout the life of a project.

As it turns out, Mike as also been connecting this mode of quantitative

benefits analysis with another initiative he’s been driving in his organization:

iterative and incremental development, or evolutionary delivery. The goal is

to deliver some benefits of the software and systems under development as

early as possible, so that more of the most valuable benefits become measur-

able sooner by the ones who matter most: the end users of the system and

its operations staff. In doing so, more information gets uncovered about the

risks of futures costs and benefits, so investments addressing those can be

prioritized and managed.

Susan says the project manager was really inspired by this new approach.

Project managers associated with projects that over-run budgets and yet

haven’t delivered many benefits become pariahs in the organization; and the

projects become a nightmare to manage, especially with the CFO looking

over your shoulder. Combining these ideas could truly change the conversa-

tion between Mike and his CFO organization, Susan and Jim, and lead to

better outcomes. Jim now smiles, and feels more encouraged than he’s felt

in months. Thanking Susan, he heads back to his office with a spring in his

step, the same gait he’s sure to use when he heads to Mike’s conference room

for their next monthly budget meeting.


Highlights

The goal is to deliver some benefits

of the software and systems under

development as early as possible,

so that more of the most valuable

benefits become measurable sooner

by the ones who matter most: the

end users of the system and its

operations staff.


Now, the questions a CFO should ask the software development leaderAre you ready to ask these sorts of questions within your own organization?

For instance, in their next monthly meeting, Jim the CFO asks Mike the

software development leader:

“Mike, before I consider your budget request, what demonstrable

benefits have we received to date on these projects? Could we begin

to capture and quantify that? Especially as you deliver those benefits

more often, in an iterative or evolutionary way.”

“And what aspects of the next phase of the project are the most risky,

or are estimated to bring the most benefit? Let’s direct the budget

at those elements, and then discuss monthly the benefits and value

received for doing so, as the budget is spent. We can learn, select

things that are working, and repeat. We’ll reason and adjust the

course together toward the best knowable outcome.”

Call to actionDid this paper start to change the way you think about software and systems

projects? Do you want to start asking questions and reasoning about your

projects and programs this way? Are you already? IBM takes this approach

in its own software organizations, and we’ve made progress on an approach

that will help you adopt similar strategies for your teams. I’d like to hear

from you. Please write to me at [email protected].

Additional papers in this series will explore topics such as selecting appropri-

ate benefit measures, tapping in to the knowledge of a handful of experts to

arrive at reasonable estimated project ROI, project management and com-

munication techniques that use investment thinking, reasoning about project

decisions using this thinking, aligning budgeting processes with evolutionary

software and systems delivery, and more. The order in which I deliver these

papers will be partly based on your feedback. I look forward to hearing from

you.

Highlights

IBM takes this approach in its own

software organizations, and we've

made progress on an approach that

will help you adopt similar strategies

for your teams.

mailto:paspung%40us.ibm.com?subject=I%20would%20like%20to%20know%20more%21

Further Readings• For a detailed and technical look (note: there will be math) at the under-

lying model for calculating the ROI and investment value of a project,

read my colleague Murray Cantor’s paper, “How to measure the return on

investment for software and systems development,”, at http://www.ibm.

com/common/ssi/fcgi-bin/ssialias?infotype=SA&subtype=WH&appname

=SWGE_RA_RA_USEN&htmlfid=RAW14205USEN&attachment=RAW1

4205USEN.PDF

• For a general discussion of investment theory concerning risk and analy-

sis, see Patrick McKenna’s paper, “Modern Portfolio Theory: Driving

project portfolio management with investment techniques,” at http://

www.ibm.com/developerworks/rational/library/aug05/mckenna/index.

html

• For a truly wonderful book on measuring benefits of projects and many

other “intangibles” in business using risk-informed statistical investment

models, see Douglas Hubbard’s How to Measure Anything: Finding the Value of “Intangibles” in Business, Wiley: 2007.

• There are many financial texts that discuss NPV and IRR, such as Erich

A. Helfert, Techniques of Financial Analysis: A Practical Guide to Man-aging and Measuring Business Performance, McGraw Hill: 1996.

About the authorPeter Spung is Director, Strategy, IBM Rational software, responsible for its

worldwide market and business strategy. Peter would like you to reach him

about this or other subjects related to pursuing the business value of software

and systems in your organization. Please contact him via e-mail: paspung@

us.ibm.com, or on his blog at IBM developerWorks.


http://www.ibm.com/common/ssi/fcgi-bin/ssialias?infotype=SA&subtype=WH&appname=SWGE_RA_RA_USEN&htmlfid=RAW14205USEN&attachment=RAW14205USEN.PDF




http://www.ibm.com/developerworks/rational/library/aug05/mckenna/index.html






Key concepts covered in the narrative• Software project estimates consist of two things: inputs such as costs (of

labor primarily), and outputs such as benefits or value of the project: increased productivity, revenue.

• Costs are easily quantified and monetized. • Benefits are not easily moentized, but can be, and IBM is making in-

roads on this.• Each has uncertainty. So they’re best thought of in ranges. The ‘width’ of

the range is a measure of the amount of uncertainty. • Risk and reward apply. For example, projects with larger budgets typi-

cally have larger benefits and wider ranges reflecting higher risk (uncer-tainty).

• The costs and benefits begin when the project does, and continue long past delivery — as long as the software and system is in use and main-tained.

• So think of them, once quantified and monetized, as ongoing financial streams that begin at project inception, and end when the system and application are retired and decommissioned.

• Since some have long duration; the time-value of money is in play: Net Present Value, or NPV.

• The critical context of each project is to understand the sum of the costs accrued and benefits (value) received throughout its life, so that you understand whether it paid off or not and that the full value was received for the investment.

• This is the Investment Value (IV) model of the project, and the context for decision making.

• The IV changes over time. As the project progresses, more information is learned that changes the teams’ views of the risks and assumptions that underlie the costs, benefits, and risks in the model.

• Systems that have been operating for a while and are being maintained have lower risk profiles than enhancements to existing systems. Those have still lower risk profiles than new systems: least is known, therefore risks and uncertainty are higher.

• When the CFO and Software Development Leader and their teams inter-act and make decisions, the current calculation of the Investment Value and underlying streams informs that conversation — the accrued costs and benefits and future expectations.

• The name of the game becomes managing the risks affecting the costs and benefit streams by investing to reduce risk directly, or to get more information about future risks to the project or system, AND to receive the next set of benefits and information on them.

• There are ties between the IV model and the software development and product engineering process model — e.g., incremental development,

evolutionary delivery.

© Copyright IBM Corporation 2010

IBM Corporation

Software Group

Route 100

Somers, NY 10589

U.S.A.

Produced in the United States of America

March 2010

All Rights Reserved

IBM, the IBM logo, ibm.com and Rational are

trademarks or registered trademarks of International

Business Machines Corporation in the United States,

other countries, or both. Other company, product, or

service names may be trademarks of IBM or other

companies.

A current list of IBM trademarks is available on the

Web at “Copyright and trademark information” at

www.ibm.com/legal/copytrade.shtml

The information contained in this document is

provided for informational purposes only. While

efforts were made to verify the completeness

and accuracy of the information contained in this

documentation, it is provided “as is” without warranty

of any kind, express or implied.

RAW14212-USEN-00

What CFOs should ask their software development leaders

Technology

Transcript of What CFOs should ask their software development leaders