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

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.”, 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



Written by Michael D. Harris at 05:00

Lean Principles Help Drive Software Value

Software value

Implementing new strategies typically requires significant change within an organization, which often impacts the culture. This is also the case when establishing new software value strategies. Organizations must first adopt the mindset to use business value as a metric for driving successful software development initiatives, and then they must optimize the necessary processes to ensure those value metrics are reached.

One practice that can go hand-in-hand with driving software value is lean software development. Many of the principles associated with lean are relevant in the discussion about increasing software value.    

An author I often reference, Donald Reinertsen, wrote a book in 2009 titled “The Principles of Product Development Flow: Second Generation Lean Product Development.”  Of the eight lean principles Reinertsen describes in his book, I suggest the following priorities for executives as they start to shift the organizational culture to lean software engineering at the strategic level:

  • Economics – the executive team needs to focus on maximizing the flow of value through software by assigning relative business value to projects or epics at the strategic level.  Reinertsen emphasizes using the cost of delay as a default metric
  • Queues – systemic or temporary bottlenecks must be easily and quickly identified and removed
  • Batch Size – inputs should be kept as small as possible to achieve a more efficient flow in the pipeline
  • WIP Constraints – Work-in-Progress limitations must be put in place at each phase of the process to minimize queues between process steps and improve focus on projects under consideration
  • Decentralized Control – executives prioritize the backlog and then the staff decides what to pull from the backlog first based on that prioritization.

Implementing these principles can go a long way in driving software value, but they will also require a change in the way things are done, which can often uproot a corporate culture. As with most strategic changes within an organization, the changes required to successfully implement lean principles for software development must be communicated across the organization at all levels. This communication is necessary to ensure the processes and reasons for these processes are clearly understood.  

Do you implement lean principles in your software development initiatives? If so, which lean principles have you found most effective in driving software value?

Mike Harris


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

Tips for Visualizing the Value of Software

Mike HarrisI’m an avid reader of industry publications – probably like many of you. So, when I come across an article that I think others may be interested in, I’m inclined to share! The latest article to pique my interest is, “Why They Just Don’t Get It,” from the May/June 2016 edition of IEEE Software.

The article itself is all about how to communicate about software architecture with business stakeholders. I’ve talked about it before (and we’re all aware by now), but there is a serious gap between the business and IT – to the detriment of the entire organization. Thus, it’s important for IT to find ways to effectively communicate with the business to facilitate thoughtful decision-making. This is true about software architecture and it’s true about software value.

The part of the article I want to focus in on is the section, “A Crash Course in Visual Communication.” In essence, the section discusses how it can be hard to put something complicated into words (like software architecture), so sometimes visuals enable improved communication. It reinforces what I have been communicating over the past year in many of my other blog posts and speaking engagements – the need for visualizing value. The section lists six lessons for creating architecture-related visuals, but they apply to value visuals as well.

1)      Our brains focus on things that are different, even in minor ways. When you’re making visuals, call-out the things you want the audience to pay attention to by making them different (changing the color is an easy way to achieve this).

2)      We also unconsciously organize visual elements into bigger groups. Help the viewer by making these groups more obvious (place like items close together or make them the same color, etc.)

3)      The colors you choose send messages, so choose wisely. For instance, many people associate red with negative emotions (anger, stop, etc.). Have these associations in mind when you select colors for your visuals.

4)      Don’t overcrowd your visual. Use icons and logos to make the image clean and easy to interpret.

5)      Read and learn about graphic design and apply basic principles whenever you can. You may not have the time for this, but I would suggest trying to look at the visuals you create with a more critical eye – or asking for someone else to review them.

6)      This is my favorite tip – try sketching! Not every visual that you share has to be a professional-looking graphic. If you’re in a meeting and having trouble communicating your thoughts, try sketching your thoughts – it may spur the right kind of conversation.

Visuals are a powerful communication tool, and when words aren’t serving us well, it’s wise to remember that we don’t always need them! When it comes to interacting with those outside of IT, think about how you can communicate in ways that will make sense to the other person – it will benefit both parties equally. My May 18, 2016 blog post, “Visualizing the Value Through Information Radiators and Business Dashboards” discusses two different visualization tools that help teams more easily manage their software development projects and demonstrate the value. Check those out – they could be useful!

How do you use imagery in your professional life for improved communication – or, how do you think your business could benefit from such a strategy?

Read the article: “Why They Just Don’t Get It,” IEEE Software.



Mike Harris

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

Is Software a Tangible or Intangible Asset?

Tangible Asset

When thinking about software value, most of us immediately think in terms of dollars and cents.  Especially CFOs who talk in terms of where it falls on the organization’s financial statements. Should software that is used within the organization be considered an asset or an expense? This question could be debated over and over depending on who is part of the conversation.

If software is considered to be an asset, it will be found as a line item on the balance sheet. However, it still needs to be broken down further as a tangible or intangible asset. Most would consider software as an intangible asset. It cannot be touched. It is not a physical material or substance. So, it must be intangible, right? Not necessarily. There are exceptions where software is actually deemed to be a tangible asset. 

According to various accounting standards, if software is used to deliver goods and services it can be classified as a tangible asset. An example, would be the software that companies like Snapfish or Shutterfly use for their customers to generate various photo products that result in revenue for their businesses. It would not include a software solution used in their warehouses to keep track of inventory. 

Another criteria to determine if it is a tangible or intangible asset is the cost of the software (to either buy or develop in house). If the cost of one copy of the software is more than $100,000 then it is considered tangible.

So, from the financial perspective, do only tangible software assets add value to the business? Most of us would agree that an inventory management system that streamlines processes and makes the warehouse more efficient adds tremendous value to the organization – it reduces costs, it helps ensure customer satisfaction, etc. 

The Statement of Federal Accounting Standards (SFFAS) No. 10 provides a set of rules about how to treat the transformation of the cost of internal software into value as an asset on the balance sheet. We will not get into these details here in this blog, but it is important to realize that both tangible and intangible software assets can and should be looked at in terms of the value they offer to the bottom line. 

Does your organization have a standard rule it uses in classifying internal software? Is it considered an expense or an asset? Do you have clear guidelines for determining whether to classify your software as a tangible asset or an intangible asset? These questions are important for CIOs and CFOs to discuss to ensure software is allocated as a value to the business.

Written by Michael D. Harris 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!