The change strategy: preparing for change, and how do I start?

Extract from the book by Cenred Harmsworth and Dr Jack Jacoby, Managing Change Initiatives
Available in Hard Back, Soft Back and eBook from Amazon

DEFINITION AND OVERVIEW

Preparing for change is the assessment, consideration, and preparation an organization makes before the change process actually commences.

Such preparations occur at the very outset of the change process and would include the following:

• Securing board approval.
• Securing an internal sponsor for the change initiative.
• Establishing a robust and accountable project-governance process.
• Establishing a clear and unambiguous vision for the change initiative.
• Developing a strategy to communicate the vision.
• Having clarity of the impacts of the change initiative on all parts of the organization and its stakeholders and having the agreement from those parts of the organization and stakeholders.
• Having clarity of the various needs of all stakeholders.
• Having a change initiative plan (project plan).
• Having a keen understanding of all relevant risk issues and having in place strong mitigation and contingency strategies/plans.
• Having an organization-wide engagement model, for example, that may include change agents.
• Having an effective and powerful project communications plan.
• Having a strategy to maintain change initiative energy and momentum—even when nothing appears to be happening.

WHY IS THIS IMPORTANT?

Wherever you have a new idea, be it a new product, a new service, or a way of improving your business or organization, then change will be involved.

The elements listed above need to occur before the change initiative actually commences. The reason for this is that once the project commences, things will happen, people will react, and activities will occur. If you haven’t thought through all this before the action commences, then some of it will come as a surprise and some decisions will be made that may be inappropriate, rushed, or without suitable organizational understanding, preparation, or approval.

There is nothing more likely to lose staff and stakeholder confidence in management than a plan, developed and approved by management, that doesn’t accommodate the obvious. You have the power and ability to manage staff and stakeholder perceptions by avoiding errors that will shape those negative perceptions.

Any actions that are undertaken that have not been thought through will be seen by staff as amateurish and unprofessional. They will inevitably lose confidence in the change initiative and make the required change that much harder to deliver.

It’s a little like a surgeon getting ready to operate. He ensures that his surgical tools, equipment, and staff are prepared for the operation and that he is ready for any situation. Then he is ready to commence the operation.

By effectively completing these preparations, you will

• reduce the risk inherent in all change programs.
• improve the likelihood of success; and
• ensure you have thought through all the impacts, thereby helping stakeholders to maintain their other operational requirements and maintain their cooperation with the change proposed.

Meticulous pre-implementation planning inevitably involves many people within the organization together with all stakeholders.

This early involvement decreases the opportunity for those people to complain later that they weren’t consulted, weren’t asked, or didn’t have the opportunity to have input. This negates much of the potential complaints that may arise during the project.

Key Points

1. Do the preparations before you start because without it, success is very hard to achieve.
2. It’s easier to prepare than to repair.

Key Actions

1. Ensure that the list of prestart activities is completed before the change initiative commences.
2. Make sure that everyone involved in the project understands the planning process that will be followed, and the contribution expected of them to its development and finalization.

WHEN DO YOU DO IT?

When an idea or a business need becomes “serious” and you want to take it further, then that is when you need to start planning for the project or change initiative.

The formal documentation doesn’t need to start immediately you get an idea, but you do need to start thinking about the initiative in a systematic way. This will include contemplating these questions:

• Why do I want to undertake this change?
• What do I want to achieve from the change?
• Will the board approve the initiative?
• How strong is the business case?
• Who within the organization can I get to provide sponsorship of the initiative?
• What sort of impact is the initiative likely to have on the organization?
• How much disruption will occur?
• How will the organization respond to the initiative and to the disruption? Can it handle the added pressure?
• Can we do this internally, or do we need external help?
• Can we afford expensive external assistance?
• What sort of risks will the organization adopt if we proceed with this initiative?
• What is our history in undertaking this sort of initiative?

When the answers to these questions are largely positive, it’s the time to seriously contemplate a formal approach to your organization’s authority to obtain initial approval to commence the formalization of the prework to get the change initiative approved.

