Structnet "Structured Scheduling"

This paper focuses on planning-scheduling techniques used in design and development of systems in the manufacturing industry. The construction industry can use these techniques as well. Yet there are differences that will be addressed separately. This is written based on using MS Project 2013 Professional since it is the most common scheduling software used.

Structnet's System: Structnet's system of "Structured Scheduling" is more methodology than any particular software used. We have tested project schedules with MS Project, Primavera P6 & Deltek Open Plan with great results. When developing the Product Breakdown Structure (PBS) it can be effectively accomplished on a white board with sticky notes. We may recommend certain software be used; yet we are not in the business of selling software.

Structnet looked at the scheduling process from the perspective of an architect. We want the building to be efficient, effective & a pleasing place to work. Work areas, management offices, conference rooms, utilities have to be planed & organized so that all workers are treated with respect to their needs. This provides the company a work place in harmony. The Structured Scheduling framework provides our customers a harmonious scheduling workspace.

Our first goal was to develop project schedules that are consistent, repeatable & reusable.

Consistent: The Structured schedule is consistent for every product at the Summery Level Planning Package (SLPP) level in the schedule. This provides an immensely efficient program to all of the stake holders. Consistency provides all stake holders ease of working their data within the schedule. This also makes it easy for managers to function from project to project. As schedules are created in the same manner people don't spend energy learning how their work fits within it.

Repeatable: In order for a process to be repeatable; it must be consistent. Structured Schedules are built with consistent repeatable logic.

Reusable: Collect data from a similar product & system from a previous schedule. Tailor or scaling the data to fit the new design. Utilizing a library of system, components & or products will pay dividends to your company. You will have confidence based on previous experience. The consistent logic built into the Structured Schedule framework makes this feasible and efficient.

Product based schedule: The Structnet Structured Schedule is product based meeting the requirements of MIL-HDBK 881C. The Product Breakdown System (PBS) & Schedule Framework is assembled just as the system will be assembled, integrated & tested. This provides many advantages. All products include the same tasks & milestones in a consistent logical order.  All products are linked vertically from parent to child & child to parent for all Work Breakdown System (WBS) levels in the program. All products tasks & milestones are straight forward to trace. Working the critical path that follows the logic of design, assembly to delivery is wonderful. Team members will have confidence with the understanding no process or milestone will be missed.

This design makes the job of schedulers, Integrated Product Team Lead (IPTL), Control Account Managers (CAM) easily work with our schedule, no matter where their job begins & ends within a schedule. Once they understand the Structured Schedule; they will know their place regarding the products they are involved with. Training to work with the Structured Schedule is consistent in all products milestones & tasks. Gone is the frustration of understanding how scheduler A, B, or C build their schedule.

When your scheduler receives our Structured Schedule framework they will fill in the SLPP tasks with duration and resources. Instead of spending time creating a schedule they will query previous job data & engineering teams for the right values of control account data. This gets your company a proposal faster and more accurate than ever before. Based on our consistent logic, management will have an easy time reading the schedule and deriving confidence in it.

Parent/Child relationship: The vertical links define the Parent/Child relationship and the Governance in the schedule which is a key function of the Structured Schedules' ability to track change properly. This is also the most difficult part of creating the schedule framework manually. When we combine product based schedule with the parent-child relationship we achieve a schedule with immense power. Earned value & Monti Carlo calculations are complete, reliable and accurate. Every product in the schedule will properly reflect changes everywhere in the schedule at all levels of the PBS. If all durations are equal in a schedule without constraints, the longest duration path will go through the terminal (lowest) element of the schedule.

Structnet urges its customers to develop a graphically enhanced Product Breakdown Structure. We use and recommend Mind Manager. It makes quick work of building & organizing network charts and it is easy to learn & use. You can use a white board with sticky notes to build the PBS. Mind Manager is an efficient way of organizing your thoughts. The addition of images in the PBS is an important part of the process. This makes it so easy for all persons working with the PBS to understand the order of assembly. The PBS becomes the index to the schedule. This index will assure all persons working with the schedule will find their place & reduce frustration.

Figure 1: Bicycle PBS example

All of these ideas sum up to your employees being more efficient when working with a Structured Schedule. Team training takes little time and is important to effectively use Structured Scheduling. Our consistent scheduling logic makes it simple to read and function all parts of the schedule. Structnet will improve your scheduler's ability to deliver programs on time and within budget.

Structnet is capable of providing Structured Schedule framework in a short period of time; days not weeks. Our pricing is based upon the number of products in the schedule. Our bicycle example of 30 products is a small cost & time budget compared to scheduler hours. Ease of working with a Structured Schedule; priceless. With such a low cost and quick cycle time, you're going to love our service.

 Swim Lane: I would like to convey the ideas of efficiency regarding CAM & IPTTL being able to see their product from stem to stern.

Figure 2: Bicycle PBS example with schedule below in pert format.

Here you can see how well organized the Structured Schedule framework is. The columns from left to right are: Product label, Requirements & Architecture, Preliminary Design, PDR, Detail Design, CDR, Assembly, Integration, Test & Ship, and Closeout.

The mantra is "Plan the Product, and Schedule the Process". "Plan the Product" refers to building the Product Breakdown Structure the way the System will be assembled.   Schedule the process means to create a schedule of tasks necessary to add value to a set of requirements to design and produce a system or product.

Scheduling: The Life-cycle of product development we call process.  At the Summary Level Planning Package level, the system and each underlying product follows the same processes steps from Authorization to Proceed and Requirements Definition, through Preliminary Design Review (PDR) and Critical Design Review (CDR) during the design process, and Fabrication, Assembly, Integration, Test, and Ship to produce the product and deliver it to the next higher level of assembly.  The process model that we use as a starting point, contains 41 discrete tasks and milestones at the Summary Level Planning Package level. This number can change to fit the process development system at the Enterprise or program level.  We strongly suggest that an attempt be made to establish and maintain a process model at the Enterprise level that can be duplicated at the program level.  This makes historical data easier to catalog and reuse for future programs promoting continuous improvement. The schedule hierarchy matches the PBS exactly, so that the governance hierarchy established in the PBS carries through to the schedule and its vertical integration. 

One or more control accounts exist under each discrete Summary Level Planning Package task.  This provides the detail needed to guide the Control Account Managers (CAM).  Each Summary Level Planning Package task is clearly defined and has an input and an output definition.  For example, requirements definition and its subsequent review starts with an Authorization to Proceed (ATP) and the requirements furnished by the parent.  The requirements definition task ends when they are ready for review.  The completion of the requirements review allows the product's IPTL to define the lower level architecture and pass the requirements to the product's children.  The control account detail, developed by the CAMs contains all of the work packages and the underlying tasks needed to complete this portion of the Summary Level Planning Package task. These control accounts when completed and verified, are the detail and lessons learned that are catalogued and stored for use by future programs. 

Requirements flow down from the system level to the lower level assemblies and products, follows the same vertical integration hierarchy from parent to child as the requirements are decomposed to the lower level products. 

The mantra is "Plan the Product and Schedule the Process". This short phrase defines Structured Scheduling.  It refers to establishing the PBS first, clearly identifying the assembly sequence for the drawing tree during the design process, and the Governance hierarchy for design and manufacture of the system. 

Governance: (Product Breakdown Structure) (Product)

Planning: Program and System Governance is addressed by establishing one clear Product Breakdown Structure (PBS), organized the way the system and its underlying products and components are to be assembled. Clearly establishing the program and system hierarchy defines the Governance hierarchy.   This pattern of parent/child relationships, defines the vertical integration, and is maintained throughout the program life-cycle.