How we change what others think, feel, believe and do
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.
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).
An early part of the work is to identify the stakeholders involved. These may include:
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.Typically there are two points at which action can take place: the symptom and the root cause. Addressing the symptom relieves current pain but may lead to recurrence of the problem – to prevent this requires action around the root cause.
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.
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 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 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
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:
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.
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:
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.
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 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 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.
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.Breaking down the approach into phases of activity and sub-tasks can be helpful, particularly when you then estimate how long each will take.
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 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:
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.
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.
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.
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.
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).
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.
In order to continue with the project, various commitments need to be made. These include:
Signoff of this gate (and other gates) requires explicit commitment either from these people or a superior manager.
And the big