Align your software practice with your business
Posted by Michael Franken around lunchtime: February 9, 2006
The Software Development Process (SDP in short) defines the way business ideas are put into software practice. It covers the entire process from requirements definition through to using the software in production. Many projects simply fail because of the fact that the business and software development processes are not aligned. It is a known fact [Standish98] that the most important factors that make or break a software development project are:
1. User Involvement,
2. Executive Support and
3. Clear Business Objectives.
These factors are more important than an experienced Project Manager. This is clearly evidence that stakeholders outside the IT department should be represented in the Software Development Process. To emphasize this even more, research has shown that 45% of all features implemented are never used at all. Therefore we can’t stress the simple point enough:
The software development process should resemble the business process.
Often this is not the case and the SDP has remained a mere IT asset or, even worse, a pure development instrument that has originated from team or developer preference, theory or vendor promotion. This can seriously hurt business as projects are more likely to fail with an inadequate process, and if they succeed they may be twice as expensive as needed.
So how predictable is your business?
Currently most projects tend to follow a ‘sequential’ process. The entire project is divided in a number of sequential phases:
Even if the project is developed iteratively, in many cases this is restricted to the realization phase, since many projects start with fixed requirements and possibly design. The fixed design is in many cases disguised as the ‘Reference Architecture’. Finally the majority of all tests are executed when the different components are put together after which at last the system is deployed to production.
This may seem a logical approach and it may appeal to management and finance, since it defines the playfield upfront, and identifies the artifacts for control. However this is in contrast with the nature of the business process and technology. Defining the requirements upfront can only be done when the business case is entirely understood.
Research [BoehmPapaccio] has shown that this is hardly ever the case. Projects with significant requirements change a lot. Typically 25% of the requirements change, and the percentage increases with the size of the project. Projects with a high value (or duration) have very little chance of success [Standish98]:
This sequential approach really is to ‘try to get it right the first time’. This is very costly as it shows. And it does not reflect the nature of business. People change their mind, opportunities happen, and competition is progressing as well. Ask a business person his requirements now, and do so once more half a year later…
The sequential approach postpones all risky parts of the project to the end of the project. The first three phases can be accomplished without much risk as most if not all deliverables are mere paper assets and can not be put to any practical stand. The risks will become evident when testing starts and finally when the system is deployed to production. Remember the fact that the project has been 90% ready for weeks or more? In a typical sequential project the stakeholders will see the system for the first time at the end of the project. In some cases this will require lawyers with the contract at hand instead of the ‘real’ stakeholders to accept the project.
A serious side effect of the sequential approach is the tendency to ‘over engineer’ the project. If you don’t put the requirements in at the beginning of the project they will never be accepted ever after. So why not stick ‘em in now?
A typical software project is much more like ‘new product development’ than ‘mass production’. And in many cases the technology used is new and complex as well. A combination of all these uncertainties, a huge scope and an inflexible process makes success sheer impossible.
Have your process reflect your business
A well kept secret is that the software development process can reflect the business process. Since the 1950’s methodologies have been developed and tried that have proven to do just that. These methodologies are nowadays known as ‘Agile’ or ‘Iterative’. These methodologies promote short projects, or project iterations. I'll blog about Agile development this later.
Filed under: Agile, Articles, General