Driving Opportunities for Change: How Users Can Mobilize Change in their Divisions

In every workplace, opportunities for improvement and innovation abound, but how does one get started?

• What seems to be the problem or opportunity?
• What are potential solutions and outcomes?
• Who to contact?
• What’s the plan?

There is always an employee, a customer (internal or external) or a manager/leader:

• Who doesn’t know what the problem is;
• Who thinks they know what the problem is, but the problem is really something else;
• Who knows what the problem is, but doesn’t understand, or believe, or listen to the customer or employee.

A good approach for identifying the problem or opportunity and effectively presenting the solution to a manager is to develop a business case. The business case defines the problem or opportunity, describes the benefits, and estimates the cost and timeline to bring the project to fruition.

Thinking about how to define a problem or opportunity is usually a great start. Within the business analysis domain, a problem is defined as “an undesirable situation that prevents the organization from fully achieving its mission, vision, goals or other objectives.” An opportunity is “a chance to improve the organization even in the absence of an identified problem.” A problem statement includes “categorization of problems and opportunities; may also include constraints and an initial vision of the solution” (Whitten & Bentley, Systems Analysis & Design).

Next, it is important to think about how the idea fits within the team/department and also the organization’s objectives and strategic direction. Examples of business objectives include improving customer service, improving employee morale, reducing software support costs, increasing enrollments, etc. You can use a grid to bring together the problem, the benefits, risks, and other information to clarify why this particular solution should be selected.

This exercise should help determine if the problem is worth solving. If that is the case, assessing the objectives to ensure they are viable is a good next step. The SMART framework is a good evaluation tool that does the job. For each objective you should ensure that they are:

Specific – describing something that has an observable outcome

Measurable – tracking and measuring the outcome

Achievable – testing the feasibility of the effort

Relevant – in alignment with the organization’s key values, mission, goals

Time-bounded – the objective has a defined timeframe that is consistent with the business need

After defining the problem, evaluating the benefits, and assessing objectives, the next step is designing the solution. In his book, “The Mythical Man-Month: Essays on Software Engineering,” Fred Brooks writes that “the hardest single part of building a software system is deciding precisely what to build. No other part of the conceptual work is as difficult as establishing the detailed technical requirements.[…] No other part of the work so cripples the resulting system if done wrong. No other part is as difficult to rectify later.” This is true for other types of change initiatives, such as process changes, change requests to add components to an existing system, etc. It is important to understand upfront what capabilities or conditions must be met by the solution.

These are formally known as requirements and they can be functional (describe the activities and services a system or process must provide) or non-functional (describe the required qualities of the system or process, such as performance, efficiency, reliability, usability, security). There are many ways to elicit requirements after the appropriate stakeholders have been identified, some ideas include focus groups or interviews, survey/questionnaire, lessons learned process, observation, data sampling, requirements workshops, root cause analysis, SWOT analysis, prototyping, benchmarking. The information gathered will help determine what’s included in scope and what’s excluded from scope, along with constraints and the potential impacts of the proposed changes.

Good planning also involves assessment of potential risks. To identify risks, begin by brainstorming what could go wrong with the project. For each risk, assess the likelihood of it happening, any associated costs (tangible and intangible) and mitigation strategies that can be used to either reduce the likelihood or the impact. You may also simply accept a known and understood risk. Risks and the planned mitigations should be well documented and reassessed throughout the project. Keep in mind that the value in identifying and evaluating risks comes from developing, implementing and tracking mitigation strategies.

The business case (the business rationale for the project) is now almost complete. Additional consideration may be given to estimates on cost/benefit (financial and non-financial), return on investment (ROI), payback (length of time for the project to pay for itself), and so on. Also, to strengthen the proposal’s chances of being approved or considered, an estimated timeline for completion (timing is critical), resources needed and budget should be included.

Good leaders always establish short- and long-term priorities and use relevant data to determine which projects to invest in. Approaching a group leader with a proposal that is well documented, will provide them with the relevant information needed to make good decisions. Providing the person researching an improvement or innovation opportunity with accurate and useful information will help determine if the idea is worth pursuing, as well as help leaders make better investment decisions, and ensure the project (should it be approved) is off to a strong start.

– – – –

References:

Brooks, F. (1975) The Mythical Man-Month: Essays on Software Engineering. Addison-Wesley Professional; Anniversary edition.

Whitten. J., and Bentley, L. (2005) Systems Analysis & Design. McGraw-Hill/Irwin; 7th edition.