Simple Metrics to Measure Value – CoD and WSJF

Cost of DelayWhen discussing value, determining how to measure that value is critical. As I write my second book on “The Business Value of Software," I find myself frequently coming back to two simple techniques that help organizations measure the business value of their software development projects: Cost of Delay (CoD) and Weighted Shortest Job First (WSJF).

CoD is the hourly, daily, or monthly cost associated with NOT starting a project. When a project is delayed, there is waste (i.e. wait times, inventory costs, opportunity costs) and this waste can negatively impact the bottom line. 

Cost of Delay =
User or Business Value + Time Criticality + Risk Reduction or Opportunity Enablement Value

WSJF is another metric that prioritizes those projects by putting the project with the highest WSJF at the top of the list. It is calculated by dividing the CoD by the duration of the project. 

These two techniques are extremely helpful in prioritizing software development initiatives based on economics. They enable an organization to prevent the frequent starting and stopping of projects that are extremely common in the software development world and allow for a continuous flow of product development based on metrics that drive business value. 

Donald Reinertsen, the author of “The Principles of Product Development Flow: Second Generation Lean Product Development” has said “If you only quantify one thing, quantify cost of delay." I whole-heartedly agree with Reinertsen, and I also encourage organizations to quantify WSJF. By measuring CoD, software development organizations will eliminate overhead associated with delays, streamline operations, and ultimately, produce more business value. By adding WSJF into the equation, they’ll be able to prioritize their projects such that they’re continuously delivering the greatest value to their business units.

I’m always interested in how software development organizations are using these two techniques. Please share the successes you’ve realized when utilizing CoD and/or WSJF.


Mike Harris
CEO

Written by Michael D. Harris at 05:00
Categories :

Function Points in the Philippines?

David LambertI know what you are thinking – and I was thinking the same thing. Is there really a company using function points in the Philippines? Yes, there is. In fact, I recently traveled to the Philippines to train a lean development team on the use of function points as a measure for their metrics program.

I’d never been to the Philippines before, so it was an interesting experience to be in a new place, but it was also interesting to see how function points are being used around the world.

This particular team is way above the curve as far as their processes and documentation is concerned. They were looking for a standardized process to size their change requests in order to measure productivity and quality and help forecast future projects. Their intent is to start sizing those small change requests and establish some benchmarks for their applications. Once those benchmarks are in place and they have gathered some valuable data, the team intends to start using the data to help size their larger projects. The sizing for those projects will allow them to better manage staffing, cost, and quality related to those projects.

This, of course, is something we encourage and espouse as a best practice for development teams. So, it was great to see that this mentality has really taken hold in this organization, and that they truly understand the benefits of sizing.

I also learned while I was there that several larger technology companies are starting to use the Philippines as a source to locate their infrastructure and development teams. So you may not think of the Philippines when it comes to the IT domain, but the country is starting to make some strides towards closing the gap on the rest of IT world. I know for sure that one lean development team has closed the gap and function points have allowed them to standardize their process even further.

I look forward to seeing how the use of function points continues to develop in the country – and beyond. Is your organization using function points? If not, it’s time to catch up!

 

David Lambert
Managing Consultant

Written by David Lambert at 05:00

IT Digitization

Michael D. HarrisAs you all know, I like to share interesting bits and pieces from the reading that I do. Like many of you out there, I subscribe to a number of industry publications, which help me get a sense of current trends, new tools, etc. in the software industry.

Today I wanted to share some takeaways from “Raising Your Digital IQ,” an article from the February 2016 issue of Strategy+Business. The article was written based on a global survey of business leaders, which showcased how the smartest companies are using technology.

The fact is – and this should not be news to anyone – that digital technology is becoming a key part of any IT strategy. The gap between traditional and digital IT is widening, and companies who are not adapting to the change will be left behind.

I suggest checking out the article for the findings, but I’d like to focus on some key points here.

This article quotes GE CEO Jeffrey Immelt, who has had this position since 2001. One particular thing I found interesting was Immelt’s comment that every industrial company will soon be a software and analytics company. Of course I find this interesting, given that our mission here at DCG is all about making software value visible.  I’m hoping that all these new software and analytics companies will take a hard-headed view towards their software investments and go for software value instead of “me too.”

For GE, a focus on analytics means a single, technology-enabled platform that supports innovation, operations, and customer support. What this looks like at any given organization will vary, but the future is using data to improve business.

