How Do I Sell IT Services to My Organization?

Scope of this Report

This report discusses the challenge Information Technology professionals face in marketing and selling their capabilities to their peers, or internal clients and how to meet that challenge in order to remain competitive in the ever commoditizing world of technology.

Bill Gates is Right…

“Information technology and business are becoming inextricably interwoven. I don't think anybody can talk meaningfully about one without them talking about the other.”

While Mr. Gates and his wife Melinda have moved on to philanthropic work, his insights that helped launch and build Microsoft into a historic IT provider remain cogent, especially the quote above.

The primary challenge IT professionals face in marketing and selling their IT services is not tactical but strategic, they must understand the company. IT professionals, at any level, have to master the core principles of the business value the company provides to its customers and how IT is related to supporting or generating that value.

Let’s take two well-known companies, 3M, and SAP. The 3M Company, formerly known as the Minnesota Mining and Manufacturing Company, is an American multinational conglomerate corporation that produces a range of products including adhesives, abrasives, laminates, passive fire protection, dental products, electronic materials, medical products, car care products, electronic circuits and optical films. SAP America is the American subset of SAP AG; which is based out of Germany. SAP is a software development and consulting corporation. The company's best known product is its SAP Enterprise Resource Planning (SAP ERP) software.

They are two vastly different companies but both rely on technology, today more than ever. 3M makes products and associated services and uses technology to support all facets of its business. SAP provides enterprise resource planning software for its customers and has to navigate the technology landscape to remain competitive. Software is a product but not a hard goods one, such as a pad of sticky notes. Software is an information management tool that manufacturers, like 3M, use to make its products.

An IT professional working for 3M and one working for SAP face different challenges in selling IT services internally but have one thing in common that will spell success or failure in their efforts. Each must understand EXACTLY what value IT (or their proposed services idea) will have to the business to grow revenue, optimize delivery or reduce costs. If an IT professional cannot monetize the value of the proposed IT services in a way that serves the greater good (corporate profits) then the sales conversation will have problems advancing to a decision.

Know Your Business

3M is a product manufacturer that often sells ancillary services to enhance its revenue beyond the one-time product sale. An IT professional well-versed about the business side of IT could discover some fact about the business that was costing the company money and could propose an IT solution to address the issue.

For example, suppose 3M, in delivering some of its liquid and purification products, only charged for the liquids or gas, supplying the cylinders for free. The bright 3M IT professional proposes a new customer cylinder tracking system to determine how many empty cylinders were at customer sites that could be filled and used to generate revenue. This information could then be used to create incentive or fee charging programs to manage the floating cylinder inventory.

Just such a similar scenario occurred for Merck, the giant French pharmaceutical manufacturer. In the mid-1990, they were able to identify this opportunity to go from free to fee in charging for their services associated with their products. Identifying the opportunity was key. It is uncertain who within the organization identified this issue, but whatever information systems data was used to make the business case, the business value was apparent.

Marketing and Selling: Not the Same

Selling IT services to your organization starts with understanding the business value IT provides to the business. But opportunities like the one hypothesized above with 3M require a pro-active mindset, timing and good internal soft-skills to sell your idea. However before try to sell any idea, you have to shape your potential client’s mindset about IT in your favor through marketing, which is not selling.

Marketing is about connecting with your internal customer in ways that have little to do with making a decision and all about an emotional connection. To make that connection, in today’s e-mail and social media driven world, you have to be consistent in communications that reinforces the positive contributions a group makes, whether it is IT, HR or accounting. It not about spin or hype, it’s about telling true stories that shine a good light.

Furthermore, internal marketing is an important activity every IT group should undertake to change their current brand. Brand? IT has a brand? Yes. For good or bad, every IT group has a brand that lives in its internal customer’s minds and hearts. Changing that brand (yes it takes time and effort) to one that works in your favor will make for a more receptive environment when “selling” an idea downstream.

Selling is About Value

