Start At The Finish Line

Why starting at the end is the way to go
When I have to visit a client I find their postcode on their website, copy that to Google Maps to have a look at the building, and when I'm sure I've got the right place I click on "Directions" to find the journey from wherever I happen to be.  Pretty much every time I haven't done that, I end up arriving a bit uncertain and peering through my bifocals at an array of buildings, looking for a sign.  The UK is notorious for not displaying building numbers or even street names, and asking passers-by can be a bit of a gamble.

Contrast that with a software development project.  One of my colleagues used to say to me the equivalent of: "I wouldn't start from here" pretty much every time I asked about adapting a model.  There are not many projects that need to start from Somewhere Else (which is an area of of greenbelt known to developers as The Blank Sheet Of Paper).  If that were the case, we wouldn't have developed so many tools and techniques that enable "re-usability" for software.


Regardless of where you start on a project, you must know where you're headed.
This isn't the same as the solution, by the way.  In most instances, we don't know at the start of project everything we want to know at the end.  No.  In the case of a modelling project, the secret is knowing what the result needs to look like to give the decision-maker a clear understanding of the solution to their problem.


For example, if they are asking "can I reduce the number of people used in this process without affecting service levels", then the model needs to generate service level information, resources used, staff and equipment utilisation and so on.


This also helps to determine what you don't need, for example you probably needn't bother including equipment energy consumption.  But you can see that absenteeism might be important, particularly if their is a risk of it rising with the increased workload.  Cue: a discussion about HR issues.


I think many of are inclined to include more detail than we really need to solve a problem.  My rule is: "If in doubt, chuck it out!".