A simple framework for managing projects

When it comes to creating a successful supply chain operation in today's competitive marketplace, maintaining the status quo is not an option. A "world class" supply chain—one that is lean, reliable, agile, responsive, and cost-effective—requires continuous process improvement and a "big picture" perspective on total ownership costs and network performance. Continuous process improvement, however, is not possible without successfully executing projects focused on areas of underperformance.

Successfully managing supply chain projects, such as those listed in Figure 1, does not necessarily require any special "magic" or complex software (although it does help). It does, however, require diligently following a methodical project management process.

Article Figures

[Figure 1] Examples of supply chain projectsEnlarge this image

[Figure 2] Supply chain project lifecycle methodologyEnlarge this image

[Figure 3] Team X's parts supply chain milestonesEnlarge this image

[Figure 4] Problems orbiting doomed projectsEnlarge this image

We have all witnessed projects lose focus halfway through, stall, or fail to have the desired effect. In nearly every case, the absence—or improper application—of a structured project methodology is a major reason for the failure. This is not just based on anecdotal evidence; research and studies such as PricewaterhouseCoopers' Insights and Trends: Current Programme and Project Management Practices have proved that utilizing a project management methodology leads to higher-performing projects.¹

Many methodologies are available for addressing the execution of a supply chain project. Some, such as Six Sigma, Lean, and Project Management Body of Knowledge, are in wide use, while others were developed by consulting companies for their own use.

At Expeditors' Network Solutions Group, which focuses on designing and optimizing distribution networks, global transportation-flow models, and workflow/business-process architecture projects, we have worked with hundreds of customers on supply chain projects. The experience gained through these projects led us to develop our own approach, which we call Supply Chain Project Lifecycle (Figure 2). We believe this straightforward project methodology helps supply chain managers to focus on projects that will return the most value to the organization while dispensing with those that would inevitably waste precious time and resources.

We purposely kept our methodology simple. No certification or professional project management curriculum is required to implement it. To the trained project manager, the ideas in this methodology will be familiar, and the steps themselves will seem intuitive. This simplicity, along with the methodology's flexibility, allows the process to be adapted to almost any supply chain situation and makes it easy for even the novice project manager to implement.

In this article, we briefly explain each of the Supply Chain Project Lifecycle's phases. We then provide a real-life example of how this process helped one customer cut order-to-delivery cycle times and save nearly $2 million annually. Finally, we offer a quick list of six signs that a supply chain project is in trouble.

DIAGNOSTIC OUTPUT
The diagnostic output is the starting point of any supply chain project. According to the Merriam-Webster Dictionary, a diagnosis is the "identification of the disease, illness, or problem" requiring a solution. We call the first stage of our methodology a "diagnostic output" because it involves the identification of a quantifiable problem that can be measured. This could be as simple as the chief executive officer (CEO) saying, "We need to reduce shipping costs," or it could be the result of a lengthy data-analysis process showing that express freight costs are rising 15 percent year over year.

In either case, a problem has been identified; whether it actually requires a solution will be decided in subsequent steps. The key to successful completion of this phase is to come up with quantifiable ideas that can improve supply chain performance: Are manufacturing lead times too long? Are frequent express shipments driving freight costs up? Is excessive inventory tying up much needed working capital? In all three instances, the diagnostic output is a problem that can be measured against goals or norms.

PROJECT HYPOTHESIS
The goal here is to transform the "idea" created in the previous step into a project hypothesis. Merriam-Webster defines a hypothesis as "an idea or theory that is not proven but that leads to further study or discussion." In other words, it is an idea that requires validation to prove (or disprove) its worth. Our CEO's diagnostic output—"we need to reduce shipping costs"—converts to the hypothesis "shipping costs can be reduced by 15 percent by reducing the use of express air freight." This statement identifies the desired future state, quantifies expected benefits, and gives the project focus by identifying where the project will look for savings. Limiting scope in this way is important, as it prevents the project from attempting to do too much in one effort.

The idea to be proved or disproved must be stated clearly from the start. Moreover, the idea will need to be vetted before resources are committed to its pursuit. This is a good time, therefore, to get a preliminary idea of the availability of resources for carrying out the project and to review any known constraints that may affect the hypothesis. These two factors will be explored in even greater depth and detail in the next phases of the project.