Your internal customers now have more options to purchase or acquire IT outside of the organization. It’s a constantly competitive world and a new reality for many IT professionals. In order to compete you have to develop not only a business value perspective but also a salesman’s discipline in communicating why the internal IT group is the best choice, overall, than any other option.

Assuming your marketing efforts have helped lay the foundation for a dialog about IT’s value and capabilities, how do you “sell” your IT services to your organization.

Let’s assume the bright 3M IT professional in our example above shared his story with his friend who works at SAP over a lunch. The SAP IT professional mulling over the success of changing free to fee (on the cylinders) gets the notion that their current software development environments, being shared with acquired companies (many of them) at no charge, is costing central IT quite a lot. Charging the acquired companies, using some formula, would improve IT’s cost profile. However, the acquired companies are also customers of central IT and pay for other services and would not welcome new costs. How do you sell this idea?

The IT professional now is a salesman who has to create a value proposition, using business terms, on why this new chargeback structure helps everyone. However before any PowerPoint or excel spreadsheet is put together to define who, what, when, where, why and how, the first thing the IT professional must do is secure executive sponsorship with a monetized argument. He must prove why, in dollar terms, is this change needed. Change is hard for any organization, more so for larger ones. There must be an economic reason to incent everyone to endure the change.

Once executive sponsorship is gained, the next steps include

  1. Gaining consensus on the why not the how with the key influencers in the organization through personal contact and appeal
  1. Facilitate “how could this work” meetings with all the key stakeholders in the proposed changed allowing them to shape the potential implementation
  1. Design a proof-of-concept exercise to build quantitative economic data about the proposed change involving a small subset of the key stakeholders
  1. Present the results of the proof-of-concept back to the executive sponsor and the key stakeholders to secure the all-important, “Let’s do this or not” decision.

By the time step 4 is complete, the idea will either sell itself or be put on hold or killed because the economic value is not there. This process allows the idea’s merits to be tested before being implemented saving an organization time, trouble and money.


Selling your IT services to your organization is less of a tactical challenge than it is a strategic one. While there are many best practices such as service catalogues, chargeback schemes and other mechanism’s they address the engineering challenges instead of the business value proposition. To propose more value, you have to know your business and how to improve it in economic not engineering terms. Before you embark on selling an idea, make sure your internal brand is solid enough to support the impending conversations. Selling your business value rich idea then becomes an exercise in consensus building and so that the decision maker can be comfortable that they have everyone’s support (or at least everyone important!).



  1. Bill Gates on IT and Business,
  2. Harvard Business Review On-line, How to Sell Services More Profitably by Werner Reinartzand Wolfgang Ulaga, May 2008 Issue,
  3. Computerworld, Marketing IT: Sell your services internally, win more respect, Mary Brandel, Sept 7, 2009, management/marketing-it--sell-your-services-internally--win-more-respect.html?page=2
  4. Harvard Business Review On-line, Selling the Brand Inside by Colin Mitchell, January 2002 issue,
Written by Default at 05:00
Categories :

Why Are So Many of Our Projects Late, Over Budget or Deliver Less Than Was Promised?

Scope of this Report

 This report identifies evidence that projects are late, over budget or deliver less than promised? It then considers various potential causes for these failures including culture, process, and estimation and how getting these things right can contribute to success.

What evidence is there that projects are late, over budget or deliver less than promised?

Most organizations develop business cases to initiate change1. These business cases require narrative explanation of the change and the associated financial return on investment.

Dan Galorath, noted software estimation expert, cites government data, “A recent US governmentreport showed 81% of budget or $57 billion in IT projects in danger of failing. Detailed reports on the hearings can be found here. Of 413 IT projects identified by OMB and federal agencies NEARLY 80% OFTHEM WERE IDENTIFIED AS HAVING BEEN POORLY PLANNED. The scorecard for IT projects shows muchprogress but much work left to do.”

The PMI Pulse Report 2014 pointed up some stark statistics. “Only 56 percent of strategic initiatives meet their original goals and business intent. This poor performance results in organizations losing $109 million for every $1 billion invested in projects and programs. High-performing organizations successfully complete 89 percent of their projects, while low performers complete only 36 percent successfully.”

