Project Leadership for Operational Excellence

A practical, self-paced course for leading operational excellence projects from first assessment to sustained results. You will learn to connect strategy to frontline work, plan and control projects, engage stakeholders and cross-functional teams, and keep people motivated through change in manufacturing, energy, health care and service operations.

Course structure

• Module 1: Foundations of OpEx Project Leadership (4 lessons). What it means to lead an operational excellence project, and how to connect strategy to the work people do every day.
• Module 2: Assess and Plan (5 lessons). Understand the current state with facts, then turn the charter into a realistic plan with scope, schedule and risks.
• Module 3: Stakeholders and Cross-Functional Teams (5 lessons). Map who matters, manage expectations, and build a cross-functional team with clear roles and effective routines.
• Module 4: Leading People Through Change (4 lessons). Apply proven change models, handle resistance constructively, keep motivation high and develop frontline leaders.
• Module 5: Execute, Control and Sustain (5 lessons). Track project health with earned value, control issues and changes, verify benefits and lock in results for the long term.

Interactive labs

• Stakeholder mapping lab: Rate typical OpEx project stakeholders on interest and influence to see which ones to manage closely, keep satisfied, keep informed or monitor. Rename or add items to map your own project.
• Earned value health check: Enter your project's budget, planned and actual progress and spending to calculate cost and schedule performance and a forecast final cost.
• Project leadership self-assessment: Rate your current practice on seven dimensions of OpEx project leadership. Use the radar chart to pick the two areas for your 90-day action plan.

How it works

• Work through 23 short lessons at your own pace. Each has key takeaways, an exercise for your own workplace and a quick knowledge check.
• Try the three interactive labs as you reach them in the course.
• Pass the 20-question final exam (70% or higher, unlimited retakes) to unlock your Chmltech certificate of completion.
• Free, with no sign-up. Your progress is saved in this browser.

Operational excellence (OpEx) is the discipline of running an organization so that work flows smoothly, quality is built in and people improve the system every day. Most of that improvement happens through projects: a changeover reduction on a press line, a new intake process at a clinic, a slotting redesign in a warehouse.

Projects like these rarely fail because the team picked the wrong tool. They fail because nobody led them. Value stream maps get drawn and then filed. A kaizen event produces a great new layout that drifts back within a month. Leadership is the difference between a project that produces a report and one that changes how the operation runs.

Three jobs of the OpEx project leader

• Direction. Make sure the project solves a problem that matters to the business, and that everyone can explain why.
• Delivery. Plan, track and control the work so it finishes on time, on budget and with the agreed scope.
• Change. Help people adopt the new way of working and keep it in place after the project team moves on.

Traditional project management focuses heavily on the second job. In OpEx work, the third job is usually the hardest. You are not building a bridge; you are changing habits, roles and sometimes the way people measure their own success.

Leader versus manager

You need both columns. A leader who ignores schedules and budgets loses credibility quickly, and a manager who ignores people ends up with a finished project and an unchanged operation.

A quick example

Imagine a 40-person fabrication shop that wants to cut late deliveries. The owner assigns the production supervisor to "fix scheduling". A manager-only approach buys scheduling software and trains two planners. A leader-led approach first walks the floor, learns that most late jobs wait on material that was never kitted, involves the stores clerk and lead hands in redesigning the kitting step, and then tracks on-time delivery weekly until the new routine holds.

Throughout this course you will build both sets of skills: the structure of a well-run project and the human leadership that makes the change stick.

Frontline staff work hard, but they often cannot say how their daily tasks connect to the company's goals. Senior leaders set targets, but often cannot see what blocks the people doing the work. An OpEx project leader sits in the middle and builds a line of sight in both directions.

Strategy deployment in plain terms

Many Lean organizations use Hoshin Kanri (policy or strategy deployment) to connect goals across levels. You do not need the full system to borrow its core ideas:

1. Few breakthrough objectives. Leadership chooses a small number of priorities for the year, such as "on-time delivery to 95%" or "reduce patient wait time".
2. Cascade into measures. Each level translates the objective into measures it can influence: a department metric, a cell metric, a shift metric.
3. Catchball. Targets are passed down, questioned and passed back up. Frontline teams say what is realistic and what support they need.
4. Regular review. Progress is reviewed monthly, and gaps trigger problem solving, not blame.

The goal tree

A simple tool for building line of sight is a goal tree (sometimes called a KPI tree or driver tree). Put the strategic goal at the top and break it into drivers until you reach things a team can change this month.

When a picker understands that walking less is directly tied to company margin, and the general manager understands that slotting is limited by an outdated item master, both sides make better decisions.