Key Points

You need a positive response to a number of preliminary questions in order to take seriously a new change initiative.

Key Actions

1. Develop a set of preinitiation assessment questions that are relevant for your organization’s senior managers to contemplate.
2. Have your managers use these questions before they formally request a change initiative or project to be adopted.

THINGS TO WATCH OUT FOR

When planning for change, you need to ensure the following:

Consider all aspects

This may sound like a motherhood statement; however, it’s too easy to skip over areas that may seem inconsequential.

What may seem inconsequential to you may be critical to someone in the business. If you mess with their world without consulting with them or considering their needs, then they may create a whole lot of pain for the project.

Also, by contemplating and accommodating all aspects of the proposed initiative, you are less likely to be surprised by an unforeseen event or unexpected occurrence.

Exercise judgment

You don’t need to go into too much detail or spend many hours unnecessarily working the details. However, you do need to apply your skills, experience, and talents to pragmatically answer the core pre-commencement questions outlined in the preceding section.

If you cannot provide realistic, practical, and pragmatic responses to each of these questions, then discuss them with someone inside the organization who can help you resolve a position on going forward or not.

And above all, keep your ego in check and avoid getting emotionally committed to the idea too early. If the project proves worthwhile, then you can release your passion, but be warned about doing that too early as irrational passion paints you as a hothead and not as a rational thinker.

Have flexibility

Knowing that circumstances may change, try not to paint the project (or yourself) into a corner.

Strictly speaking, the only unchangeable aspect of a project is its intent. Note that required outcomes and desired outcomes are not necessarily or always the same. And even then, that may change over time or as more information becomes available.

Where the outcome of a project is a specific measurable outcome (for example, a particular percentage, quantity, or dollar value), then this may be compromised or changed as a result of technical, financial, or even regulatory constraints or realities.

If the objective isn’t amended in light of these constraints and realities and the constraints hinder achievement, then it’s possible that the project will be seen to have failed even when it achieves 99 percent of its objective.

Where the outcome is more nonspecific, then, all other things being equal, it should be easier to achieve (for example, making a process faster, making more money, cutting costs, etc.).

The point here is to remain flexible (and realistic) in setting and defining the outcomes desired from a change initiative and in determining what it will take to deliver those outcomes.

If, for example, you are of the opinion that fifteen processes are critical for change and that there are another three that could be changed but are not critical, then don’t try to enforce the adoption of the three noncritical processes if it’s going to cause grief and pain and means considerable management overhead to get people over the line.

Carefully consider future scope

The preparation and planning should accommodate contingency for any additional requirements that you may not have originally allowed for. This means that if you have a contingency allowance, then you can accommodate additional training or engagement overhead if necessary.

If there are issues that are beyond your control, as there will be, then a reasonable contingency reserve allows you to accommodate the blowout without asking for more budget.

On a more practical note, ask yourself the following questions:

• When the project is implemented and operational (i.e., it “goes live”), what will change apart from the intended changes?
• Are there any likely ramifications on staff?
• Will there be redundancies?
• Do we need more staff or other resources?
• Do you need to backfill the organization’s employees allocated to the project?
• Will staff become bored?
• Will they want more reward?
• Will there be an impact on how their reward is calculated or earned?
• Will they leave?
• Does reporting need to change?
• Is there an impact on structure or resource allocation?
• Have there been any changes to managers’ spans of control? Do there need to be changes?
• Have we captured all budget impacts?
• Are there any legislative or regulatory issues we need to consider?
• Are there any ramifications on suppliers?
• Are there any ramifications on customers, channels, or on the market?
• What will our competitors do?
• If competitors react to match or better our gained advantage, what is our next response strategy?
• Do we need to start preparing for a next response strategy change project?

Don’t commit to a project too early

Often, one sees management promote an idea and then manage the evidence to support that idea. That is both immature and organizationally dangerous.

A mature manager will respond to an idea without committing to it until the evidence and analysis supports it. An idea is just that—an idea. It’s not fact, and it has not yet demonstrated its worth for your organization at this time.

