ImpactModelling

Last edit December 31, 2003

Could someone fill in a simple cookbook for impact modelling here?

One way I explain it is that it involves going from the simplistic customer statement "I want X" (static model of requirements) into the following questions (the first two straight from TomGilb in the early 80s):

Is X a function or quality (atomic requirement or measurable one) ?
If X is a quality, how much of X do you want (target and worst acceptable) ?
When do you want (that much of) X ?
Who exactly wants X at that time ?
How successful would they judge the system to be if X is achieved then (100 = successful) ?

In the very early days of a project, when the shape of even a first SpikeSolution isn't yet clear (for example the software tools or hardware it's going to use aren't) the answers lead to a set of SuccessStatement's of the form:

60S(Head Accountant, Jun99) |= AgedDebtors(5%) [the head accountant would consider the system 60% successful if it reduced the number of debtors not paying within 30 days to 5% or less by June 1999]

Then there's discussion (involving customers) of high-level technical solutions that would 'solve' the statements at some point in the future (earlier the better in line with BusinessValueFirst). This then coalesces into one or more milestones (agreed delivery points) in a CommitmentSchedule. [Sorry I can't link to all relevant XP terms and corresponding WikiNames here]

We call the early days situation high potential and the whole aim of ImpactModelling is to progress as soon as possible from that dangerous but exciting consultancy state, where programmers assigned to the project probably don't have enough definition about what to do, to steady state. Steady state is where impact modelling simply becomes the regular updating, with the customer, of a list on a single piece of paper of one line EngineeringTask's or simple UserStories updatable as often as weekly.

We've recently tried using a Wiki clone for updating the list, linked to separate pages for each task or story (as I think KenAuer does). We're wondering if we need to think again about IndexCards for any descriptions to back up one line task definitions, as I explain a little in KnowingWhenToStop.

ImpactModelling certainly aims to SimplifyTheRequirements with the customer wherever possible. This is one part of the challenge of doing just enough ExternalAndInternalDesign for the next set of SuccessStatement's to be met. We believe strongly that it's a benefit for experienced IT and HumanComputerInteraction people to work closely with customers on external design issues, using prototyping or paper. In some areas, in other words, it's not wrong for developers to influence SuccessStatement's, it's essential. But it must be highly visible (and thus agreed).

Steady state is intended to be kind of boring and predictable for customers - except for those exciting scoops that the evolutionary process and well factored code allow, as described in SuccessStatement. Another way of saying this is NoNegativeSurprises.

As I've read Wiki pages concerned with XP the impression that I'm given by most of them is that they assume steady state is achievable in all projects from day one. Although this is much better than presuming the need for conventional BigDesignUpFront I believe that it is over-simplistic if applied to all project situations. --RichardDrake

See also the 1997 slideware around http://www.objective.co.uk/events/presentation/9710_java_design/sld025.htm

CategoryAnalysis