How to Use Requirements to Improve Schedule Performance

This article discusses the difference between Parallel and Serial development methods.

Why use requirements documents? We always knew that it was good practice, but what exactly are the benefits? Then I moved from a company that used formal requirements on a daily basis to a company that was successful without any conventional requirements management whatsoever, and discovered that there are developments that formal requirements documents really speed up (like 4X faster, or more), and developments that are far better off without formal requirements. The difference between the two, and when to use which, is explained below.

These are the most important reasons for developing Requirements documents prior to starting the design:

1) Development of Solid Requirements is a Good General Work Habit

The act of defining requirements can uncover conflicts and/or simplify difficult aspects of a design.

2) Requirements Provide a Formal Method of Defining and Verifying the Work to Be Done

Verification of all the “Shalls” provides exit criteria and a method for grading performance, contractual or otherwise.

3) Requirements Management Can Drastically Improve Actual Schedule Performance

WHAT????You're kidding, right????? How can wasting critical time arguing over requirement details SAVE time? There is stuff to be done!!!!

There are two very different ways of developing anything, Parallel and Serial. I have worked with both types. They have different schedule performance, costs, management structures, and requirements methods. Everything you plan combines these methods.

The Parallel method can be much, much faster. It results in better integrated, more reusable and more robust products. However, the Parallel method costs more than the Serial method, and requires more training and method development. It also depends heavily on high quality requirement documents, something not everyone is good at creating.

Below are descriptions of the same single board computer, performed using serial and parallel development methods, for comparison.

The Serial Development Method

Below is a typical Serial Project Plan for a single board computer. Each task is performed in sequence. Then the work is handed off to the next lead, who may not have known anything about the project before receiving it. Each task is completed before next functional department is involved. The output of each task becomes the requirements input for the next task. Electrical turns it over to CAD (Mechanical Design), who turns out a Bill of Materials to be purchased (Materials), etc.

Critical path tasks are shown as red. Note that, in a serial development, all tasks end up being in the critical path. The only task in parallel below is the development of the production test equipment and the production material procurement, although I have seen instances where the production test capability was not started until the production hardware arrived. This would make the schedule below even longer.

What is not shown above are the gaps that are usually found between tasks. Once you have a package complete, you need to provide it to the next in line to continue development. Theoretically, these gaps can be minimized by preparing the following group, so it is ready to start when the tasks arrives. Unfortunately, for those using this method, there is usually little trust that the package will show up when promised. It is typical for functional groups to have done little preparation before receiving the package - who knows what will be in it? If you are using subcontracted elements, there will need to be time for the package to be quoted, bids evaluated, and accepted. Considering the gaps between tasks that will surely occur, and the number of critical path items, the schedule above is very optimistic.

Advantages of Serial Design

1. No formal requirements document is necessary. For these developments, requirements documents are basically guidelines. Each designer gets his actual requirements from previous step in the development process.

   1. • The CAD requirements are contained in the schematic.

      • The material requirements are contained in the Bill of Materials (BOM), when the electrical design is finalized.

      • The Software requirements are defined by the completed hardware when it appears.

      • The production test requirements are defined when the product finishes integration.

Each task takes it's requirements from the previous result, and an overall management input at the initiation of the task.

2. Serial design project management can be primitive or nonexistent. When the schematic is ready, you call the CAD guy. When the assembly package is complete, you order parts. Little planning required here. When a person becomes available, work starts. Manpower planning is moved to the next management level up.

3. The design can morph easily if conditions change during development. Only one functional group is affected.

4. There are few battles between departments. The package is completed, and the next group works with it. Those receiving a package will bid exactly what they get, which they cannot possibly bid before they receive an actual package. See 3) below.

5. This is very suitable to outsourcing, in that each stage can theoretically bid by an independent vendor. The best choice can then be selected in a clear and concise manner.

6. Funding expenditures can be easily controlled. Work can be stopped, restarted, moved to another division. And very little money is wasted by other groups if an approach by a functional group does not work out. Only the group doing the work is affected by any change.

The Earned Value Schedule Variance method is useful for this type of development. Not true for parallel development, as shown below.

Disadvantages of Serial Design

1. Developments can be quite lengthy, especially when gaps are added between tasks.

2. Since the development is lengthy, there is a much greater possibility that product need or top level requirements will shift during development, making the product less desirable or obsolete. I have seen serial developments so long that many components are no longer being manufactured by the time production is ready to start.

3. Since there is no interaction between design elements, there is little feedback on whether the design is easy or hard to for the next stage. This is left completely to the previous stage designer. There is a possibility that a stage could reject an input as being beyond scope or ability of the stage, and the project stalls completely.

