Impact analysis is one of the most basic tools for managing change. Yet (in my experience at least) it remains little used.
This is a problem for Agile, though not because we should suddenly start writing excruciatingly pains-taking impact analyses for everything that moves. Far from it. The problem is rather that, Agile is best done when all the participants are already more or less experienced in all the major managerial and technical techniques. That is the reason why Agile is able to be so informal: because the team already know a) which techniques really add value; and b) how to do the ones that remain, without having to read a manual, fill in forms or hold a formal meeting.
So if impact analysis is a valuable technique (and it most certainly is) yet relatively few practitioners of Agile have much hands-on experience of using it, how do we get the benefit of impact analysis without incurring the cost of formal procedures? It’s hard to say: it’s really quite hard – and generally counterproductive – to insert ‘hard’ controls like this back into Agile, even if they are nominally valuable.
So to be going on with, the table below suggests a list of things most managers with experience of impact analysis know they need to ask about when a change is proposed. You don’t want this to turn into a formal procedure – even a checklist can quickly bog the team down in endless debate – but the team should be able to quickly home in on which of the issues suggested below are relevant, and come up with the right questions.
And as ever, the change being proposed should be compared with ‘no change’. Don’t assume that ‘no change’ has no impact – the whole point of many changes is to avoid or undo the negative impact of the current approach, a shift in the environment or to take advantage of an opportunity no one had previously expected.
|Area of impact||Key issues|
|The business case for the change.|
|Impact on scope.|
Just a thought.