And don’t fall into the trap of doing stuff because it’s the flavour of the time or because others are doing it. A new initiative still requires evidence and analysis—and be justified in its own right.

If you put your reputation on the line for an idea and the idea doesn’t stack up, then what happens to your reputation when the idea bites the dust? Was it worth it? Was it smart on your part to play your cards too early?

For management to adopt it without sufficient examination and assessment is to accept a promise without an understanding of the costs and impacts of the promise.

Key Points

In contemplating a project, ensure that all aspects are considered, that you remain flexible, that you always provide a contingency for unforeseen events and factors, and you haven’t committed to it too early—that is, before the analysis and before the evidence is in.

Key Actions

1. Learn to think and assess without emotion and without commitment.
2. Think in order to decide. Don’t decide and then think how to justify your decision.

THE IMPORTANCE OF A STRATEGY AND A PLAN

Every change initiative or project should have a reason for doing it - that is, an objective required of and from the change.

That objective represents a future outcome or future organizational state - the way you want the organization (or part of it) to perform, look like, or to deliver when the change is complete. If that were not so, then why would you bother doing the project in the first place?

In order for that objective to be satisfied, the organization needs a strategy and a plan to get you from where you are today to where you want or need to be in the future, enjoying the change you are contemplating.

A strategy and a plan are not the same thing. A strategy represents the tactical steps you will adopt. Each step builds on the previous steps so that ultimately, when all the steps are complete, the outcomes will be achieved. The strategy provides the logic and rationale for what will be done.

The plan, on the other hand, provides the detail of what will be done that is required to bring the strategy to fruition. More specifically, the plan identifies

• What work tasks will be undertaken?
• Who will undertake them?
• When they will be undertaken?
• What is the governance structure of the project?
• What needs to be reported, to whom, and when?
• What milestones will be reached during the project and when?
• Which milestones provide a view of the critical delivery path of the project?
• How much will it all cost?
• When will the change initiative be regarded as complete?
• What depends on the successful completion of each task?
• What outcomes and deliverables will be provided during the project and at its conclusion?

Generally, the strategy for the change initiative or project is developed before approval of the project is secured. The reason for this is that the approver will not only need to know why you are proposing the initiative, but also how you propose to undertake it.

Most commonly, the strategy is a significant part of the business case that is submitted for approval.

The plan, on the other hand, is generally developed after approval is secured. Although the business case and perhaps even a standalone strategy paper may deal with a high-level plan, it will not be until approval is secured that a highly detailed and costed plan is developed—commonly using Microsoft Project or a similar planning and tracking tool.

Both strategy and plan are critical for a successful change initiative.

A strategy without a plan is pointless (and sometimes dangerous) - it’s like having a destination without a vehicle to get you there.

A plan without a strategy and clear purpose is a waste of time - it’s like having a vehicle without knowing where you want to go.

Key Points

1. A strategy represents the tactical steps you will adopt in a change initiative. The strategy provides the logic and rationale for what will be done.
2. The plan provides the detail that is required to bring the strategy to fruition.
3. Both strategy and plan are critical for a successful change initiative.

Key Actions

1. For every change initiative undertaken, identify its purpose (i.e., its objective, its strategy, and its plan).
2. Ensure that the objective is also the outcome.
3. Ensure that the strategy is robust, logical, and based on your organization’s real-world environment.
4. Ensure the plan is complete and robust and that it answers all the “what, who, when, how, and outcome” questions.

HOW DO YOU START?

A project generally evolves through a number of phases. It’s semantic where the project actually starts because it depends on how you define start.

Is it when the idea first surfaced, or is it when approval is secured or when the Project Team actually begins work on the project?

If the logical project evolution is followed, then it doesn’t matter much, from a semantic perspective, when the project ‘started’. If it’s done properly, everything that needs to be done will be done and the pieces will fall into place.

The process is as follows:

Phase 1: The Need

Someone (inside or outside of the organization) identifies that things are not as they should be or could be and that something needs to be done to better align the issue, function, or process.

