How can we get more value out of software development? An introduction to value visualization

Transcription

1 How can we get more value out of software development? An introduction to value visualization The Problem The title of this white paper is a common refrain amongst heads of business units in major corporations. In many cases, it is a fair question. Generally, IT management is not focused on value delivery. More often, they are focused on getting a few high profile projects finished as quickly as possible. Then, because most of their budget consists of people costs (either directly or through outsourced vendors), they focus on maximizing resource utilization to minimize cost. As a consequence, IT often makes decisions for their software development projects based on: Difficultly of the project How many and which resources are required Who shouts the loudest Findings from more than 1,500 software development projects DCG analyzed in 2013 and 2014 suggest that the median cost of a software development project for a Fortune 500 company ranges from $114,000 (offshore) to $164,000 (onshore). Without getting too statistical here, the use of the term median rather than average is important because the size and cost of projects is not a normal distribution (i.e. evenly distributed around the average). Perhaps unsurprisingly, there are many more small projects than medium-sized projects and more medium than large projects. It seems that few companies have this type of data about the size of their projects. We also found that very few of the companies surveyed knew the distribution of the business value of their projects, never mind communicate that information to the tactical decision makers who are prioritizing software development resources to projects. Why would this be so? Surely no project gets started if there is not an approved business case, right? Our experience and follow-up inquiries revealed that in most large corporations, large projects or programs usually require business cases, while most small projects don t have these requirements. Those large projects which have business cases are usually sub-divided into smaller projects. Breaking out the business value across these smaller projects is perceived to be too difficult or worthless (we will return to this challenge later). Doesn t Agile software development solve this problem? Well, yes and no. Mature implementations of Agile prioritize Product Backlogs (lists of the next tasks or

2 stories to work on) by business value. In some methodologies, such as the Scaled Agile Framework (SAFe), business representatives are encouraged to put numeric values on stories to allow for prioritization by value when tactical leaders and teams are making resource allocation decisions. However, there are three challenges even with Agile implementations: There are not enough Agile implementations that are mature enough to include value information; The value information is either not disseminated to the actual tactical decision makers or those decision makers are not aware of the importance of prioritizing by business value (in the face of the person in front of them shouting loudly for their favorite project); The information about value is not structured enough to be captured as an output metric or, even if it is, it is simply not captured. We have seen an example of this where the story management system in one corporation is perfectly capable of handling the necessary value tracking; but the teams are not held accountable for entering any data into the story management system after a particular story has been approved and funded. What are the consequences of tactical decisions being made using criteria other than business value? It is not necessarily a disaster. If software development managers and teams are prioritizing based on, say, resource utilization, then resource utilization will be high, but value delivery almost certainly will not. If our goal is to maximize business value delivery or flow, then we must be able to measure value flow and identify ways to optimize it. The solution to this problem is end-to-end Value Visualization. Why Value Visualization? All stakeholders and team members must know the business and economic value of the project and work toward the same goal of maximizing business value flow. Specifically for software development, business units and IT must collaborate to define the value for each initiative, right down to the lowest level at which resourcing decisions are made. For example, in corporation X, there must be an approved business case for every project or program above a certain size, let s say $10M. This business case will presumably include some metric such as return on investment (ROI). Let s assume that the project ROI can be banded as follows: ROI <5% is rejected 6% < ROI <10% is a LOW value project but worthwhile 11% < ROI <20% is a MEDIUM value project 21% < ROI <40% is a HIGH value project 41% < ROI is a VERY HIGH value project Now, let s say we have a $15M project with a medium value ROI. For software development to start, we need to break the project up into, say, epics and stories. It probably does not make sense to do an individual business case for each epic and story but we need to make sure that each epic and story is linked to the master project AND inherits the T-shirt size value label of the master project (i.e. In this case, Medium. ) Accountability is essential to monitor progress and assure successful attainment of the goal of maximizing business value flow. This requires slightly different metrics and, more importantly, the visualization of those metrics. For example, Figure 1 is a Cumulative Flow Chart showing the flow of stories through a software development team. In this simple case, we are assuming that the team has a least T-shirt size information on business value for each story and is using that to prioritize stories such that number of stories is a reasonable proxy for business value flow in this simple illustration.