4. Innovative synergy is difficult, if not impossible. Solutions will not be integrated for optimal size, weight, cost, etc.

5. If recursion is necessary due to integration or design issues, the design can really stretch out.

This design method emphasizes the efficiency of the individual designer, and has minimal overhead. So to an individual, it appears extremely efficient. But the schedule performance is ghastly, and the product will not be optimal.

Planning Methods - I have shown these as Gantt charts for comparison, but Gantt charts are not the best way to show a serial process. Visio has an excellent tool for this, an example is here: Visio Timelines.

The Parallel Development Method

Now, examine a parallel development below for the same development as above.

For comparison, the task durations below are the same as the Serial Method shown above, with the exception of:

• • The Requirements task has been increased to 3 weeks

  • An Integration task (8) has been added

Holding everything up to write a spec should slow everything down, right? Nope.

Examine the chaining shown. Each functional element starts when the requirements document is completed.

Even with a longer requirements time span and the additional task of integration, the development for this project has been cut roughly in half. So even if this schedule is missed by months, it is still way ahead of the serial method. And there are many tasks that are not red, meaning that there is slack in those tasks, so staffing timing is not as critical. Small changes in staffing availability do not affect the schedule the way that they would in a serial design. This plan has much less schedule risk, especially considering the typical gap between serial tasks. So in real life, the schedule performance would likely be way better than a factor of two.

Note that engineering wise, the level of effort has not really changed much. The same amount of hours, of people doing the same things, with the exception of the requirements document generation and tracking. This is why this method is so sought after. The hub of the approach is useful requirement documents. They must be high quality, and taken seriously. Reviews are important too. More on this elsewhere.

I know from experience that this does work. I have lead 20 week developments three times that all had new circuit cards, enclosures, user manuals, software and certification, all developed in parallel. Totally new products through sell off and into production in less than five months. And it wasn't just our group. A buddy of mine, in the space group, was launching custom space probes exactly one year after receipt of order, over and over. New products available years before our competitors.

What is counter intuitive to the individual designer is that while s/he is slowed down by the parallel method, the overall product development is drastically improved, since many more people can work in parallel.

This is not executed by single a person. It is a learned activity by an organization, and improves with practice. All participating departments to work in this manner to achieve this sort of performance.

So how do you start work before the "preceding" task is complete? Some examples:

• Since the requirements are set, development of functional verification procedures can start, even be completed. All that is needed is the requirements. Special equipment can even be built or ordered based on the requirements doc. The functional requirement test can be waiting for the test product.

• As soon as the arbitrary requirements are fixed (usually on the schematic or construction drawings), the production test equipment can start.

• Software can begin work on the applications, and the low level software interface can begin using breadboards or similar hardware. This requires modularization, but that is what it is for.

• CAD can begin layout studies for the tough parts to layout, and maybe even change techniques or PWB vendors or buy software packages to cope with new parts or techniques.

• Items with lead time risk can be identified and procurement begun.

  • This is usually known as identification of "Long Lead", and presented at the Preliminary (30%) Design Review. Approval of Long Lead procurement is one of the formal outcomes of a Preliminary Design Review.

• Operations can work up new processes to handle the changes coming. Even build new capability.

This method introduces a management challenge, not found in the serial method: Electrical Engineering may pick a part that Software and Test like, but CAD and Operations do not. This creates a leadership issue that would not occur using the serial method. With the serial method, each function can only work with what it is provided.

Advantages of Parallel Design

1. Development can be much, much faster. And it is scalable. Large developments can be completed by integrating subsystems in parallel.

2. Many problems can be avoided entirely with an interactive approach

   • Design and Verification can identify difficulties in requirements, yielding both better requirements and verification. Expect early arguments about what the requirements actually mean.

   • CAD and Design for Manufacturing can optimize implementations to ease each others lives.

   • Software and Electrical trade off functions to move out to microcontrollers or gate arrays to improve product performance.

3. Since development is much faster, Market/Company needs are less likely to change during development

4. Task Breakout allows hand-off to wider range of contributors

5. Product updates are cleaner and more compact, since the structure of interactions are defined.

6. Product is first to market. Since it provides value sooner, you should get more design wins, and have a lower cost of money.

As a note, the Earned Value Schedule Variance method is not useful for this type of development.

Disadvantages of Parallel Design

1. It is harder. This is a process that is learned and practiced by an organization. Each functional group needs to work out what it will need in the requirements document. If a functional group wants to wait until everyone else is done to minimize their exposure/budget, then they just don't get it.

   • For example, a method is needed to enable long lead components to be identified, authorized, and ordered. Your MRP system may not have a method to order material that is not tied to a complete Bill of Materials.