Your role as the project leader

• Translate the strategic "why" into words the frontline uses. Avoid jargon such as "synergies" or "transformation".
• Carry frontline constraints back up. If the target needs a forklift that is not in the budget, say so early.
• Make the connection visible: put the goal tree on the project board where the team meets.

A project without line of sight becomes "management's project". A project with it becomes "our project", and that shift drives most of the energy you will need later.

Most SMEs have more improvement ideas than people to run them. Starting too many projects at once is one of the most common reasons OpEx efforts stall: everyone is busy, nothing finishes and staff conclude that improvement is just extra work. Good project leaders help leadership choose, sequence and sometimes say no.

Simple selection criteria

Score each candidate project against a short list of criteria. Keep it to five or six so the discussion stays focused.

• Strategic fit: does it move one of the few objectives from the goal tree?
• Benefit size: what is the estimated annual value in time, cost, quality or safety?
• Effort and cost: how many people, how many weeks, what spending?
• Risk: how uncertain is the outcome, and what could go wrong?
• Readiness: is there a willing process owner and reliable data?
• Time to benefit: will results show in weeks or in a year?

Worked example

An engineering office scores three ideas from 1 (poor) to 5 (strong). Higher is better on every criterion, so for effort and risk a 5 means "low effort" or "low risk".

The checklist is a quick win and builds confidence. The automation project has the strongest fit and is worth planning next. The software project may still be valuable, but the low readiness score says the office should clean up its processes first.

Limit work in progress

Treat improvement projects like a production line: too much work in progress slows everything. A practical rule for a small organization is no more than one major project per sponsor and no more than two or three projects running across the whole site at once. Finish, sustain, then start the next.

Scoring is a conversation aid, not an algorithm. If the totals contradict common sense, discuss why. Often a criterion was misunderstood or an important factor such as safety was missing.

The project charter is the single most useful document in an OpEx project. It is a one- or two-page agreement between the sponsor and the project leader about what problem is being solved, why, by when and with whom. A good charter prevents most of the misunderstandings that derail projects later.

Core sections

Writing a good problem statement

Weak: "Our receiving process is inefficient and we need a new system."

Strong: "Since January, the average time from truck arrival to stock being available for picking at the Burnaby warehouse has been 2.5 working days. Pickers report frequent stock-outs on items that are physically in the building. This delays roughly one in ten customer orders."

The strong version names the measure, the place and the impact. It also avoids jumping to a solution. Maybe a new system helps, maybe a second receiving shift helps; the team should find out.

A SMART goal

"Reduce dock-to-stock time from 2.5 days to 1 day or less by the end of June, while keeping receiving accuracy at or above current levels." The second half is a guardrail: it protects against improving one measure by damaging another.

Using the charter as a leadership tool

• Draft it with the sponsor, not for the sponsor. The conversation matters more than the document.
• Review it with the team at kick-off and invite challenges.
• Revisit it at each phase gate. If scope or goals change, update the charter and get it re-signed.

If you cannot get the sponsor to agree on a one-page charter, the project is not ready to start. That discovery, made early, saves weeks of wasted effort.

Before you can lead improvement, you need an honest picture of how the work happens today. Not how the procedure says it happens, and not how the manager believes it happens, but what actually occurs on an ordinary Tuesday. This is where many projects are won or lost.

Go to the gemba

Gemba means "the real place": the shop floor, the clinic front desk, the warehouse dock. Spend time there observing before you hold meetings about the problem. Ask open questions, watch for waiting and rework, and thank people for showing you.

Three practical assessment tools

• SIPOC. A high-level map of Suppliers, Inputs, Process (five to seven steps), Outputs and Customers. It sets boundaries and makes sure everyone is talking about the same process.
• Process walk or value stream map. Follow one item, order or patient through every step. Record time spent working, time spent waiting, handoffs and information flows.
• Voice of the customer. Talk to the internal or external customer about what they value and where the process lets them down.

Worked example: clinic intake

A physiotherapy clinic wants to shorten time from patient arrival to treatment. The project leader times ten arrivals and maps the steps.

Total elapsed time is 37 minutes, of which only 13 minutes is work. The biggest wait sits between the patient finishing forms and the admin entering them. Nobody had noticed because each person was busy doing their own step.

Leadership habits during assessment

1. Involve the people who do the work in mapping. They know the workarounds.
2. Separate observation from judgement. "The form waits eight minutes" is a fact; "admin is slow" is a judgement and is usually wrong.
3. Look for the system, not the culprit. Most delays come from how work is designed.
4. Share what you found with the team before you share it with management.