It’s not far-fetched to claim that every organization could identify a large number of potential change initiatives using these criteria.

What then elevates some change proposals to “critical” while others remain “unimportant”?

If a project can satisfy the following criteria, it will (should) be elevated to the top of the change targets. Those that fail to satisfy these criteria are unlikely to ever be tackled by rational management and boards as funds and resources are almost always limited, and most organizations never satisfy all their top priorities to allow them to then tackle lower-priority initiatives.

The following are criteria for establishing project priority:

1. Does the proposed change contribute, directly or indirectly, to the satisfaction of key corporate objectives or outcomes (KPOs)? If there is no clarity of those objectives, then management and/or the board has a real problem as they will struggle to identify and promote those projects that will really impact organizational performance. They risk allocating scarce funds and resources to projects that just don’t matter that much.
2. Is the strategy for the proposal rational, logical, independently verifiable, and within the experience and skill of the organization to successfully deliver?
3. Is the complexity of the project within the capability of the organization?
4. Does the project satisfy the breakthrough principle? Does the project focus on a hurdle to performance, which, if removed, would make a significant breakthrough contribution to organizational performance and effectiveness?
5. Can we afford to do it?
6. Can we afford not to do it?
7. Can we spare the internal resources?
8. For the estimated cost of the project, is there another project that would better be able to deliver corporate objectives?

Phase 2: Authority

Someone in authority (or the board itself) authorizes that time, effort, and resources can be applied to investigate the options available. This frequently leads to a person or department being assigned the responsibility to “take the running on the issue.”

Appropriate authorities may vary depending on

• the discretionary spend allocated to all senior positions,
• the level or type of initiative that must be brought to the board,
• senior-executive-role definition and their ability to undertake certain scope of works and projects,
• senior executive accountabilities, and
• the level of risk likely to be encountered in the initiative.

Ultimately, authority derives from the organization’s charter or constitution.

Phase 3: Options

The authorized person or entity reports back to the initial authorizing person or entity, arguing for a specific approach to solve the problem.

Normally, the authorizer will ask for a detailed business case that clearly identifies costs, benefits, risks, resources, organizational impacts, and timelines.

The options may be developed by an individual, a department or function, a group of cross-disciplinary internal managers, or external parties.

Normally, these options will be presented to an authorizing person or group in a format that covers the following:

• The outcome that is required from each of the options.
• The strategy behind each option - how will this option get the organization to the required outcome?
• The resource commitment (internal and external) required by each option.
• The business, organizational, and stakeholder impacts of each option.
• The timing involved with each option.
• The cost of each option.
• The risks and mitigation strategies associated with each option.
• A recommended priority or ranking of each option against other options.
• A suggested governance structure for each option.

Therefore, when the authorizing person or group adopt a particular option, they should have a realistic understanding of the implications of their decision on the business (i.e., the decision hierarchy) and the chosen option.

Phase 4: The Business Case

At the completion of phase 3, normally a single option is determined as the way forward.

The business case is developed, submitted, refined, and eventually approved. This leads to the following activities:

• Finance is committed, sourced, and embedded in the organization’s cash requirements and projections. Lenders or banks and sometimes shareholders may need to provide approval of additional funding requirements.
• A project leader within the organization is identified, and their role in the project is formalized (project work and normal business duty conflicts are considered, and conflict resolutions strategies agreed). Time away from normal work is understood and agreed.
• Internal resources (i.e., people, premises, equipment) are advised or booked and committed.
• External resources, such as consultants, premises, equipment, are appointed or booked.

The project sponsor is normally a very senior executive, commonly a divisional or corporate manager, and of course, they will not be able to devote all their time to the project. They will not be expected to act as if they were on the project team in an operational sense, but rather their role is to ensure that the project plan, budget, resources, and timelines are adhered to. They also act as adjudicator of issues within the organization relating to the project (such as scope, change, access to resources, people, and facilities), deciding when to escalate issues or not.

The business case is commonly developed with the cooperation and involvement of a wide range of people across the organization, particularly when the project’s impacts will be felt across the organization.

