How we change what others think, feel, believe and do

Discovery

Disciplines > Change Management > The 4D Change Project Framework > Discovery

Understanding | Formulating the problem | Outlining the solution | Agreeing to the project | See also

.

The overall activity in discovery is to understand the situation and hence formulate the problem (including benefits) from which the probable solution may be outlined and hence an initial estimate made for the time and cost of project.
Note that the Definition phase may expand upon work here, adding more detail. In a small project where analysis is easy and solutions are relatively obvious, Discovery and Definition may be done together.

Understanding

The first step is to discover what there is to understand, gathering data, information, opinions and anything else that will help you formulate the overall problem to be solved.

Review materials and data

Depending on the project, there may be more or less materials that may be reviewed to help gain an understanding of the situation. Existing materials may be very extensive or may be sparse or non-existent. They may also be dated, giving a view that is no longer valid (but are still useful for understanding the historical context).
Information may include both written documents and in numerical data that can be analyzed to give further understanding. As appropriate, further measurement and analysis may be required and may be planned as an additional step in the project.
Beware of being trapped by existing materials, either because of the quantity of them or perhaps because they are no longer fully representative. Just because something is written down it does not mean that it is wholly true.

Interview stakeholders

An early part of the work is to identify the stakeholders involved. These may include:

• The primary operational manager who will benefit from the project
• The executive sponsor who acts as organizational champion and acts as a point for escalation of organizational issues.
• Other resource owners who will be asked to direct their people or spend money on the project
• People who have a understanding of the process and issues in question.
• Influential people whose opinions in the project area are respected.

During the interviews, a number of different views may be given as to the problem to be resolved and its causes (this is sometimes called the ‘presenting problem’). These may or may not be the right problem. Often they may be more to do with experienced symptoms rather than real causes or framed as assumed solutions.

Understanding the big picture

Clarifying the historical events that led up to the problem being experienced often help to make sense of what has happened and why. This may occur as a chain of causes as ‘one things leads to another’, culminating in the issue to be resolved. For example an unexpected change in regulations led to development of a quick-fix spreadsheet that got changed by people who did not fully understand how it worked, resulting in inaccuracies that affected customer deliveries.

The business context of the situation gives boundaries to the problem, detailing what processes, departments and organizations are affected by the issue. This helps scoping of the problem. Note that those who are experiencing the problem may not be those who are causing it. The business context includes both the beneficiaries of the project and also those who may have to change.

Issues are the less than perfect problems that are being experienced that need to be resolved. They are typically experienced as unplanned and uncomfortable events and are effectively ‘risks which have happened’.

Causes may also be found. These may be chained, with the root cause being distant from immediate causes. Causes can also be circular, creating vicious spirals of decay and increasing issues. Finding the real cause of an issue is not always straightforward and may need additional work.

Formulating the problem

Having gathered data about the situation, the next stage is to crystallize the real problem that is to be resolved. Note here that the problem as presented in the mandate may change significantly, particularly as the views of additional stakeholders and other evidence are examined.

Benefits

In defining the purpose of the project, detail the benefits that target stakeholders will receive. These may well be intangible, for example where decisions are ‘easier’ to make, or may be more measurable, such as when work takes less time or costs less.

Outcomes

Outcomes are what happens as a result of the project and may be beneficial or undesirable for various stakeholders. Sometimes a benefit for one is a dis-benefit for another, such as when workload on one group is shifted to another (perhaps as a result of  ‘workload balancing’). Outcomes can also be neutral, being an effect of the change but which neither benefits nor troubles anyone, for example a route change that remains the same time and distance.

The benefit or issues caused by perceived outcomes are a root cause of support or opposition to the change project and hence communications around these should be managed carefully. Sometimes, for example, the project might be adjusted to compensate those who receive some negative benefits.

Constraints

Constraints are typically identified during interview and review. They limit the project in various ways and typically include aspects of time, quality and cost, for example the need to align with other work and remain with budget constraints. Regulations and standards also constrain the project.

Constraints may thus contribute both to the formulation of the problem and also limit potential solutions.

Project goals / objectives

Project goals (or objectives) typically summarize benefits and outcomes in a short sentence including change words such as ‘create’, ‘eliminate’, ‘increase’ or ‘reduce’. Typical project goals are shown in Table 1, below.

Table 1. Typical project goals

Targets

Project targets are measurable levels for project goals. Thus, for example, if you have a goal to ‘decrease delivery time’, a target could be ‘two days’. There can be three types of target:

• A Standard target is one which, if achieved, allows success to be declared.

• A Stretch target is one which, if achieved, will allow outstanding success to be claimed.

• An Ultimate target is the best possible result, for example zero errors.

Outlining the solution

The solution may be known in varying detail at this time, depending on the project. It may also be that you need to explore a number of options in the next stage.

Options

If you are going to explore further in the next stage, the options to understand may be described in as much detail as is known now. The criteria by which options are selected may also be described.

Outputs / deliverables

Project outputs (or ‘deliverables’) are those things created or caused in the project that lead to the outcomes and benefits. Outputs may be:

• Material, such as software or documents,

• Information, such as communications or training, or

• Commitment, such as agreement.

Knowing the outputs of the project implies knowing what the solution will be. This may not be known at this time and hence may described either in outline or not at all. The detail of outputs are usually specified in the Definition phase.  On the other hand, some projects are well understood from the beginning and clients are able to clearly specify the deliverables they need. When this is the case, is may still be worth stepping back for a moment to check what they are asking for will truly resolve the real problems and issues they face.

Selection of what to include in the solution may require a process of rational choice, using defined criteria. This may use a weighted scoring method or simple assessment.

Scope

