E-books & White Papers

Geospatial Strategy Essentials For Managers

Issue link: https://resources.esri.ca/i/1313392

Contents of this Issue

Navigation

Page 41 of 61

40 | GEOSPATIAL STRATEGY ESSENTIALS FOR MANAGERS MATTHEW LEWIN The key takeaway from these different models is that they all serve different purposes and closely reflect the goals and culture of the overall organization. This can't be overstated. When considering a re-organization, don't lose sight of what your business will realistically accept. Another point of note is the location or organizational "home" of the central group described in the centralized, hub-and-spoke, balanced and federated models above. The home of the group is dependent on a range of strategic factors. We will discuss these in the next two sections. In practice, we most often see shared geospatial teams reporting into IT or a specific business unit or operating as a standalone corporate function. In the case of the standalone function this could be internally managed or outsourced. Defining Your Model The intention of the organizational archetypes is not to suggest that there are five ways to organize a geospatial program. The point is that organizing talent is a balancing act. To settle on a model that fits your organization, you're better served by thinking about re-organization as a design process. This means following a structured and iterative process that starts with a base model and incrementally refines the model until a desired version emerges. A suggested approach (derived from an approach developed by Kates and Galbraith in Designing Your Organization (2007)) is described as follows: • Start with a decentralized model: To begin, we need to start at one end of the centralization spectrum or the other. The recommendation is to start with a decentralized model and work toward increasing centralization rather than the opposite. A decentralized model prioritizes autonomy and freedom and puts decision making in the hands of those closest to the business challenges. We want to start with that as a baseline. • Identify functions that cannot be centralized: Certain systems, data, roles and services must remain in the departments for legal, regulatory, privacy, risk or security reasons. Identifying these components and acknowledging them as part of the greater geospatial complement is important, but centralizing is not possible. City police services, for example, often require separate infrastructure, databases and security credentials from the rest of the city government. • Pull out functions that are non-core to the departments: Systems, data or roles that are not essential to the departments' mission are candidates to be moved to the center. These are often functions that exist on the business periphery or are supporting functions. This could include application development, production mapping, application support and geodatabase administration. • Move functions that would benefit from economies of scale: Many functions, while important to the work of the business, could be more efficiently delivered through a central, shared provider. Often these are functions that are not fully utilized by any one business area. Centralization, in this case, enables sharing the cost of expertise. Examples could include a pool of generalist location analytics professionals. • Identify the management and governance functions that should be owned centrally: Overall geospatial management and governance functions are often better suited to a central, coordinating function. This might include the development of corporate architectural standards, policies and frameworks, solution rationalization criteria and talent development plans.

Articles in this issue

view archives of E-books & White Papers - Geospatial Strategy Essentials For Managers