A careful, respectful assessment builds trust. Staff see that you came to learn, not to audit, and that trust will carry the project through harder phases later.

If you do not measure the starting point, you cannot prove the project made a difference. Worse, you may convince yourself that things improved when they did not. Setting a clear baseline is a core leadership responsibility, because it is what lets you claim credit honestly at the end.

Choose a small set of measures

Aim for one primary measure, one or two secondary measures and at least one guardrail.

• Primary (outcome) measure: the result the charter promises. Example: on-time delivery.
• Secondary (driver) measures: things that lead to the result. Example: percentage of jobs released with complete material kits.
• Guardrail measure: something that must not get worse. Example: overtime hours or first-pass quality.

Write an operational definition

An operational definition removes ambiguity. "On-time delivery" sounds clear until you ask: on time against the promised date or the requested date? Does a partial shipment count? Is it measured by ship date or receipt date? Write the answers down and get the sponsor to agree.

Worked example

A small food processor wants to reduce changeover time on its bottling line. The team pulls eight weeks of records.

Note the use of the median. A few unusually long changeovers can distort an average, so the median gives a fairer picture of a typical event. Also note the guardrail: if the team rushes changeovers and rejects climb, the project has not really succeeded.

Look at variation, not just averages

Plot the baseline data as a simple run chart over time. If the measure swings widely from week to week, a single "before" and "after" number can mislead you. Leaders who understand variation avoid celebrating random good weeks or panicking over random bad ones.

When data is poor

Many SMEs lack clean data. That is fine. Collect a short manual sample using a check sheet for two weeks. Imperfect data you gathered deliberately is better than no data at all, and the act of collecting it often reveals the problem on its own.

Scope creep is the quiet killer of OpEx projects. A project to fix receiving turns into a project to fix purchasing, then supplier quality, then the ERP. Each addition seems reasonable, but together they make the project impossible to finish. Clear scoping is a leadership act, because it often means telling a senior person "not in this project".

In-scope and out-of-scope

Use a simple two-column list, and get the sponsor to sign it as part of the charter.

Out-of-scope items are not rejected forever. Park them on a "future opportunities" list. People are much more willing to accept a boundary when they see their idea recorded.

Building a work breakdown structure

A work breakdown structure (WBS) breaks the project into deliverables and then into work packages small enough to assign, estimate and track. In OpEx work, organizing the WBS by project phase is often the clearest approach.

1. Assess: process map, baseline data, voice of the customer.
2. Design: root cause analysis, new layout, draft standard work.
3. Pilot: trial on one shift, measure results, adjust.
4. Roll out: train all shifts, update procedures, move tools and racking.
5. Sustain: control plan, audits, handover to process owner.

Each of these breaks down further. "Train all shifts" might become: prepare one-point lessons, schedule sessions with the supervisor, run three sessions, and sign off competency for each employee.

The 8/80 guide

A common rule of thumb is that a work package should take between about 8 and 80 hours of effort. Smaller packages create micromanagement; larger packages hide problems until they are late. For small projects, adjust to fit, but aim for pieces that finish within one or two weeks so progress is visible.

Handling scope change requests

• Listen and record the request.
• Assess the impact on time, cost and the goal.
• Take a decision to the sponsor: add it, swap it for something else, or park it.
• Update the charter and plan if it is accepted.

The leader's job is not to refuse all change. It is to make the trade-off visible so the sponsor decides consciously.

OpEx projects in SMEs almost always run on borrowed time. Team members still have their day jobs: the lead hand still runs a shift, the nurse still sees patients. A schedule that ignores this reality looks good on paper and slips from week one.

Build the schedule from the WBS

1. Estimate effort for each work package with the person who will do it.
2. Identify dependencies: what must finish before something else can start.
3. Check real availability for each person, in hours per week.
4. Lay out the work on a simple Gantt chart or a visual board.
5. Mark milestones: phase gates where the sponsor reviews results.

Effort versus duration

Effort is the number of hours of work. Duration is the calendar time it takes. They are very different when people are part-time.

A planner who only looks at effort might expect mapping to take two days. In reality, with four hours a week available, it takes a month. Leaders who make this visible early protect the team from impossible deadlines.

Find the critical path

The critical path is the longest chain of dependent tasks; it sets the earliest finish date. Any delay on the critical path delays the whole project. Focus your attention and your escalations there. Tasks off the critical path have float and can move a little without harm.

Protect capacity explicitly

