Business logic in a hurry

How to get business experts to play in the IT sandbox

By Samuel Michaelis, JavaWorld.com, 01/23/06

We have probably all experienced this scenario: At the end of a project, the customer comes up with more new demands for the system that have not been previously created or were only incompletely formulated. Depending on the extent of necessary adjustments, these new requirements may exceed the planned budget and cause those involved to be at loggerheads about who is to bear the cost.

One reason why projects often gradually veer off track is because business experts are not effectively involved. To use a metaphor implied in this subtext: Programmers and architects meet in the IT sandbox to build a castle together, thereby forgetting the business expert on the swing. And because the business expert isn't allowed to play in the sandbox, he doesn't like the sandcastle. This is rather unfortunate if the business expert paid for the outing. So let's consider how we can get business experts involved in our sandcastles without muddying up the end result.

Identify hot spots

The most important safeguard against the risk of specification creep, the emergence of more and more demands at the end of a project, is comprehensive specification of the project's subject matter. We can't blame the business experts for not imbibing in documentation and specification along with their mother's milk, so we need a clear idea how to extract from them the information necessary to our project. In addition, different goals can conflict when writing the specification. Time and effort well spent with the specification may reduce the risk of extra costs at the end of a project, but it is an investment of its own right and must be accounted for. Pure monetary investment is not the only issue; the parties involved in the process produce their own challenges: the cell of technology-resistant employees, the able-minded consultant mainly interested in invoice-vindication, an extremely cooperative but perhaps incompetent project leader. Let's at least nail down that cell of technology-resistant employees by adopting the ancient Arabian proverb, "If the camel once get his nose in the tent, his body will follow".

Figure 1. Conflict of goals between specification benefit and cost

Specification intensity

Not all parts of a system are equally susceptible to specification creep. It is therefore essential to identify those parts of the system that present a high risk of extra cost due to inadequate documentation. One important index for this is specification intensity, which I casually define as the ratio of time and effort spent on the specification versus that invested in implementation. A system's specification-intensive part is one that requires a relatively large amount of programming for relatively little documentation.

Let's use the following requirement as an example: "Port existing data and procedures to the new XYZ database server, improve performance." This requirement could comprehensively describe a project phase lasting several weeks. But what about the requirement, "If the customer buys 10 items, shipping is free"? This requirement has a high specification intensity, every word corresponding almost 1:1 to some code.

1 | 2 | 3 | 4 | 5 | 6 | Next >