FEASIBILITY
In this phase, the objective is to validate or disprove the hypothesis and conclusively prove that the future state goals are achievable. This involves quantifying both the current state, or baseline, and the system's desired future state, as well as testing the hypothesis against already known constraints.

If the hypothesis involves an adjustment of the workflow or business process model, establishing its feasibility may be as simple as developing a few process maps showing that, for instance, collapsing steps on a noncritical path can reduce cycle time. If the hypothesis relates to a complex change, however, establishing its feasibility is likely to be a rigorous undertaking requiring many hours of analysis. For example, checking the feasibility of the hypothesis "shipping costs can be reduced by 15 percent by reducing express air freight" would require collecting and analyzing data on airfreight spend, shipment volumes, and customers' service-level expectations over time, as well as destination geo-coding, mapping, and alternate transportation flows. In this case, potentially hundreds of hours would be invested studying data to prove that costs could actually be reduced by 15 percent, and if so, what tradeoffs exist.

Either way, validating a hypothesis's feasibility is critical if you want to avoid overcommitting resources to a project that ends up being a marginal producer or cannot be implemented due to a "hard" constraint (for example, if customers paid for all express airfreight shipments in the previous year).

"GO/NO GO" DECISION POINT
At this point, the team decides whether or not the project should proceed. In fact, a project idea must "pass muster" several times before it moves into the full-blown project phase. We designed such decision points into the process because project managers need the flexibility to abandon the project early on if it does not meet certain feasibility requirements.

Many projects produce suboptimal results because no one individual—or even a large group—has the power to stop them. Subordinates are often unwilling to tell their superiors that a project should not be implemented. By designing in "gates" where the team needs to provide sufficient evidence in order to proceed, we take the burden off the project team and place it on the process itself. Failing to prove that sufficient evidence exists to continue a project does not constitute "failure," and project sponsors can refocus their energy in other areas.

DUE DILIGENCE
This is the time to discover information that will be relevant to designing a solution, such as what processes, relationships, activities, and information technology (IT) systems should be involved, as well as what their interdependencies are. In many cases it requires gathering large quantities of historical transactional data from multiple systems.

This is a much longer data-gathering exercise than in the feasibility phase. The purpose of the feasibility stage is to quantify the potential to implement a solution; the purpose of the due diligence phase, by contrast, is to explore the qualitative aspects of implementing a solution. For example, if we determined that express airfreight costs had risen substantially year-over-year, we would now engage relevant stakeholders in a root-cause analysis and seek remedies. This is also where you would evaluate the future impacts of the project as modeled and test your original assumptions. In short, you want to quantify and qualify the performance gap, and then either build additional credibility for the hypothesis or disprove it using the information you uncover. If the due diligence phase turns up information that disproves the hypothesis's feasibility, then the project should be terminated. For that reason, another "go/no go" decision point occurs after this phase.

DETAILED DESIGN
The work completed in this phase is directly related to the project's scope and the complexity of the activity being analyzed. Its aim is to identify the optimal model after evaluating several alternatives. If airfreight costs can indeed be reduced by 15 percent, what are some ways to accomplish this, and what would be the impact of each alternative on service levels?

Now that the project process has determined that the future state is feasible and you have done the extensive analysis required in the due diligence phase, you can more fully understand potential tradeoffs. This is where the term "optimal" comes into play. "Optimal" means nothing without context. Is the cheapest model the optimal one? Is it the one with the lowest inventory, or the one with the shortest lead times? Understanding the project's goal and the strategy behind it brings the notion of tradeoffs into clear focus. If the analysis was thorough, weighing the pros and cons of each candidate scenario becomes a straightforward exercise. Making the final decision about which one to adopt may not be easy, but it will at least be an informed, risk-adjusted decision that relies on facts. Naturally, an initial implementation plan with resource requirements and timing is also created at this point.

IMPLEMENT
Now the project is "put into production" based on the findings from all the previous phases. This phase requires managing the project across many functional areas. Staffing for the project typically involves engaging both stakeholders and domain experts.

