The American Society for Quality (ASQ) defines Six Sigma as a method that gives organisations tools to improve the capability of their processes, and distinguishes it from Lean: Lean focuses on reducing waste, Six Sigma on reducing variation. Lean Six Sigma combines the two to reduce variation, waste and cycle time, and many implementations start with Lean and then apply statistical tools if process problems remain. ^[1]

Both approaches began in manufacturing, but the US Environmental Protection Agency describes Lean as a philosophy that has been extended to government and the service sector to help agencies identify and eliminate waste in their processes. ^[3] The difference in services is that the “product” is invisible: a patient file or licence application moving between offices, with nobody seeing how long it waits between one step and the next.

Where does waste hide in hospitals and government agencies?

The EPA guide uses the acronym DOWNTIME to remind teams of eight types of waste when observing day-to-day work. ^[3] The table below translates them into illustrative service examples:

The Institute for Healthcare Improvement (IHI) says the journey towards Lean begins with identifying the value-added and non-value-added steps in every process, and that waste includes money, time, supplies and goodwill. ^[2]

How do you apply DMAIC to a service project?

DMAIC is the most widely adopted Six Sigma methodology; its phases are define, measure, analyse, improve and control. ^[1] In services, each phase needs a practical translation:

• Define: state the problem in the service user’s terms, such as “time to issue a licence”, not in management language.
• Measure: record the baseline before any change; without it you cannot prove improvement.
• Analyse: walk with the file or the patient through the actual workplace (the gemba) and record where it waits, is returned or is reworked.
• Improve and control: test the solution on a small scale, then document it as standard work, the best currently known way of doing the job. ^[3]

What do documented hospital examples show?

In 2016 the American Hospital Association (AHA) published the case of a critical access hospital (a small rural hospital) that used Lean Six Sigma to improve patient flow in its emergency department. Mean time from the admission decision to the patient leaving the department fell by 40%, and patient and physician satisfaction rose by 12 percentile points. ^[4]

A study published in 2024 on an academic emergency department seeing around 100,000 patients a year mapped the value stream and redesigned the flow for less complex cases. Patients seen per eight-hour shift rose from 17 to 20.5, and the time from the attending physician’s assessment to the disposition decision fell significantly, as did the number of patients who left before treatment was complete or against medical advice. But the 9% fall in average length of stay was not statistically significant, and the authors noted that a single-centre before-and-after design cannot prove causation and that sustaining the new process after the trial ended was a barrier. ^[6]

The lesson is professional before it is statistical: separate what has genuinely improved from what only appears to have improved, and plan the control phase from the start.

What do government examples show?

The EPA’s 2013 guide documents results from US government bodies: ^[3]

• Florida Department of Environmental Protection: a kaizen event cut by 50% the time for a permit application to reach a processor.
• EPA Region 6: a value stream map of pesticides enforcement procedures cut total processing time by 53%.
• Minnesota Pollution Control Agency: a Six Sigma project raised the share of permits issued within 180 days from 9% to 75% and cut the backlog from nearly 50% to 8%.

The guide also notes that Minnesota state agencies held at least 265 kaizen and 5S events between 2008 and 2012, so improvement became a repeated practice rather than a one-off project. ^[3]

In a value stream mapping event as the guide describes it, the team maps the current state of the process from start to finish, identifies value-added time and waste, then maps the future state and draws up an implementation plan. ^[3] The common thread in these examples is that improvement came from rearranging steps and removing waiting and unnecessary approvals.

Which tool should you choose?

Not every improvement needs a full DMAIC project. If the cause is clear and the problem well defined, a kaizen event or even workplace organisation with 5S is enough. If the process is long and crosses several departments, start with a value stream map. If errors keep recurring and their cause is unknown, that is where Six Sigma’s statistical tools come in. ^{[1, 3]}

Hypothetical example: time to issue a trade licence

Hypothetical example: a local government body takes an average of 15 working days to issue a trade licence. Mapping the process, the team finds nine steps, three of them successive signatures on the same decision, and that the application spends most of its time waiting between steps rather than being worked on.

The team decides to merge the three signatures into one approval under delegated authority and to add a document checklist at intake to reduce returned applications, then measures the time weekly for three months. Results are reported as both average and spread, because applicants remember the longest wait, not the average.

What makes Lean Six Sigma succeed in services?

