Project-Oriented Supply Chain Management in Microsoft Dynamics 365

For many project-oriented companies, the traditional supply chain model characterized by MRP (Material Requirements Planning), part masters, bills of material, routings, etc. might be downplayed as not applicable to the business. After all, the projects are typically “one-off’s”, not repetitive manufacturing, so anything beyond the project’s framework would be overkill, right?

While it’s true that many activities associated with traditional product-oriented company supply chain management are not applicable or well suited to projects, this doesn’t mean companies should adopt an either/or approach when implementing Microsoft Dynamics 365 Finance. Trying to manage exclusively within projects or within products may leave some valuable benefits of the functionality on the table, and project-oriented companies may be especially challenged managing highly complex projects manually, where utilizing standard supply chain tools can reduce or even automate a large portion of that work.

By comparing the relative strengths and weaknesses of “project mode” and “product mode”, companies may be able to adopt a hybrid or blended solution approach that provides a better overall fit than focusing predominately on one methodology over another.

To better understand the differences between the two modes, consider the illustration below that shows the main elements of project management. Note that there are a few aspects highlighted that are inherently part of the project management beast and clearly belong within the domain of “project mode”. For example, while both products and projects may involve some degree of cost estimation and comparison of plan to actual, earned value, estimate to complete and estimated (cumulative) cost at completion analysis is unique to projects. Both projects and products generally need to reflect profitability through posting of costs and revenues, but in products both are fully recognized when shipped or sold, whereas in projects more complex recognition prior to delivery is often the case.

There are, though, other aspects of project management that have similar counterparts within “product mode”. For example, change management is hardly unique to projects—whether at customer’s request or via unexpected events from suppliers and internal resources, change is clearly a way of life. The project’s work breakdown structure (WBS) represents a more interesting area of potential overlap. Consider the primary purposes of the WBS framework:

• Task identification—for deliverable goods and services, these could arguably be called products and Dynamics supports “products” that move through inventory in the traditional manner as well as non-inventory products that may be tracked and managed as a service type of product.
• Resources/tools/equipment—these are the people and equipment needed to perform a WBS task. This is clearly another area where project management can hardly claim uniqueness to this management challenge. Traditional product-oriented capacity planning generally has more than adequate capability to manage the complexities of resource and equipment planning, utilization management, etc.
• Materials—material requirements within a WBS are identical to traditional bill of material (BOM) structure within products.
• Task dependencies—this can be a bit more complex, but predecessor/successor relationships within a project’s WBS can generally be matched in product mode through a combination of BOM level hierarchy and production route operation sequences.

Looking at “product mode” shows that it, too, has a few distinct features that have no equivalents within project mode, and as previously described, quite a few that are similar to what is typical within projects. The distinctly product-oriented tools include:

• Material Requirements Planning (MRP)—this is the automated process that performs a comprehensive top-down analysis through a product structure to evaluate the supply (inventory, open orders, etc.) of material to the demand. It will create planned orders, recommend rescheduling of existing orders where applicable, and identify potentially unnecessary orders where the requirements may have changed.
• Capacity Requirements Planning (CRP)—this is a process included within the Dynamics 365 Master Planning process that follows MRP and creates a detailed production schedule for the work to be performed. Within this process there are a variety of options available for evaluating and managing the planned schedule against the availability or capacity of the people and equipment needed for the work.

While both of those may seem to be included within the WBS, the important difference is that the WBS generally only defines the requirements and relationships and is comparatively weak in terms of planning and scheduling the tasks and supporting activities. MRP/CRP, by contrast, not only plan and schedule but as will be shown, can monitor and automate much of the work.

An updated diagram of the two modes is shown below, with distinctly project mode elements in green and distinctly product mode elements in blue.

Let’s now explore a potential approach to managing the delivery of a relatively simple project deliverable using a hybrid approach involving both “project mode” and “product mode” to illustrate the potential advantages of using each module’s strengths over the others. Under this approach:

• Project module WBS includes only the end item deliverable(s) and the indirect activities necessary to support them. Indirect activities in this context would not be indirect production activity such as material handling or supervision, but instead are project indirect activities such as project management, engineering/design, etc.
• Materials, resources, etc. needed to produce or support the production of the end item deliverable(s) are tracked and managed exclusively within “product mode”. For example, raw materials needed for the project should not be ordered from within “project mode” even if they are exclusively for the project. They should be planned, managed and transacted through “product mode” and will ultimately fold into the project upon completion or delivery.

We will illustrate this separation through a very simple project/product example. The project involves a single deliverable CS-Top. That deliverable will consist of a single manufactured component or subassembly CS-SA01, which in turn is produced from a single purchased material CS-RAW. Before we can begin building anything, though, we need to spend an estimated 10 weeks on the design, obtaining permits, etc.

The project WBS will consist of two branches—the deliverable/item requirement, and the design. Given that the design is expected to span 10 weeks, breaking that down into smaller trackable tasks would be appropriate, but will be ignored for this review in order to focus on the deliverable branch and “product mode”.