Some part of the finance department commonly plays a critical role in the development of the business case, but it really depends on the type of project being undertaken. The most common criteria from a financial perspective are as follows:

• How much will it cost?
• When will these costs be incurred?
• How will these costs be treated in the organization’s books?
• How much saving or benefit will be generated?
• When will these savings or benefits be secured?
• Will the project generate new revenues?
• If so, how much and when?
• When will the project’s “breakeven” occur?
• What is the project’s return on investment (ROI) or other internal investment criteria?
• Does the projected ROI (or other criteria) exceed the ROI (or other criteria) hurdle rate stipulated by the board for this type of project?
• What commercial risk is involved?
• Are there any insurance issues that require consideration?

Different managers and the board will examine the business case differently due to their particular roles, focus, talents, skills, and responsibilities. Each party will certainly read the business case in its entirety but will focus on its own core interest.

The board, for example, will read the entire business case, take a serious interest in all of it, but have a keener focus on the governance, accountability, investment, legislative/regulatory, compliance, shareholder and stakeholder impacts, reputational and outcome aspects of the initiative.

Divisional managers are more likely to be focused on the operational impacts of the initiative or project on them, their area of responsibility, and their own accountabilities. Will the initiative impede or enhance their personal or divisional KPOs? At what “cost” to them?

If the project will seriously or significantly impact a particular area, then the manager of that area is likely to raise the issue and even object to the project on the grounds of its negative impacts. In such a case, particularly when the project is high priority, then these objections need to be accommodated in some way.

Potential ways to accommodate such concerns are to

• adjust the business case for the project, and its ultimate project plan, to minimize the negative impacts on certain areas by adjusting timing or resources.
• adjust the business case for the project, and its ultimate project plan, by removing the negative impacts on certain areas by extracting from the plan those elements that cause negative and unacceptable impacts, often at the cost of diminishing project outcomes.
• adjust the negatively impacted department’s KPOs or resources for the duration of the project to better reflect their contextual reality and avoid demotivating its people by an influence outside their control; and
• enhance the affected areas’ resources to enable them to better cope with the negative impacts.

Phase 5: The Project Plan

A project plan is developed that specifies what will be done, by whom, when and with what outcomes/deliverables, and at what cost. The plan identifies key milestones when certain key activity completions are due.

This plan is coordinated with all key stakeholders to ensure they are aware of what is proposed and understand how and when they are expected to participate or be impacted.

They are expected to assess the impacts of the plan on their own area of responsibility and make any preparation required to keep their area operating to expected standards.

Phase 6: Commencement

The project commences work according to the project plan.

Depending on how you define project start, you might have effectively started the project anywhere between phase 1 and 6.

Key Points

1. The concept of a project start depends on the way you define it.
2. Starting the project involves a number of specific actions, tasks, and contingency activities.

Key Actions

1. Review the last few major projects undertaken by the organization.
2. Determine whether they followed phases 1 to 6.
3. If not, what were the implications of adopting an alternate process flow?
4. Determine the lessons to be learned from this analysis.

RESOURCES

Resources are generally considered to be sources of supply or support for a project—that is, the things needed to get the project done.

It’s very unusual to find a project that doesn’t require resources of some sort to do what needs to be done.

Resources are diverse and can include the following:

• Money to fund the project and its activities.
• People to undertake project activities and tasks (these may include project managers, business analysts, system developers, system programmers, system architects, stakeholders, HR specialists, finance specialists, change specialists, facilitators, negotiators, support staff, and other wide-ranging specialists defined by the needs of the particular change project):
• Internal people. A project can secure required human resources from different parts of the organization depending on their availability, skills and experience, expediency, available time, and political suitability. Sometimes key internal people required for intensive involvement in a project may have their operational roles backfilled by other internal staff or by external temporary contractors.
• External people. An organization that does not have sufficient spare, skilled, and experienced people to allocate to a project might hire external people (individuals or consulting companies) to augment the project team as required to enable the project to be completed as stipulated and approved.
• Equipment (for example, computers, printers, scanners, faxes, vehicles, construction equipment, telecommunications equipment, etc.) with which tasks get done.
• Premises from which the project gets managed and coordinated and where people do the tasks they have to do.
• Access to other people’s resources by agreement.
• Software with which what needs to be done can be done.
• Internal and external Information upon which project decisions are based (this information may be transactional, market, system, functional, or any other type that is critical to the objective of the project).