1. Leadership commitment: IHI stresses that a Lean culture starts at the top, with all staff involved. ^[2]
2. Leading at the front line: managers go to where the work is done and coach their teams rather than managing from reports alone.
3. Measure before and after: do not announce an improvement without a baseline and a test of whether the difference is significant. ^[6]
4. A process owner after the project: someone who tracks the indicators and updates the standard work.
5. Integration, not competition, between methods: Lean and other quality improvement models complement each other. ^[5]

Conclusion

Lean Six Sigma in services means seeing what is normally invisible: waiting, rework and unnecessary approvals. Start by mapping the process as it actually runs, measure before you change anything, choose the tool that fits the size of the problem, and do not close the project until you know who will sustain the gains.

Imagine a report saying the project has spent 50% of its budget and we are halfway through its duration. Everything looks fine. But that figure says nothing about how much work has actually been done; only a quarter of the project might be complete.

Earned value management closes that gap. PMI’s standard defines it as a methodology that integrates scope, schedule and resources, measures performance and progress objectively, and forecasts project outcomes. ^[1] In other words, it answers three questions at once: are we on plan, are costs where they should be, and what will the rest cost?

The three measures the system rests on

All earned value calculations are built on three figures read at the same status date, plus the total budget:

• Planned value (PV): the budget for the work that should have been done to date.
• Earned value (EV): the approved budget for the work actually done.
• Actual cost (AC): what was actually spent on the work done.
• Budget at completion (BAC): the total approved budget for the project.

The key idea is that EV is measured in budget, not spend. If a work package has a budget of SAR 100,000 and is fully complete, its earned value is SAR 100,000 whether it cost 80,000 or 130,000.

Variances and indices: what the numbers say

Four core indicators are calculated from the three measures. The US Department of Energy reference card treats indices above 1 as favourable and below 1 as unfavourable. ^[4]

To express variance as a percentage, divide cost variance by EV and schedule variance by PV. ^[4] Overall percentage complete is EV divided by BAC, and the percentage of budget spent is AC divided by BAC. ^[4] Putting those two figures side by side in a report shows immediately whether spending is running ahead of progress.

Hypothetical example: a project in its fifth month

A project to develop an online system for a government entity has a budget of SAR 2,000,000 and a duration of ten months. At the end of month five:

Results: cost variance is minus SAR 200,000, schedule variance is minus SAR 200,000, CPI is 0.8 and SPI is 0.8. The project has spent exactly what was planned, but has completed only 80% of what it should have, and at a higher cost than budgeted.

Had the report simply compared spend with plan, the project would have looked under control. Earned value shows it is both late and over cost.

What will the project cost at completion?

Estimate at completion (EAC) is actual cost to date plus the estimated cost of the remaining work. Remaining work is BAC minus EV. ^[4] In our example, remaining work is SAR 1,200,000 in budget terms.

• Assuming current cost efficiency continues: EAC = BAC ÷ CPI = SAR 2,500,000.
• Assuming the delay will also drive up cost: EAC = AC + remaining work ÷ (CPI × SPI) = SAR 2,875,000.

GAO’s guide explains that the cumulative CPI formula usually gives the lowest estimate, so it is best read as the best case, and the CPI × SPI formula usually gives the highest, so it is read as the worst case. ^[6] So present management with a range, not a single figure: from SAR 2.5 million to about 2.9 million, an expected overrun of between SAR 500,000 and 875,000.

The guide also reports research finding that once a programme is 20% complete, cumulative CPI varies by less than 10% from its value, and that it tends to worsen as completion approaches. ^[6] The practical message: do not wait for efficiency to “recover naturally” without a tangible reason.

To-complete performance index (TCPI)

This index measures the efficiency needed on the remaining work to hit a given financial target: remaining work divided by remaining money. ^[4] To stay within the original budget in our example: 1,200,000 ÷ 1,000,000 = 1.2. The team would need to deliver SAR 1.2 of work for every riyal, having so far delivered only 0.8.

If TCPI is higher than CPI, the team is assuming improved productivity, and the analyst should look for evidence that supports that assumption. ^[6]

How do you measure progress objectively?

Earned value is only as accurate as the way progress is measured. GAO’s guide requires objective measures of earned value to be set before work starts, and sets out the following techniques: ^[5]

The guide warns that heavy reliance on level of effort means the system will not do its job, and notes that work packages typically run for 4 to 6 weeks. ^[5]

