“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.

1. Executive Whitepaper
March 2010
What CFOs Should Ask Their Software
Development Leaders
Peter Spung
Director, Strategy, IBM Rational Software

2. Executive Whitepaper
Page 2
“Without changing our patterns of thought, we will not be able to
Contents solve the problems we created with our current patterns of thought.”
- Albert Einstein
3 What is the missing context for
these discussions?
4 Projecting financial measures Discussions between chief financial officers (CFOs) and heads of IT
5 Costs and benefits of the departments most often center on the the funding of projects, or need to
investment, and associated risks continue funding, as if a simple commodity-based relationship existed between
6 Software project investment fiscal outlay and value received. But this “pattern of thought,” to use Einstein’s
models involve multiple cost and term, hinders a much more productive mode of discussion that these two
benefit streams over a long life business leaders might engage in. In this paper, I will illustrate a new way of
8 The investment value of a project thinking about the funding of IT software projects, one that considers funding
changes over time, and could in terms of investment, and value as an expansive, longitudinal variable.
improve through a better
understanding of its past Let’s begin with a scenario you may find familiar.
performance and future risks
10 Investment models reflecting cost After an already long day of meetings about budget over-runs, our CFO
and benefit ranges that factor in Jim faces the prospect of yet another monthly drain on his software project
risk, and the time value of money expenses, not to mention his personal stamina. On the monthly agenda are
(eg, NPV) look promising budget requests typical of projects in his software development leader Mike’s
12 Now, the questions a CFO should organization: upgrades gone awry, projects behind schedule, enhancements
ask the software development needed to existing systems so they perform as expected, and the like. Through
leader his connections and regular dialogs with other CFOs in the region via their
12 Call to action industries’ association, Jim knows this is not unusual, and Mike is no villain. If
13 Further Readings he is, so is every other software development leader in this part of the country.
13 About the author
14 Key concepts covered in the But something gnaws at Jim as he trudges to the meeting room, contemplating
narrative 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. Executive Whitepaper
Page 3
Yet for some reason, they never talk about that in the monthly meetings.
Highlights 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
Sometimes additional expense little to show for them, making future requests necessary and painful. It
requests have increased over long also calls into question Mike’s understanding of the value and reliability
periods with little to show for them, to deliver. Even if the projects do finally complete and deliver, it’s still not
making future requests necessary clear they met their intended purpose and value to the organization.
and painful.
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
From the beginning, the budget was an iron-glad guarantee that the additional funding will complete the proj-
a precise figure, guaranteeing a fixed ect, with certainty, despite all experience to date. The more you reflect on
set of returns and benefits for the this, the more you realize this pervades the thinking around these projects;
project. Is that the way it really works? 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.