This is where project plans and timing meet reality. IT interfaces are constructed across internal and external systems, measurable systems and performance metrics are established, and training for all of the people involved takes shape. Within all of these operational realities, something is bound to go wrong. Open communication between stakeholders about new realities is a key determinant of success and is therefore essential.

It's very likely that to meet budgets and deadlines, the implementation plan will have to be modified while the project is underway. While an abundance of flexibility can harm a project (for example, through "scope creep" or expanding to include too many objectives), an abundance of rigidity can produce equally poor results. New discoveries are always made while a project is in production, and the implementation plan needs to be flexible enough to adapt accordingly. Once again, when change is involved, clear communication becomes critical.

This is a good time to address any questions about whether the new model should be managed internally or by an external expert. The concern is whether the company would be better served by performing activities under the new model itself or by hiring a third party to do it. Questions to ask include: Do we have the bandwidth and the resources to manage it successfully? Do we have the necessary knowledge to ensure success? If the answer to those questions is no, then you may want to consider working with a third party.

INSTITUTIONALIZE
A company's overall business environment and corporate culture can create fierce resistance to organizational change.² Change management involves (among other things) developing the means to overcome such resistance, so that any changes that are implemented actually stick. That's why the institutionalize phase includes the development of new operating procedures, audits, and controls as well as updating workflows, responsibilities, and accountability. All of these are tools for making sure that the change resulting from the project is not just delivered but also sustained.

We also recommend adjusting compensation in a way that provides employees with an incentive to institutionalize the project's purpose. We believe such incentives ensure that change happens.

CLOSE
Project closure is not of much significance if a project has a discrete beginning and end. The problem is that few projects do. More often than not, a project does not just end; instead, it dovetails into another project. If a project is a pilot or was tested in one geographic area and will be taken to another, then the lessons learned from the initial site will be of extreme value to the next business unit where the project will be implemented. Therefore, closing a project involves two critical steps: defining "reusable content," and establishing permanent metrics for measuring success.

Putting it into practice
To illustrate the power of a project management methodology, let's consider a real-life case study from one of our clients, a worldwide industrial equipment manufacturer that we will call Team X. Team X had a situation that will be familiar to many businesses: Policies and practices had evolved over time to become the "way we do things." Moreover, Team X had taken assumptions from its well-established domestic market and carried them into the international arena.

When international customers represented a small portion of the company's sales, process inefficiencies caused by those unquestioned policies and practices were not visible. However, when growth outside North America rose to more than 50 percent of net sales, these inefficiencies became much more noticeable. Rapid international growth coupled with top executives' focus on operational efficiencies and improving inventory turns were the genesis of this study.

Like others in its peer group, Team X has two distinct fulfillment models: one for finished goods and another for service parts. This study focuses on its service-parts flow from the United States to a European distribution center (DC).

Diagnostic output and hypothesis: As shown in Figure 3, Team X's European DC sent monthly transfer orders to the U.S. distribution center, which then built the shipments. These shipments moved in multiple 40-foot containers, flowing from a southern U.S. inland rail port to a U.S. East Coast port of lading, and then by ocean to Europe. At the European discharge port, containers were offloaded and shipped to the inland European DC via barges.

This is a commonly used transportation flow, yet it was plagued with excessively long and inconsistent cycle times. The variable cycle times meant that Team X's in-transit inventory was unnecessarily high, tying up precious capital. Additionally, a high degree of variability in the fulfillment process resulted in higher safety-stock levels at all nodes in the supply chain. Recognizing this, the client engaged Expeditors to assist in designing and implementing a project that would address those problems.

After working with Team X, we hypothesized that if shipment cycle times were reduced, then in-transit inventory could be cut and working capital could be freed up. With our hypothesis established, we set out to identify root causes and quantify performance gaps. After gathering historical data and conducting interviews with process stakeholders at the DCs in the United States and Europe and the relevant third parties in both regions, we entered the "feasibility" and "due diligence" stages.

Feasibility: During this phase, we employed process analysis, workflow review, and statistical analyses to determine whether it would be feasible to reduce in-transit inventory via a reduction in shipment cycle times. We used statistical analysis to determine the baseline performance of shipment cycles. This analysis focused on the average cycle time and standard deviation in shipping times between the five shipment milestones shown in Figure 3.