The limits of SPI

SPI measures schedule in money, not time, and that gives it a known limitation: it returns to 1.0 when the programme is complete, and its predictive value declines as work progresses. ^[6] A project that finishes three months late will end with an SPI of 1.

So do not rely on it alone in the final third of a project; review the critical path alongside it. Are the late activities on the critical path, or do they have float? PMI’s Standard for Earned Value Management (2019) includes the concept of earned schedule, which extends the meaning of value to measure time performance. ^[1]

The reference standards: PMI and EIA-748

PMI publishes The Standard for Earned Value Management (2019), which builds on the earlier Practice Standard for Earned Value Management and covers hybrid approaches that combine earned value with agile practices. ^[1]

EIA-748 is the reference for earned value management systems on large contracts. Revision E was issued in February 2026 and sets out seven principles that apply to all programmes, while its detailed guidelines are directed at large, complex or high-risk programmes. ^[2] The revision cut the guidelines from 32 to 27, organised in the same five process categories. ^[3]

In the Gulf, the level of application is usually set by the contract terms or by the organisation’s project management office policy. If a contract requires an EIA-748-compliant system, ask for the contractor’s approved system description rather than relying on monthly reports alone.

Implementation steps for your project

Start with a work breakdown structure and assign a manager to each control account, where a WBS element meets the organisational unit responsible for it, then link the schedule to the budget to produce the performance measurement baseline. Set the progress criterion for each package before it starts, then analyse variances and update estimates at least monthly, comparing them with the results of risk analysis. ^[5] Record every baseline change in a change log, so that variances do not disappear through replanning.

Conclusion

Earned value turns “how much have we spent?” into “what have we delivered for what we spent?”. Calculate CPI and SPI every month, present the estimate at completion as a range between best and worst case, and make progress measurement objective before trusting any figure.

A project risk is an uncertain event or circumstance that, if it occurs, would affect one or more project objectives. ^[4] The effect can be negative, a threat, or positive, an opportunity. PMI’s 2019 Standard for Risk Management in Portfolios, Programs, and Projects addresses events and conditions that may affect objectives, whether or not they could be foreseen during planning, and aims to capture opportunities and limit threats. ^[1]

In 2024 PMI updated the standard and folded its content into a practice guide that focuses on the “what” and “how” of risk management, covering the risk management life cycle and its application to portfolios, programmes and projects within an enterprise risk management approach. ^{[1, 2]}

The project risk management cycle

Risk management is not a session held at project launch and then forgotten. The PMI-RMP Examination Content Outline divides the work into five domains: strategy and planning, identification, analysis, response, and monitoring and closing. ^[3]

Planning defines risk management roles and responsibilities on the project and aligns them with a responsibility assignment matrix such as RACI. ^[3] Every stage after that both feeds and draws on the risk register, which is why the register sits at the centre of the cycle.

How should a risk be worded in the register?

The most common mistake in risk registers is mixing up cause, risk and effect. In an article published by PMI, David Hillson proposes a three-part statement: ^[4]

As a result of [a definite cause], [an uncertain event] may occur, which would lead to [an effect on objectives].

• Cause: a fact that exists now in the project or its environment, such as using an unproven technology or a shortage of specialist staff. ^[4]
• Risk: the uncertain event itself, signalled by words such as “may” or “might”. ^[4]
• Effect: the deviation from objectives if the risk occurs, such as a missed milestone or a budget overrun. ^[4]

One example from the article: a plan needs ten people but only six are available. The shortage is an existing cause, the risk is that the team may be too small for the workload, and the possible effect is schedule delay. ^[4]

Why does the separation matter? A cause is certain, so if it is logged as a risk it scores the highest probability and pushes genuine risks down the list. An effect does not exist until the risk occurs, so it cannot be managed directly. ^[4]

What goes into a risk register?

According to the PMI-RMP outline, developing the risk register involves validating risks and their triggers, assessing probability, impact and urgency, establishing each risk’s origin and owner, and classifying it as a threat or an opportunity. ^[3] These practical columns cover that:

A PMI Lebanon Chapter presentation adapted from the PMBOK Guide, Sixth Edition, shows a register with the code, event, causes, effects, breakdown category, impact on time, cost, scope and quality, score and level, and response strategy. ^[6]

Response strategies for threats and opportunities

