It’s the age old question in IT. If you go back to the early years, there wasn’t really an option to buy (other than hardware) as all IT organizations built the software that they needed. This was the time before application vendors started appearing in the industry. Well, I was part of those early times with Sears. Back then Sears was THE powerhouse in retail merchandising (remember the Sears Catalog?). We not only built applications, we built every ‘tool’ that we needed to facilitate application development and to support operations.
Today, we are at the other end of the spectrum. Not only can we purchase applications to run our company’s business, we can purchase just about any tool we need to support any aspect of IT. And there are literally thousands of choices. So, it begs the question, should we even be asking ourselves this when we need a software solution?
One area that still seems to lean toward the build side is analytic reporting. And, as with any build decision in IT, there are enormous cost and risk factors that need to be considered.
From a cost aspect, a build decision requires the following:
• Time it takes to re-build reports & metrics when you switch ITSM platform (Avg. is 5 years)
• Time it takes to re-build reports & metrics when you upgrade ITSM platform (major upgrades)
• Subject matter expertise your organization has in the service management platform
• Project management expense
• Technical development, either internal resources or external resources
• Business intelligence development tools
• Infrastructure cost, for development and production
• Support cost (you build it, you support it)
• Other software cost such as reporting tools and dashboard tools
From a risk aspect, a build decision inherently has these considerations:
• Can a solution be built within the time a solution is required?
• Inadequate/incomplete communication between project participants
• Less than complete requirements definition
• Changing scope and objectives, “need more than I thought I did”
• Project staff turnover
• Project delayed or put on hold due to higher priorities in other projects
• Less than adequate skill sets on the project team
• Inadequate funding
• For a longer list, see http://www.dummies.com/how-to/content/the-essentials-of-managing-risk-in-your-project.html
IBM puts the development project success rate at under 62%. Furthermore, the factor contributing the highest percentage of failure, at 50%, is failures due to requirements gathering errors. And it hasn’t improved for the last 20 years. An off-the-shelf application has most, if not all the requirements established, as vendors have the experience of numerous customer implementations, and the resulting feedback, to get it right.
So if you need to report and monitor key metrics and KPIs in your service management system, does it really make sense to build what you can buy?