The Strategic Planning Process
In the 1970's, many large firms adopted a formalized top-down strategic planning model. Under this model, strategic planning became a deliberate process in which top executives periodically would formulate the firm's strategy, then communicate it down the organization for implementation. The following is a flowchart model of this process:
The Strategic Planning Process
Mission
|
V
Objectives
|
V
Situation Analysis
|
V
Strategy Formulation
|
V
Implementation
|
V
Control
This process is most applicable to strategic management at the business unit level of the organization. For large corporations, strategy at the corporate level is more concerned with managing a portfolio of businesses. For example, corporate level strategy involves decisions about which business units to grow, resource allocation among the business units, taking advantage of synergies among the business units, and mergers and acquisitions. In the process outlined here, "company" or "firm" will be used to denote a single-business firm or a single business unit of a diversified firm.
Mission
A company's mission is its reason for being. The mission often is expressed in the form of a mission statement, which conveys a sense of purpose to employees and projects a company image to customers. In the strategy formulation process, the mission statement sets the mood of where the company should go.
Objectives
Objectives are concrete goals that the organization seeks to reach, for example, an earnings growth target. The objectives should be challenging but achievable. They also should be measurable so that the company can monitor its progress and make corrections as needed.
Situation Analysis
Once the firm has specified its objectives, it begins with its current situation to devise a strategic plan to reach those objectives. Changes in the external environment often present new opportunities and new ways to reach the objectives. An environmental scan is performed to identify the available opportunities. The firm also must know its own capabilities and limitations in order to select the opportunities that it can pursue with a higher probability of success. The situation analysis therefore involves an analysis of both the external and internal environment.
The external environment has two aspects: the macro-environment that affects all firms and a micro-environment that affects only the firms in a particular industry. The macro-environmental analysis includes political, economic, social, and technological factors and sometimes is referred to as a PEST analysis.
An important aspect of the micro-environmental analysis is the industry in which the firm operates or is considering operating. Michael Porter devised a five forces framework that is useful for industry analysis. Porter's 5 forces include barriers to entry, customers, suppliers, substitute products, and rivalry among competing firms.
The internal analysis considers the situation within the firm itself, such as:
• Company culture
• Company image
• Organizational structure
• Key staff
• Access to natural resources
• Position on the experience curve
• Operational efficiency
• Operational capacity
• Brand awareness
• Market share
• Financial resources
• Exclusive contracts
• Patents and trade secrets
A situation analysis can generate a large amount of information, much of which is not particularly relevant to strategy formulation. To make the information more manageable, it sometimes is useful to categorize the internal factors of the firm as strengths and weaknesses, and the external environmental factors as opportunities and threats. Such an analysis often is referred to as a SWOT analysis.
Strategy Formulation
Once a clear picture of the firm and its environment is in hand, specific strategic alternatives can be developed. While different firms have different alternatives depending on their situation, there also exist generic strategies that can be applied across a wide range of firms. Michael Porter identified cost leadership, differentiation, and focus as three generic strategies that may be considered when defining strategic alternatives. Porter advised against implementing a combination of these strategies for a given product; rather, he argued that only one of the generic strategy alternatives should be pursued.
Implementation
The strategy likely will be expressed in high-level conceptual terms and priorities. For effective implementation, it needs to be translated into more detailed policies that can be understood at the functional level of the organization. The expression of the strategy in terms of functional policies also serves to highlight any practical issues that might not have been visible at a higher level. The strategy should be translated into specific policies for functional areas such as:
• Marketing
• Research and development
• Procurement
• Production
• Human resources
• Information systems
In addition to developing functional policies, the implementation phase involves identifying the required resources and putting into place the necessary organizational changes.
Control
Once implemented, the results of the strategy need to be measured and evaluated, with changes made as required to keep the plan on track. Control systems should be developed and implemented to facilitate this monitoring. Standards of performance are set, the actual performance measured, and appropriate action taken to ensure success.
Dynamic and Continuous Process
The strategic management process is dynamic and continuous. A change in one component can necessitate a change in the entire strategy. As such, the process must be repeated frequently in order to adapt the strategy to environmental changes. Throughout the process the firm may need to cycle back to a previous stage and make adjustments.
Drawbacks of this Process
The strategic planning process outlined above is only one approach to strategic management. It is best suited for stable environments. A drawback of this top-down approach is that it may not be responsive enough for rapidly changing competitive environments. In times of change, some of the more successful strategies emerge informally from lower levels of the organization, where managers are closer to customers on a day-to-day basis.
Another drawback is that this strategic planning model assumes fairly accurate forecasting and does not take into account unexpected events. In an uncertain world, long-term forecasts cannot be relied upon with a high level of confidence. In this respect, many firms have turned to scenario planning as a tool for dealing with multiple contingencies.
Rationale for an Information Systems Plan
Every year, $300-700 million dollar corporations spend about 5% of their gross income on information systems and their supports. That's from about $15,000,000 to $35,000,000! A significant part of those funds support enterprise databases, a philosophy of database system applications that enable corporations to research the past, control the present, and plan for the future.
Even though an information system costs from $1,000,000 to $10,000,000, and even through most chief information officers (CIOs) can specify exactly how much money is being spent for hardware, software, and staff, CIOs cannot however state with any degree of certainty why one system is being done this year versus next, why it is being done ahead of another, or finally, why it is being done at all.
Many enterprises do not have model-based information systems development environments that allow system designers to see the benefits of rearranging an information systems development schedule. Consequently, the questions that cannot be answered include:
• What effect will there be on the overall schedule if an information system is purchased versus developed?
• At what point does it pay to hire an abnormal quantity of contract staff to advance a schedule?
• What is the long term benefit from 4GL versus 3GL?
• Is it better to generate 3GL than to generate/use a 4GL?
• What are the real costs of distributed software development over centralized development?
If these questions were transformed and applied to any other component of a business (e.g., accounting, manufacturing, distribution and marketing), and remained unanswered, that unit's manager would surely be fired!
We not only need answers to these questions NOW!, we also need them quickly, cost effectively, and in a form that they can be modeled and changed in response to unfolding realities. This paper provides a brief review of a successful 10-step strategy that answers these questions.
Too many half-billion dollar organizations have only a vague notion of the names and interactions of the existing and under development information systems. Whenever they need to know, a meeting is held among the critical few, an inventory is taken, interactions confirmed, and accomplishment schedules are updated.
This ad hoc information systems plan was possible only because all design and development was centralized, the only computer was a main-frame, and the past was acceptable prologue because budgets were ever increasing, schedules always slipping, and information was not yet part of the corporation's critical edge.
Well, today is different, really different! Budgets are decreasing, and slipped schedules are being cited as preventing business alternatives. Confounding the computing environment are different operating systems, DBMSs, development tools, telecommunications (LAN, WAN, Intra-, Inter-, and Extra-net), and distributed hard- and software.
Rather than having centralized, long-range planning and management activities that address these problems, today's business units are using readily available tools to design and build ad hoc stop-gap solutions. These ad hoc systems not only do not interconnect, support common semantics, or provide synchronized views of critical corporate policy, they are soon to form the almost impossible to comprehend confusion of systems and data from which systems order and semantic harmony must spring.
Not only has the computing landscape become profoundly different and more difficult to comprehend, the need for just the right--and correct--information at just the right time is escalating. Late or wrong information is worse than no information.
Information systems managers need a model of their information systems environment. A model that is malleable. As new requirements are discovered, budgets modified, new hardware/software introduced, this model must be such that it can reconstitute the information systems plan in a timely and efficient manner.
Characteristics of a Quality ISP
A quality ISP must exhibit five distinct characteristics before it is useful. These five are presented in the table that follows.
Timely
The ISP must be timely. An ISP that is created long after it is needed is useless. In almost all cases, it makes no sense to take longer to plan work than to perform the work planned.
Useable
The ISP must be useable. It must be so for all the projects as well as for each project. The ISP should exist in sections that once adopted can be parceled out to project managers and immediately started.
Maintainable
The ISP must be maintainable. New business opportunities, new computers, business mergers, etc. all affect the ISP. The ISP must support quick changes to the estimates, technologies employed, and possibly even to the fundamental project sequences. Once these changes are accomplished, the new ISP should be just a few computer program executions away.
Quality
While the ISP must be a quality product, no ISP is ever perfect on the first try. As the ISP is executed, the metrics employed to derive the individual project estimates become refined as a consequence of new hardware technologies, code generators, techniques, or faster working staff. As these changes occur, their effects should be installable into the data that supports ISP computation. In short, the ISP is a living document. It should be updated with every technology event, and certainly no less often than quarterly.
Reproducible
The ISP must be reproducible. That is, when its development activities are performed by any other staff, the ISP produced should essentially be the same. The ISP should not significantly vary by staff assigned.
Whenever a proposal for the development of an ISP is created it must be assessed against these five characteristics. If any fail or not addressed in an optimum way, the entire set of funds for the development of an ISP is risked.
The ISP Steps
The information systems plan project determines the sequence for implementing specific information systems. The goal of the strategy is to deliver the most valuable business information at the earliest time possible in the most cost-effective manner.
The end product of the information systems project is an information systems plan (ISP). Once deployed, the information systems department can implement the plan with confidence that they are doing the correct information systems project at the right time and in the right sequence. The focus of the ISP is not one information system but the entire suite of information systems for the enterprise. Once developed, each identified information system is seen in context with all other information systems within the enterprise.
Information Systems Plan Development Steps
Step Name Description
1. Create the mission model The mission model, generally shorter than 30 pages presents end-result characterizations of the essential raison d=etre of the enterprise. Missions are strategic, long range, and a-political because they are stripped of the Awho@ and the Ahow.@
2. Develop a high-level data model The high-level data model is an Entity Relationship diagram created to meet the data needs of the mission descriptions. No attributes or keys are created.
3. Create the resource life cycles (RLC) and their nodes Resources are drawn from both the mission descriptions and the high level data model. Resources and their life cycles are the names, descriptions and life cycles of the critical assets of the enterprise, which, when exercised achieve one or more aspect of the missions. Each enterprise resource Alives@ through its resource life cycle.
4. Allocate precedence vectors among RLC nodes Tied together into a enablement network, the resulting resource life cycle network forms a framework of enterprise=s assets that represent an order and set of inter-resource relationships. The enterprise Alives@ through its resource life cycle network.
5. Allocate existing information systems and databases to the RLC nodes The resource life cycle network presents a Alattice-work@onto which the Aas is@ business information systems and databases can be Aattached.@ See for example, the meta model in Figure 2. The Ato-be@ databases and information systems are similarly attached. ADifference projects@ between the Aas-is@ and the Ato-be@ are then formulated. Achievement of all the difference projects is the achievement of the Information Systems Plan.
6. Allocate standard work break down structures (WBS) to each RLC node Detailed planning of the Adifference projects@ entails allocating the appropriate canned work breakdown structures and metrics. Employing WBS and metrics from a comprehensive methodology supports project management standardization, repeatability, and self-learning.
7. Load resources into each WBS node Once the resources are determined, these are loaded into the project management meta entities of the meta data repository, that is, metrics, project, work plan and deliverables. The meta entities are those inferred by Figure 2.
8. Schedule the RLC nodes through a project management package facilities. The entire suite of projects is then scheduled on an enterprise-wide basis. The PERT chart used by project management is the APERT@ chart represented by the Resource Life Cycle enablement network.
9. Produce and review of the ISP The scheduled result is predicable: Too long, too costly, and too ambitious. At that point, the real work starts: paring down the suite of projects to a realistic set within time and budget. Because of the meta data environment (see Figure 1), the integrated project management meta data (see Figure 2), and because all projects are configured against fundamental business-rationale based designs, the results of the inevitable trade-offs can be set against business basics. Although the process is painful, the results can be justified and rationalized.
10. Execute and adjust the ISP through time. As the ISP is set into execution, technology changes occur that affect resource loadings. In this case, only steps 6-9 need to be repeated. As work progresses, the underlying meta data built or used in steps 1-5 will also change. Because a quality ISP is Aautomated@ the recasting of the ISP should only take a week or less.
Collectively, the first nine steps take about 5000 staff hours, or about $500,000. Compared to an IS budget $15-35 million, that's only about 3.0% to 1.0%.
If the pundits are to be believed, that is, that the right information at the right time is the competitive edge, then paying for an information systems plan that is accurate, repeatable, and reliable is a small price indeed.
Executive and Adjusting the ISP Through Time
IT projects are accomplished within distinct development environments. The two most common are: discrete project and release. The discrete project environment is typified by completely encapsulated projects accomplished through a water-fall methodology.
In release environments, there are a number of different projects underway by different organizations and staff of varying skill levels. Once a large number of projects are underway, the ability of the enterprise to know about and manage all the different projects degrades rapidly. That is because the project management environment has been transformed from discrete encapsulated projects into a continuous flow process of product or functionality improvements that are released on a set time schedule. Figure 3 illustrates the continuous flow process environment that supports releases. The continuous flow process environment is characterized by:
• Multiple, concurrent, but differently scheduled projects against the same enterprise resource
• Single projects that affect multiple enterprise resources
• Projects that develop completely new capabilities, or changes to existing capabilities within enterprise resources
It is precisely because enterprises have transformed themselves from a project to a release environment that information systems plans that can be created, evolved, and maintained on an enterprise-wide basis are essential.
There are four major sets of activities within the continuous flow process environment. The user/client is represented at the top in the small rectangular box. Each of the ellipses represents an activity targeted to a specific need. The four basic needs are:
• Need Identification
• Need Assessment
• Design
• Deployment
The box in the center is the meta data repository. Specification and impact analysis is represented through the left two processes. Implementation design and accomplishment is represented by the right two processes. Two key characteristics should be immediately apparent. First, unlike the water-fall approach, the activities do not flow one to the other. They are disjoint. In fact, they may be done by different teams, on different time schedules, and involve different quantities of products under management. In short, these four activities are independent one from the other. Their only interdependence is through the meta data repository.
The second characteristic flows from the first. Because these four activities are independent one from the other, the enterprise evolves by means of releases rather than through whole systems. If it evolved through whole systems, then the four activities would be connected either in a waterfall or a spiral approach, and the enterprise would be evolving through major upgrades to encapsulated functionality within specific business resources. In contrast, the release approach causes coordinated sets of changes to multiple business resources to be placed into production. This causes simultaneous, enterprise-wide capability upgrades across multiple business resources.
Through this continuous-flow process, several unique features are present:
• All four processes are concurrently executing.
• Changes to enterprise resources occur in unison, periodically, and in a very controlled manner.
• The meta data repository is always contains all the enterprise resource specifications: current or planned.
Simply put, if an enterprise resource semantic is not within the meta data repository, it is not enterprise policy.
• All changes are planned, scheduled, measured, and subject to auditing, accounting, and traceability.
• All documentation of all types is generated from the meta data repository.
ISP Summary
In summary, any technique employed to achieve an ISP must be accomplishable with less than 3% of the IT budget. Additionally, it must be timely, useable, maintainable, able to be iterated into a quality product, and reproducible. IT organizations, once they have completed their initial set of databases and business information systems will find themselves transformed from a project to a release environment.
The continuous flow environment then becomes the only viable alternative for moving the enterprise forward. It is precisely because of the release environment that enterprise-wide information systems plans that can be created, evolved, and maintained are essential.
Improving information management practices is a key focus for many organisations, across both the public and private sectors.
This is being driven by a range of factors, including a need to improve the efficiency of business processes, the demands of compliance regulations and the desire to deliver new services.
In many cases, ‘information management’ has meant deploying new technology solutions, such as content or document management systems, data warehousing or portal applications.
These projects have a poor track record of success, and most organisations are still struggling to deliver an integrated information management environment.
Effective information management is not easy. There are many systems to integrate, a huge range of business needs to meet, and complex organisational (and cultural) issues to address.
This article draws together a number of ‘critical success factors’ for information management projects. These do not provide an exhaustive list, but do offer a series of principles that can be used to guide the planning and implementation of information management activities.
From the outset, it must be emphasised that this is not an article about technology. Rather, it is about the organisational, cultural and strategic factors that must be considered to improve the management of information within organisations.
The key goal of this article is to help information management projects succeed.
Information management is not a technology problem
Exploring information management
‘Information management’ is an umbrella term that encompasses all the systems and processes within an organisation for the creation and use of corporate information.
In terms of technology, information management encompasses systems such as:
• web content management (CM)
• document management (DM)
• records management (RM)
• digital asset management (DAM)
• learning management systems (LM)
• learning content management systems (LCM)
• collaboration
• enterprise search
• and many more…
(For a brief overview of many of these systems, see the earlier article Definition of information management terms.)
Information management is, however, much more than just technology. Equally importantly, it is about the business processes and practices that underpin the creation and use of information.
It is also about the information itself, including the structure of information (’information architecture’), metadata, content quality, and more.
Information management therefore encompasses:
• people
• process
• technology
• content
Each of these must be addressed if information management projects are to succeed.
Information management challenges
Organisations are confronted with many information management problems and issues. In many ways, the growth of electronic information (rather than paper) has only worsened these issues over the last decade or two.
Common information management problems include:
• Large number of disparate information management systems.
• Little integration or coordination between information systems.
• Range of legacy systems requiring upgrading or replacement.
• Direct competition between information management systems.
• No clear strategic direction for the overall technology environment.
• Limited and patchy adoption of existing information systems by staff.
• Poor quality of information, including lack of consistency, duplication, and out-of-date information.
• Little recognition and support of information management by senior management.
• Limited resources for deploying, managing or improving information systems.
• Lack of enterprise-wide definitions for information types and values (no corporate-wide taxonomy).
• Large number of diverse business needs and issues to be addressed.
• Lack of clarity around broader organisational strategies and directions.
• Difficulties in changing working practices and processes of staff.
• Internal politics impacting on the ability to coordinate activities enterprise-wide.
While this can be an overwhelming list, there are practical ways of delivering solutions that work within these limitations and issues.
Information management issues can be overwhelming
Ten principles
This article introduces ten key principles to ensure that information management activities are effective and successful:
1. recognise (and manage) complexity
2. focus on adoption
3. deliver tangible & visible benefits
4. prioritise according to business needs
5. take a journey of a thousand steps
6. provide strong leadership
7. mitigate risks
8. communicate extensively
9. aim to deliver a seamless user experience
10. choose the first project very carefully
Each of these is discussed in the sections below.
Future articles will explore additional principles and guidelines, as well as providing a concrete approach to developing an overarching information management strategy.
There are no simple answers to complex issues and needs
Principle 1: recognise (and manage) complexity
Organisations are very complex environments in which to deliver concrete solutions. As outlined above, there are many challenges that need to be overcome when planning and implementing information management projects.
When confronted with this complexity, project teams often fall back upon approaches such as:
• Focusing on deploying just one technology in isolation.
• Purchasing a very large suite of applications from a single vendor, in the hope that this can be used to solve all information management problems at once.
• Rolling out rigid, standardised solutions across a whole organisation, even though individual business areas may have different needs.
• Forcing the use of a single technology system in all cases, regardless of whether it is an appropriate solution.
• Purchasing a product ‘for life’, even though business requirements will change over time.
• Fully centralising information management activities, to ensure that every activity is tightly controlled.
All of these approaches will fail, as they are attempting to convert a complex set of needs and problems into simple (even simplistic) solutions. The hope is that the complexity can be limited or avoided when planning and deploying solutions.
In practice, however, there is no way of avoiding the inherent complexities within organisations. New approaches to information management must therefore be found that recognise (and manage) this complexity.
Organisations must stop looking for simple approaches, and must stop believing vendors when they offer ’silver bullet’ technology solutions.
Instead, successful information management is underpinned by strong leadership that defines a clear direction (principle 6). Many small activities should then be planned to address in parallel the many needs and issues (principle 5).
Risks must then be identified and mitigated throughout the project (principle 7), to ensure that organisational complexities do not prevent the delivery of effective solutions.
Information systems are only successful if they are used
Principle 2: focus on adoption
Information management systems are only successful if they are actually used by staff, and it is not sufficient to simply focus on installing the software centrally.
In practice, most information management systems need the active participation of staff throughout the organisation.
For example:
• Staff must save all key files into the document/records management system.
• Decentralised authors must use the content management system to regularly update the intranet.
• Lecturers must use the learning content management system to deliver e-learning packages to their students.
• Front-line staff must capture call details in the customer relationship management system.
In all these cases, the challenge is to gain sufficient adoption to ensure that required information is captured in the system. Without a critical mass of usage, corporate repositories will not contain enough information to be useful.
This presents a considerable change management challenge for information management projects. In practice, it means that projects must be carefully designed from the outset to ensure that sufficient adoption is gained.
This may include:
• Identifying the ‘what’s in it for me’ factors for end users of the system.
• Communicating clearly to all staff the purpose and benefits of the project.
• Carefully targeting initial projects to build momentum for the project (see principle 10).
• Conducting extensive change management and cultural change activities throughout the project.
• Ensuring that the systems that are deployed are useful and usable for staff.
These are just a few of the possible approaches, and they demonstrate the wide implications of needing to gain adoption by staff.
It is not enough to deliver ‘behind the scenes’ fixes
Principle 3: deliver tangible & visible benefits
It is not enough to simply improve the management of information ‘behind the scenes’. While this will deliver real benefits, it will not drive the required cultural changes, or assist with gaining adoption by staff (principle 2).
In many cases, information management projects initially focus on improving the productivity of publishers or information managers.
While these are valuable projects, they are invisible to the rest of the organisation. When challenged, it can be hard to demonstrate the return on investment of these projects, and they do little to assist project teams to gain further funding.
Instead, information management projects must always be designed so that they deliver tangible and visible benefits.
Delivering tangible benefits involves identifying concrete business needs that must be met (principle 4). This allows meaningful measurement of the impact of the projects on the operation of the organisation.
The projects should also target issues or needs that are very visible within the organisation. When solutions are delivered, the improvement should be obvious, and widely promoted throughout the organisation.
For example, improving the information available to call centre staff can have a very visible and tangible impact on customer service.
In contrast, creating a standard taxonomy for classifying information across systems is hard to quantify and rarely visible to general staff.
This is not to say that ‘behind the scenes’ improvements are not required, but rather that they should always be partnered with changes that deliver more visible benefits.
This also has a major impact on the choice of the initial activities conducted (principle 10).
Tackle the most urgent business needs first
Principle 4: prioritise according to business needs
It can be difficult to know where to start when planning information management projects.
While some organisations attempt to prioritise projects according to the ’simplicity’ of the technology to be deployed, this is not a meaningful approach. In particular, this often doesn’t deliver short-term benefits that are tangible and visible (principle 3).
Instead of this technology-driven approach, the planning process should be turned around entirely, to drive projects based on their ability to address business needs.
In this way, information management projects are targeted at the most urgent business needs or issues. These in turn are derived from the overall business strategy and direction for the organisation as a whole.
For example, the rate of errors in home loan applications might be identified as a strategic issue for the organisation. A new system might therefore be put in place (along with other activities) to better manage the information that supports the processing of these applications.
Alternatively, a new call centre might be in the process of being planned. Information management activities can be put
in place to support the establishment of the new call centre, and the training of new staff.
Avoid ’silver bullet’ solutions that promise to fix everything
Principle 5: take a journey of a thousand steps
There is no single application or project that will address and resolve all the information management problems of an organisation.
Where organisations look for such solutions, large and costly strategic plans are developed. Assuming the results of this strategic planning are actually delivered (which they often aren’t), they usually describe a long-term vision but give few clear directions for immediate actions.
In practice, anyone looking to design the complete information management solution will be trapped by ‘analysis paralysis’: the inability to escape the planning process.
Organisations are simply too complex to consider all the factors when developing strategies or planning activities.
The answer is to let go of the desire for a perfectly planned approach. Instead, project teams should take a ‘journey of a thousand steps’.
This approach recognises that there are hundreds (or thousands) of often small changes that are needed to improve the information management practices across an organisation. These changes will often be implemented in parallel.
While some of these changes are organisation-wide, most are actually implemented at business unit (or even team) level. When added up over time, these numerous small changes have a major impact on the organisation.
This is a very different approach to that typically taken in organisations, and it replaces a single large (centralised) project with many individual initiatives conducted by multiple teams.
While this can be challenging to coordinate and manage, this ‘thousand steps’ approach recognises the inherent complexity of organisations (principle 1) and is a very effective way of mitigating risks (principle 7).
It also ensures that ‘quick wins’ can be delivered early on (principle 3), and allows solutions to be targeted to individual business needs (principle 4).
Successful projects require strong leadership
Principle 6: provide strong leadership
Successful information management is about organisational and cultural change, and this can only be achieved through strong leadership.
The starting point is to create a clear vision of the desired outcomes of the information management strategy. This will describe how the organisation will operate, more than just describing how the information systems themselves will work.
Effort must then be put into generating a sufficient sense of urgency to drive the deployment and adoption of new systems and processes.
Stakeholders must also be engaged and involved in the project, to ensure that there is support at all levels in the organisation.
This focus on leadership then underpins a range of communications activities (principle that ensure that the organisation has a clear understanding of the projects and the benefits they will deliver.
When projects are solely driven by the acquisition and deployment of new technology solutions, this leadership is often lacking. Without the engagement and support of key stakeholder outside the IT area, these projects often have little impact.
Apply good risk management to ensure success
Principle 7: mitigate risks
Due to the inherent complexity of the environment within organisations (principle 1), there are many risks in implementing information management solutions. These risks include:
• selecting an inappropriate technology solution
• time and budget overruns
• changing business requirements
• technical issues, particularly relating to integrating systems
• failure to gain adoption by staff
At the outset of planning an information management strategy, the risks should be clearly identified. An approach must then be identified for each risk, either avoiding or mitigating the risk.
Risk management approaches should then be used to plan all aspects of the project, including the activities conducted and the budget spent.
For example, a simple but effective way of mitigating risks is to spend less money. This might involve conducting pilot projects to identifying issues and potential solutions, rather than starting with enterprise-wide deployments.
Principle 8: communicate extensively
Extensive communication from the project team (and project sponsors) is critical for a successful information management initiative.
This communication ensures that staff have a clear understanding of the project, and the benefits it will deliver. This is a pre-requisite for achieving the required level of adoption.
With many projects happening simultaneously (principle 5), coordination becomes paramount. All project teams should devote time to work closely with each other, to ensure that activities and outcomes are aligned.
In a complex environment, it is not possible to enforce a strict command-and-control approach to management (principle 1).
Instead, a clear end point (’vision’) must be created for the information management project, and communicated widely. This allows each project team to align themselves to the eventual goal, and to make informed decisions about the best approaches.
For all these reasons, the first step in an information management project should be to develop a clear communications ‘message’. This should then be supported by a communications plan that describes target audiences, and methods of communication.
Project teams should also consider establishing a ‘project site’ on the intranet as the outset, to provide a location for planning documents, news releases, and other updates.
Staff do not understand the distinction between systems
Principle 9: aim to deliver a seamless user experience
Users don’t understand systems. When presented with six different information systems, each containing one-sixth of what they want, they generally rely on a piece of paper instead (or ask the person next to them).
Educating staff in the purpose and use of a disparate set of information systems is difficult, and generally fruitless. The underlying goal should therefore be to deliver a seamless user experience, one that hides the systems that the information is coming from.
This is not to say that there should be one enterprise-wide system that contains all information.
There will always be a need to have multiple information systems, but the information contained within them should be presented in a human-friendly way.
In practice, this means:
• Delivering a single intranet (or equivalent) that gives access to all information and tools.
• Ensuring a consistent look-and-feel across all applications, including standard navigation and page layouts.
• Providing ’single sign-on’ to all applications.
Ultimately, it also means breaking down the distinctions between applications, and delivering tools and information along task and subject lines.
For example, many organisations store HR procedures on the intranet, but require staff to log a separate ‘HR self-service’ application that provides a completely different menu structure and appearance.
Improving on this, leave details should be located alongside the leave form itself. In this model, the HR application becomes a background system, invisible to the user.
Care should also be taken, however, when looking to a silver-bullet solution for providing a seamless user experience. Despite the promises, portal applications do not automatically deliver this.
Instead, a better approach may be to leverage the inherent benefits of the web platform. As long as the applications all look the same, the user will be unaware that they are accessing multiple systems and servers behind the scenes.
Of course, achieving a truly seamless user experience is not a short-term goal. Plan to incrementally move towards this goal, delivering one improvement at a time.
The first project must build momentum for further work
Principle 10: choose the first project very carefully
The choice of the first project conducted as part of a broader information management strategy is critical. This project must be selected carefully, to ensure that it:
• demonstrates the value of the information management strategy
• builds momentum for future activities
• generates interest and enthusiasm from both end-users and stakeholders
• delivers tangible and visible benefits (principle 3)
• addresses an important or urgent business need (principle 4)
• can be clearly communicated to staff and stakeholders (principle
• assists the project team in gaining further resources and support
Actions speak louder than words. The first project is the single best (and perhaps only) opportunity to set the organisation on the right path towards better information management practices and technologies.
The first project must therefore be chosen according to its ability to act as a ‘catalyst’ for further organisational and cultural changes.
In practice, this often involves starting with one problem or one area of the business that the organisation as a whole would be interested in, and cares about.
For example, starting by restructuring the corporate policies and procedures will generate little interest or enthusiasm. In contrast, delivering a system that greatly assists salespeople in the field would be something that could be widely promoted throughout the organisation.
Conclusion
Implementing information technology solutions in a complex and ever-changing organisational environment is never easy.
The challenges inherent in information management projects mean that new approaches need to be taken, if they are to succeed.
This article has outlined ten key principles of effective information management. These focus on the organisational and cultural changes required to drive forward improvements.
The also outline a pragmatic, step-by-step approach to implementing solutions that starts with addressing key needs and building support for further initiatives. A focus on adoption then ensures that staff actually use the solutions that are deployed.
Of course, much more can be written on how to tackle information management projects. Future articles will further explore this topic, providing additional guidance and outlining concrete approaches that can be taken.
REFERENCES:
http://www.tdan.com/view-articles/5262
http://www.flint.umich.edu/~weli/courses/bus181/notes/chapter3.pdf
http://scm.ncsu.edu/public/facts/facs060329.html
http://www.talkingquality.gov/docs/section1/1_2.htm
Labels:
Friday, January 29, 2010
What does Google do?
1. Apple 
1. Free SEO Labor
1. New Storage Service