There are five strategies for threats: ^{[5, 6]}

• Avoid: remove the root cause so the risk cannot affect the project, for example by changing the design.
• Transfer: pass the risk and liability for it to a third party, for example through insurance, warranties or subcontracting.
• Mitigate: reduce probability, impact or both to below the acceptability threshold.
• Accept: passively, by taking no action until the risk occurs and then deciding how to respond, or actively, by setting aside a contingency reserve.
• Escalate: when the project cannot manage the risk, pass it up to a higher level such as programme management.

Opportunities have counterpart strategies: exploit, to make the opportunity certain; share, with a party better placed to capture it in return for part of the benefit; enhance, by raising its probability or impact through its drivers and triggers; or take no specific action while staying ready to benefit if it arises, which Hillson calls “ignore”. ^[5]

Remember that transfer on projects usually happens through the contract or insurance, and the validity of risk-transfer clauses depends on each GCC country’s contract law and government contract conditions, so review them with a legal specialist before relying on them.

From plan to action: owner, trigger and contingency plan

Choosing the strategy is only half the job. The PMI-RMP outline calls for identifying action owners and allocating responsibilities, setting time-bound response actions, and showing their effectiveness with tools such as risk burndown charts. ^[3] Planning also covers contingency plans and workarounds. ^[3]

• Trigger and threshold: document triggers, causes and timing, and empower stakeholders to challenge existing thresholds. ^[3]
• Residual risk: what remains once the response has been implemented. It should be lower than the inherent risk; if it falls outside tolerance it needs further treatment, otherwise it goes on the watch list. ^[6]
• Secondary risk: a new risk that exists only because of the response, and which can sometimes be worse than the original. ^[6]

Hypothetical example: an online booking system for a government entity

Hypothetical example: a team is delivering an appointment booking system for a government entity, with a publicly announced launch date.

As a result of the system relying on an untested integration with the national identity platform, approval of the integration by the platform owner may be delayed, which would lead to postponement of the announced launch date.

• Assessment: medium probability, high impact on schedule and reputation, high urgency because testing is six weeks away.
• Strategy: mitigate by requesting the test environment immediately and naming a contact person at the platform owner.
• Trigger: test environment credentials not received within two weeks.
• Contingency plan: a pilot launch with temporary manual registration, subject to sponsor approval.
• Secondary risk: manual registration may increase errors, so it is added to the register with an owner and a daily check.
• Escalation: if the delay goes beyond the project manager’s authority, it is escalated to the PMO or the sponsor.

Monitoring the register and closing risks

In the PMI-RMP outline, monitoring means gathering risk-related performance data, comparing it with the baseline, analysing variances and tracking the effect on overall project risk exposure. ^[3] It then means updating the risk register, lessons learned, project management plan and change logs, and closing out expired risks. ^[3]

In practice, review high risks at every progress meeting, add new risks as soon as they appear, and give the sponsor a short report that focuses on what has changed rather than the whole register. The outline also recommends preparing reports suited to each stakeholder group. ^[3]

Conclusion

Project risk management starts with wording that separates cause from event from effect, and succeeds with a register that gives every risk an owner, a trigger and a dated response. Without tracking residual and secondary risks and closing out expired ones, the register becomes a document nobody reads.

Every organisation takes risks to achieve its objectives; the question is how much, and of what kind. ISO Guide 73:2009, as quoted by the IRM, defines risk appetite as the amount and type of risk an organisation is willing to pursue or retain. ^[4] The Financial Stability Board (FSB), whose principles are written for financial institutions, adds an important constraint: appetite must stay within risk capacity, the maximum risk the organisation can take on with its current resources before breaching capital and liquidity requirements or its obligations to stakeholders. ^[5]

The UK Institute of Risk Management (IRM) distinguishes two ideas: appetite is about the risk an organisation sets out to pursue, tolerance is about what it can absorb, and in most cases appetite is narrower than tolerance. ^[3] Risk limits, in the FSB’s words, are quantitative measures based on forward-looking assumptions that allocate the aggregate appetite to business lines, legal entities, risk categories and concentrations. ^[5]

In COSO’s 2017 enterprise risk management framework, defining risk appetite is Principle 7 within the Strategy and Objective-Setting component, meaning appetite is set alongside strategy, not after it. ^[1] ISO 31000:2018 can be used by any organisation regardless of size, activity or sector. ^[2] In 2011 the IRM noted that the then-current edition of ISO 31000 did not address risk appetite directly, focusing instead on risk attitude and risk criteria. ^[4]