3 Figure 1: Cumulative Flow Chart: The flow of stories through stage gates in software development by day (release every 3 rd day) So, is there a comprehensive way for organizations to communicate business value information for software development projects? We should first acknowledge that even simple ways to communicate and visualize business value to the tactical decision makers are better than none at all. We are quite happy to start with T- shirt sizes. But, we can do so much more with the Value Visualization Framework (VVF). The Value Visualization Framework (VVF) Figure 3: Visualization of Value Visualization Framework If we compare Figure 1 to Figure 2, an ideal Cumulative Flow Chart, we can see that the team in Figure 1 has some challenges in the form of bottlenecks. It should be noted here that the trend information provided by this type of cumulative flow chart is much more predictive of future events and potential problems than a simple count of released stories. When we think about Value Visualization and projects, it is important to remember that cost is not value any more than price is! So why do organizations only talk to IT about cost? If organizations can share business value details for their initiatives, they will enable IT to become part of the ROI solution. Figure 2: Cumulative Flow Chart: Idealized - flow through the stage gates is even (parallel lines) and ideally as steep as possible VVF is a 5-step process in parallel to the process that creates the business case for a project and then breaks the project down into epics and stories or some form of tasks in a work breakdown structure. Each epic and story should have the following information associated with it: STEP 1: Define the units of value delivery (e.g. number of subscribers, hours saved in the process) STEP 2: Define the value of the project in specific units (e.g. 17 new subscribers once deployed) STEP 3: Define the size (e.g. 100 story points) STEP 4: Define the cost of delay of the implementation challenge, including level of complexity, duration, etc. (e.g. $2,000 penalty for a missed deadline) STEP 5: Quantify the economic value once deployed (e.g. $10, $15 and $20 per subscriber at weeks 9, 12 and 15 respectively) (see Figure 6) The first three steps should be pretty clear. They are extremely important parts of the process and need to be well thought out. Steps four and five may need a little more explanation.

4 VVF Step 4: Define the Cost of Delay Defining the Cost of Delay is of fundamental importance to prioritizing work packets or projects or stories. Essentially, we should always prioritize projects with the highest cost of delay. However, identifying the cost of delay for a particular story is neither intuitively obvious nor easy. There are many approaches of which we give three examples here: 1st Approach: Explicit Cost 1. Penalty if completion date is missed (e.g. $2,500 fine if not completed by Day 15) 2. Missed opportunity (e.g. the loss of an incentive 30 new subscribers will sign up if delivered by Day 17 or not!) 2nd Approach: Cost if Stories in Software Development are Too Long Figure 4: Examples of costs of delay for excessive times in software development Figure 5: Relative cost of delay using a modified Fibonacci set of numbers VVF Step 5: Quantifying the Economic Value of Stories Once Deployed Delaying the assignment of actual market value to deployed functionality until it is actually deployed allows fluctuations in value due to market forces or environment changes to be taken into account. The example in Figure 6 assumes that the value of subscribers increases as the subscriber base grows. Hence, in week 9 each subscriber is worth $10. This goes up to $15 in week 12 and $20 in week 15. This is based on advertising revenue per subscriber increasing as the number of subscribers increases. Of course, the value could just as easily fall! Figure 6 Example of quantifying the economic value of stories once deployed (VVF Step 5) 3 rd Approach: Relative Cost of Delay of One Story Against Another This approach can allow cost of delay to be assigned by an informed and representative team with relative little data. The process is similar to story estimation in Agile using planning poker. Usually a limited set of numbers (Fibonacci or modified Fibonacci e.g. Cohn Scale - Popularized by Mike Cohn for use in Story Points: 0, 0.5, 1, 2, 3, 5, 8, 13, 20, 40, 100,?) are used and participants must choose from this and set the relative cost of delay for each story against the other stories as in Figure 5.

5 Resource Allocation at a Tactical Level With the full VVF in place (even if only T-shirt sizes), teams and team leads with resources to deploy against incoming stories or tasks will be positioned to prioritize based on: Business value Cost of delay Resource availability Summary This paper makes the case that we can only get more value out of software development if we use business value as the most important consideration in prioritizing the flow of work through software development, in particular, and IT, in general. Even though new methodologies such as Agile seek to bring value into the tactical decision making of teams, we assert that very few businesses measure or track value with sufficient rigor. We accept that measuring and tracking value through software development is challenging. We offer a series of examples of how value can be measured and tracked relatively easily. Value visualization means not just measuring and tracking value but making value information visible to tactical decision makers so they can use it to prioritize workflow and, hence, value flow. Capturing value data has a number of other benefits including aligning the business and IT. These additional benefits will be the subject of future white papers. Michael D. Harris, President & CEO, DCG Software Value Michael Harris has more than 30 years of broad management experience in the IT field, including periods in R&D, development, production, business, and academia. An author and speaker on a range of topics related to the Value Visualization of IT, Mr. Harris is considered a thought leader in the software development industry. He became president, CEO and majority owner of DCG Software Value in 2006 and previously held numerous senior executive positions in Fortune 500 companies, including: Fidelity National Information Services (NYSE: FIS), Sanchez Computer Associates (NASDAQ: SCAI) and MasterCard International (NASDAQ: MA). Contact: mharris@softwarevalue.com or x22