Deliverables-Driven Scheduling

We’ve been exploring different aspects of PLM process management. From a high level look at product development process management, to more focused conversations on product change management and change management processes. My colleague, Mark Homrich, will continue this discussion as a guest blogger, focusing on program and project management.

With the rise of more dynamic product development environments, I’ve noticed companies moving toward deliverables-driven scheduling. In the past, we’ve looked at project management in dynamic environments, as well as executing tasks with enterprise project management. In those blogs I discussed the prioritization and execution of project tasks in dynamic environments.Organizations that function in dynamic environments:

• • Operate in highly competitive markets

• • Build and maintain market share via regular new product introduction

• • Must respond to rapidly evolving requirements

• • Optimize their product portfolio via product platforms that can be leveraged for individual customers or markets

• • Are constrained by time, money and skilled resources

Because these organizations deal with lots of uncertainty, there must be a balanced approach with respect to planning and execution by giving all team members:

• • Visibility into the overall schedule, especially project and program milestones

• • Visibility to all tasks to which they are assigned as soon as that information is available, even if it is highly probable the task dates may change

• • Visibility into upstream and downstream task dependencies so they can see who/what they will be waiting on and who/what will be waiting on them

• • The ability to prioritize and sequence (but not schedule) tasks

• • Efficient mechanisms by which they can communicate to the project manager / schedule coordinator forecasted start or finish dates for the tasks

• • Efficient mechanisms by which the project managers / schedule coordinators can either accept or reject the forecasted dates and efficiently communicate their decisions back to the team members

The uncertainty issues impact not only team members’ abilities to efficiently execute tasks, but uncertainty also, of course, impacts coordinators’ abilities to effectively identify the tasks that the team members need to work on.

I have recently spent time with several of our larger customers who have very dynamic product development environments. They deliver high quality, market leading products, often comprised of a variety of technologies, in very competitive markets across the globe. New products and product extensions are introduced on regular cycles, and whether their cycle is every few months or every few years, they perform some level of upfront planning but also realize they cannot predict all of the tasks and deliverables that will be required to successfully deliver the product to market (or deliver the product to whatever is the downstream “customer”, such as another development team, their manufacturing operations, an OEM, an end consumer, etc).

These organizations are adapting their planning techniques by integrating their project management processes with their PLM processes and deliverables.They still perform some level of planning, but these plans tend to focus on the areas of certainty, e.g. program-level milestones that ensure the various program work streams are aligned with respect to critical dates dictated by their internal governance process or by the customer. Typically, these dates are critical gate reviews with executive management and integrated virtual and physical product build events.

Within the context of these program milestones, the detailed schedules are formed and this is where the level of uncertainty increases.Rather than trying to define and schedule all of the tasks and deliverables required for a gate or build event, they conduct initial cross-functional planning sessions to identify as many of the required deliverables as possible.They complete these sessions with an understanding and acceptance that not everything is known.The deliverables are then organized into discrete work packages, such as change orders (or change requests or change notices), program deliverables, or, in some cases, sub-assemblies, components or individual piece parts.

In deliverables-driven scheduling, what they do next is, rather than creating a massive schedule and then assigning the work packages to tasks, whereby a given schedule may have many hundreds or thousands of tasks driving work across a very large number of various deliverables, they let the work package drive the definition of the schedules.Thus, they have one work package (which may be a single part) that drives the creation of one schedule with a small number of tasks and each task in that schedule is only for that work package.This results in a large number of schedules with a smaller number of tasks.

Whereas this could be a very labor intensive process, they use Teamcenter to automate the creation of these schedules based on business rules.Also, because the schedules are very discrete, it is easy to adjust the schedule through additional automations.

The benefit of the deliverables-driven scheduling approach is that as new deliverables (e.g. work products) are identified, they can quickly create the requisite discrete schedule, integrate that schedule into the program plan, create dependencies and start on the new work without having to replan a large monolithic program or project schedule.

Therefore, as time progresses, the uncertainty of what must be worked on the near-term is quickly reduced while at the same time they can make the appropriate business decisions related to cost, timing and scope.For example, because of the deliverables-orientation, it is easy for them to quickly balance project scope by simply deferring a deliverable to a later gate or build event or by removing the deliverable (and its dependent deliverables) from the project all together; when the deliverable is moved or removed, the schedule is moved or removed as well.These customers find it more natural to understand how the project is performing by viewing the status of deliverables as opposed to the status of tasks and schedules.They drill into schedule and task status only when they are concerned about the release status of the deliverable vis-à-vis the gate or build event.

These customers are using Teamcenter in very smart ways, including leveraging it for deliverables-driven scheduling. If you would like to learn more, please let me know.

About the Author:

Mark Homrich is responsible for the Teamcenter applications product management team, covering program planning, schedule manager, portfolio manager, change management, workflow and more. He is responsible for defining the vision of these applications and ensuring they meet the strategic needs of Siemens customers.