The WBS is shown below, with design expected to be completed by 7/27. The deliverable is showing shipment of 7/30, and this introduces some of the complexity of trying to “schedule” production within the WBS. The WBS reflects an assumption of 3 days’ cycle time or 24 hours effort, but that doesn’t drill down to the lower levels, multiple workcenters that might be involved, etc. Is this an accurate plan? That’s a very complicated question even in this very simple example:

• We initially have virtually no information on how long it takes to manufacture the CS-SA01 or CS-Top other than whatever quasi-random number were used in our always-nearly-perfect quotation process, and our business levels and backlogs have certainly not changed since we offered that quotation, right?
• There’s clearly a leadtime to purchase the material, so a need to order before the start of production. This means that some portion of the engineering/design scope that isn’t scheduled to complete 7/27 needs to be prioritized to happen early in the effort, so that at least a token part and BOM structure will be created, with properly vetted engineering review to ensure that the quantity, specifications, etc. are appropriate versus any rough estimates or assumptions that might have been used in the quotation process.
• Production clearly has two different things to manage—the CS-SA01 predecessor/component and the CS-Top deliverable. Those also need to be separately prioritized within the design process, scheduled separately within the shop floor, with sufficient leadtimes through whatever manufacturing steps are involved to produce them.

This could theoretically be managed within the WBS using another level, more detailed tasks and items, predecessor/successor relationships, etc., but now even in this simple example we’ve described at least 6-8 related tasks that must all be coordinated, and any unexpected change to one of them will impact the others. How realistic is it to count on the initial WBS schedule, driven by quotation and initial estimates, will be stable through delivery? The project manager will be hopelessly overloaded having to constantly override individual WBS tasks and activities trying to realign schedules.

Now let’s look at the view from within “product mode”, starting with that product requirement that’s showing on the WBS as due 7/28. Without having to fully engineer the deliverable and full structure, one of the first design/engineering steps would be to create the basic tracking framework, consisting of part numbers, BOM hierarchy and rough leadtimes. In this example, the CS-Top is estimated with 2 days production time, the CS-SA01 another 3 days, and 2 weeks for the material. In order to deliver 7/28 (admittedly still unrealistic if we’re still engineering through 7/27), when do we need to place the order for the material, and when do we tell the supplier it’s needed? When do we have to complete all engineering for the CS-SA01 and CS-Top for their respective production start dates? Go ahead and do the math in your head or in the WBS. After all, this is an extremely simple example 😉. While you’re doing that, I’ll hop over into “product mode” to see what the MRP plan has to offer:

MRP has taken care of the math and relationship tracking between the three parts/levels and determined that we need to place the material PO no later than 7/14 for arrival by 7/24, followed by production wrapping up by our committed 7/30 delivery date.

The buyer has a clear workbench to follow on a daily basis:

While that’s just one small and simple branch, the other related activities can also be tracked and identified through the automated scheduling support within MRP. One major difference that immediately jumps out versus the WBS is that we now have very detailed start/finish dates for each part, order etc. rather than trying to manipulate WBS activity durations. We can even view those orders, dates and relationships in Gantt view if that’s more comfortable to a project manager than MRP-like details 😊:

Now to illustrate one more benefit to letting the supply chain “product mode” manage the details supporting the deliverable, let’s imagine that the supplier has contacted us with an update to the purchase order delivery. It’s probably never happened in your business, but let’s hypothetically imagine that instead of getting the material on 7/24 we find that it won’t arrive until 8/5. The chain reaction would involve looking into the production order for CS-SA01 that needs it, the higher level assembly using the CS-SA01, and the resulting impact to project deliverable date. Go ahead and rework your WBS, I’ll wait 😉. In the meantime, I’ll take a quick look at what happens within MRP. We can configure the auto-pilot to operate several different ways, and in this demonstration we’ve configured it to treat revised PO deliveries as the new/current reality and replan production around that. With an updated PO dock date of 8/5, we now see:

Having only entered a PO update, the production schedule for both the CS-SA01 and the CS-Top have been replanned, and it has even thrown an exception/update on the delivery order indicating that it’s currently tracking to 8/11 despite the 7/30 promise date.

This isn’t a condemnation of using project management functionality or WBS, but is merely showing that it’s possible to use a combination of both “project mode” and “product mode” to provide much more robust support for managing the complex network of materials, labor and coordinated activities needed to support the project’s end deliverables. By using “project mode” to focus on the deliverables themselves and the project management supporting activities and delegating management of the requirements supporting the deliverable to “product mode” supply chain functionality, even for “one-off” projects the challenges of detecting and reacting to changes to plans, schedules or assumptions can be much managed using standard tools instead of relying on project managers constantly trying to maintain a reliable WBS.

This paper’s objective is to introduce the concept of the hybrid mode. Future papers will focus on specific topics within the supply chain process to provide more details on the how-to’s that support operating in this hybrid mode.