Therefore, when planning a project, it’s vital that there is a very accurate understanding of the resources required, when they are required, and how much of them are required. Otherwise, project progress will be impeded when its resources run out or when they are not available as and when they are required.

Capital Resources

Some of these resources may be considered as capital resources by the organization. Capital resources are those that are assets that aid the production of goods and services. Generally, the use of these resources is involved in the production process over an extended period.

If a project requires the use of capital resources, then the financial assessment of the project will probably incorporate an assessment of the opportunity costs associated with the use of these resources.

Opportunity cost (or revenue foregone) of a particular project is a measure determined by the value of other opportunities that the organization has decided not to pursue as a result of pursuing this particular project.

Estimating Resource Requirements

By its nature, a business case and the business plan must estimate the number and type of human resources it needs to do what needs to be done in the allocated time frame.

Generally, the shorter the time allowed to complete the project; the more resources are required.

As an example: 10 people are needed for 6 months = 60 months of effort.

All other things being equal, if the same project needs to be completed in 3 months, then the 60 months of effort will require 20 people for the same output.

The methods that will assist resource estimation include the following:

• Expert judgement of people who have done it all before. This is particularly valuable when they have undertaken the same sort of project and have experienced typical “blowouts” or problems encountered in that type of project. This enables the plan to accommodate a suitable contingency value for time and resources (and of course, costs). That is why consultants are valuable in defining a realistic project envelope within which a project can or should be completed—they will have been chosen (presumably) because they have successfully completed a number of projects of the same or similar type. They should have good experience in estimating project scope—and made accountable to deliver the project if they win the job.
• Examination of hard data on resources required for similar projects. This data might be available within the organization that has been accumulated on past project experience. That is why it’s really important to conduct robust project audits after the completion of projects and keep the data in a place and form that is easily accessible for future reference. Hard data may also be found from external sources that benchmark data on projects and effort required for certain tasks.
• Model resource scenarios through “best case,” “most probable case,” and “worst case” scenarios using whichever scenario is the most suitable for the organization—as each case has its advantages and disadvantages.
• Bottom-up method, which asks the people who must undertake the task to estimate the time needed to complete it, and possibly more importantly, what are the dependencies that will affect when they can start their tasks? This method assumes that you have identified those people who are skilled in assessing the type of task you have allocated to them.
• Resource contingency is the value that is allocated to the resource budget that allows for variation from the estimated resource requirement. This contingency value is the variation that the project is allowed (approved) to occur as a result of project complexity, schedule slippage, and external impacts. It’s expected that drawing on the contingency allowance is a last resort after all other internal options have been exhausted.

Key Points

1. Resource requirements for a project vary and must be estimated before the project commences (unless it’s a “do at any cost” type of project).
2. To avoid delays or shortages once a project has commenced, it’s critical to have estimated resource requirements accurately and obtained approval for their use.
3. Estimating resource requirements is not a matter of best guess. There are techniques for estimating what will be required, when it will be required, and how much of it will be needed.

Key Actions

1. Build a database of past projects and their accuracy in terms of resource usage: that is, what was approved versus what was really used (i.e., direct and indirect usage/costs).
2. Calculate the accuracy ratio.
3. Use the variance from 1:1 (i.e., perfectly accurate) to determine your organization’s accuracy in estimating resource usage for projects.
4. Use this variance percentage as your next project’s contingency factor for resource estimation.

DELIVERABLES

Depending on how you have defined the start of the project, there are a number of milestones that are wrapped around identifiable progressive outcomes. These will vary depending on the type of project undertaken. A technology or systems project will have different milestones and therefore deliverables than, say, a customer channel or an HR project.