Based on historical data, we determined that 24 days separated the minimum and maximum cycle times, indicating that it would indeed be feasible to reduce cycle times. Pareto analysis then told us to focus on those milestones with the greatest variability: from the U.S. DC to the loading port; from the discharge port to the European DC; and during receipt and putaway at the European DC.

Due diligence: To help us determine how Team X could improve shipment cycle times, we interviewed key stakeholders to identify existing practices and policies at both origin and destination points. The interviews revealed constraints and practices that existed outside the officially approved processes, such as sites holding extra safety-stock buffers and transfer-order procedures that did not follow approved protocols. The interviews yielded a wealth of information about process inefficiencies that directly and negatively affected cycle times.

After defining Team X's current state, we calculated an achievable cycle time based on internal process factors, such as order-approval times and receiving, processing, and putaway practices, as well as on external factors, such as transit times across multiple carriers and modes. Even though improvements clearly were necessary, a compelling business case was needed to provide an incentive for the U.S. and European DCs and the third parties to make changes. We therefore quantified the value that reducing cycle time would generate and demonstrated how overall lead time and its variability affected cash flow. Once that had been established, both the managers' and their teams' performance against specified goals became a stated component of their compensation.

Detailed solution design and implementation: The analysis determined that four actions, ranging from order creation to process accountability, were necessary to achieve comprehensive performance improvements. They included:

1. Order generation. The first action was to switch to a weekly ordering pattern. For both sites, establishing a weekly cadence leveled the flow of containers and enabled the DCs to plan their workforces appropriately. Smaller, more frequent orders reduced the number of containers per conveyance. In turn, bottlenecks at the European DC's receiving dock were reduced.

2. Container and carrier prioritization. To reduce the DC-to-loading-port lead time and improve reliability, Team X created a new policy for selecting which full containers of product to ship next. The decision was now based on two criteria: the carrier's sailing schedule and a container's first in, first out (FIFO) status in the pool. By following the new FIFO procedures, Team X ensured that full containers were no longer sitting unmonitored at the container freight station in the U.S. The new FIFO procedures ensured that containers sailed according to order precedence. This all but eliminated demurrage charges (assessed by the carrier on containers held beyond a specified number of days) in the United States.

3. New metrics. The project team also implemented new metrics that measured the end-to-end cycle time. These metrics were used to measure performance and determine compensation at each DC. They also allowed Team X to engage in benchmarking, trend analysis, and continuous process improvement.

4. Ownership of process improvements. Individuals at each DC were assigned responsibility for process performance. This ensured that the end-to-end process remained under control, and if diversions did occur, they could be efficiently corrected. More importantly, with clear responsibilities and goals, individual and team performance could be rewarded.

Institutionalize and close: The client's instincts were correct. Excessive variability in the export process unnecessarily added an extra 24 days to the order-to-delivery lead time. By cutting out these excess days, more than US$1.9 million in carrying costs were eliminated annually, demurrage charges disappeared, and personnel were freed up to focus on other tasks. The benefits of a more efficient and reliable supply chain also included reductions in safety stock at each node.

Note that in this case, the client's investment in the four actions did not require capital outlays or incremental expenses. All the workflow and policy changes were institutionalized within standard operating procedures and processes to promote adherence.

Everyone can benefit
The experienced project manager who reads this article may be thinking, "Thanks, I knew all this already." That's entirely understandable. But this article is not for you! It is for the legions of supply chain management professionals who are toiling on projects and are seeking a method for improving their project outcomes today. (If that sounds like you, then be sure to read the accompanying sidebar on six project pitfalls to avoid.)

As research has verified—and as we have repeatedly observed throughout our own years of experience—using a project management methodology definitely improves outcomes. If you are not already using a formal methodology, applying even a simple, straightforward system like the Supply Chain Project Management Lifecycle will help you solve problems and unlock your organization's full potential.

Notes:
1. PricewaterhouseCoopers, Insights and Trends: Current Programme and Project Management Practices, (2007).
2. Pascale, M. Millemann, and L. Gioja, "Changing the way we change," Harvard Business Review (November-December 1997): 126-139.