Why does the board own risk appetite?

Because it is a decision about how big a bet the organisation is prepared to make, and that is the core of governance. COSO makes board risk oversight the first principle of its framework and lists the strategy and risk appetite proposed by management among the matters the board may review, challenge and concur with. ^[1] The FSB principles require the board to approve the risk appetite framework and statement, developed with the CEO, chief risk officer and chief financial officer, to hold senior management accountable for the framework’s integrity, to monitor the risk profile against limits and to ensure breaches are acted on. ^[5]

In the Gulf, requirements vary by regulator and sector. In the UAE, for example, the Central Bank of the UAE’s Risk Management Regulation, issued by Circular No. 153/2018, requires a bank’s risk framework to include a board-approved risk appetite statement with limits for all relevant risk categories and concentrations, and places ultimate responsibility for the risk governance framework on the board. ^[6] Organisations in other countries and sectors should go directly to the requirements of their own regulator.

What should a risk appetite statement contain?

A risk appetite statement is a written document setting out the aggregate level and types of risk the organisation will accept or avoid, using qualitative and quantitative measures. ^[5] Under the FSB principles, the statement should: ^[5]

• Link to the strategic, capital and financial plans, and to remuneration.
• Set the maximum level of risk for each material risk and for the organisation overall.
• Include quantitative measures that can be translated into limits for business units.
• Include qualitative statements explaining why risks are taken or avoided, including reputational and conduct risk.
• Be forward-looking and subject to scenario and stress testing.

The IRM adds that appetite must be measurable so the wording does not become vague, and that it differs from one type of risk to another, so a single sentence for the whole organisation is not enough. ^[3] The table below is a drafting template (the values are illustrative):

How does the statement become decision limits?

This is where many organisations fail: the board approves a well-written statement, then nothing changes in day-to-day decisions. The FSB principles assign the translation clearly: the CEO ensures appetite is translated into limits for business lines and legal entities, the CFO builds it into business planning, new products, mergers and acquisitions and capital management, and business line leaders set and monitor limits within their units and escalate breaches promptly to the CRO and senior management. ^[5]

The IRM notes that tolerance tends to take the form of limits, either hard boundaries or early-warning tripwires that signal an impending breach, and recommends key risk indicators (KRIs) and key control indicators (KCIs) to measure tactical and operational risks and controls. ^[4] In practice, each indicator is linked to three zones:

• Safe zone: the manager acts within normal authority.
• Warning zone: the risk owner and risk function are informed and a corrective plan is put in place.
• Breach zone: the decision moves up to the next level of the delegation of authority matrix, or to the board risk committee.

The financial and administrative delegation matrix thus becomes the tool that carries appetite into decisions: any decision outside the limits is not the manager’s alone.

Hypothetical example: a logistics company sets its appetite

Hypothetical example: the board of a Gulf logistics services company approves a statement of “moderate appetite for growth risk and low appetite for customer credit risk”. Executive management turns the second phrase into an indicator: receivables overdue by more than 90 days as a share of total receivables.

• Below 5%: safe zone; the sales manager can accept contracts on credit terms within normal authority.
• 5% to 8%: warning zone; any new contract on credit terms needs CFO approval.
• Above 8%: breach zone; new contracts on credit terms stop and the matter goes to the risk committee.

With the indicator at 6%, a large contract on deferred payment terms comes in. The sales manager does not decide alone; the contract goes to the CFO, who accepts it on condition of a bank guarantee. That is what decision limits mean: appetite did not block growth, but it set who decides and on what terms.

What happens when a limit is breached?

A breach is not necessarily a failure, but hiding one is. Under the FSB principles, the chief risk officer reports regularly on the risk profile against appetite and escalates material breaches promptly to the board and CEO, and the CEO sets a policy for notifying the board and supervisor of serious breaches. ^[5] For UAE banks, the Central Bank regulation requires exceptions to be addressed immediately and the Central Bank to be notified immediately of any significant deviation from the board-approved risk appetite statement. ^[6]

The IRM recommends that the board exercise governance over appetite at four points (approval, measurement, monitoring and learning) and that breaches trigger a mid-cycle review where needed rather than waiting for the annual one. ^[3]