A description of scope typically indicates what is in and what is out of the project. It thus defines the boundaries of the work. Where the scope crosses organizational boundaries then work will be required to establish legitimization and collaboration in these areas.

Constraints

Constraints are specific other factors that bound the solution, and may include elements of time (such as aligning with delivery schedules), cost (perhaps constrained by budget) and ‘quality’ (for example as defined by specifications). External laws, regulations and standards adopted also act as constraints and should be listed as appropriate.

Guidelines

Guidelines are suggestions that are offered by stakeholders as to the approach that might be used, for example the level of involvement of various people and groups in the process.

Whilst guidelines need not be followed, they can provide useful suggestions from people who are intimately engaged in the target areas. Guidelines can also sometimes yield further understanding of the problem where they give an insight into the thinking of those who are proposing them.

Approach

At this stage a detailed plan may not be possible, but enough needs to be defined to determine costs and overall timescales and hence determine the business case and whether or not the project should continue.

The approach should address risks identified, for example by using collaborative methods to reduce risks of resistance to change or using known and proven technical suppliers for software development.

The approach may offer several options (typically around three) that may be taken. It can be helpful to show the pros and cons of each option. Explain the assumptions being made, to allow for later justification and rational challenge.

Dependencies

Dependencies are a particular form of risk for change projects that need to be handled carefully. All it takes is for one person on whom you are dependent to limit their collaboration and the whole project can go astray.

Different approaches may lead to different dependencies – thus consideration of dependencies and the approach taken may well done concurrently or iteratively.

Dependencies can occur in two directions – whilst the project may be dependent on others, others may also be dependent on the project, for example where another change project is based on the success of this project. The success of business strategies and operational activities may also depend on the project delivering to specification.

Risks

Risks are a moderating factor that may affect such as cost, quality and timescales, changing the achievement of goals from being certain to having some lower probability.  Overall assessment of risks should include consideration of:

Impact

• What would happen should the risk occur, who this affects and the impact on them. Impact may include elements such as cost, reputational damage, timescale of impact and so on.

• How manageable the risk would be if it happened, including how easy it would be to recover the situation such that losses are only temporary.

• What contingency may be put in place beforehand to improve that manageability and reduce the impact.

Probability

• The probability of the risk happening, how clear this probability is and how this may change over time and with events.
• How the changing probability and triggers may be monitored and what should be done about this.
• What should be done to reduce or contain probability, for example by managing trigger events.

Where risks of successful completion of a project are high then this may be a good reason not to continue the project beyond this point. Risks may also change the approach used, for example where significant extra relationship management activities are added to handle risks of non-collaboration.

A very common risk in change projects is a lack of collaboration by key people, either in analysis and developing the solution, or in implementation of the change. This can be due to resistance to change where they do not agree with what you are trying to do. It may also be simply because people have a ‘day job’ which is taking priority over the change. It is important to identify and address such issues early, for example by getting senior commitment to the allocation of people’s time in working in and with the project.

Another common risk is that the solution will not solve the problem. Where solutions are large and expensive (such as automating a process with a complex software solution), this risk is even greater. It is also common that the problem to be resolved is not fully identified, which will automatically ensure any solution will fail.

Risk can be compounded when the urgency of resolution or limited funds leads to unrealistic expectations around timescales, budgets and the quantity and quality what will be delivered. Particularly when the problem or solution is not well understood it is easy to pick a convenient number out of the air without real knowledge of how attainable it will be in practice.

Taking time up-front to assess and address change risks can pay dividends. Failure to pay up front will lead to a more expensive and difficult problem later in the process.

Resourcing

Resource for change projects is often described in terms of people and management support required. Where appropriate, additional expenditure may be required, for example to hire consultants and facilitators.

Also include the resource that will be needed from the organization, for example the days of effort from people with operational responsibilities.

Timescales

Time comes in two types: calendar time and person time. Individual activities may thus take three weeks, yet only need three days of total effort. The project may also be driven by constraints of when deliverables are needed and when resources are available.

The timescale typically appears as a Gantt Chart and may be done using MSProject, Excel or Powerpoint, depending on the complexity of the project.

Agreeing to the project

Time and resource are the main investment for most projects. They also often need the collaboration of a wide range of people. Gates are the major agreement points and Gate 1 is the first main point. Done well, a signoff will result in full and firm commitment by everyone involved to all subsequent work and change.

Business case

The business case gives justification of the project and summarizes much of the previous detail into the pros and cons for continuing the project, in particular:

·    Reasons why the project should go ahead, including benefits to be gained and continued problems and issues if the project is not completed.

·    Reasons why the project may not be continued, including cost, timescale and significant risks.

In Discovery, resource and time allocation should be divided into two parts – that required to reach the next Gate should be accurately defined, whilst that needed to complete the project may only be an estimate (this will be determined in the subsequent Definition phase).

Explorations

The solution to take may not be clear in this stage and may need more exploration into various options in the next stage. If so, this 'options analysis' needs to be in the plan.

Commitments

In order to continue with the project, various commitments need to be made. These include:

• The functional manager who is the main client agrees that outcomes, deliverables and timelines will deliver needed value.
• All knowledge owners and experts from whom information and collaboration will be required.
• All process owners who are affected by process changes, including affected adjacent processes, who will need to agree to any process changes.
• All managers whose people will need to act differently in some way as a result of the change.
• The executive sponsor who agrees to project resourcing and promises ongoing high-level support.
• Any additional stakeholders whose support for the change is needed, including those who have the power to block or veto the change, or otherwise cause issues for the project. 

Signoff of this gate (and other gates) requires explicit commitment either from these people or a superior manager.

See also

Gate 0 Checklist, Gate 1 Checklist, Stakeholders in change