Culture, Process or Estimation Issue?

Are process, culture or estimation responsible for the failures? Any or all of them can have a significant impact on a project’s performance. The tendency is always to blame the supplier for the failure – ‘Company X failed to deliver the ABCD project on-time for the XYZ government’, is not an uncommon headline. In truth it’s normally a combination of all three.

We need to look at potential sources of failure from several directions


  • Culture: Is the organisation working as one towards a common, transparent, communicated goal?
  • The Governance Process: What decisions need to be made, who makes them and are they tracked to completion?
  • Backlog Prioritisation and Change Control: Was there a product backlog or its equivalent effectively managed and prioritised?
  • Is estimation effective?: Are estimates based on facts or opinions?
  • Is the development model effective?: Agile, Iterative or Waterfall methods are found, but are they effectively policed?

Weaknesses or failures in any of the above will put a project at risk. It is incumbent on both the supplier and Business teams to ensure that there are strong robust processes in place to de-risk the project.


The PMI Pulse report consists of responses to a voluntary questionnaire and is therefore self-selecting, but it is a valuable resource for discussion of what seems to be a constant refrain over the years.

The clear message of the report is that the most successful organisations in terms of project delivery have strong processes backed by effective measurement and project management offices.

Success comes on the back of success. Companies with effective traditional development methods can adapt quickly and effectively to agile methods. The key here is the word “effective” – Kotter suggests that without urgency, transformation cannot happen – and change is harder for some companies than others. The whole organisation adopts agile because of effective leadership, visible sponsors and a commitment to succeed. Such organisations are either consciously or culturally Lean. To them facts influence decisions; changes to process are tracked and monitored, and successful change remains while unsuccessful change is found early and discarded. During projects deviations from the norm are analysed and corrections are made. Projects seldom fail.

Contrast that with poor process organisations that change methods to follow the latest trends. For them a change in process is an excuse for chaos. Typically we see blame cultures, with poor communications and absent sponsors. Use of metrics is poor and often concentrates only on cash and time to market. If a project falls behind schedule the typical response is to throw people at it. Hordes of heroes are bound to help. Once again we have people repeating the same behaviour expecting a different result. That’s the definition of insanity often, incorrectly, attributed to Einstein. Whoever said it was right. In this instance insanity comes from not analysing reasons for failure but looking for quickv“obvious” answers, and doing that repeatedly.

Process – Governance

We look for an IT governance framework which has similar characteristics to the model proposed by Weill and Ross in 2004:

  • Identify what decisions you need to make;
  • Identify who makes those decisions – an individual;
  • Identify how those decisions will be made e.g. what data is needed, who else should contribute opinions.

Effective organisations have clear governance based on effective leadership and visible sponsorship. They avoid committee decision making and clearly communicate decisions. Crucially they have effective monitoring and measurement activities so that deviations from course are made knowingly or are corrected quickly with little drama.

Process - Development methods

All development methods demand process. Some, such as waterfall, can be process intensive. Agile by contrast is process light, but it’s not process absent. Rather, we can say that Agile is less prescriptive.

Many effective organisations use waterfall or iterative development with defined methods backed by strong metrics and effective reporting. The best performers can adapt to agile when it fits the situation and they continue to be successful.

Agile works best when thought of as a lean process and that means that once you commit to build some user functionality you should do it only once. That means taking a disciplined approach to defining the minimum marketable features, refining the product backlog and delivering sufficient documentation to enable maintenance. It can become a game in ineffective organisations.

Two conversations, which we have had recently, underscore the need for discipline in the use of agile methods. In both cases the productivity related to delivery of functionality was defined as low. When probed, the reason is that both organisations were content to develop and re-develop the same functionality a number of times – to get it right in the end. The business and the development teams seemed to accept that delivering a business change using agile methods allowed for infinite changes of mind. This adoption of agile is not cost effective and gives rise to concern about how effectively agile methods are being used. Instead of the oft-quoted “paralysis by analysis” we see in waterfall, we have “endless enhancement,” and in either case a lot of time, energy, creativity and money is wasted.