Common mistakes in risk appetite statements

• Vague, unmeasurable wording: such as “we take a prudent approach to risk”, with no measure or limit. ^[3]
• One appetite for every risk: appetite varies by risk type and organisational level and changes over time. ^{[3, 4]}
• Appetite above capacity: appetite must sit within risk capacity, not be set in isolation from it. ^[5]
• Appetite detached from remuneration: if incentives reward breaching limits, the statement will not survive. ^[5]
• Appetite without control: the IRM warns that appetite must be matched by the capacity to control risk, and that setting an appetite is worthwhile only if the organisation can actually manage risk to that level. ^[4]

Conclusion

Risk appetite is a governance decision owned by the board, but its value shows at the levels below: allocated limits, warning indicators and a delegation matrix that sets who decides as a limit approaches. Start with three or four material risk categories, give each a statement, a measure and a limit, and link them to decision rights before expanding the framework.

Kaoru Ishikawa highlighted these tools in his guide to quality control because they let front-line staff solve most everyday problems without advanced statistics. The American Society for Quality (ASQ) lists seven: the cause-and-effect diagram, check sheet, control chart, histogram, Pareto chart, scatter diagram and stratification. Some newer lists replace stratification with the flowchart. ^[1]

Their value today is as a shared language: when a team in a hospital or government entity shows a Pareto chart, everyone sees where the biggest problem lies without a long explanation.

Which tool do you use, and when?

A common mistake is for a team to start drawing a fishbone before it knows which problem deserves analysis. Always start with a clear question, then choose the tool that answers it.

Check sheet and stratification: correct data first

A check sheet is a simple form for tallying how often each type of problem occurs. ^[1] It looks obvious, but its value lies in agreeing definitions: what counts as “late”? More than one working day, or beyond the published service time? If each employee records in their own way, every later analysis is built on sand.

Stratification means separating data by groups such as branch, shift or service type. ^[1] An error rate may look acceptable overall, then turn out after stratification to be high on the night shift alone.

Pareto: where to focus first

A Pareto chart ranks problems or causes from largest to smallest, based on the 80/20 rule: a few causes explain most of the effect. ^{[1, 3]} ASQ summarises how to build one: choose the categories, then the measure (count, cost or time), then the time period; collect the data; arrange the bars in descending order, grouping small categories as “other”; and, if you wish, add a cumulative percentage line. ^[3]

Watch the choice of measure. The most frequent cause may not be the most costly, so you may need one Pareto chart by number of cases and another by cost before setting priorities.

Fishbone: organising possible causes

The cause-and-effect diagram, or fishbone, puts the problem at the head and arranges its possible causes in main and secondary branches. ^[1] In services, branches might be people, procedures, systems, environment, measurement and inputs.

Remember that the diagram collects possible causes, not proven ones. You then need data to confirm or rule out each cause, which is where the scatter diagram, histogram or a return to the check sheet comes in.

Histogram and scatter diagram: understanding the data

A histogram shows the shape of the data’s distribution more clearly than a table. ^[1] If transaction times have two peaks, there may be two different processes operating under one name.

A scatter diagram plots two variables together to reveal a possible relationship, such as daily request volume and reply time. ^[1] But correlation does not prove causation; a third factor may be driving both.

Control chart: is the process stable?

A control chart plots a measured value over time against control limits calculated from the process’s own data. It separates two kinds of variation: common causes inherent in the process, and special causes arising from unusual events that make the process unstable and unpredictable. ^[2]

Out-of-control signals listed by ASQ include a point beyond the control limits, eight points in a row on one side of the centre line, or an obvious persistent pattern. The team then looks for the special cause and documents it. ^[2] If the process is stable but its performance is unacceptable, the answer is to change the process itself, not to chase each point.

A hypothetical example: complaints at a customer service centre

A service centre in a government entity is receiving more complaints. The team designs a check sheet of complaint types and collects four weeks of data, stratified by service channel. A Pareto chart shows that three types account for most complaints, led by slow replies to email.

The team draws a fishbone for that type, and possible causes include manual email routing and no reply templates. A scatter diagram confirms that reply time rises with the number of messages per shift. After introducing automatic routing and reply templates, the team tracks weekly average reply time on a control chart to confirm the improvement has held. The case is hypothetical, to illustrate the sequence.

