It is self-evident that to have value a thing must have a purpose. All design begins with purpose or quickly devolves into scribbles. The intent of any creative effort is to reverse entropy, to create order, to achieve a purpose. Art and science, a business, a spreadsheet, or a salmon swimming upstream to spawn must have purpose to fight the constant downward flow.
Microsoft and partners have diligently developed many templates for common purposes, which are excellent sources of new ideas for spreadsheet design. Yet templates seem to go largely ignored even when they fit the purpose nicely, or can be easily adapted. As a broader observation, a clear statement of purpose is undervalued and commonly omitted. Many a spreadsheet has had an ignoble birth as a brain dump, storm, fart or whatever graphic noun you choose. Not surprisingly, many of these are stillborn, or if saved end up as numbered orphans; Book1, etc.
Certainly, there is nothing wrong with starting on Sheet1 of Book1 with ideation. In fact, it is good to articulate the purpose, expand the objectives, and give the newborn a good name. Expound the fundamental program elements: input, process and output. But this step does not require Excel and may be more productive on paper or whiteboard. Articulation often exposes hidden needs, and alternate sources and methods. Take some time to let the purpose settle before jumping in.
The first key question of purpose is the customer. Who will consume the product of this labor? You might have a budget or home inventory file that is for you alone, but in business it is almost always for or shared with someone else. Whether it is an actual customer, a project team, your boss or the CEO, you need to define purpose from their perspective. Start with a good name, then connect the design, features and documentation to the purpose as simply as possible. Simplicity leaves the comforting impression of exposing purpose.
The second key question is use. How will the product be used? Is it stand-alone or linked to other data sources? Is it ongoing or temporary? Will users input data or only read and output the data? Is the data sensitive? What is the shelf life of the data, and how will it be renewed? Is VBA a must-have, nice-to-have, or not applicable?
Once the use case is clear, the next important step is to assess the market competition. Is there a standard solution already available? Can one be modified? Is there a template that can be adapted? Is there a ready-made solution available for purchase? If there is nothing available for the specific need, then it’s time for reality check. Is there enough value to justify the cost? This is hard to answer objectively, maybe impossible, so common sense applies. In the absence of a formal solution, users will proliferate informal ones. The tipping point to justify development might be the need to regain control, over any quantifiable payback. Coupled with the use case of any shared tool is the purpose to entice willing adoption.
Having a clear purpose enables efficient design and test, and leads directly into training and adoption. A good project, like any good presentation, begins with objectives and ties everything back to them.
Comments