Software Value: Impact on Software Process Improvement | DCG

Business value has not always been the primary driver of software process improvement, but that is changing.  This is the main point of an excellent article by Richard Turner in the March/April edition of CrossTalk, “The impact of Agile and Lean on Process Improvement.”

Turner’s article is a concise and refreshingly frank walk through the history of software process improvement from the perspective of an expert who has been intimately involved.  With a hint of frustration that I certainly share, Turner captures perfectly the thinking that has led to a move away from process improvement initiatives like CMMi in commercial software development organizations:

“One of the drawbacks of earlier process improvement approaches was the concept and distribution of value. The overall value of the process improvement was often situational at best and nebulous at worst.  Where it was seen as a necessity for competitive credibility [as was the case for my development group at Sanchez Computer Associates back in 2001], the value was in passing the audit rather than in any value to the organization and the customer.  In other cases, the value was essentially associated with the success of one or two champions and disappeared if they failed, changed positions or left the company [as I did].  On those occasions where PI was primarily instituted for the actual improvement of the organization, the internal focus on practices was often valued as a way of cutting costs, standardizing work [We certainly needed to make our processes repeatable] or deploying better predictive management capabilities rather than improving the product or raising customer satisfaction.”

While I agree with 95% of Turner’s analysis here, in my experience both passing the audit and standardizing our processes raised customer satisfaction.  We went from having one customer ready to give us a reference to most of our customers being referenceable on the basis of solid evidence that we had fixed the reliability of our software development

Turner contrasts historic process improvement initiatives, mostly targeted at waterfall operations, where business value was not a prime driver to today’s initiatives where, “With the emergence of Agile and Lean, the concept of value became more aligned with outcomes.  The focus on value stream and value-based decision making and scheduling brought additional considerations to what were considered best practices.”

Turner recognizes that in today’s Agile and Lean software development teams, the teams themselves are responsible for their own processes.  Mostly, this is a strength because creative people are likely to optimize processes under their control out of simple self-interest (which benefits the organization).  Where this falls down in my experience is where, “These organizations rely on cross-fertilization of personnel across multiple projects to improve the organization as a whole.”  To put it bluntly, this rarely happens.  Teams can be self-organizing but groups of teams don’t typically self-organize.  Hence, there is still a place for organizational process improvement – with a lean, software value driven emphasis – in the most modern software development organization.  By way of evidence, scrum teams that are working together on the same program struggle to develop ways to coordinate and synchronize their efforts unless a framework such as SAFe is introduced through a process improvement initiative. 

That said, I will leave the last word to Turner, “Process improvement that does not improve the ability to adapt has little value.”

 

Michael D. Harris, CEO

Written by Michael D. Harris at 13:36

Mergers & Acquisitions: Software Integration Planning

 

 

 

"My company is acquiring another company, how should I plan to integrate their software with ours?"

Scope of Report:

Many venture capitalists, investors, and managers have experienced unforeseen and unnecessary losses due to hidden challenges in a target company’s software. Excessive enhancement requirements stemming from the size and/or complexity of a software asset can lead to significant upgrades and maintenance costs or worse non-performing functionality. These, sometimes large, issues can remain unidentified until very late in the development lifecycle.

Those who have unexpectedly dealt with these problems often face a loss of clients as they struggle to adapt to the new demands placed on their IT departments. Pressured to meet sometimes unrealistic budgetary and release constraints, perhaps due to excessive transaction savings expectations, they find themselves understaffed and incapable of getting their IT back under control.

Generally, there can be four distinct tasks in the acquisition process as it relates to the target company’s software:

- Software Asset Due Diligence (ADD): A profile of how the target organization relies on its technology.

- Software Asset Risk Management (ARM): An assessment of the risk involved in transitioning the target organization’s software.

- Software Asset Maturity Analysis (AMA): A profile of the return-on-investment for the acquired software, with an eye on the future.

- Software Asset Integration Management (AIM): An analysis of how to integrate the acquired software into the current environment.