Mistakes that spoil the analysis

• Drawing the tools with data collected under different definitions.
• Treating fishbone causes as facts without checking them.
• Treating every rise on the chart as a crisis when it is within normal variation.
• Putting the chart in a report without a decision or action following it.

Conclusion

Start with a question, then choose the tool that answers it: a check sheet to collect data, Pareto to set priorities, a fishbone to organise causes, and a control chart to tell whether an improvement has held.

At the start of every project the same debate returns: do we prepare a detailed plan and full schedule and stick to it, or start with small deliveries and adjust course as we learn? The answer does not depend on which approach is newer, but on the nature of the project itself. The Agile Practice Guide, published by the Project Management Institute (PMI) and the Agile Alliance, stresses that no single life cycle suits every project. ^[3]

What is waterfall (the predictive approach)?

The guide describes a predictive approach as a traditional one in which most planning happens up front, followed by execution in a single sequential pass: requirements, design, build, test, deliver. Requirements are fixed, there is a single delivery at the end, and the main management goal is controlling cost. ^[3]

This approach suits projects where the output is known precisely and late change is expensive, such as construction, equipment installation and moving to new premises, or where the contract requires a fixed scope and price.

What is agile (the adaptive approach)?

Agile is fundamentally a set of values declared in the 2001 Agile Manifesto: individuals and interactions over processes and tools, working software over comprehensive documentation, customer collaboration over contract negotiation, and responding to change over following a plan. The manifesto adds that while there is value in the items on the right, the items on the left are valued more. ^[1]

The Agile Practice Guide defines an agile approach as both iterative and incremental: it refines work through repeated cycles and delivers frequently, with the goal of customer value through frequent delivery and feedback. ^[3]

Its best-known framework is Scrum, which according to the 2020 Scrum Guide is founded on empiricism with three pillars: transparency, inspection and adaptation. The team, typically 10 people or fewer, works in fixed-length sprints of one month or less, with a Product Owner who manages the Product Backlog, a Scrum Master who supports the team’s effectiveness, and Developers who do the work. ^[2]

How do you choose the right approach?

The Agile Practice Guide offers a model inspired by the Stacey matrix that plots requirements uncertainty against technical uncertainty. When both are low, linear approaches work; as uncertainty rises, adaptive approaches become more suitable. When both are very high, the project is fundamentally risky and needs one of the variables contained first. ^[3]

The guide also lists other factors used in suitability assessment models, including buy-in to the approach, trust in the team, the team’s decision-making powers, team size and experience, access to the customer, likelihood of change, criticality of the product and the ability to deliver incrementally. ^[3]

Hybrid approaches: the realistic answer in large organisations

In many government entities and large companies, annual budgets, procurement and contracts require an agreed scope and schedule in advance, while the product itself needs flexibility. This is where hybrids come in, and the guide describes several patterns: ^[3]

• Agile development, then predictive rollout: the system is built in increments, then deployment, training and migration follow a fixed plan.
• Predictive project with an agile component: agile is applied only to the most uncertain part.
• Agile project with a predictive component: when one part comes from an external vendor on a fixed contract.
• Mixed practices: short iterations and retrospectives within an overall predictive plan.

The guide warns that tailoring should be deliberate; premature or haphazard changes can lose the benefits of an approach. ^[3]

A hypothetical example: an e-services portal

A government entity is launching a customer services portal with an approved budget and a fixed launch date. Signing the vendor contract, preparing infrastructure and meeting cybersecurity requirements are managed predictively, with a fixed plan and schedule. The service screens themselves are developed in two-week cycles, shown at the end of each cycle to a sample of customers and service staff, and reprioritised based on their feedback.

The entity keeps its budget and date commitments to senior management while getting services closer to what customers actually need. The details are hypothetical, to illustrate the idea.

Common mistakes when choosing an approach

• Adopting agile in name only: daily meetings with no involved customer and no real deliveries.
• Forcing waterfall on a project with unclear requirements, then managing dozens of change requests.
• No Product Owner with real authority, so the team ends up waiting for decisions.
• Signing a fixed-scope contract for a product that is expected to change a lot.

Conclusion

Ask about the project before you ask about the method: how clear are the requirements and technology? Is the customer available? Can the work be delivered in stages? Choose predictive for what is clear and stable, adaptive for what is changing and uncertain, and hybrid when both exist in one project.