• Agree each team member's project hours with their manager, in writing, as part of the charter.
• Schedule project time as a recurring block, such as Tuesday and Thursday mornings.
• Plan around known peaks: year-end in an accounting office, harvest season for a food processor, flu season in a clinic.
• Add a small buffer before key milestones rather than padding every task.

A realistic schedule is a leadership signal. It tells the team you understand their workload and will defend their time, and it tells the sponsor exactly what they are buying.

Every OpEx project carries risk: a key person leaves, a supplier delays new racking, data turns out to be worse than expected, or the frontline simply does not adopt the new method. Good leaders do not wait for these to happen. They think ahead, decide which risks matter and agree what to do about them.

The risk register

A risk register is a short table that lists risks, rates them and assigns an owner and response. For a small project, ten to fifteen risks are usually enough.

Score equals likelihood times impact. Focus attention on the highest scores first.

Four standard responses

• Avoid: change the plan so the risk cannot happen, such as removing a risky feature from scope.
• Reduce (mitigate): lower the likelihood or impact, such as training a backup person.
• Transfer: shift the impact to another party, such as a supplier contract with delivery penalties.
• Accept: consciously live with it and prepare a contingency plan.

People risks are real risks

Notice that the highest-rated risk in the example is about people, not equipment. In OpEx projects, resistance, fatigue and loss of a champion are often the biggest threats. Put them on the register openly and assign real responses. Treating them as "soft" issues that will sort themselves out is a common and costly mistake.

Run a pre-mortem

A pre-mortem is a quick, powerful exercise. At kick-off, ask the team: "Imagine it is six months from now and this project has failed. What went wrong?" Give everyone five minutes to write reasons on sticky notes. This gives people permission to voice concerns they might otherwise hide, and it usually surfaces risks the leader had not considered.

Keep it alive

A risk register written once and never opened is useless. Review the top five risks at every team meeting for two minutes, and update scores as things change. Close risks that have passed and add new ones as they emerge.

A stakeholder is anyone who affects the project or is affected by it. In OpEx work that list is usually longer than people expect. A changeover project on one line touches operators, maintenance, quality, scheduling, the union or employee committee, and possibly key customers.

Step 1: brainstorm widely

List every person or group, then check the list with a few questions:

• Who will do the work differently after this project?
• Who controls resources we need (money, people, equipment, IT access)?
• Who can block or delay a decision?
• Whose performance measures will change?
• Who outside the organization notices the result, such as customers, suppliers or regulators?

Step 2: map on the power and interest grid

Rate each stakeholder on two dimensions: their interest in the project (how much it affects them or how much they care) and their influence (their power to help or hinder). This gives four groups.

Worked example

For a warehouse slotting project, the operations director (sponsor) and the warehouse supervisor land in "manage closely". The finance controller has high influence over the racking budget but little day-to-day interest: "keep satisfied". Pickers are highly affected but individually have limited formal power: "keep informed", and ideally involved in design. The IT contractor who updates bin locations sits in "monitor" until the go-live week, when they move up.

Step 3: note their current and desired position

For key stakeholders, note whether they are currently a supporter, neutral or resistant, and where you need them to be. The gap tells you where to spend leadership time.

Remember that maps change

Positions move as the project moves. A quiet maintenance manager may become critical when the pilot needs equipment modified. Revisit the map at each phase gate. Also, keep the map private; labelling a colleague "low influence" in a shared file rarely helps relationships.

In the lab that follows, you will practise rating a typical set of OpEx stakeholders and see where each one lands.

Most stakeholder trouble comes from a gap between what people expected and what they got. A sponsor who expected a 50% improvement is disappointed by 30%, even though 30% is excellent. A supervisor who expected to be consulted feels ambushed by a new layout. Managing expectations means closing those gaps before they open.

Set expectations early and in writing

• Agree the goal, scope and timeline in the charter.
• Be honest about uncertainty. "Our target is 1 day dock-to-stock; we expect somewhere between 1 and 1.5 days" is more credible than a single bold number.
• Explain what stakeholders will need to give: time, decisions, access, patience during the pilot.

The communication plan

A simple communication plan states who gets what information, how, how often and from whom.

Note that frontline staff hear from their supervisor, not from the project leader. People trust messages from their own manager most, so equip supervisors with clear talking points.

Deliver bad news early

When something goes wrong, tell the sponsor promptly, along with what you know, what you do not know and what you recommend. Sponsors can handle bad news; what they rarely forgive is hearing it late or from someone else. A useful rule: no surprises at the steering meeting.

Worked example

Midway through a clinic intake project, the team learns that the electronic form vendor needs six extra weeks. The leader calls the sponsor the same day, explains the delay, and offers two options: pilot with a simplified paper form now, or wait. The sponsor chooses the paper pilot. Expectations were reset in one conversation, and the team kept momentum.