2. More expensive Engineering Cost

   • Generation of Requirements Document (1 man week from all designers)

   • Project Management Planning Function (tax of 10% of all engineering activities)

   • Organization must learn a new skill (Capital cost)

3. Difficult to take advantage of discoveries along the way to incorporate value into the product. Changing the direction of three or four parallel efforts is more difficult than changing the direction of one.

4. Design approach seems backwards to designers

   • Designers like to design from the inside out. When I finish the design, I will tell you the interfaces you get.

   • The Parallel method defines the interfaces first, which requires designing from the outside in!

5. This method may outrun the customer. Since many decisions are made in parallel, sheer volume of decisions being made up front may be more than you or your customers organization can handle. Our customers had to double their support staff during the requirements phase using the parallel method, due to the issues pushed out - but got their designs completed much, much faster. They liked that.

General Theory of Parallel Design

• Develop complete requirements at the start of the job

  • Assign responsibility for each of the requirements

    • Requirements that are needed to meet the schedule are defined by the organizations prior to specification development.

  • Adhere to the requirements to completion

    • The Requirements documents become contracts between individuals. Making a change after release will disrupt someone else's activity, and must be tracked rigorously.

• Identify Risks and Work Them Off Prior to Design Implementation

  • This Technique is Developed, Learned and Practiced, Not Just “Done". Each Discipline Has to Develop Methods to Integrate With the Overall Development.

OOPS File - What is it, and when should it be used?

After a Parallel specification is released, there will be specification errors that will be discovered. Some of these will require an in-process change (ouch), but many of them will not be as urgent, or will not be worth the cost of implementing them right away. These changes need to be saved for the next update, when they can be rolled in to improve the product without impacting the current development effort.

We called the file for these the OOPS file - Obvious Oversights for Production Straightening-out. Redundant interfaces, round the horn accesses, unnecessary pauses, hardware inserted from wrong side, etc. Usually the corrective action was pretty straight forward.

In the Serial Process, no one is impacted if you stop and implement changes in the middle, so no OOPS file. However, in the parallel process, you are constantly evaluating whether the changes you are anticipating will wreck everyone else's approach, and some improvements cost more overall than they are worth in the version under development. So in the Parallel process, you will need a folder like this, to pick up the improvements that will be implemented on the next go around. In a serial process, you just stop in the middle, then restart with a new direction. Again, schedule is not most critical when using the serial method. Or else you wouldn't be using it.

In general, you should be able to do two parallel developments in the same time as a single serial development. This means your second generation product will be up against your competitors first generation product. Maybe even available before it.

When should I use Parallel Development, and when should I use Serial Development?

Serial Method is used :

• To keep engineering costs to a minimum

• In a resource constrained environment (only one packaging engineer, only one person with clearance, only one license, etc).

• When funding is per set period

• Generally used for Standard Products

• When Schedule is Flexible, and not critical to success

Parallel Method is used:

• When schedule is more important than engineering costs, or when hard deadlines are present (Christmas, Harvest, Hunting Season, etc.).

  • When Resources are freely and immediately available.

• When Funding is milestone based. The earlier the milestone (or the product introduction), the sooner we get paid.

• Generally used for custom developments.

As a note, you should be aware that the Serial or Parallel method can be almost a religion to those experienced with one or the other. Having seen one method work, a developer will likely assume the other method doesn't. Ever. So be prepared to deal with those view the Parallel requirements development phase as a waste of time, and those who refuse to get involved at all without development of complete Parallel quality requirements.

A way to really waste money is to insist on parallel quality requirements document, then implement a serial design flow. Or you can try to do parallel development with inadequate requirements documents. Don't do either of these. You will not be happy in your work.

Summary

The Serial/Parallel choice directly affects the purpose, and as such the content, of any requirements documents.

If you are using the Serial process, then then requirements documents are really just high level guidelines. The real requirements documents are the hand off documentation between the functional efforts. E.g., your construction manager won't even look at a drawing until the PE has signed them all off. So in the serial process, the hand off documents are king, be ruthless to get them complete.

For parallel development, you need a rock solid requirements development discipline, so everyone can go off and start work at the same time. If all groups do not participate in the review and release of the Requirements Document, do not expect to achieve much of a schedule improvement.

Most projects are combinations of serial and parallel developments. As with any tool, it is best to use it where it is appropriate. Some things are better done serially, and some done using the parallel process. Pick the right tool for the job.