Challenges occur for the surviving IT department if not all of these tasks are done or if they are not done by software experts. This report focuses on the last task, software asset integration management but reviews the other three tasks to identify the components they need to deliver for successful software asset integration. If these components are not available they need to be done retrospectively as part of software asset integration which can be difficult to impossible.

Software Asset Due Diligence (ADD):

The prospect of capital losses or unplanned expenditures in a targeted company, due to their software, rarely generates as much concern in the M&A team. It rarely affects deal pricing and structure as much as it should. However, anyone who has experienced the challenges of unexpected software project costs, schedule overruns, integration management problems or source code failure can imagine the potential for unforeseen damage to the value of an asset.

Both the balance sheet and the P&L statements are affected by a target company’s dependence on its software. In particular, if custom software is the embodiment of the target company’s unique business model and value, then there is a real risk if the software is unduly expensive to maintain or extend.

Acquirers should be informed about the potential pitfalls or the hidden asset value in any target company that depends on software. Investors will appreciate the thorough nature of the software due diligence and the enhanced quality of performance for the ongoing management teams.

The initial due diligence examination of a targeted asset’s software provides the M&A team with an evaluation of the current state of the targeted assets software and internal operating structure. This information can produce substantial gains for the M&A team, either via negotiation for a more advantageous position in the targeted asset or via a much more thorough understanding of financial statement impact. In some cases, we have identified hidden asset value for our clientele, thereby substantially enhancing returns for investors. In all cases, the benefit has far outweighed the cost of the initial software due diligence.

This information can produce substantial gains, either via negotiation for a more advantageous position in the targeted asset or via a much more thorough understanding of the impact on financial statements.

In many cases, we identify hidden asset value, thereby substantially enhancing profitability for investors. The return-on-investment is the confidence you receive in moving forward with a comprehensive understanding of the impact of the software involved.

Software ADD is designed to shed light on the impact IT can have on a merger or acquisition. Other benefits include:

  • Improved confidence in the profitability associated with a merger or acquisition

  • Identification of hidden asset value

  • Early recognition of post-acquisition risks, including software maintenance and upgrade

    fees

  • Identification of undue dependency on selected individuals in the development team

Software ADD should provide recommendations on how to move forward with the technological piece of the merger or acquisition – or not!

Software Asset Risk Management (ARM):

Software ARM should identify post-acquisition risks. One of the more intangible risks is often the quality of the source code in any custom applications. Venture capitalists, investors, and managers have been subject to unforeseen and unnecessary losses too often due to hidden challenges in the target company’s software. These, sometimes large, capital exposures can remain unidentified until very late in the investment life cycle. Excessive operating expense due to the size and/or complexity of software applications leads to large enhancement requirements and maintenance costs, or worse, non-performing functionality. Some who have experienced these problems have endured losses of credibility and market share.

One way to manage risk in the target’s custom software is to identify the code that presents the biggest risks and then use source code analysis tools to build up a picture of each custom applications strengths and weaknesses. The source code analysis can then inform the investment decision at hand to evaluate the potential financial impact. Source code analysis can provide an appraisal of the source code’s maintainability, ability to support growth and a risk profile defining issues embedded within the custom software, actionable for mitigation. Of course, the acquirer will require access to the source code for this service. This may be difficult to arrange during due diligence and may need to be deferred to the post-acquisition implementation phase. Software ARM outlines the risks involved in transitioning a target company’s software into your portfolio. Other benefits include:

  • The ability to avoid unnecessary losses due to hidden issues in the target’s custom software
  • Identification of potential IT team constraints – and enough time to mitigate them
  • An improved transition timeline based on a comprehensive understanding of the software related issues involved

Software Asset Maturity Analysis (AMA):

The software comes with its own unique growth cycle. Unfortunately for most M&A teams, it can be difficult for an outsider to spot the signs that a particular custom software application is reaching the point where its maturity is becoming a liability rather than an asset. Typically, new software platforms and applications evolve through several stages of maturity, each with its own set of capital, personnel, strategy and support requirements. Dependent upon the nature and size of software functionality, most growth entities will see a consistent pattern of increased resource requirement through the first stages of the maturity curve. If business growth continues, there will come a point where a large influx of resources will be a necessity to allow the software asset to perform to match the business growth and maximize opportunity profit. Put more simply, the more complex an application becomes, the harder it is to make even small changes. We have illustrated this point in the chart below