The deliverable (i.e., that which is to be delivered) from a change initiative is ultimately the change required and outlined in the project’s BRD.

However, some of the progressive deliverables that a project may be required to produce may include the following:

• A problem (opportunity) scoping paper
• An options paper
• Business case
• Project strategy paper
• Business requirements document (BRD)
• Stakeholder analysis and needs document
• Business impact analysis
• Change management strategy
• Training needs analysis
• Training plan
• Risk management strategy
• Contingency plan
• Project office plan
• Project plan
• Project schedule
• A range of progressive deliverables defined by the nature of the project
• Data migration plan
• Testing plan
• Go live with the future state defined by the BRD
• Evaluation report
• Monitoring reports

These and more are all deliverables. Their purpose is to ensure that each critical stage of the project is as it should be and marks an important reference point for the project team, the organization, and its stakeholders—and of course, the project’s sponsor and authorizer.

When things are not going according to plan, these deliverables are usually the documents that are referred to and examined to identify discrepancies between the approved business case, the BRD, and the progressive or changed reality.

However, the bottom line, in terms of deliverables, is the “go live” event. Everything builds to the “cut over,” which is the moment the new system, product, process, or method goes into production—that is, becomes part of the organization’s normal operations. This is when all is meant to operate as expected and as developed.

Regardless of how extensive and successful the preproduction testing regimen is, this is the first big test of project success—if it doesn’t work at cut over, then there is generally panic because most organizations don’t have an adequate contingency for this type of failure.

The usual method of handling a failed cut over is to revert back to pre-cut over if and when that is possible—but it’s not always possible. That is why a contingency plan for just such an event becomes critical.

The second test of the project’s deliverable is whether the changed environment operates as required over time. As important as a successful cut over is, it’s more important that the change is sufficiently robust to keep working effectively as required.

Some changes take a relatively long time to determine whether they have been successful. Other changes will let you know pretty much at cut over.

Key Points

1. Projects have multiple deliverables.
2. All are important as they act as measures of progress.
3. The ultimate project deliverable is defined by the project’s BRD.
4. Most commonly, the cut over is when the ultimate deliverable is made operational

Key Actions

1. Review past projects.
2. Determine whether deliverables were clearly identified.
3. Determine whether the BRD clearly defined the “future state” that the change initiative was meant to deliver.
4. Determine whether the “cut over” represented the final deliverable or whether the deliverable had a longer-term characteristic.
5. Was the ultimate success of the project determined by the effectiveness of the change (i.e., the deliverable) at cut over or later?
6. How was this done?

ACTIONS AND CHECKLIST

Actions represent the tasks or group of tasks that need to be undertaken within a project. These are listed in detail in the project plan.

Actions listed in the project plan must have the following characteristics to be effective:

1. They must provide a distinctive name to tell them apart from other actions so that people can place the action into a project context.
2. Each action must specify when it starts.
3. Each action must specify when it finishes.
4. Each action must identify who is responsible for the completion of the action.
5. Each action should identify the things that are needed for it to commence; that is, the dependencies upon which it relies.
6. Each action should have clear outputs or outcomes from its efforts. Sometimes this is easily understood (such as an action entitled “approve report”), while other actions are somewhat ambiguous (such as an action entitled “consult stakeholders”).
7. Each action should identify where its outputs go when finished; that is, who relies on the action’s outputs as its own inputs, its own dependencies.

A checklist is normally a list of actions that together represent the completion of a milestone, a deliverable, or the entire project.

Key Points

1. A project without actions is like a balloon without air.
2. Actions identify activity and context.
3. The progression of actions denotes the progress of a project.

Key Actions

Ensure that all actions in all project plans include the following:

1. A distinctive name
2. Start timing
3. Completion timing
4. Person responsible/accountable
5. Dependencies
6. Clarity of intent
7. Output recipient

Thank you for reading this article till the end. We owe you one today.
You will see real transformation when you start implementing the above in your business.

