Reprinted with permission.
A visionary sees how technology can change his or her job and makes it happen. This change is impressive, but not optimal, because optimally business geographics should be driven from a corporate perspective. Without that perspective, the technology probably is not being fully leveraged.
Occasionally, particularly in some larger corporations, individual departments may have the brawn to push high-powered, far sighted business geographics implementations through. On other occasions, the politics of a situation might make it necessary for a single department to drive the initiative. The most promising business geographics initiatives always involve both strategic planning and information systems (IS) people.
Viewed as a strategic and corporate initiative shared by both departmental and corporate entities, these groups' joint interests can push a program further than either one alone. The departmental activity--generally in response to a user's request for specific needs--pushes corporate priority. The corporate activity--focused on planning and coordination--facilitates action and arranges for efficiencies between departments that couldn't be coordinated by one department.
The problem is that an efficient arrangement demands communication. And as projects spin into development, its not unusual for strategic planning to drop out and for information systems and user departments to remain. And when IS talks directly to users, a project can come to a screeching halt.
For many users, the thought of moving ahead with a business geographic project through the IS department is a contradiction in terms. In itself, it is a reason for pushing a departmental solution. There's surprisingly few IS people championing business geographics, and I can't help wonder if it's because IS people and business geographics users just don't speak the same language.
Consider the traditional communication vehicle and methodology in place at many IS departments--the software development life cycle (SDLC):
SDLC is a well-regimented approach that demands requirements be thoroughly thought out before moving forward. The problem is that business geographics users often are not conversant or comfortable in this mode of operation. Moreover, its basic foundation might not even apply. As Larry Runge observed in his article "New Method for a New Era" in Information Center Quarterly, summer 1991, SDLC was designed on concepts from when software developers were scientists and computing languages were closer to electronics than speech. In those days, SDLC's target applications were primarily simple, serial business tasks.
Reiterative development styles, sort of advanced forms of prototyping, are well suited to business geographics. Its users generally fit the reiterative profile well, i.e. they want to see an idea, build it up a little more, see it again, build it some more and so on. And as a result, they may indeed be better suited to "progressive development" than SDLC.
If we are going to work with IS, it is to communicate the unique features of business geographics and the potential need to new software development methodlogies. We shouldn't say that SDLC can't work with business geographics, but we should point out how working in a prototyping manner might work better. Conceivably, with the right development team, SDLC can work fine--but a hybrid approach might be best.
There is no panacea--different methodologies will work for different situations. The chief point, though, is that we need to be think beyond our own departments and develop consensus if we're going to develop business geographics across an organization and maximize their worth.