Under-promise slightly, then deliver

This is not about sandbagging. It is about giving honest ranges and building credibility over time. Each kept promise makes the next request for support easier.

Operational problems rarely live inside one department. Late shipments involve sales, planning, production and shipping. Long patient waits involve reception, nursing, scheduling and billing. A cross-functional team brings the people who own each piece into one room. Leading such a team means getting people with different bosses and different priorities to work as one.

Choosing team members

• Include people who do the work, not just their managers.
• Cover every major handoff in the process.
• Include at least one respected sceptic. Their buy-in convinces others, and their questions improve the design.
• Keep the core team small: four to seven people. Bring in specialists when needed.

Clarify roles with RACI

A RACI chart lists key activities and decisions and shows who is Responsible (does the work), Accountable (owns the result; only one person), Consulted (gives input before) and Informed (told after).

Common RACI problems

1. Two A's on one row. When two people are accountable, nobody is. Pick one.
2. No R. The task is everyone's job and no one's.
3. Too many C's. Consulting ten people slows every decision. Ask who truly needs a voice.
4. Process owner missing. The person who will run the process after the project must be accountable for the new standard. Otherwise the change belongs to the project team and fades when they leave.

Team charter and working agreements

At the first meeting, agree a few working rules together: start on time, decisions are recorded, disagreements are raised in the room, data beats opinion. Write them on the project board. When things get tense later, you can point back to rules the team set for itself.

Cross-functional teams form fast when people can see their own department's pain in the problem. Spend time at the start helping each member say what they hope to gain.

Projects run on routines. A cross-functional team that meets with no structure wastes hours and loses energy. A team with a short, predictable rhythm and a visible board moves quickly and stays aligned. As project leader, you design and protect these routines.

The project rhythm

A 30-minute huddle agenda

1. Safety or wellbeing check (2 min).
2. Measure update: where is the primary metric this week? (5 min)
3. Action review: done, late, blocked (10 min).
4. Top risks and issues (5 min).
5. New actions, with owner and date (5 min).
6. One-sentence close: what we will tell our departments (3 min).

Deep problem solving does not belong in the huddle. If a topic needs more than two minutes, park it and schedule a working session with the right people.

Visual management

Hold the huddle in front of a physical or digital board that shows, at a glance:

• The charter goal and the run chart of the primary measure.
• An action list with owners, dates and a simple status colour.
• The top five risks.
• Phase milestones and where you are now.

A board placed near the work, such as in the warehouse or at the clinic's staff station, also communicates to everyone else that something is happening and invites questions.

Worked example

A fabrication shop's project team was meeting for an hour every Monday and leaving without clear actions. The leader switched to a 30-minute standing huddle at the production board, using the agenda above. Within three weeks, late actions dropped noticeably because each owner had to report in front of peers, and the team gained back half an hour a week.

Record decisions

Keep a simple decision log: date, decision, who decided, why. It prevents relitigating settled questions and protects the team when someone later asks "who approved this?"

The sponsor is the senior person who owns the business result and gives the project its authority. A strong, engaged sponsor is one of the best predictors of project success. A disengaged sponsor leaves the project leader with responsibility but no power. Part of your job is to lead upward: help your sponsor be effective.

What a good sponsor does

• Explains why the project matters, in person, at kick-off and at key moments.
• Secures resources: people's time, budget, IT support.
• Removes barriers the project leader cannot, such as conflicts between department heads.
• Makes timely decisions on scope, trade-offs and escalations.
• Visits the gemba and recognizes the team's work.
• Holds the process owner accountable for sustaining results.

Making it easy for your sponsor

Sponsors in SMEs are often the owner or general manager, with little spare time. Make every interaction efficient.

1. Bring a short agenda to every check-in: progress, decisions needed, help needed.
2. Frame decisions as clear options with a recommendation.
3. Tell them specifically what to say or do, such as "Could you open Thursday's huddle and explain why on-time delivery matters to our biggest customer?"
4. Never let them be surprised in front of their peers.

Steering groups and phase gates

Larger projects, or a portfolio of several projects, benefit from a steering group: the sponsor plus two to four senior leaders whose areas are affected. At each phase gate, the steering group asks a few simple questions.

When the sponsor disengages

If check-ins keep getting cancelled, have an honest conversation. Remind them of the goal, show the impact of delayed decisions, and ask directly what level of involvement they can give. Sometimes the right outcome is to pause the project or find a different sponsor. Pushing on without real sponsorship rarely ends well.

