13. Implementation, Change and Project LeadershipIntroduction and ContextA logistics or supply chain project creates value only when its proposed design becomes accepted, operational behaviour. A network redesign, warehouse-management system, transport initiative, sourcing programme, or inventory policy may be analytically sound and still fail if users reject it, suppliers cannot support it, controls are weak, or benefits are not measured. Implementation is therefore not a final administrative phase. It is the managed transition from an approved project proposition to a stable organisational capability. Implementation combines technical deployment, process redesign, people management, commercial coordination, governance, and benefits realization. It also exposes assumptions made during analysis. Data may be less reliable than expected, operational constraints may have been underestimated, and stakeholders may interpret success differently. Project leadership is required to reconcile these realities without losing strategic direction. This chapter presents an implementation roadmap for logistics and supply chain projects. It examines pilots, resources, stakeholder engagement, negotiation, change management, capability development, vendor management, controls, and benefits realization. The central argument is that implementation should be designed as a controlled learning process: begin with a credible baseline, test the new approach in a bounded setting, learn from evidence, scale deliberately, and continue measuring outcomes after project closure. Learning ObjectivesBy the end of this chapter, students should be able to: 1. Construct an implementation roadmap for a logistics or supply chain project. 2. Design pilots that generate operational and financial evidence before scaling. 3. Identify resource, capability, stakeholder, vendor, and governance requirements. 4. Apply change-management and negotiation principles to implementation problems. 5. Develop controls, performance measures, and benefits-realization mechanisms. 6. Evaluate implementation risks, ethical issues, and leadership choices. 7. Recommend improvements using digital monitoring, analytics, and structured review. Implementation as a Transition from Design to CapabilityA project proposal normally describes a future state: lower logistics cost, shorter lead time, improved visibility, greater resilience, or better service. Implementation converts that future state into repeatable routines. Four transitions usually occur simultaneously: - Technical transition: systems, equipment, data, interfaces, facilities, and operating parameters are introduced or modified.
- Process transition: responsibilities, workflows, decision rules, approvals, and performance measures change.
- Behavioural transition: employees, managers, suppliers, and customers learn to act differently.
- Institutional transition: the organisation embeds new capabilities in budgets, policies, contracts, training, and governance.
A useful distinction is between outputs, outcomes, and benefits. An installed transport-management system is an output. Higher planning accuracy and improved carrier coordination are outcomes. Reduced cost per shipment, improved on-time delivery, or lower emissions are benefits. Implementation plans that stop at outputs confuse completion with value. Implementation also has a dual character. It is a delivery exercise, requiring schedules, budgets, dependencies, and quality controls; and it is a learning exercise, because assumptions must be tested in actual operations. Excessive emphasis on the first creates rigid roll-outs. Excessive emphasis on experimentation creates uncertainty and weak accountability. Effective project leadership balances disciplined execution with structured adaptation. The Implementation RoadmapA practical roadmap should identify the sequence of work, decision gates, owners, resources, evidence requirements, and conditions for proceeding. A typical sequence is: Mobilize and baseline. Confirm the business case, scope, governance, assumptions, constraints, and baseline performance. Establish the project team, decision rights, risk register, communication plan, and benefits register. Design the transition. Translate the target operating model into detailed processes, roles, data requirements, training needs, technical specifications, procurement actions, and transition risks. Determine what must change simultaneously and what can be phased. Prepare the organisation. Clean and migrate data, configure systems, qualify vendors, prepare facilities, communicate the case for change, train affected groups, and test procedures. Readiness should be assessed using evidence rather than confidence statements. Pilot and learn. Introduce the change in a controlled location, product category, route, supplier group, or user segment. Define success criteria in advance and protect the pilot from uncontrolled expansion. Decide and scale. At a formal gate, compare results with baseline and thresholds. The appropriate decision may be to scale, redesign, extend the pilot, or stop the initiative. Scaling should occur in waves, with lessons from each wave incorporated into the next. Stabilize and transfer. Resolve defects, normalize work, transfer ownership to line management, close temporary arrangements, and confirm that operational teams can sustain performance without extraordinary project support. Realize and review benefits. Continue measuring benefits against the approved baseline, validate financial effects, investigate variance, and conduct post-implementation reviews. Benefits ownership remains with the business rather than the project manager alone. A roadmap is more useful when expressed through decision gates. For example, a pilot may proceed only when data quality exceeds an agreed level, training completion reaches a defined threshold, safety controls are tested, and the vendor has demonstrated technical readiness. A scale decision may require stable service performance for a specified number of operating cycles and no unresolved critical risks. Pilots: Learning Before ScalingA pilot is a deliberately limited implementation designed to test feasibility, usability, economics, and operational consequences. It is not merely a small roll-out. A well-designed pilot has a hypothesis, a defined population, a comparison point, a time horizon, measures, decision rules, and an accountable owner. Pilot selection involves a trade-off. A highly representative site may reveal realistic complexity but be difficult to control. A simple site may be easy to manage but produce misleadingly positive results. Selection criteria should include operational representativeness, data availability, leadership support, risk containment, supplier participation, and the ability to isolate effects. Pilot measures should combine leading and lagging indicators. Leading indicators include training completion, system adoption, data accuracy, exception resolution, and adherence to new procedures. Lagging indicators include order-cycle time, inventory accuracy, delivery reliability, cost per order, damage, safety incidents, and customer complaints. Baseline measurement must use comparable definitions and time periods; otherwise apparent improvement may reflect measurement change. A pilot should also test failure modes. For a warehouse system, this may include barcode failure, network interruption, short shipment, urgent orders, product substitutions, and user override. For a transport programme, it may include carrier rejection, route disruption, missed collection, and incomplete proof of delivery. Testing only the normal case creates false confidence. Pilot governance should specify who may authorize exceptions, how defects are logged, when operations can pause the pilot, and how decisions are documented. A pilot that imposes hidden overtime, manual workarounds, or service deterioration may be technically successful but economically unacceptable. The post-pilot review should distinguish design defects, training gaps, data problems, vendor failures, and normal learning effects. Resourcing the TransitionResource planning extends beyond project headcount. Implementation may require operational subject-matter experts, process analysts, data specialists, trainers, change leads, legal and procurement support, cybersecurity expertise, facilities personnel, and vendor resources. Their availability must be planned because operational experts are often needed precisely when day-to-day workload is high. The resource plan should address: - required roles, competencies, and decision authority;
- full-time and part-time allocation by implementation stage;
- budget for technology, equipment, training, temporary labour, travel, and contingency;
- data, testing, and infrastructure requirements;
- backfill arrangements for employees assigned to the project;
- escalation capacity during cutover and stabilization.
A common mistake is to budget the purchase price while excluding transition costs. Temporary duplicate operations, data cleansing, parallel running, overtime, lost productivity, integration changes, and post-launch support can materially affect the business case. Financial governance should therefore distinguish approved budget, committed cost, actual cost, forecast cost to complete, and contingency consumption. Stakeholder Engagement, Negotiation and LeadershipStakeholder engagement is not a public-relations activity. It is a means of improving decisions, securing cooperation, identifying risks, and building ownership. Stakeholders include sponsors, employees, functional managers, customers, suppliers, carriers, regulators, technology partners, finance teams, and communities affected by facilities or transport activity. Stakeholder analysis should consider influence, impact, expertise, interests, likely concerns, and the quality of the relationship. A warehouse employee may possess low formal authority but high practical knowledge. A carrier may have substantial power during peak periods. A finance executive may control approval but not understand operational consequences. Engagement methods should reflect these differences: workshops, interviews, demonstrations, data reviews, training sessions, steering committees, and targeted negotiation. Negotiation is particularly important where benefits and burdens are distributed unevenly. A project may reduce a buyer’s price but increase a supplier’s packaging cost; improve customer delivery windows but increase carrier complexity; or automate work while requiring employees to acquire new skills. Effective negotiation begins with interests rather than stated positions. Parties should clarify objectives, constraints, alternatives, decision criteria, risk allocation, and evidence requirements. Agreements should record responsibilities, service levels, escalation procedures, data rights, change mechanisms, and consequences of non-performance. Project leadership differs from administrative coordination. Leaders create a credible purpose, make trade-offs visible, protect ethical standards, and maintain momentum when results are ambiguous. They also create psychological safety: employees must be able to report defects and operational risks without fear that bad news will be suppressed. A leader who rewards optimistic reporting may achieve apparent schedule performance while increasing implementation risk. Change Management and Capability DevelopmentChange management addresses the human and organisational adoption of a new way of working. It is not limited to communication. A practical change strategy explains why change is needed, what will change, who will be affected, what support will be provided, and how adoption will be assessed. The ADKAR model is useful for individual adoption: Awareness of the need for change, Desire to participate, Knowledge of how to change, Ability to perform the new behaviour, and Reinforcement to sustain it. At organisational level, Lewin’s unfreeze–change–refreeze logic highlights the need to challenge existing assumptions, introduce new practices, and stabilize them. Kotter’s change framework emphasizes urgency, coalition building, vision, communication, removal of barriers, short-term wins, consolidation, and institutionalization. These models are not mechanical recipes; they are diagnostic lenses. Capability development should be role-specific. A planner may need training in new exception rules and analytics; a picker may need practical system and safety training; a supervisor may need coaching in performance management; a procurement professional may need contract and supplier-governance skills. Training should use realistic data and scenarios, followed by assessment and supervised practice. Attendance is not evidence of competence. Adoption measures may include active system use, compliance with standard work, error rates, override frequency, training assessment, help-desk themes, and supervisor observations. Resistance should not automatically be treated as irrational. It may indicate inadequate design, conflicting incentives, workload pressure, poor consultation, or legitimate concerns about job security and safety. Leaders should distinguish constructive challenge from obstruction. Vendor Management and Inter-organizational DeliveryMany supply chain projects depend on software providers, systems integrators, equipment manufacturers, carriers, consultants, or outsourced logistics providers. Vendor management begins before contract award by clarifying requirements, evaluation criteria, implementation responsibilities, integration assumptions, acceptance tests, data protection, and exit arrangements. A sound contract connects payment and acceptance to verifiable deliverables rather than activity alone. It should address service levels, availability, response times, defect correction, cybersecurity, confidentiality, audit rights, subcontracting, business continuity, intellectual property, change control, and transition assistance. Service-level agreements should measure outcomes that matter to the operation, not only technical statistics. Vendor governance requires a regular operating rhythm: implementation reviews, issue logs, risk reviews, performance dashboards, and executive escalation where necessary. The buyer should retain sufficient internal knowledge to challenge the supplier and operate after contract termination. Overdependence on a vendor can create lock-in, weak negotiation power, and continuity risk. When performance deteriorates, the first response should be evidence-based diagnosis. The cause may be ambiguous requirements, poor client data, inadequate integration, supplier under-resourcing, or unrealistic acceptance criteria. Remediation plans should identify root cause, owner, deadline, evidence of closure, and consequences of failure. Commercial remedies should be applied consistently and proportionately. Controls, Governance and AssuranceImplementation controls protect value, safety, compliance, and decision quality. They include scope control, change control, financial control, quality assurance, data governance, access control, segregation of duties, safety procedures, and documented approvals. A change-control process prevents uncontrolled expansion of scope. Each proposed change should state its rationale, impact on cost, schedule, risk, benefits, resources, and interfaces. Not every change should be rejected; the purpose is informed authorization. A risk register should record probability, impact, proximity, owner, response, residual exposure, and review date. Issues differ from risks because they have already occurred and require action. Governance should be proportionate. A steering committee provides strategic direction and resolves cross-functional decisions; a project manager coordinates delivery; workstream leads manage specialist activities; process owners accept operational outcomes; and an assurance function tests whether controls and evidence are adequate. Decision rights should be explicit through a responsibility matrix such as RACI, while avoiding excessive committees that slow action without improving accountability. Logistics projects also require attention to regulatory and ethical obligations. These may include occupational safety, transport and customs rules, product traceability, environmental requirements, labour protections, competition law, privacy, and records management. Automation and algorithmic allocation can create hidden discrimination or unsafe work intensity. Employee monitoring and location data should be proportionate, transparent, secure, and legally justified. Cost savings cannot ethically justify unsafe loading, misleading emissions claims, or shifting unacceptable risks to small suppliers. Benefits Realization and Performance ControlBenefits realization begins with a benefits map linking project outputs to operational outcomes and strategic objectives. Each benefit should have a definition, baseline, target, measurement method, timing, owner, dependencies, and validation authority. Benefits may be financial, service-related, risk-related, environmental, or capability-based. A benefits register can include the following fields: benefit statement; baseline value; target value; measurement frequency; data source; accountable owner; enabling changes; forecast date; actual result; confidence rating; and corrective action. Finance or an independent assurance function should validate claimed financial benefits. Avoided cost, cash-releasing savings, accounting savings, and revenue effects should not be treated as interchangeable. Performance dashboards should combine outcome indicators with operational controls. A transport implementation, for example, may track on-time-in-full delivery, cost per consignment, empty kilometres, claims, driver safety, fuel or energy use, and electronic proof-of-delivery adoption. A warehouse project may track inventory accuracy, lines per labour hour, order cycle time, replenishment adherence, damages, near misses, and system exceptions. Metrics must be interpreted together: increasing productivity alongside rising injuries is not successful implementation. Benefits can erode after project closure because attention shifts, staff change, workarounds return, or external conditions change. Sustainment reviews at thirty, ninety, and one hundred eighty days can test whether performance is embedded. Where benefits are not achieved, leaders should determine whether the problem lies in adoption, design, measurement, external assumptions, or ownership. Digital Tools, Analytics and AutomationDigital tools can strengthen implementation when they improve visibility and decision speed. Integrated project dashboards can connect milestones, risks, costs, defects, training, and benefits. Process-mining tools can compare intended workflows with actual system events. Collaboration platforms provide version control and decision records. Digital twins or simulation can test warehouse flows, capacity, routing, and inventory policies before physical changes are made. Analytics can identify adoption gaps, predict service failures, and prioritize exceptions. Machine-learning models may support demand sensing, route planning, or predictive maintenance, but implementation requires attention to data quality, model drift, explainability, human override, and accountability. Automation should be introduced with fallback procedures and clear ownership when the system is unavailable or produces anomalous recommendations. Technology does not remove the need for leadership. A dashboard may expose a problem but cannot negotiate a new carrier arrangement, resolve conflicting incentives, or persuade employees that a process is safe and workable. Digital evidence should support managerial judgement rather than replace it. Illustrative Case: The NorthRiver Distribution PilotBackground. NorthRiver Foods, a fictional regional distributor, planned to introduce a warehouse-management system and standardized replenishment rules across three distribution centres. The intended benefits were improved inventory accuracy, fewer emergency replenishments, and more reliable customer deliveries. Situation. The business case assumed that product and location data were sufficiently accurate. During preparation, the team found duplicate item codes, inconsistent units of measure, and uneven barcode coverage. Warehouse supervisors were concerned that the new task sequence would reduce flexibility during promotions. The software vendor proposed a rapid deployment, while the operations director wanted all three sites converted before the peak season. Analysis. The project team established a baseline using eight weeks of comparable data. It found that inventory accuracy, rather than software functionality, was the principal constraint. A risk review showed that simultaneous deployment would multiply disruption and leave little capacity for correction. Stakeholder interviews also revealed that supervisors were not opposed to the system itself; they feared being held responsible for data problems they could not control. Approach. The steering committee selected one medium-sized site with representative products and supportive local leadership. Before the pilot, the team cleansed master data, introduced barcode checks at receiving, mapped exception procedures, and agreed decision gates. The pilot measured inventory accuracy, picking productivity, order-cycle time, emergency replenishment, training competence, and safety observations. The vendor was required to resolve critical defects within defined periods, while NorthRiver retained ownership of data standards and process decisions. Training used realistic orders and included stock discrepancies, urgent orders, and system interruption. Supervisors participated in design workshops and received authority to pause the pilot for safety or severe service risk. Daily huddles reviewed defects; weekly reviews separated software defects from process and data issues. Outcome. The pilot initially reduced productivity because users were learning and data corrections generated additional work. After stabilization, inventory accuracy and exception visibility improved, but the original productivity target was not reached. The committee therefore approved a revised two-site scale-up rather than a full roll-out. It added a data-governance workstream, extended supervisor coaching, and revised the benefits forecast. The second site adopted the improved procedures with fewer disruptions. Learning points. First, a pilot is valuable even when it does not immediately meet the business case: it reveals assumptions before they become enterprise-wide failures. Second, readiness depends on data, roles, training, and governance, not only software installation. Third, leaders must be willing to revise the scale decision when evidence challenges the original schedule. Finally, benefits ownership transferred to operations, with finance validating results after stabilization. Challenges, Risks and Common Implementation ErrorsImplementation commonly fails through predictable patterns. Treating communication as a single launch announcement creates confusion and rumours. Underestimating data preparation produces unreliable outputs. Deploying everywhere at once increases exposure to defects. Removing subject-matter experts too early weakens operational ownership. Measuring activity rather than outcomes rewards completion without value. Other risks include vendor lock-in, cybersecurity incidents, weak integration, loss of key personnel, labour resistance, benefit double-counting, regulatory non-compliance, and change fatigue caused by multiple simultaneous initiatives. External shocks such as fuel-price changes, demand volatility, industrial action, or border disruption can obscure project effects. Baselines and scenario analysis help distinguish project performance from environmental variation. Common leadership errors include hiding bad news, assigning accountability without authority, accepting ambiguous requirements, using unrealistic deadlines to signal commitment, and imposing standardization without understanding local operating conditions. Conversely, endless consultation can prevent decisions. The remedy is transparent criteria, time-bounded consultation, clear escalation, and documented decisions. Best-Practice PrinciplesSeveral principles provide a practical standard for implementation: 1. Begin with a credible baseline and a clearly defined future state. 2. Treat implementation as both delivery and learning. 3. Pilot with explicit hypotheses, measures, decision rules, and stop criteria. 4. Engage those who perform the work and those who bear the consequences. 5. Match training and support to roles, risks, and real operating conditions. 6. Make decision rights, vendor obligations, and escalation routes explicit. 7. Protect safety, data integrity, privacy, and regulatory compliance. 8. Link outputs to measurable outcomes and named benefits owners. 9. Scale in waves and preserve the ability to pause or redesign. 10. Continue assurance after handover until the capability is demonstrably stable. Chapter SummaryImplementation is the disciplined transition from a project design to a sustainable logistics or supply chain capability. It requires technical deployment, process redesign, behavioural adoption, and institutional ownership. An effective roadmap moves through mobilization, preparation, piloting, gated scaling, stabilization, and benefits review. Pilots should test assumptions and failure modes, not merely demonstrate normal operation. Resource planning must include transition and backfill costs; stakeholder engagement must support negotiation and ownership; and change management must develop practical capability rather than rely on communication alone. Vendor governance, controls, risk management, ethical safeguards, and data governance protect implementation quality. Benefits realization connects outputs with measurable operational and strategic value and continues beyond project closure. Digital dashboards, analytics, process mining, simulation, and AI can improve visibility and decision-making, but they require human accountability. Project leaders create the conditions for honest reporting, informed trade-offs, safe adoption, and sustained performance. Key TermsImplementation roadmap: A sequenced plan showing activities, dependencies, decision gates, owners, resources, and evidence requirements. Pilot: A bounded implementation used to test feasibility, adoption, risks, and benefits before wider deployment. Baseline: A documented measure of current performance against which change is assessed. Future state: The intended operating condition after a project has been implemented. Output: A deliverable produced directly by a project, such as a configured system. Outcome: A change in operational performance or behaviour resulting from project outputs. Benefit: A measurable improvement in value, service, capability, risk, cost, or sustainability. Benefits register: A controlled record of benefits, baselines, targets, owners, measures, and status. Change management: The structured management of adoption and transition to new ways of working. Capability development: The creation of knowledge, skills, behaviours, and systems needed for sustained performance. Change control: A formal process for assessing and authorizing changes to approved scope or plans. Decision gate: A formal review at which continuation, modification, delay, or termination is decided. Stakeholder engagement: Deliberate interaction with parties affected by or able to influence a project. Vendor governance: The structures and practices used to manage supplier performance, risk, and accountability. Service-level agreement: A contractual specification of measurable service expectations and remedies. Operational readiness: The demonstrated ability of people, processes, systems, and resources to perform after transition. Adoption: The extent to which intended users consistently employ the new process or system. Stabilization: The period in which defects, workarounds, and performance variation are reduced after deployment. RACI matrix: A responsibility model identifying who is responsible, accountable, consulted, and informed. Process owner: The person accountable for the continuing performance and improvement of a business process. Review QuestionsShort Answer Questions1. Why should implementation be treated as both a delivery and a learning process? 2. Distinguish between a project output, outcome, and benefit, using a logistics example. 3. What evidence should be considered before scaling a pilot? 4. Why is training attendance insufficient evidence of capability? 5. What is the purpose of a benefits register? Long Answer Questions1. Explain the stages of an implementation roadmap for a supply chain technology project. 2. Discuss how stakeholder engagement and negotiation influence implementation outcomes. 3. Compare the roles of project governance, vendor governance, and operational ownership. 4. Explain how change-management models can support adoption while recognizing their limitations. 5. Discuss the ethical, regulatory, and data-governance issues that may arise in logistics implementation. Analytical / Application Questions1. A transport-management pilot improves route utilization but reduces delivery reliability during the first month. How should the project team analyze the result and decide whether to scale? 2. A warehouse automation project is on budget, but employees use manual workarounds and injury observations are increasing. Develop an intervention plan covering leadership, training, controls, and benefits measurement. 3. A software vendor blames poor performance on client data, while the client blames configuration defects. Design an evidence-based governance and remediation process to identify responsibility and protect business continuity. 22. Multiple Choice Questions with AnswersQuestion 1Which statement best distinguishes an implementation output from a benefit? A. An output is always financial, while a benefit is always technical. B. An output is a project deliverable, while a benefit is a measurable improvement created through its use. C. An output occurs after project closure, while a benefit occurs before implementation. D. An output is owned by finance, while a benefit is owned by the vendor. Correct Answer: B. An output is a project deliverable, while a benefit is a measurable improvement created through its use. Question 2What is the primary purpose of a pilot in a logistics implementation? A. To guarantee that the original business case will be achieved. B. To avoid measuring baseline performance. C. To test assumptions, feasibility, adoption, and risks before wider deployment. D. To transfer all implementation responsibility to the vendor. Correct Answer: C. To test assumptions, feasibility, adoption, and risks before wider deployment. Question 3Which condition most strongly supports a decision to scale a pilot? A. Senior managers are confident despite incomplete evidence. B. The vendor requests immediate expansion before peak season. C. Training has been announced but not assessed. D. Predefined performance thresholds are met and critical risks are controlled. Correct Answer: D. Predefined performance thresholds are met and critical risks are controlled. Question 4Why should implementation budgets include temporary duplicate operations and backfill? A. These costs are often part of the transition even though they are not the purchase price. B. They eliminate the need for a contingency reserve. C. They are incurred only when a project has failed. D. They replace the need for operational subject-matter experts. Correct Answer: A. These costs are often part of the transition even though they are not the purchase price. Question 5A warehouse supervisor resists a new system because data errors may make the supervisor accountable for failures outside the supervisor’s control. What is the most appropriate leadership response? A. Ignore the concern because resistance is inevitable. B. Remove the supervisor from the pilot. C. Investigate the concern, clarify accountability, and involve the supervisor in process and data design. D. Make system use mandatory without changing responsibilities. Correct Answer: C. Investigate the concern, clarify accountability, and involve the supervisor in process and data design. Question 6Which contractual practice best supports vendor accountability? A. Paying entirely for effort hours regardless of results. B. Linking acceptance and payment to verifiable deliverables and service levels. C. Allowing the vendor to define its own acceptance tests after deployment. D. Excluding data protection and exit provisions to simplify the contract. Correct Answer: B. Linking acceptance and payment to verifiable deliverables and service levels. Question 7What does a benefits owner primarily do? A. Approve every technical change made by the vendor. B. Ensure that the intended operational or strategic benefit is measured and sustained. C. Replace the project sponsor after implementation begins. D. Conduct all employee training personally. Correct Answer: B. Ensure that the intended operational or strategic benefit is measured and sustained. Question 8Which situation illustrates a control failure rather than merely a schedule variance? A. A training workshop is postponed by two days. B. A project milestone is rescheduled after a supplier delay. C. Users receive unauthorized access to sensitive operational data. D. A pilot is extended to collect more evidence. Correct Answer: C. Users receive unauthorized access to sensitive operational data. Question 9Why should implementation dashboards combine outcome indicators with safety and control indicators? A. Because a single productivity measure may conceal harmful trade-offs. B. Because outcome indicators are never useful on their own. C. Because safety indicators determine the project budget automatically. D. Because control indicators replace the need for benefits measurement. Correct Answer: A. Because a single productivity measure may conceal harmful trade-offs. Question 10In the NorthRiver case, why was a phased scale-up chosen instead of immediate deployment to all sites? A. The project had no approved business case. B. The pilot revealed data and productivity issues requiring redesign and further capability development. C. The vendor refused to support additional sites. D. The organization decided that inventory accuracy was irrelevant. Correct Answer: B. The pilot revealed data and productivity issues requiring redesign and further capability development.
|