Software Value Needs to Start at the Top

McKinsey

I read an article recently, written by Hugo Sarrazin and Paul Willmott at McKinsey & Company, that I thought would be of interest to the readers of this blog. It resonates with my past posts about getting the software value message right to the top of the organization. The article was titled “Adapting your board to the digital age."

Who can argue with recommendations to make board members more informed about the development of technology solutions? I particularly like, “Board members need better knowledge about the technology environment, its potential impact on different parts of the company, and its value chain.”

I would have liked to have seen more stress on the importance of the board being focused on the value delivered by digital transformation. Some of the recommendations (such as having technology committees) could be seen as sufficient in themselves, which they are not. I’m sure that if the board has a “balloons” committee then the company will end up spending more on balloons, even if that is not going to increase the value of the company.

My recommendation to boards? Follow most of the good ideas in this paper, but beware of “digitization” for its own sake. Start and end with business value!

Read, “Adapting Your Board to the Digital Age,” here.


Mike Harris
CEO

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

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 :

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!