Last week I came across a project team that did just that. They had asked the customer what she/he wanted and built the system exactly to those specifications.
I was called in to do an IT assessment of the progress of this project and I soon realised that this project was an abysmal failure. But how could that be, here was a project that was built exactly to specification and was delivered more or less on time.
The problem was that the project team built a system, based on what the business users wanted without considering if there is any business value in it. The business users were line managers and clerks and they had a very limited view of what the business was about, and how their day to day actions affected the top line/ bottom line performance of the company. So this resulted in a very narrow view of the requirements, and sure enough when the system went live it did not deliver as much value as top management expected it would.
So how does one get past a problem like this ? Here is where stories play a very crucial role, and the importance of the "As a role I would like to do some action so that I achieve some business value" format.
Some people feel that we are being pedantic if we insist on every story adhering to this format. But if the team had stuck to this format, they would have realised early in the game that the requirements being given to them were probably not adding any business value. This visibility would have allowed upper management to terminate the project early and reevaluate their strategy.
The other aspect to this problem is the maturity of an organization to consume a custom built software. For custom built software it is critical for the users to be able to clearly articulate the need of the business. They should be able to tie every requirement to the bottom line or top line performance of the company. This implicitly means that the business users have exhausted all means to improve performance by business process modifications. Only in such a situation should the business consider using technology to get them that extra bit of competitive advantage.
In my opinion the IT maturity of an organization is closely linked with the business maturity. I can think of four stages of IT maturity an organization can be in.
- Chaotic tactical business processes (use of spread sheets and multiple point solution)
- Business processes which provide accurate and up to date information to the upper management to make decisions. But the processes themselves don't adhere to a overarching strategy
- Business processes tied to a strategy that is clearly articulated by the upper management
- Business processes which are flexible and can easily shift and align themselves to the subtle strategy changes being employed by the upper management
To get to the Nirvana state of business, it is important for information systems to support them
Stage 1: To start with you have a bunch of spread sheets and custom point solutions spread out through the organization
Stage 2: Fewer spread sheets and some central solution which can provide some business intelligence
Stage 3: Collection of commercial off the shelf (COTS) best of breed solutions integrated with glue code
Stage 4: Collection of COTS as well as custom solutions in areas which give the organization a competitive advantage integrated with glue code
Pros and cons of each stage
Stage 1
Pros: Relatively easy to stand up spread sheets for your day to day work.
Cons: Virtually impossible to get any sort of business intelligence at an over all enterprise level
Stage 2
Pros: Easy to obtain business intelligence
Cons: If the team supporting the central application is small, they become the bottleneck.
The whole enterprise will over time become overly dependent on a small group of people who control the application.
The single application is critical to the functioning of the organization, this reduces the number of upgrades and changes that you can make to the application. Over time the application become out dated and crufty.
Stage 3
Pros: Allows flexibility
Can get the best of breed for each individual functional area
Cons : Can't get competitive advantage from such a solution (if you can glue together off the shelf products, then so can your competitor)
Will have greater IT spend because the skill level required to maintain this kind of an architecture is quite high
Stage 4
Pros: Competitive advantage
Cons: Increased IT spend