Operational excellence projects change how people work. Even a small change, such as a new order of steps at the packing bench, can feel disruptive to someone who has done it the same way for ten years. Change models give you a structured way to think about what people need in order to change.

ADKAR: change at the individual level

The ADKAR model, developed by Prosci, describes five outcomes each person needs to reach, in order.

The power of ADKAR is diagnosis. If people are not adopting a change, ask which stage they are stuck at. Training (knowledge) will not fix a lack of desire, and more speeches (awareness) will not fix a lack of ability.

Kotter: change at the organization level

John Kotter's eight-step model looks at change across the whole organization:

1. Create a sense of urgency.
2. Build a guiding coalition.
3. Form a strategic vision.
4. Communicate the vision widely.
5. Remove barriers and empower action.
6. Generate short-term wins.
7. Sustain acceleration.
8. Anchor the change in the culture.

For a single OpEx project, steps 1, 2, 5 and 6 are especially useful. Urgency comes from showing the real cost of the problem. The coalition is your sponsor plus respected frontline champions. Short-term wins, such as a successful pilot on one shift, build belief that the change works.

Worked example

A distributor introduces scan-to-confirm picking. Two weeks in, the night shift still skips scans. The leader uses ADKAR to diagnose: the pickers know how to scan (knowledge) and can do it (ability), but they believe it slows them down and they are measured on lines per hour (desire). The fix is not more training. The leader works with the supervisor to adjust the shift measure to include accuracy and shows the team how mis-picks create rework for them later.

Use Kotter to plan the overall journey and ADKAR to check how each group of people is moving through it.

Resistance is a normal reaction to change, not a sign of a bad employee. People resist for understandable reasons: they fear losing competence, status or control; they have seen past initiatives fail; or they spot genuine flaws in the plan. A leader who treats resistance as information gets a better solution and stronger commitment.

Common sources of resistance

Practical techniques

1. Listen first. Ask "What worries you about this?" and listen without defending the plan. Summarize what you heard before you respond.
2. Separate the concern from the person. A sceptic may be your best quality check.
3. Involve, do not sell. People support what they help create. Invite the strongest critic to help design or run the pilot.
4. Make it safe to try. Frame the pilot as an experiment that can be adjusted, using PDCA (Plan, Do, Check, Act).
5. Be honest. If some roles will change, say so and explain the support available. Vague reassurance destroys trust when the truth comes out.

Worked example

In an engineering office, a senior drafter openly opposes a new standard drawing checklist, saying it insults experienced staff. The project leader meets her privately and learns her real concern: a past checklist was 60 items long and was filled in blindly. The leader asks her to help trim the checklist to the twelve checks that catch real errors. She becomes its strongest advocate, and the checklist is better for it.

When resistance becomes obstruction

Occasionally someone actively undermines an agreed change after being heard and involved. At that point it becomes a performance matter for their manager, not a project matter. Escalate through the sponsor and process owner, with facts, and keep it separate from the project team discussions.

Energy in an OpEx project usually follows a curve. Kick-off brings enthusiasm. Then comes the long middle: data collection, root cause work, delays waiting for equipment, the first pilot that does not quite work. This is where motivation drops and projects stall. Leaders plan for the dip instead of being surprised by it.

What drives motivation at work

A widely used way to think about motivation, drawn from self-determination theory, focuses on three needs:

• Autonomy: having a say in how the work is done.
• Mastery: getting better at something that matters.
• Purpose: seeing how the work makes a difference.

OpEx projects can feed all three. Let the team design solutions (autonomy), teach them problem-solving tools and recognize their growth (mastery), and keep connecting the work to customers and colleagues (purpose).

Practical motivation tactics

Recognition that works

Recognition does not need a budget. It needs to be specific, timely and sincere. "Thanks for your hard work" is forgettable. "Priya, the kitting checklist you designed cut material waits on Line 2 this week; the shipping team noticed" is memorable. Ask the sponsor to deliver some recognition personally, on the floor.

Worked example

In week six of a clinic intake project, staff were tired and the electronic form was delayed. The leader picked three "just do it" fixes the team had listed: moving the printer closer to the desk, a pre-visit reminder call script and a simple queue board. Within a week, waiting room complaints dropped and the team saw their ideas working. The bigger project regained momentum.

Watch your own energy

Teams mirror the leader. If you look discouraged in the huddle, they will be too. Be honest about setbacks, but always pair them with a next step.

Supervisors, lead hands, charge nurses and team leads make or break an OpEx project. They control daily routines, they are the people staff trust most, and they will own the new process after the project team moves on. The project leader's job is not to do the change for them, but to coach them to lead it.