Again the lesson is that effective development methods work to their maximum potential when the right amount of control and monitoring of progress is applied. Measurement and reporting is often seen to be an overhead and expensive. We have found that effective measurement and reporting consumes about 1% of project budget (1.5% to 2% on small projects and as low as 0.5% on major programmes). Companies that want to use facts to manage recognise this as money well spent as it enables effective management. Those that look for easy cost-cuts generally take out “overhead” first preferring to chart their course through the icebergs in the dark with a small rudder.


Estimating is difficult and the key thing to remember is that it is only an estimate. Often these become written in blood as the initial and final answer. Estimates should be a living thing throughout the project and should be revisited when either something significant changes in the project or when we know sufficiently more to refine the estimate.

In a waterfall development, estimates should at least be performed at Requirements, end of High level design, the start of Construction and reviewed at implementation. Just because Agile doesn’t have the traditional phases, early estimates are still important, and just as useful.

However, estimates can be revisited any time during the lifecycle such as when requirement shift or other variables come into play which will impact originally stated outcomes.

Failure to review and maintain project estimates means you can’t manage risk or use any contingency.

Early Estimates and the Challenges

Early in the project lifecycle, cost and schedule estimates are generated based on best information available. As is often the case, this information is lacking in detail and most likely is ambiguous. This presents several problems for the estimator. For example, ambiguous requirements make it difficult to determine a proper size.

However, by making and documenting stated assumptions, the estimate produced early in the lifecycle can be effectively managed and customer expectations can be properly set.

What Should Estimates Be?

Estimating is a risk assessment activity. The wise project manager can use a well-developed project estimate to properly set and manage end user expectations. Transparency is the watchword here. By sharing stated assumptions with the user and by helping them to understand the basis for the estimate, you are engaging them and making them share in the accountability for the estimate.

For example, if they are aware that the estimate is based on their requirements and the general feeling is that the requirements are somewhat incomplete then it can safely be assumed that another estimate will be required when more data is available and that the new estimate will probably be different from the original estimate.

“I want it delivered NOW!”

This dynamic shows itself, not so subtly, when management doesn’t really want an estimate at all; they want the software delivered when they want it delivered.

How many times have we seen a situation where the sales/marketing group, the business users or even our own senior management has requested a software solution that has a fixed delivery date already attached to it? And even though the user or senior manager may ask for an estimate they really aren’t interested in the response unless they are told what they want to hear or alternatively the supplier is told what the answer already is.

In this type of management environment, the IT organization doesn’t invest much time in their estimating practice because they don’t realize the power of good estimation as a vehicle to properly manage the project and/or their customer’s expectations. The net result is the best endeavours by the IT organisation in a blind attempt to deliver the requirement and usually a project starting with a high tariff of risk.

Expert Estimates?

One perceived problem that is seen in expert estimates is that of memory. Estimates based on memory are subject to the cognitive bias of the estimator therefore involvement of others provides a balance that helps to cancel the potentially negative impacts of bias.

Single expert estimates tend to be either too high or too low depending on the estimator responsible and the culture, for example, the Scotty from Star Trek syndrome (bias) creeps into play with expert estimates. The seasoned estimator estimates high knowing it’ll be corrected anyway by the PM and the ultimate result may be a sensible figure.

The other typical scenario is it is easy for the expert to estimate how long a piece of work would take him to do but when he has to estimate for less experienced colleagues then it’s much more difficult to achieve so we tend to get under-estimates.

Don’t accept just a number for the estimate, three point estimates and the estimate assumptions are a key way to review and validate estimates.

Use of three-point estimating techniques also allows a more reasoned view of the estimate. In reality usually when we estimate we always think of a range –how long does it take you to get to work each day it might be 30 minutes on average but 20 minutes with quiet roads and 50 minutes in rush-hour. So combining all three estimates (Optimistic of 20, Average of 30 and Pessimistic of 50) gives you a much better view of the risk and what contingency you may need to use.

