When a company engages in custom software development, it is making an investment into itself. Company executives decide to convert capital into software because they believe that the resulting software will make the business better.
How we make that investment decision is crucial to the success of the investment.
Our first investment decision is based solely on an idea. We spend some money to research an idea that looks promising to see if there is a business case for making further commitment. That business case comes down to the expected impact from the features we want at an expected cost by an expected time. We also want to understand the investment strategy: How will it be developed? By whom? Where will they be working? How well do they know these technologies? How well do they understand our business domain? What is the release schedule? How will we assess quality of the asset? We also want a risk analysis of both our business case and investment strategy, so that we understand the many different forms of risk there are to the capital the firm is committing.
This gives us enough information to make our second (and usually larger) investment decision: either we have an opportunity that meets our investment criteria that can be fulfilled at reasonable risk, or we don't.
Even if we secure financing and approval, sign the contracts, and get on with development, that's not the end of our investment decision-making. The investment rationale needs to be revisited continuously over the course of the investment. Once we begin executing on an investment, our objective is to maintain its viability. If reality turns out to be significantly different from the strategy (people quit, scope turns out to be larger than anticipated, business needs change), we either go back to our investment committee to ask for an adjustment to the investment (more money, rescope functionality, recast the expected business impact), or we have to recommend that they scuttle the investment.
We do this with any financial investment we make. Before we invest in a company, we do our research into the industry, business, and management team. We scrutinize quarterly reports for results and indicators. We withdraw our investment if we are not confident that management can turn it around. This is classic investing behaviour, and it is applicable to strategic software investments.
IT projects tend to lack investment rigour. Managers beholden to an annual budget cycle will concoct wildly optimistic cost forecasts based on flimsy details in the hope of getting a project funded in the annual budget lottery. Instead of using project inception as an investment qualifying activity, it's used strictly as a way to refine scope, time and cost estimates as a precursor to development. And once development is under way, the management mantra is to be "on time / on budget / on scope"; management will do whatever they can to bend reality to match the project plan to give the appearance of control.
What we end up with is budget money chasing any means of development that pledges it can fit under the spending cap, rather than corporate capital chasing a business outcome. Development isn't invited into the process of shaping the investment parameters, they're expected to live with them. That leads to compromise in team construction (availability over capability), vendor partners (low bid), and standards of performance (showing progress is more important than verifying completeness).
When money is chasing the means and not the ends, quality is the first casualty, followed quickly by scope. Costs will rise to meet budget, at which point a project sponsor is forced either to dial up more money or dial down expectations.
Software is an investment, not a cost. Good investment outcomes require good investment rigour.