Why coaching beats telling

If you tell a supervisor exactly what to do, you get compliance while you are present. If you coach them to work out the answer, they own it and keep doing it after you leave. Coaching also builds problem-solving capability across the organization, which is the real long-term goal of operational excellence.

A simple coaching conversation

Toyota Kata, a Lean coaching approach, uses a short set of questions that a coach asks a learner, often daily at the board. A simplified version:

1. What is the target condition you are working toward?
2. What is the actual condition now?
3. What obstacles do you think are preventing you from reaching the target? Which one are you addressing now?
4. What is your next step, and what do you expect to happen?
5. When can we see what you learned from that step?

These questions keep the supervisor in charge of the thinking while the coach keeps them focused and accountable.

Leader standard work

Help frontline leaders build a short daily and weekly routine that keeps the new process alive.

Worked example

A newly promoted supervisor at a fabrication shop struggles to run daily huddles; they drift into complaints. Instead of running them for him, the project leader observes two huddles, then asks afterwards: "What did you want the huddle to achieve? What happened? What will you try tomorrow?" Over two weeks the supervisor tightens the agenda himself. His confidence grows, and the huddle keeps running long after the project closes.

Practical tips

• Coach in the work area, briefly and often, rather than in long office sessions.
• Give feedback privately and recognition publicly.
• Gradually step back: do, then do together, then watch, then let go.

"We are 60% done" is one of the least reliable sentences in project work. Earned value management (EVM) gives you a more honest picture by comparing three numbers: what you planned to have done, what you have actually done, and what it actually cost. It works for small projects too, as long as your work packages are clear.

The three core numbers

• Planned value (PV): the budgeted cost of work scheduled to date. PV = budget at completion (BAC) × planned % complete.
• Earned value (EV): the budgeted cost of work actually completed. EV = BAC × actual % complete.
• Actual cost (AC): what you have really spent to date.

Variances and indices

Worked example

A warehouse improvement project has a budget at completion of $200,000, covering racking, scanners and team time. At the end of month three, the plan said 50% should be complete. The team has actually completed 40% of the work, and $95,000 has been spent.

• PV = $200,000 × 50% = $100,000
• EV = $200,000 × 40% = $80,000
• CV = $80,000 − $95,000 = −$15,000 (over budget)
• SV = $80,000 − $100,000 = −$20,000 (behind schedule)
• CPI = 80,000 ÷ 95,000 ≈ 0.84
• SPI = 80,000 ÷ 100,000 = 0.80
• EAC = $200,000 ÷ 0.84 ≈ $237,500

The project is both behind and over budget. If nothing changes, it will cost roughly $37,500 more than planned. That is a clear signal to take to the sponsor now, not at the end.

Measuring "% complete" honestly

EVM is only as good as the percent complete. Use simple, objective rules: a work package counts as 0% until started, 50% once started, and 100% only when finished and accepted. This 0/50/100 rule prevents the familiar "90% done for weeks" problem.

Using EVM as a leader

Do not use the numbers to blame. Use them to ask better questions: Which work packages are behind? Is it a capacity issue, an estimate issue or a scope issue? What decision does the sponsor need to make? In the lab that follows, try your own project's numbers.

Risks are things that might happen. Issues are things that have happened. Every project accumulates issues: a key operator is off sick during the pilot, IT cannot change a report in time, a new label printer jams. How quickly and calmly issues are handled has a big effect on the team's confidence in the leader.

The issue log

Keep a simple issue log alongside the risk register.

An escalation ladder

Agree up front who can decide what, so issues do not stall waiting for someone to take ownership.

1. Team level: the owner resolves within their authority, within a few days.
2. Project leader: resolves issues across team members or within the agreed tolerance on cost and schedule.
3. Sponsor: decides on issues that exceed tolerance, cross departments or change scope.
4. Steering group: decides on issues that affect strategy, other projects or major budget.

Tolerances

Tolerances tell the project leader how much room they have before escalating. For example: "You may absorb up to one week of schedule slip and up to 5% of budget variance without escalation. Beyond that, come to me." Tolerances give the leader freedom to act and give the sponsor confidence that they will hear about real problems.

Escalating well

Escalation is not complaining or passing the problem upward. A good escalation includes:

• The issue in one or two sentences.
• The impact on goal, cost and schedule.
• What has been tried already.
• Options, with your recommendation.
• The decision you need and by when.

Change control

Some issues lead to requests to change scope, budget or dates. Log them as change requests, assess their impact, get a decision from the right level and update the charter and plan. This protects both the team and the sponsor from slow, unmanaged drift.

