Like many of my colleagues, I find myself thinking back to my pre-Cartegraph days when I was completely unaware of all the things local government did to make my life easier, safer, and more comfortable. With this understanding of the amount of infrastructure that has to be installed, maintained, inspected, and replaced, I proudly help the people that keep the cities I visit in good working order.
One thing I’ve noticed in the time I’ve been at Cartegraph is an uncertainty of what this software will do when starting a new implementation. I appreciate the fact that many of the users I interact with are not database administrators or designers, or in some cases, not really even daily computer users. Apprehension creeps in where people are wondering what information is needed and how the system can be used. This is where a needs analysis comes into the implementation puzzle.
To clarify, the needs analysis is one of the tools we use when a member of the services team comes in for a few hours or a week asking endless questions and requesting documents currently in use. While this is sometimes long and tedious for the people we are interviewing, it is a very valuable part of a successful project. After sitting through those meetings, taking pages of notes, and examining countless documents, we return to the office and start putting together the ideal system, starting with the corner pieces – reports. We absolutely have to begin at the end; knowing what the larger picture will be aids us in putting things together correctly the first time.
There have been instances where I’ve worked with clients who when asked the question, “What do you want to track?” enthusiastically list off every little detail. Usually, this is followed by me asking, “Why?” If there isn’t a good reason for tracking the data – if it isn’t going to be referenced, if it isn’t reported on – then there probably isn’t a true need for it. If the crews go from putting in eight hours of work in the field to five hours in the field (because the other three hours are spent entering data into the computer), what have we accomplished? There has to be balance.
An implementation consultant’s job revolves largely around understanding what is needed and then interpreting those needs into database structure. We listen to what users need. We understand the ins and outs of the database. We are partially responsible for bringing those two worlds together and making it as uncomplicated as possible. To be perfectly honest, I wouldn’t know how to properly install a sewer main without guidance. We don’t expect all users to know how to build a database or determine data needs without guidance either; however, together, we make a pretty great team.