4. Executive Whitepaper
Page 4
Projecting financial measures
Highlights After 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,
What was surprising was not the gap and she is visibly anxious and eager to meet. Something’s clearly gnawing
between the initial project estimates at her, too, and before Jim can ask, she describes her findings. Susan found
and the actuals, but that for the that some of the project managers were diligent about keeping data on their
collection of projects, (a) the bigger projects. Not only did they have actuals on the key measures for the projects
the project's budget or number of that had ended, they had “snapshots” of the planned measures at monthly
requirements, the wider the range intervals. Jim thinks that’s at least one benefit of the monthly meetings with
between estimates and actuals, Mike. Susan plotted them over time and against some of the key measures
and (b) over the life of the project, such as expense budget. What was surprising was not the gap between the
the ranges narrowed. Now that's an initial project estimates and the actuals, but that for the collection of projects,
insight. (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.

5. Executive Whitepaper
Page 5
Costs and benefits of the investment, and associated risks
Highlights I 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
Occasionally, one of the senior senior executive stakeholders about the return on that investment. Occasion-
executives on your team will ask ally, one of the senior executives on your team will ask questions related to
questions: What's the likelihood the Susan’s findings: What’s the likelihood the project will return what’s esti-
project will return what's estimated? mated? What are the underlying risk factors and assumptions that could
What are the underlying risk factors affect that outcome? What have we learned from prior, similar projects that
and assumptions that could affect could help our understanding? Susan and Jim are onto something - trying
that outcome? What have we learned to contemplate the risk/reward profile of the project, and reason about how
from prior, similar projects that could to act to reduce the risks and increase the likelihood of the return. Those
help our understanding? 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
Estimates behave like ranges and make an investment later — to finish and deliver the project. And despite point
typically narrow over time. So treating estimates of “an average 7% return,” you know well that there’s a range of pos-
them as point estimates doesn’t reflect sible returns and a standard deviation that expresses the risk, or likelihood, of that
reality, nor does fixing them at one return. They narrow over time as more information is learned about the project,
point in time. 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?

6. Executive Whitepaper
Page 6
Jim realizes that the way he’s been thinking about Mike’s projects is not
Highlights 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 life
Susan can relate. She mentions that at her last organization, they were
A software project has a long life. zeroing in on a couple of key ideas that seemed promising. One was that
You should establish a funding or a software project has a long life, as it includes development, operation,
investment model over that entire maintenance, and upgrades over many years. They should establish a
period that treats the costs and funding or investment model over that entire period that treats the costs and
benefits as several quantified and benefits as several quantified and monetized streams that, when summed up,
monetized streams that, when yield the elusive return on the investment in the project. That’s clearly the
summed up, yield the elusive return value of the investment. Sure, it’s hard to do, but they’ve recently stumbled
on the investment in the project. on some approaches to measure just about anything in business, including
That's clearly the value of the intangibles, that seemed promising. For example, investment models are
investment. 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.

7. Executive Whitepaper
Page 7
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.

8. Executive Whitepaper
Page 8
The investment value of a project changes over time, and could improve
Highlights through a better understanding of its past performance and future risks
When 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
A complete forward looking view 30 years. A complete forward looking view of the expected costs and benefits
of the expected costs and benefits would reflect the long life span, as would a backward looking accrued view.
would reflect the long life span, as The forward looking estimated costs and benefits vary among the team mem-
would a backward looking accrued bers and leaders who have an expert opinion about them. When discussing
view. The forward looking estimated this with them, you’ll often hear, “In the best case it will be (this) amount,
costs and benefits vary among the and in the worst case (another) amount. My best guess and most likely is that
team members and leaders who have it will be an in-between amount.”
an expert opinion about them.
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.

9. Executive Whitepaper
Page 9
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.

10. Executive Whitepaper
Page 10
Investment models reflecting cost and benefit ranges that factor in risk, and
Highlights the time value of money (NPV) look promising
Then 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
The costs stream actuals could end stream, and added them together. Jim’s stunned: the project has a negative
up being a mix of most likely and total NPV. The costs outweigh the benefits; it has no value, and is not worth
worst cases, and the benefits actuals investing in. Not wanting to fall back into his old “point estimate” think-
a mix of the most likely and best ing, he asks Susan about her findings related to ranges and risks, and she
cases. 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.

11. Executive Whitepaper
Page 11
There’s one last question on Jim’s mind, and he asks Susan where the
Highlights 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-
The goal is to deliver some benefits able sooner by the ones who matter most: the end users of the system and
of the software and systems under its operations staff. In doing so, more information gets uncovered about the
development as early as possible, risks of futures costs and benefits, so investments addressing those can be
so that more of the most valuable prioritized and managed.
benefits become measurable sooner
by the ones who matter most: the Susan says the project manager was really inspired by this new approach.
end users of the system and its Project managers associated with projects that over-run budgets and yet
operations staff. 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.

12. Executive Whitepaper
Page 12
Now, the questions a CFO should ask the software development leader
Highlights Are 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 action
IBM takes this approach in its own Did this paper start to change the way you think about software and systems
software organizations, and we've projects? Do you want to start asking questions and reasoning about your
made progress on an approach that projects and programs this way? Are you already? IBM takes this approach
will help you adopt similar strategies in its own software organizations, and we’ve made progress on an approach
for your teams. that will help you adopt similar strategies for your teams. I’d like to hear
from you. Please write to me at paspung@us.ibm.com.
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.

13. Executive Whitepaper
Page 13
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 author
Peter 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.

14. Executive Whitepaper
Page 14
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.

15. © 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