At the end of a project, the sponsor will ask one question: did it work? Answering that honestly requires comparing results against the baseline you set at the start, using the same operational definitions, and checking that the improvement is real and not just a good week.

Benefits tracking from day one

Plan benefits tracking at the charter stage, not the end. A simple benefits register states each expected benefit, how it is measured, who owns it and when it should appear.

Hard and soft benefits

• Hard benefits show up in financial results: lower overtime, less scrap, reduced contractor spend.
• Capacity benefits free up time or equipment. They only become cash if the time is used, such as taking more orders or avoiding a hire. Be clear about this distinction with finance.
• Soft benefits include safety, morale, customer satisfaction and lower risk. They are real and should be reported, but with honest measures rather than invented dollar values.

Worked example

After the bottling line project, median changeover time falls from 74 to 38 minutes, measured over eight weeks with the same definition as the baseline. With nine changeovers a week, that saves about 36 × 9 = 324 minutes, or roughly 5.4 hours of line time each week. First-hour rejects average 50, so the guardrail holds. The finance controller confirms the recovered hours are being used to run an extra product, so the capacity benefit is real.

Checks before claiming success

1. Same operational definition as the baseline?
2. Enough data points after the change to rule out a lucky streak?
3. Run chart shows a sustained shift, not a single spike?
4. Guardrail measures stable?
5. Has finance or the process owner reviewed the figures?

Honest benefit reporting builds credibility for the next project. Inflated claims are usually discovered, and they make every future improvement harder to fund.

The most painful moment in OpEx work is returning to a process six months after a successful project and finding it back where it started. Sustainment is not automatic. It must be designed into the project's final phase and owned by the people who run the process every day.

Why improvements fade

• The project team leaves and no one owns the new standard.
• New staff are trained on the old method by experienced colleagues.
• Measures stop being reviewed, so drift goes unnoticed.
• Pressure peaks push people back to familiar shortcuts.

The sustainment toolkit

A clean handover

Handover moves accountability from the project team to the process owner. Make it a formal step, ideally at the closure phase gate.

1. The process owner confirms the new standard work and control plan.
2. Measures are added to the owner's regular reporting.
3. Open actions are transferred with owners and dates.
4. The sponsor confirms the handover and recognizes the team.
5. A 30, 60 and 90-day check is scheduled.

Worked example

A clinic redesigns its intake process and cuts arrival-to-treatment time significantly. At handover, the office manager takes ownership of a one-page intake standard, a weekly review of wait times on the staff board and a monthly audit by the clinic director. At the 60-day check, waits have started creeping up on Mondays. The office manager identifies that Monday has a different receptionist who was trained before the change. A 20-minute refresher solves it. Without the control plan, the drift would have continued unnoticed.

Lessons learned

Close with a short lessons-learned session: what worked, what did not, and what we would do differently. Record it in a place future project leaders will find. This turns one project into organizational learning.

You have now covered the full journey of leading an operational excellence project: setting direction, assessing and planning, engaging stakeholders and teams, leading people through change, and executing, verifying and sustaining results. The final step is to turn what you have learned into action in your own workplace.

Review your self-assessment

If you completed the project leadership self-assessment lab, look at your two lowest dimensions. These are your development priorities for the next quarter. Do not try to fix everything at once; pick one leadership habit to build and one project practice to adopt.

A 90-day plan structure

Your one-page leadership plan

• My project: the problem, the goal and the sponsor.
• My key stakeholders: the three people I must manage closely.
• My leadership habit: for example, a weekly gemba walk or a daily coaching question.
• My project practice: for example, a risk register reviewed weekly or EVM at each month end.
• How I will know it worked: the primary measure and a date.
• Who will hold me accountable: a peer, a manager or a mentor.

Worked example

A supervisor at a mid-sized distributor writes her plan: project, reduce dock-to-stock time; sponsor, the operations director; key stakeholders, the night lead, the purchasing manager and the IT contractor; habit, a 20-minute gemba walk every Tuesday and Thursday; practice, a 30-minute weekly huddle at a visual board; measure, dock-to-stock under one day by the end of the quarter; accountability partner, the quality manager, with a monthly coffee check-in. The plan fits on one page and she reviews it every Friday.

Keep learning

Leadership skill grows through practice and reflection. After each project, ask yourself three questions: What did I do that helped? What got in the way? What will I do differently next time? Small, steady improvements in how you lead compound just like improvements in a process.

Thank you for completing this course. When you finish the final exam, you will receive a Chmltech certificate of completion.