The difficulty comes in defining where you are on the curve and, hence, the degree of resource requirement necessary to maintain consistency in performance going forward. Should management not be aware of, or be misinformed as to these metrics, implosion may be on the horizon. Many target assets have appeared to be wonderfully performing with respect to market penetration, quality of provision and profitability until the bubble bursts. These entities entered a period of stagnation due to their inability to be responsive to market demands, and in doing so severely damaged their brand.

The key to success is understanding whether the custom software behind the business processes is up to the task of supporting the business model in the future and what future investments might be required. Undetected and unplanned for substantial development or maintenance expenditures can be devastating. Management may be forced into unplanned software asset acquisitions in order to meet future needs.

As more and more seemingly successful organizations fall victim to the expansion “bubble”, it has come to our attention that many investment management entities now want to identify and avoid software asset related capital losses and unplanned expenditures. To that end, software asset maturity analysis “AMA” provides a clear understanding of exactly where your custom software asset sits on the maturity curve.

Software Asset Integration Management (AIM):

Venture Capitalists, M&A firms, and private equity investors all have target ROI, ROE, and EV metrics. Substantial amounts of money and time are invested in potential targets to determine whether these metrics meet or exceed prescribed limits, both now and during the tenure of the investment. When the stars align, the completed transaction becomes another asset in inventory requiring ongoing financial reporting, planning, and management. Should management meet or exceed “pro forma” (essentially a financial plan for the joint entity) in the ensuing years, balance sheets can balloon from the increase in retained earnings. That being said, an inadequate software asset integration plan or an adequate plan based on insufficient information about the custom software will cause unexpected roadblocks on the path to value creation. Existing customers may risk the loss of functionality or may simply choose other alternatives if the integration plan is not clear. Clearly, this could impact ongoing revenue.

Most M&A experts understand capital, marketing, sales and human resource requirements as defined in painstakingly generated pro forma. Unfortunately, most do not consider the impact of weakness in operational systems and/or individual custom software applications. Even fewer plan for these requirements, producing too many examples of non-performing assets with pro forma of great promise. Understanding if, and how, the custom software should be integrated into a new parent company’s software asset portfolio can be the difference between substantial capital losses and financial health.

For a successful merger, it is necessary to document a clear understanding, via analysis and in the form of a plan, of how each target software asset should be integrated (or not) with the parent’s software asset portfolio to achieve the pro forma savings targets. This provides operating a management efficiencies and early identification and management of software integration and scaling problems.

The first step in the integration plan is to decide which applications duplicate the same functionality (e.g. HR software) and which provide unique value to the acquiring or target companies. Generally, the decisions over duplicated functionality applications will generally be decided in favor of the acquiring company who will want to retain their existing HR, finance, etc. software unless there is a compelling reason not to do so (e.g. cost). For these applications, the integration is an operational, people problem. For the targets custom applications with business value to add to the combined entity, the integration plan should cover the following information for all affected applications:

  • Development and testing e.g. Description of methodologies and techniques used for software development and testing
  • Maintenance e.g. Current Defect Backlog by Severity and Age and staff assigned to maintenance
  • Software e.g. List of purchased and developed software and their authors and other creators including information whether the author/creator made their contribution as a company employee under their employment contract, outside their employment, as a consultant or as an independent contractor.
  • Application(s) e.g. Components within application including third party software embedded (especially open source) and the schedule of all ongoing or planned software, databases and related systems development projects that affect the application or its environment.
  • Partners e.g. List of other companies, partnerships, individuals or other entities who are stakeholders in the application.
  • Customers and users e.g. List of the application’s largest customers or users in terms of sales or activity.
  • Employees, other staff and sub-contractors e.g. List of key employees or contractors who work on the application for development, testing, operation or security and an organization chart showing line management and functional relationships
  • The legislation, codes of practice and standards e.g. List any mandatory compliance requirements the application needs to comply with and evidence of most recent compliance audit.
  • Risk mitigation e.g. Copy of the business continuity plan and data backup and verification policies and procedures with a schedule of tests undertaken.