Next? The effect of this transformation on budgeting. Traditional IT costs are now transforming too; for instance, cloud-based services are often cheaper to run and support. But, digitization also likely means an increased use of tools to manage the work – and not just in IT. This democratization of technology means that IT spending is now widespread in organizations – in fact, the article notes that in 2015 68 percent of technology spending was outside of IT. But, this too brings new considerations; when other departments are making their own IT choices, it can lead to incompatible systems, security risks, and off-strategy investments.

How is your organization planning its digital strategy?

Read, “Raising Your Digital IQ,” here.


Mike Harris
CEO

Written by Michael D. Harris at 05:00
Categories :

Focused on One Goal: Business Value Delivery

Scrum Alliance

This past week, the Scrum Alliance published an article I wrote, “What is Productivity in Agile?.” Productivity can be a painstaking conversation for Agile teams, who are dedicated to following the principles in the Agile Manifesto, aimed at improving productivity, but they are often pulled in the opposite direction by management to achieve a higher velocity.

In my article, I discuss how everyone (IT and the business units) needs to focus on the same end goal – business value delivery. To do this, they must jointly define value metrics and ensure all team members, both in IT and the business side, understand those metrics and are held accountable for achieving them.

I have seen my clients successfully use metrics for Cost of Delay (CoD) and Weighted Shortest Job First (WSJF) to help prioritize their projects based on business value. I believe that having the IT team and business unit collaborate to create relative metrics in these two areas is a good starting point, but it is also critical that everyone is held accountable for improving value. 

Organizations need to put standard processes in place to ensure the appropriate parties (this includes the business unit) are involved in the entire software development process and that the metrics are not being decided on by one individual, such as the product owner. The business units may push back on being so involved in the process as they will expect the IT department to simply do what they have asked. However, if they realize that the collaboration with IT is more than just about efficiency, but also about enabling them to justify the expenditure to management, they may be less resistant to being involved in the process.

Check out the complete article on the Scrum Alliance website. I welcome your feedback on how your team prioritizes your projects.


Mike Harris
CEO

Written by Michael D. Harris at 05:00

IT Project Failures

Mike HarrisFailures in IT never seem to go away. Every month the news seems to be covering a new, high-profile IT issue, many of which Jay Liebowitz enumerates in his recent IT Professional article, “IT Project Failures: What Management Can Learn.” HealthCare.gov, The National Program for IT (UK), United Airlines, the Wall Street Journal, and even the New York Stock Exchange have all experienced very public, very high-profile failures. Why?

As Liebowitz notes, many organizations blame these failures on scope, cost, and time, but they can be further categorized by process-driven, context-driven, and content-driven issues.

  • Process-driven: Those related to business planning, project management and control, strategic formulation, and the change-management process.
  • Context-driven: Those related to the information system itself (technology, system design).
  • Content-driven: Those related to the environment in which the project is being development (culture, structure, management).

One process-driven issue that is often the impetus for failure is when organizations pick the project they like the best – without taking into account the business case for that project. If you’ve been in IT long enough, you’ve seen this happen. Needless failure.

Liebowitz also points to research from Rateb Swies asserting that IT projects fail due to the following reasons (in priority order):

  1. High degree of customization (context-driven)
  2. Changes late in the design stage (process-driven)
  3. Underestimating the timeline (process-driven)

So the question, of course, is what can management do? An obvious solution, suggested by Liebowitz, is to better educate current and future IT project leaders. Specifically, I recommend the following:

  1. High degree of customization (context-driven) – Management needs to better understand the size of the project. Function points can help.
  2. Changes late in the design stage (process-driven) – Management needs to understand the impact of these changes. Better IT governance can help.
  3. Underestimating the timeline (process-driven) – Management needs to understand the probability of the estimates that they are getting. Better estimating using statistical analysis and, yes, a tool can help.

Liebowitz also suggests better coordination between business users, IT, and finance. I’ve talked about this on the blog repeatedly – the need for improved coordination between IT and the business is paramount.

We have a number of services that support this type of improvement, including Function Point Analysis, IT Governance, and the Measurement Roadmap. IT serves to support the goals of the business; if it’s not appropriately aligned with the interests of the business, then it’s not fulfilling its role and failure will be more likely.

Management has the ability and the tools available to prevent failure – so when will they start doing their part?

Read, “IT Project Failures,” here.


Mike Harris
CEO

 

 

Written by Michael D. Harris at 05:00

"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!