Expert estimates are a key estimate to obtain but there is great value in obtaining another estimate to reconcile this estimate against.

In the Agile space, the benefit of normalizing various experts estimates is often formalized through “planning poker” which constrains the estimate values that experts are allowed to choose and then requires the experts to justify and ultimately reconcile their estimates with each other. Given how effective it is in Scrum planning, the same process could and should apply more widely to expert estimates in general.

How Else Should We Address the Estimating Issue?

We can view popular estimation techniques through two separate perspectives: data and algorithms. First, from the perspective of experiential data / historical data and algorithmic / collaborative techniques, we see that many of the experiential based techniques leverage collaborative techniques to combat perceived weaknesses.

Historical data is used both in model based and expert estimates. Estimating without memory of the past is not possible. The bigger issue is whether models derived from historical data are clearly superior to expert estimates. If you are trying to remove the need for expert estimators the answer is unfortunately ... no.

Finally what is true is that expert estimates require a level of expertise that is sometimes not readily available, which then requires leveraging tools to be used to validate estimates. If estimates are important and the required level of expertise is not available then the choice is far starker. Estimates generated from models leveraging historical data in calibrated tools are the only logical choice.

Volatility and the Impact of Change?

Another key characteristic of a failing or delayed project is the degree of volatility and change. Studies show the exponential rising cost of change as you get in the later stages of a project particularly with a Waterfall methodology.

Agile is designed to accommodate change but change can occasionally be an excuse to use it as in, ”I don’t need to know what I want, I can keep changing my mind and we’ll be fine if we use Agile” can be a client view. This can lead to the same “priority” story being redeveloped multiple times until the client has worked out what they want and the Agile project fails because it runs out of time or money. Is the methodology at fault? Of course not but perhaps a requirements or design “spike” could have been implemented with the client to help them clarify their ideas.

Governance of change is the key, if you know what the business is going to look like at the implementation of the project then the project will control change and is much more likely to succeed.

Deviation from the Norm?

Often, changes to applications with regular release cycles tend to be of a similar size with the same team doing the work. The expert estimates roll into complexity matrices and sensible size metrics and all should be well as long as the estimators continually update their historical records and test the results against external databases. We still see the same mistakes repeated in the hope that a miracle will happen.

The challenge is when we deviate from the norm. Compressed timescale, significant increase in size will invalidate the current estimating methodology in the project. People will assume we can deliver at the same rate and the project is set to fail.

Lawrence H. Putnam published an empirical software estimation model in 1978. In the formula noted below, Size is the product size (whatever size estimate is used by your organization is appropriate). Putnam uses ESLOC (Effective Source Lines of Code) throughout his books.

  • B is a scaling factor and is a function of the project size.
  • Productivity is the Process Productivity, the ability of a particular software organization to produce software of a given size at a particular defect rate.
  • Effort is the total effort applied to the project in person-years.
  • Time is the total schedule of the project in years.

In practical use, when making an estimate for a software task the software equation is solved for effort:

Parametric estimating toolsets understand the likely impact and use this or their own bespoke calculation engines to deal with this and can make a major contribution in increasing the change of success in a project by setting realistic expectations.

Tracking and Monitoring

The final area to consider is effective tracking and control of the project. Continuous review of the projects velocity (Agile) or rate of delivery (Size measure per time period) will indicate the projects real status and chance of success, for example, if the development team report the project is 80% complete 3 weeks in a row then the project is likely in trouble.

Again the PMI report indicates that organisations that deliver successful projects, irrespective of the methods used, tend to have functioning and effective Programme Management Offices (PMO) and theses PMOs gather and analyse data effectively to support the successful delivery of business initiatives.


There is no need for projects to be delivered late, over budget or with less scope. These statements come from organisations that don’t understand that the light in the tunnel is actually a train coming full speed at you.