Conclusion:

If your company is acquiring another company, you can plan to integrate their software with yours by working with the M&A team as early as possible to gather information about the risks and challenges that you are likely to face during the due diligence process.

It is sensible to focus on the target’s custom software that is part of their unique business proposition because your existing software will probably replace any software they have that duplicates functionality you already have and custom software is more likely to be risky and difficult to integrate than any commercial off-the-shelf (COTS) software they have. 

Having identified the riskiest, most difficult applications to integrate, gather as much information about them as you can and plan accordingly. Measure twice and cut once!

Written by Default at 05:00

The Software Development Productivity Benchmarking Guide

DCG Software Value

If you missed the news, DCG Software Value, LEDAmc, and TI Métricas recently announced the release of “The Software Development Productivity Benchmarking Guide.” 

It contains actionable benchmarking guidance and information that will enable organizations to track their progress both internally and against industry standards to facilitate the creation of high quality software and improve resource and budget management.

The guide is available to all international software metrics organizations, including IFPUG, ISBSG, NESMA, and COSMIC, as well as to any independent company that is interested in implementing or improving its benchmarking practice.

Don't miss out on this resource; it's free and available for download here

Written by Default at 05:00

The Top Programming Languages

We all remember our first programming language. Mine was basic on the Commodore64. And, we all know our favorite language – I still love “C” (without the “++” or the “#.” But it’s hard to keep up to date with all the languages and particularly hard to keep their relative importance sorted in your head.

So, which languages are considered “need to know?” Luckily, Baseline has the answer, sharing 11 essential programming languages, as identified in IEEE Spectrum.

Nick Diakopoulos, a well-known computational journalist and assistant professor at the University of Maryland, created the list by weighing and combining 12 metrics from 10 sources, including IEEE Xplore, Google, and GitHub.

Check out the list to see if you agree with the ranking. We’d love to know what you’d add or remove! And, if you’re interested, IEEE has posted an online, interactive version of the list so you can adjust the weight of each metric used to create a customized ranking.

Read, “11 Essential Programming Languages,” here.


Mike Harris
CEO

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

The Magic Quadrant for Software Test Automation

Mike HarrisOne of the most fundamental questions test engineers ask before starting a new project is what tools they should use to help create their automated tests. Luckily, Gartner issues a yearly report to address this issue. This report, “Magic Quadrant for Software Test Automation,” focuses specifically on functional software test automation and the UI automation facilities of tools. The use cases the report considers with regard to each tool includes:

  • They must support mobile applications
  • They must feature responsive design
  • They must support packaged applications

With those use cases as evaluation criteria, Gartner evaluated 12 major vendors:

1. Automation Anywhere
2. Borland
3. Hewlett Packard Enterprise
4. IBM
5. Oracle
6. Original Software
7. Progress
8. Ranorex
9. SmartBear
10. TestPlant
11. Tricentist
12. Worksoft

As part of its analysis, Gartner placed each vendor in one of four categories:

1. Leaders – Those who support all three use cases.
2. Challengers – Those who have strong execution but typically only support two of the use cases.
3. Visionaries – Those who generally focus on a particular test automation problem or class of user.
4. Niche Players – Those who provide unique functions to a specific market or use case.

Beyond that, the vendors were assessed by their ability to execute and their completeness of vision. In short, ability to execute is ultimately the ability of the organization to meet its goals and commitments. Completeness of vision is the ability of the vendor to understand buyers’ wants and needs and successfully deliver against them.

The Magic Quadrant

The result is above. It’s important to mention that Gartner notes that most organizations typically have more than one automation tool provider. In addition, many of the solutions are still maturing – and will continue to mature over time.

Gartner updates the report on an annual basis, and it’s valuable to any organization who does testing. Testing, as we often say at DCG, is a key part of the development process, but it’s one that is often overlooked. The information in this report can enable organizations to make educated choices about software vendors, resulting in improved software quality and execution.

Read the article: “Magic Quadrant for Software Test Automation.”


Mike Harris
CEO

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 President

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