Quite often system projects are launched with a lengthy discussion of some data set that is needed, or a set of exciting new tools or techniques that could be used for reporting. There is debate over how and where to store specific fields of data, record layouts and structures. Sometimes there is a plan for who will gather and maintain these data. But all of this without any clarity on the ultimate purpose for the exercise. What problem are we solving? What question are we answering?
In system design the objective is not to have a cool system design but rather to meet a specific need or answer a specific question. Before we can identify the information or calculations we need we must fully understand the problem being addressed.
This morning I read a request for assistance with a technology to locate trailers. The parameters of the problem were well articulated. The trailers are stored at several hundred locations and can be at rest for long periods of time. Facts like battery life and fuel efficiency were included. Several popular location technologies such as RFID and GPS were mentioned and discounted for various reasons. The author asked for help with a solution.
In any event, unless we know the question we may spend considerable time finding or creating some new methodology for locating the trailers without ever solving the actual problem.
My favorite tactic is to disrupt any meeting by magically producing with pencil and paper the system output exactly as requested and pushing it across the table to the requester. Once they have it I ask what they will do with it. Their response will lead to more refinement of the report or analysis, or will answer their question and, importantly, should lead to some action.
If they cannot answer the question, there is no point in going any further.
Follow me on Twitter @JPuglisiLLC