Successful delivery of a project requires a culture of effective business processes, effective estimation and sound development processes.

Strong business processes linking, effective business vision, realistic expectations and close communication between the vendor and supplier are key elements in successful delivery.

Development methods are only as good as the organisation that uses them. Whatever end of the process spectrum, it’s the effective use of the end to end processes that delivers the goods without drama.

The fundamental transformation of the idea to money comes with the estimate. Good estimates are living things that change with the circumstances.

Effective estimation requires an organization to commit resources to the development and execution of a well-defined software estimating practice, backed by a PMO that delivers effective data analysis.


  1. Dan Galorath on Estimating Blog,
  1. PMI Pulse Report 2014:
  1. “IT Governance: how top performers manage IT decision rights for superior results.” Peter Weill and Jeanne Ross 2004
  1. “DCG Works With Leading Customer Management Company to Implement Measurement and Governance Program for Data-based Decision Making” /insights/publications/measurement-program-for-data-based-decision-making/Is there a Business Case for Better Estimation? DCG Trusted Advisor Report, July 2013
  1. “What are the benefits if any of estimating my software projects through the use of a vendor developed estimating model?” DCG Trusted Advisor Report, July 2014
  1. Putnam Model
Written by Default at 05:00

Is Calculating ROI Meaningful for Agile Projects?

Scope of this Report

This report is not about ROI of agile methods versus other SDLC’s. Instead, we consider if the traditional approach to producing business cases for projects or programs by predicting financial outflows (project costs) and financial inflows (new income of savings) is still appropriate or even meaningful for agile software development based on scrum and/or enterprise wide extensions of scrum such as SAFe or DSDM.

Definition of Return on Investment (ROI)

Definition Of ROI

The Traditional Approach to ROI

The traditional approach to justifying software development investment has been to draw up a time line of predictions of project costs and project income or savings in the form of displaced current costs. The “go – no go” decision is then based upon company targets for one or more of simple ROI, Cash-on-cash return, payback period, cost of money or some other similar measure. ROI has always been useful for comparing alternative projects or investments when funds are limited, as they almost always are!

Appropriate Granularity for ROI

Traditionally, we have worked with software development projects which are sometimes aggregated up into programs. Of course, there is no universally agreed definition for these terms and different organizations have had different financial cut-off points above which investments in projects/programs require business cases and for which those business cases must return a minimum ROI to proceed. Once a commitment has been made to fund a project /program based on a business case, there is an expectation (however naïve) from stakeholders that all of the elements of the software needed to deliver the estimated financial returns will be completed with a manageable increase in estimated costs. Any other outcome threatens the viability of the original funding business case. Perhaps it is for this reason that few organizations track the actual cash flows from projects very carefully. Or perhaps it is simply that the asynchronous nature of the cash flows - “out” during the project but only “in” when the software is employed by the business – is beyond the attention span of both IT and the business. This is a gap that Finance could fill.

In contrast, for Agile software development where most organizations start with Scrum, the future workload is represented by a backlog of epics that break down into user stories which form the incremental deliverables. Stories, by design, are much smaller units of work than projects (see Figure 1):

Figure 1: Contrasting models of value delivery (Source: Scaled Agile Inc.)

A Stark Choice Of Approaches

In Tara Hamilton-Walker’s blog post in 2009 on “Self-funding Projects”, she notes, “In reality, it is unlikely that you would/should take the time out to calculate the ROI for each story.” Indeed, the incremental delivery of value raises some important questions that go to the heart of the title of this report:

  • Is it possible to associate future income/savings with a single story? We agree with Hamilton-Walker – while it may be possible it is almost certainly not practical.
  • Is it worth investing in the cost of building a business case for an individual story? Again, no.
  • Can we conclude that it is not meaningful to calculate ROI for Agile Projects? Not yet – but we do have to get away from the concept of “Agile Projects” and consider further the appropriate level of granularity for ROI for Agile Software development at the epic or functions (which might be groups of epics) level which are business recognizable.

