Business Models

A successful software system in a commercial environment must be totally aligned to the business models. This subject was comprehensively addressed by the MIT’s Corporation of the 1990s project. There have been related thinking ranging from Davenport’s Business Process Improvement, Hammer’s Re-engineering and Six Sigma’s Cycle Time Reduction.

These approaches all involve drawing process workflow diagrams. Some put great emphasis on the work team themselves drawing these diagrams – after all they know what really happens. This is the “As Is” model. Then one focuses on Triage – identifying whether we can automate the 80% of cases which are the most common – and hence simplest. By brainstorming in the team, ideas for continuous improvement can be surfaced. We move to “Should Be”. From there and by seeking benchmarking partners and bringing experts into the team we can move to ‘Best Practice”.

When the user team have been through the first two of these processes they are readily for a software system. They have thought through the various cases which will be our User Stories. Their thinking will be clear and readily communicated to the software team. They are ready to be our Customer on-Site.

If they have not been through these processes the introduction of an IS project will push them down this path. They will be learning and the model will change – and usually quite quickly. This is why Big Up Front Design approaches fail – they do not allow for the learning that will inevitably take place.

But business models change for other reasons many external – new technologies within the particular industry; competitive responses; marketing campaigns; new product introductions.

Customer Relationship Management and other Internet based approaches imply that we respond quickly to our customers responses. We may recognise a pattern from a market segment and prepare a campaign to address it within a week – rather than a 12 months planning cycle.

If our project takes more than a few months then some of these changes will arise. We must begin another short project or have adaptation built into our processes.

Extreme Programming approaches meet these needs for flexible delivery, optional scope and rapid change.