Strategy Analysis for Document Management
Ready to embark on a new document management initiative? You know all about strategy analysis for document management, of course. As an information management professional, you have a background in IM, business analysis, project management methodologies, change management, procurement and everything else that’s needed to run a successful document management project—from start to finish.
Or maybe not. You’re new in your role. Management has a new top-down strategic initiative and now you’re part of it. You have your CRM, CIP or IGP, but not a PMP or CBAP. So how do you start, and–just as important–how do you finish? In this first of five installments in our Insights series on document and information management projects, I’ll explain how using strategy analysis for document management will get your initiative going in the right direction from the start.
Four Phases of a Document Management Initiative
To be successful, you need to be able to incorporate business analysis and project management methodologies into your information management initiative. Based on my experience as a business analyst and project manager in information management, the phases you’ll need to go through in your document management initiative are:
The first, strategy analysis, is the focus in this Insights blog. Strategy analysis includes the business analysis activities you do before you start a project and others you do as soon as the project starts. Future Insights blogs in this five-part series will cover project planning, delivery, monitoring, and closing.
Before you start a project, you’ve got to have a business need. It could be a business problem that needs solving, or a process that needs improving, or an external factor that needs addressing. Regardless of the need, starting with strategy analysis will help you focus on the right things to be successful.
Specifically, strategy analysis is one of the six knowledge areas the International Institute of Business Analysis (IIBA) includes in its Business Analysis Body of Knowledge (BABOK). In summary:
[Strategy analysis] describes the tasks used to identify the business need, address that need, and align the change strategy within the enterprise.BABOK v.3
Strategy analysis consists of four tasks—as they are referred to in the BABOK—each of which has inputs, is completed by using a variety of tools and techniques, and produces outputs that you’ll eventually use in your project…IF you decide to move forward. In other words, one possible outcome of strategy analysis is not doing a project or doing something else. Now let’s look at the four tasks you’ll go through:
Four Strategy Analysis Tasks
Although these four tasks are presented sequentially, which for the most part they are, there will be overlap and revisions as you complete the four tasks in the process. I’ll summarize each task with the assumption that some business needs have been identified:
|Analyze current state||Inventory what you have and what you don’t have to find out why you need to change something|
|Define future state||Define what you need to have|
|Analyze risks||Find things that could negatively impact your transition from the current state to the future state|
|Define change strategy||Figure out ways to get from the current state to the future state, while considering risks|
As we go through the four strategy analysis tasks, I’ll also include some examples based on the following business need, which are identified with an orange background:
Part of a strategic initiative to modernize the finance, accounting, and controlling function, upper management implemented a company-wide ERP system last year. As expected, it is up and running on time, on budget, and to specifications. However, it was not integrated with your document management system because…you don’t have one. Management’s new strategic initiative to improve the quality and efficiency of business processes that interact with the ERP system, and as head of the records management department, you know lots of processes need to change…
Now let’s get started with strategy analysis!
Analyze Current State
Assuming you have identified your business needs, you’re ready to start your current state analysis. The activities you perform in this task form the baseline for the other three strategy analysis tasks. Basically, when you analyze the current state, you’re figuring why things are the way they are:
- Process. Why are we doing processes the way we’re doing them? …because we’ve always done it that way…
- Technology. Why do we have the systems we have and why don’t we have others? …because IT says we can’t use open source tools…
- Policies. Why are these policies and procedures in place? …they seem outdated…
- Resources. Who do we have that knows about …information governance, business process improvement, document management systems…
The outputs from your current state analysis include a current state description (what you have) and your business requirements (what you need). Business requirements define your high-level business needs and explain why you need to do something. Based on our scenario:
Analyze Current State. You’ve analyzed the current state and have concluded that the best course of action to meet the business need (process efficiency) is to implement a company-wide document management system. A business requirement would be: To process records more efficiently, we need a single system of record that can integrate with our ERP system.
Business requirements describe why you need to do something, but not what or how to do it…the specifics start to emerge when you define the future state.
Define Future State
When you define the future state (aka the “proposed” or “to be” state), you are defining what success will look like. The purpose of defining the future state is to communicate to stakeholders the benefits of addressing the particular business need. You will consider things like:
- Goals and objectives. Based on our business needs, what do we want to achieve and by when.
- Scope. What’s in, and what’s out;
- Constraints. What are the boundaries of what we need to do: Money, people resources, time, expertise, etc.
- Measurable results. CSFs define what must be done to be successful, and KPIs define if goals have been achieved.
- Policies and procedures. What do we need to add or change to accommodate the future state.
The outputs from your future state analysis include the future state description, business objectives, and potential value (aka cost-benefit analysis). Business objectives need to be both attainable, time-targeted, and measurable.
Describe Future State. You’ve analyzed the current state and have come up with some goals and objectives that will meet the business need to improve process efficiency. One goal is: To implement a document management system (DMS) that will integrate with our ERP system, and a related business objective is: By January 1, 202X, have invoice and contract documents in our DMS linked to master records in our ERP system.
Now, do you just dive in and start? Of course not, projects have risks that you need to manage. So how do you deal with them reasonably? That’s when you assess your risks, the third task in strategy analysis.
As described in Get Started with Information Governance, risk reduction (mitigation) focuses on reducing the likelihood an adverse event will occur while determining the impact the event would have if it did occur. In a project, there are two levels of risk: Individual and overall. Let’s look at the definition and an example of each:
|Individual Project Risks||Overall Project Risks|
|Affect one or more project objectives||Affect the entire project and can be made up of multiple individual risks, external environmental factors, and other events|
|“There is a 10% chance that all 201X contracts will need to be migrated to the new DMS after it goes live.”||“There is a 5% chance that our preferred project manager will not be available for the duration of the project.”|
At a high level, you first need to identify project risks and determine your organization/project risk tolerance (e.g., how much are we willing to spend if ‘x’ happens). Next you need to classify the risks that are above your tolerance threshold and decide how to mitigate those risks. This is what that process looks like:
Quantify and Qualify Risks
Risks should be quantified and qualified whenever possible. For example, it is more precise (and informative) to say “there is a 20% chance ‘x’ will occur within the first 3 months of the project” instead of “there is a risk that ‘x’ will happen during the project”. Definitely consider the financial and scheduling impact risks can have. For example:
Assess Risks. You’ve identified a risk related to your objective of getting documents linked to your ERP system on time: There is a 20% chance we will not be able to migrate in-process contacts to the DMS by January 1, 201X because of resource constraints, which means we’ll need to run two systems concurrently until the migration is complete. To mitigate this risk, you might engage a contractor who has document/record/metadata migration experience.
And don’t confuse risk: Bob in accounting is going to retire at the end of the year with change strategy activities (next section): Bob in accounting is set in his ways and there is a 50% chance he’ll try to sabotage the project.
Finally, understand your risk tolerance, which is simply how much risk “you can live with”. At one end is zero tolerance, which is generally going to be prohibitively expensive, on the other is, basically, let’s not worry about it, which can also be expensive since you’ll need to react to (vs. plan for and mitigate) negative events.
Define Change Strategy
The last task to consider in strategy analysis is your change strategy. You need a solid change strategy to successfully get from the current state to the desired state. It represents the plan to transition from now to then (it even has its own requirements…the aptly named “transition requirements”). Let’s look some of the key elements of change strategy:
- Scope. The boundaries of the solution, the scope describe what’s in scope, and what is out-of-scope.
- Gap analysis. Considers the ‘gap’ between what is currently possible and what needs to be done to meet the business needs.
- Readiness assessment. A personal favorite, this analysis looks at your organizations capacity / willingness to change from the current state to the future state.
Change Strategy vs. Change Management
From a business analysis perspective, change management is part of your change strategy and refers to organizational change management, which includes the activities, tools and techniques to get change accepted in an organization. The Prosci ADKAR Model is a well-known organizational change management framework that can help you manage the people side of your change strategy (aka, stakeholder engagement).
Change Strategy. You’ve known Bob in accounting for a long time. He is well respected in the organization and was key to getting the new ERP system implemented. However, you know Bob is less enthusiastic about a new DMS but you need him to be actively engaged in the project. As part of your change strategy, you engage Bob directly, starting with the “A” (awareness) from the ADKAR Model: Make sure Bob is aware of the business need (process efficiency) and how it will benefit him and his department (e.g., higher quality, better controls, and other things that accountants like to hear).
From a project management perspective, a change management plan describes how change requests are handled throughout the project life cycle. Your change strategy is quite different from project change management. Don’t be ambiguous…be sure to use the right qualifier so everyone is on the same page!
Strategy Analysis for Document Management Considerations
This blog, is of course, an overview and therefore rather light on specifics. The intent is to inform you at a very high level about the things (tasks) you need to consider when you’re thinking about a document management project. The IIBA BABOK guide is nearly 500 pages of techniques, processes, and ideas, and you’ll probably only ever use some of the information in it, but what you use will vary in each new project so it makes a good reference. The same is true of the PMI PMBOK (over 700 pages); you apply what is relevant to your particular project.
Once you’re clear on what the needs are, look at what you’ve got (current state) as your baseline. Next, figure out at a high-level, what your ideal future looks like (desired state). Then identify, classify and quantify risks, and finally develop a change strategy to get your from where you are to where you need to be.
Remember, when you start your strategy analysis, start with your business needs. If there’s no business need, then there’s no reason to continue. Happy analyzing!
Contact us with your questions—we’re ready to help you be successful!CONTACT OVITAS