The ‘build’ part of IT is the most understood function we have, at least in concept. There are thousands of articles and books and numerous methodologies and tools supporting the building of an application. It is the glamor of IT, the function that can be used to differentiate a business from its competitors. It is that possibility that puts the glimmer in the eye of both IT and the CEO. Then, of course there is the reality. Building is risky and expensive. Maybe not as high profile failure as an SAP or Oracle failed implementation, but a failed investment in building an application can certainly impact a business and the faith in IT as an organization. Negative (maybe cautionary is a better term) as I sound, I am in favor of building applications for the right reason, at the right time. This posting is intended to provide some guide posts to help make this decision. It will not get into dissertation length detail and most of the ideas here I have learned from someone else. This post is intended for IT leadership although other business department leaders and executives could get a general understanding of the risk to their investment from a read of this. Also, let me give some context to this posting. I am assuming your IT organization is a support function, not a company where delivering applications is your business.
Below are several key questions you should ask before making the decision to build.
- Is it strategic for the business?
- How long will this provide a competitive advantage?
- Can you document the return realistically?
- Will this impact your organization’s agility?
- Is your organization mature enough to successfully complete the development?
- What are the risks of ownership?
- Is a commercial package functionality ‘close enough’?
- Is it strategic to the business?
Strategic does not have to mean it makes you visibly different to your end customer. If it provides you a significant advantage in Increasing Revenue, Improving Service or Avoiding Cost, it is strategic. IRACIS is the acronym an old professor of mine used to repeat. Two examples from my career include building a commercial project management system for a multi-billion dollar general contractor and developing a web front end for tracking orders for a technology recycling company.
For the project management application, we built it to improve efficiencies (improve service and avoid costs) and because there were no commercial applications available at the time. Investment risk was low even though several man-years were put into design and development. The construction industry is a technology laggard and business practices do not change quickly. This slow pace of business change kept the maintenance cost low and lengthened the life span of the application to at least 10 years. An agile platform was able to be used for development since business processes were very modular. There was also minimal additional cost for infrastructure. The investment return from litigation avoided alone paid for development and support in multiples. No client specifically awarded a project based on this application.
The web reporting application was a differentiator and therefore, a revenue ‘increaser’, probably not a real word. The application took less than 3 man-months to design and develop. No new data stores were required and no changes to business processes were required. This tool allowed the customer to track orders from request through remanufacturing and provided the customer a sense of control and security. This capability became a contractual requirement for many large customers.
These projects were successful because they were core to the business, costs and risks were well understood and were sponsored by the business. We did not try to build something that is more contextual to the business and was readily available off the shelf, such as a new accounts payable module. That type of functionality has been available in commercial products for 20+ years and is best served by modifying your processes to meet the capabilities of the application chosen and ensure proper controls at the lowest cost structure.
- How long will it provide competitive advantage?
This will depend on your industry but with the pace of change in technology, you need to be conservative in your estimate. You probably should not project beyond two years for the lifespan of your application as originally built. In calculating your return, you will need to factor in additional functionality development beyond this and increasing support costs over time.
- Can you document the return realistically?
If your savings include soft costs, it is not realistic. Saving time in someone’s job is nice but not a cost reduction unless that function is eliminated. Think cash flow. In the end, that is how success will be judged. If you can not justify the investment with hard dollars, go back to process improvement or move on to the next project. The exceptions are those projects that fall under regulatory compliance. They just have to be done at the lowest cost possible that meets the regulatory requirement.
- Will this impact our organization’s agility?
The architectural design of any application needs to be as loosely coupled as possible to allow for changes in the business. This is a downfall of many commercial application providers. They are continually increasing functionality based on customer demand and increasing breadth of their customer base. This increases complexity and product cost for customers that don’t need this functionality. Your requirements must be concise and focused on the value added during initial design and in future development. Be prepared to change out the application as your commercial applications increase capabilities.
- Is your organization mature enough to successfully complete the development?
IT does not own applications. They are developed to serve a business function(s) so maturity does not apply to IT only. Do you have a project owner, an executive outside of IT with the organizational standing to force the business to support the development. Inside IT, do you have the skills to manage a project, document requirements, for technical development, testing, and release management? Is this a core IT competency? If not, consider your options such as outsourcing if the cost is justified.
- What are the risks of ownership?
The paragraphs above lists some of the risks of initial development but there are on-going risks. The benefits of a commercial application are that support costs are known and the risk of loss of staff is removed. Release management of a commercial application can be more easily managed since the provider will be on a release schedule with changed functionality documented. A comprehensive acceptance test plan, once developed, will become routine. You own these risks with a custom application. You need a change and release management process, technical documentation on the application and dependencies with processes and other applications need to be maintained. Application knowledge must reside in more than one staff member. You don’t want one person to be ‘too big to fail’.
- Is a commercial package functionality ‘close enough’?
If you can obtain a high percent of the return by modifying your business processes or, can work with the provider to enhance the application, you should take this path. Building a partnership with an application provider will reduce your cost and risk. It will probably take longer to implement. A managed relationship with your key vendors, such as participation in advisory boards or outsourcing custom development, will pay great returns.
I did not get into any detail on topics of vendor management, TCO, ROI, standards, organization bias or package selection. This is based on personal experience and hope this is thoughtful for you. Again, I advise you to read as much as possible on industry frameworks, in this case on CMMI for development maturity and ITIL for process knowledge of project initialization, requirements gathering and release management.
I hope this has value to you and send questions or comments.
Management and technology consultant and former CIO in Fortune 300 companies. Currently leading the consulting practice focused on support of Private Equity organizations and their portfolio companies to allow realization of the full value of the investment.