One approach to calculating ROI for Agile

In her blog post, Hamilton-Walker goes on to assert that one of the biggest benefits of developing software in an iterative or agile way,

“… is that you can start realising the benefit of your work before the project is officially ‘finished’. The objective is to front-load the project with the most profitable or highest value deliverables and release them as soon as possible so that they can start making money for you. If you’re using a Lean approach, you’ll release them as soon as they’re finished, if you’re using a Scrum approach, you’ll cluster a few into one (or more) releases at the end of each iteration.”

This concept of delivering value early and continuously is one of the foundations of Agile (See Figure 2) and the breaking down of enterprise level demand (and cost) into lower level backlogs then ensuring that the resulting value (income or savings) is a critical benefit of the Scaled Agile Framework® (SAFe).

Figure 2 Value Flow from Agile (Source: Scaled Agile, Inc.)

Makes Money Faster

Figure 2 also illustrates another benefit of Agile from a ROI perspective by identifying the diminishing market value of a feature over time. This effect is separate from and additional to the use of Net Present Value (NPV) in ROI calculations.

In his blog post, Steps for Calculating ROI on Agile Projects, Richard Banks identifies a key challenge with calculating ROI for Agile at the higher levels of granularity, the final scope of the deliverable at any given future time point is not fixed. As he states, “In an agile project requirements are often discovered, adapted and/or changed completely as the project progresses and very little up-front design work is performed as a result, unlike traditional methods that work on the belief that requirements can be defined up front and then fixed for the duration of the project.”

Banks proposes using the Product Backlog as the appropriate aggregation of stories for ROI. He suggests an initial ROI calculation can be done broadly as follows (with our proposed modifications included):

  1. Gather the initial high level requirements for the project (presumably the project is describe as a theme or one or more epics) and place them in the product backlog
  2. Get the team to estimate sizes for the requirements individually at a high level using story points, or whatever unit of measure they are comfortable with, but keep it high level and estimate quickly.
  3. Examine the overall size of the product backlog. If the size seems too large at the start, then it probably is. Before proceeding either look to cull items from the backlog, or cancel the project.
  4. Work out your starting velocity (i.e. how many points your team completes in a sprint). If possible, get approval to develop one item (or a few) as a proof of concept exercise - this often helps determine what the initial velocity of the project is likely to be.
  5. Extrapolate from your initial velocity how many sprints will be required, and thus what the cost will be.
  6. Find out from the business the following income or savings metrics:
    a. One or more units of measure in which the income or saving will be denominated e.g. “new subscribers added” for a website
    b. The number of units of value associated with delivering all, or subsets of, the Product Backlog e.g. this story/group of stories/epic will deliver 100 new subscribers
    c. The actual monetary value of delivering a unit of value at particular dates on the project timeline and beyond e.g. Each 10 new subscribers are worth $10 on March 1, $15 on April 1, $20 on May 1, $15 on June 1 and so on.
    d. The cost of delay, if any, of delivering all, or subsets of, the Product Backlog e.g. this story/group of stories/epic will deliver cause us to pay a fine of $2000 if we do not deliver by August 1 or this story/group of stories/epic will deliver cause us to pay a fine of $2000 if we do not deliver by August 1 be worth nothing if delivered after the Christmas sales season.
  7. Use the estimated time, income, savings and cost figures to determine your ROI.

Of course, the product backlog, income and saving metrics and velocity can and will change and that must trigger recalculation of the ROI. When? It is appropriate to calculate the sensitivity of the business case to changes in the underlying metrics and set up allowable ranges of fluctuation for individual metrics, beyond which the ROI must be recalculated. It is certainly not Agile to continue to pursue a theme, epic or even story for which there is no longer a business case. It has to be said that while Product backlog grooming and sprint reviews should guard against this happening by providing fast feedback from stakeholders, it is often the case that these activities focus on functional and user experience issues more than economic reviews.

More Thoughts on Granularity for ROI

