Software development is a risky endeavor, with many things that can go wrong. At any moment, you may find that your budget or schedule targets have been completely missed and your developers and customers disagree about the scope and functionality of the project. In fact, numerous studies state that up to 60% of projects completely fail or massively exceed their budgetA recent study by McKinsey found that on average, most software projects over $5 million exceed their budget by 45%, turning that $5 million application into a $7+ million application.  As responsible software systems developers, we have to constantly ask ourselves – how do we prevent this from happening to our projects?  The answer is to reduce risk.

There are many ways to quantify and manage risk. I like to look at PMI’s definition of risk:

Risk – uncertain event or condition that if it occurs will have a positive or negative impact on one or more project objectives, such as scope, budget or schedule.

Given this definition, there are several ways that PMI recommends for you to address risk:

  1. Transferring risk by shifting the impact to another party (by purchasing insurance, for example).
  2. Avoiding the risk, which is often not possible if you have to develop a custom solution.
  3. Mitigating the risk by reducing its probability of occurring or the impact that it may have.
  4. Accepting the risk.

The best way to reduce risk of failure or exceeding the budget or schedule is to simply avoid it altogether. Unfortunately, this is very challenging when it comes to custom software solutions. Generally, when organizations choose to develop a custom solution, they have already confirmed that there are no acceptable COTS alternatives, so they must develop something that is customized to their unique needs. However, you can still minimize the actual custom development required by using a development platform that gives you built-in functionality you do not have to build yourself. We achieve this on many of our projects by leveraging Microsoft SharePoint and Dynamics CRM as a platform.  In a previous blog entry, I discussed how SharePoint and Dynamics complement each other in this regard, and my colleague Larry Katzman touched on it in his post on optimizing IT budgets.

By focusing on XRM – Extended Relationship Management – Dynamics CRM provides a very capable software development platform for just the type of large projects that McKinsey studied. This means that it provides a platform for managing relationships between any two objects. For example, you can use XRM to manage the relationships between users, workstations and offices for an asset management system. Users might have one workstation per office, and each office has a set group of workstations. By using Dynamics CRM to build this tool, the developer only needs to configure CRM to gain a quick data entry system, custom reports and secure access — all without writing a single line of code.  This cascades to reduce costs and risk throughout the development lifecycle. Here’s how:

  • Testing – There is no custom code to test. While you still need to perform some acceptance testing, the bugs will be dramatically reduced because there is no custom code.
  • Deployment – By running on a standard architecture, the system does not require any additional servers or infrastructure.
  • Requirements Analysis – This type of configuration can be performed with close participation from customers. If performed correctly, they can see the tool evolve in near-real time, ensuring that they are able to provide the best quality of feedback and requirements to the team.

Looking back at our discussion of risk, we can see how using Dynamics CRM as a platform makes sense from a budget perspective by examining two scenarios:

Scenario 1: A custom-built system, with a budget of $5 million for development and $1 million for software licenses.  This system appears to cost $6 million at the beginning, but if we use the study linked above as a basic guide, we can see that we should expect the system to actually cost $7,350,000.

Scenario 2: A system built on Dynamics CRM, with little to no custom development. Costs for software licenses are much more because we now must factor in licensing costs for Dynamics CRM, but licenses are a ‘low risk’ item in that their costs do not change and the organization will receive the software. On a side note, the likelihood of failure should decrease with the reduction of custom software, but I’ve opted to keep it the same for demonstration purposes and compare ‘apples to apples.’

These scenarios demonstrate why it is important to compare the true expected costs of projects. Examining both scenarios at the outset gives the impression that they are both the same cost. However, the second scenario is actually much cheaper – nearly $1 million cheaper – because it re-allocated funding from risky software development to low-risk software licenses. Using Dynamics CRM achieves similar cost reductions because it replaces the resources spent on performing custom development with software licenses and capability provided ‘out-of-the-box.’  In many cases the savings are even more extreme because the cost savings continue throughout the lifecycle of the system, reducing costs for requirements analysis, testing, deployment, management, security and infrastructure.