Feel free to benefit from a free informal and confidential working session with us as a follow-up - Register here.

About Advisory & Mentoring (A&M)

……just in case you were wondering.

A&M is an international business advisory and mentoring firm providing talent to solve your business problems and achieve your objectives.

We apply a powerful diagnostic to your organisation to identify the issues that require remedy in your business systems. Those issues fall into one or more of the 12 core elements of every organisation which we term the 12 Pivot-Points.

We then bring expertise to those elements to help you navigate your issues in a complex world.

Our Diagnostic and Methodology

Like you, we have learned from decades of experience and research that there are no islands in organisations. When things happen, or don’t happen, there are impacts up and down the organisation.

Therefore, to fix issues, or to undertake change, or to take advantage of opportunities, one needs to understand what happens up and down the organisation in order to successfully deliver objectives.

There are two broad ways clients engage with us: they either have a very specific issue they need resolved, or they have a number of issues and aren’t sure where or how to start.

We have a way of looking at organisations that understands how they think, how they operate, and how to deliver successful outcomes that last.

Specific Problems or Issues

When clients talk to us about specific issues, we undertake a few tasks to better understand the organisational context and deliver a successful outcome using our methodology to ensure the appropriateness of the solution.

We:

• Establish clarity over the client’s objective.
• We secure an understanding of the context of the issue within the organisation.
• We clarify the impacts of the issue up and down the organisation.
• We explore the implications of those impacts on relevant stakeholders.
• We then develop a realistic, pragmatic, and workable solution that sits realistically within the client’s context.
• We then develop an Implementation Plan to help the client know what needs to be done, in what sequence, and with what resources, time and cost.

• If the client wishes, we can also manage the implementation and whatever changes are required.

Multiple or Complex Issues

When the client has a number of issues but isn’t sure where or how to start, we apply our methodology.

This research-validated methodology focusses on the 12 key organisational pivots that occur in a sequence and which impact other Pivot-Points and must be understood to deliver an enduring and robust solution.

The 12 Pivot-Points we focus on are:

1. Organisational purpose(either shareholder objectives, or charter or constitutional objectives). Describes why the organisation exists.
2. Organisation’s required outcomes(KPOs, priorities, and strategic direction). Converts broad purpose statements into measurable performance metrics.
3. Marketand Operating environments. Identifies the operating environments from which all performance metrics must be achieved.
4. Products and Services(including manufacturing, procurement and product and service-related systems). Identifies the things that customers will buy in the markets you’ve chosen to satisfy performance metrics.
5. Channelsand distribution. Determines how you will get your products and services to their customers.
6. Support Determines how you will support the customers and intermediaries in all markets to provide an efficient and profitable service.
7. Selling and Communication. Determines how you will approach, offer and secure customer purchase and the messages you will use.
8. Human Resourcesand culture. Determines the number and types of people you need, and the culture that will engender the mindsets required.
9. T. systems, procedures and processes. Determines the systems needed to make it all work.
10. Managementincluding structure. Determines how you will manage and structure the business.
11. Financeand other outcomes ($, #, %). The decisions above are modelled and compared to performance metrics. 
12. Formal  When #11 = #2, then formal plans are created that explain and instruct the organisation.

When we identify and clarify the client’s issues, we then bring specific subject experts of ours to the challenge of solving the problem, issue, or opportunity. Our subject experts cover over 350 areas of expertise distributed over the 12 Pivot-Points.

Our experts are located around the world and focus on projects globally.

Getting started

If you wish to explore the possibility of working with us, then it’s easy.

We meet (face-to-face or digital) to discuss your needs – this is NOT a sales ambush, nor a brainstorming or ideas session. The conversation is between mature professionals to see if we have something that fits your needs.

If we believe we can assist you and based on your needs, we prepare a detailed proposal that we believe, based on the understanding we have gained from you or your people, will satisfy those needs.

If you would like to have the initial discussion to see if A&M can assist you, or if you have any questions about our diagnostic and methodology, please contact Dr Jack Jacoby, the Head of Client Satisfaction at [email protected]