Now that we have an approach for calculating ROI for Agile, it is worth considering the appropriate level of granularity further because our calculation approach involves cooperation, or at least coordination, between the development group and the business sponsoring the development. Various organizations implementing scrum have found it difficult to get commitments from the business for the day-to-day involvement necessary for the Product Owner role. This may be due to lack of resources or lack of understanding or some other reason embedded in the traditional corporate culture (and budget). Building and tracking business cases in the past was a business function or a PMO function. The PMO may no longer exist in an Agile organization so moving to ROI from business cases with Agile implementations will require some education and will need to recognize that the effort required will only be justified at quite high levels of aggregation – the assumptions required to operate at this high level of aggregation will seem quite contrary to Agile principles at first.

SAFe addresses this challenge by defining “Product” and “Portfolio” levels of aggregation above the “Team” level characteristic of Scrum. Business cases are made and long-running (longer than a typical project or release) “trains” of scrum teams are funded at the Portfolio Level.

One of our clients takes a different approach by using a hierarchy of story types in which high-level “Demand Stories” correlate closely with business cases at the business-development interface. These Demand Stories are then broken down successively into Customer Experience Stories, Component Stories, Engineering Stories and so on. Their experience with this approach has led to them building a rule into their story management system that only complete Demand Stories can be progressed through their Kanban stages. That is, all of the subsidiary stories must be complete before any one of them can be progressed because too often subsidiary stories were worked on in isolation but the expected business value could only be realized when all the subsidiary stories in a Demand Story were delivered. The phrase “orphan CE stories” barely hints at some of this issues that can occur if some such rule is not in place. But, again, many people think that such a constraint is in conflict with the principles of agile.


We believe that it is meaningful to calculate ROI for Agile “Projects” but only at an enterprise or portfolio level. Further, we have demonstrated that it is not a trivial exercise. Finally, we believe that the risk of funding long-running projects which turn out to have limited business value is much smaller with Agile than with Waterfall or other SDLCs.

The report is available for download here.


  • “Self-Funding Projects – A Benefit of Agile Software Development”, Tara Hamilton-Whitaker, July 22, 2009,
  • “Foundations of the Scaled Agile Framework®” Presentation, ©Leffingwell et al. © 2014 Scaled Agile, Inc. (with permission).
  • “Steps for Calculating ROI on Agile Projects”, Richard Banks,
  • “The Business Value of Agile Software Methods: Maximizing ROI With Just-in-time Processes and Documentation,” 2009, by David F. Rico, Hasan H. Sayani, Saya Sone.
Written by Michael D. Harris at 05:00
Categories :

What Is Lean Software Development?

Trusted Advisor

This month's Trusted Advisor report is all about Lean Software Development. Unfamiliar with the term? This report is for you!

Download the report for a definition of Lean Software Development, including key characteristics. You'll also learn the similarities and differences between Lean Software Development, Lean Manufacturing and Lean Six Sigma, as well as how traditional waterfall and Agile (primarily scrum) approaches to software development can be considered “Lean Software Development.”

More information on how to join Trusted Advisor is available here.


Download the Report

Written by Default at 05:00

How Do I Size My Non-Functional Software?

Most organizations are familiar with functional software sizing, using it to effectively manage and control project delivery. DCG offers this via IFPUG function points and COSMIC function points.

However, not many organizations realize that there are also techniques for sizing non-functional software. Luckily, a Trusted Advisor member submitted the question, "How Do I Size My Non-Functional Software?" to the Trusted Advisor question backlog, and it was voted as the topic for this month's report.

Check out the report to learn why you would want to measure the non-functional components of software, the measures that should be used for sizing, as well as how to implement those measures.

More information on how to join Trusted Advisor is available here.

Download the Report

Written by Default at 05:00
Categories :

"It's frustrating that there are so many failed software projects when I know from personal experience that it's possible to do so much better - and we can help." 
- Mike Harris, DCG Owner

Subscribe to Our Newsletter
Join over 30,000 other subscribers. Subscribe to our newsletter today!