Cornell University Unit Name

• 4. 1. Design Reviews
• 4. 2. Prototyping
• 4. 3. Documenting Results
• 3. 4. Formulating Project Timelines

Keeping Research & Design on Track

4. 1. DESIGN REVIEWS

Research and design can be an engaging and fruitful process for student project teams, but without appropriate guidelines and structure, the design process can quickly spiral out of control, threatening successful completion of the project. Below is a three-stage framework for structuring design that makes the research and design phase more efficient and results-oriented.

An appropriate design strategy helps by adding structure to an otherwise potentially chaotic process. It is helpful to think of research and design in three distinct phases: preliminary, secondary, and final. As a student project team moves through these phases, design activity becomes more specific, more formalized, and more integrated at a systems level. In general, these phases should be given reasonably equal priority and time.

Preliminary Phase of Design

Early design should be seen as a loosely structured examination of a variety of concepts and ideas. The process should involve attention to previous practice or any previous years’ design history, but team leaders and faculty advisors should encourage new and untried ideas as well.

The preliminary design phase can be plagued by both excessively broad and excessively limited scope.

• Too Broad:
  Imagination and creativity are generally progressive and necessary forces in a student project team, but they can stand in the way of progress if left unbridled and unchecked. Excessive attention to discovering new solutions can lead to no solution at all.
• Too Limited:
  Conversely, it is very easy to arrive at conclusions and solutions too quickly, without considering enough alternative options. Sometimes teams depend too much on previous designs, and can get locked into proven but perhaps not optimal solutions.

This is also a good time to think about potential system-level interactions among subsystems or component designs to ensure that proposed designs will be compatible with one another. Radical designs with potentially profound systems interaction issues should not be shelved but rather discussed with full presentation and discussion of potential interactions so that other designers can react accordingly and strategies so that for dealing with these interactions can be fleshed out.

Common inspirations for preliminary design ideas include:

• Brainstorming alternatives
• Researching applicable rules and regulations
• Competitive intelligence and benchmarking
• Researching previous team practices and designs
• Leveraging applicable external research
• Outlining potential systems interactions
• Outlining potential external constraints (e.g., weight, cost, complexity)

The end deliverable of preliminary design should be a limited but still open-ended outline of several alternative designs that can be shared among team members for comment, discussion, and debate.

Secondary/Intermediate Phase of Design

Moving from preliminary to secondary design, designers should consider the challenges and opportunities offered in proposed ideas and begin to focus on those options that show the most merit and promise overall.

This can be a difficult process, particularly if it means shelving interesting or radical ideas. Team leaders should be careful that all ideas are given equal and fair treatment and that the process of reducing complexity amongst options is reasonable, open, and based on objective analysis.

Considerations that can be used to reduce complexity include:

• Performance:
  Will a particular design produce what is expected of the part/system? Does it exceed this expectation? Is this excess justifiable or beneficial or simply excessive?
• Complexity:
  Is it simple to design and realize, or is it a considerable challenge? Can it be simplified without sacrificing performance or sophistication? Will the complexity of design affect its later realization?
• Resources:
  Does the team have the money and human resources to realize the idea? If not, can resources be found or acquired to realize it?
• Systems integration:
  Does a particular design greatly affect other designs in the whole system? Have these interactions been investigated? Have reasonable compromises been considered and outlined?

By the end of the intermediary phase, designers should be leading towards a final design solution based on weighing these and other competing factors. Alternative designs may still have weight but mostly as fallback solutions should continued investigation and discussion prove that the ideal solution is unfeasible.

Final Phase of Design

By the end of this phase, designs should be locked down in preparation for their realization or manufacture. This provides a formal conclusion to design activities and allows the team to shift from design and research to creating a working prototype. Creating and testing the prototype will likely yield new challenges to the design, but these are best dealt with in the context of the development and testing phases.

By the end of the design phase, designs should be:

• Formalized:
  All drawings, architectures, specifications, etc. should be locked down and be satisfactory to meeting performance requirements.
• Realizable:
  The design should be able to be developed and created without over-taxing human or financial resources. Any outside support required should have been identified. Realizing the design should be able to begin immediately.
• Integrated:
  Any systems integration issues should be formalized and accounted for in development and testing plans in future phases.

Doing this perfectly is a tall order for experienced professional work groups, and it is even more challenging for student project teams. Many "final" designs will be revisited based on feedback from development and testing as a result.

4. 2. PROTOTYPING

A prototype offers a decent approximation of the final product that can visually clarify apparent manufacturing, packaging, and aesthetic issues. Even well-reasoned design processes benefit from a tangible, if incomplete, prototype. As design nears a close, it’s often possible and advisable to create a mockup of the system being developed. Doing so is a great way of transitioning from design to realization and can help discover unforeseen obstacles, hidden in the abstract 2-D versions.

Examples of Prototypes as a Learning Technique

During abstract design, one can avoid and eliminate obvious errors but in complex systems it is usually a small, unapparent detail that can compromise system integrity. For example, mistakes are very difficult to discover when looking at pages of code or a printed circuit board design specification. Simply put, it’s hard to visualize what a particular circuit or piece of code will do until it’s put into action. Once a prototype is created, problems are often much more obvious. Successive prototypes can solve these problems and are themselves tested for validity. This iterative cycle of development helps make the design and realization of a complex system that much easier to grasp.

Physical systems can also benefit greatly from simple 3-D mockups of current design ideas. Both Formula SAE and Mini Baja create prototypes of the frame before manufacturing the car itself. These mockups are fabricated from wood, and known dimensions and locations of parts are mocked up using foam, spare parts, and other available placeholders.

The frame mockups accomplish four goals:

• Making systems conflicts tangible:
  It is often difficult to conceptualize system integration and interdependency issues in the abstract, especially with mechanical systems. A mockup makes potential integration issues obvious and spurs new designs to resolve those problems.
• Catching problems before it’s too late:
  Unlike software development, fixing problems after the fact in mechanical systems can be significantly more complex. FSAE can attest from experience that ripping out pieces of wood or foam from a mockup is much easier than ripping out pieces of steel or remanufacturing a part.
• Allowing for attention to qualitative details:
  The Formula SAE car is generally well regarded by design judges because all systems seem to be integrated neatly and efficiently. It is perhaps easy to ignore this as irrelevant, but there is a certain subtle effect functional aesthetics provides. In a quick evaluation of a team’s work—and although most evaluations are quick—if it looks right, it probably is. Functional and aesthetic packaging is greatly improved through the use of mockups.
• Building morale and motivation:
  Often, by the end of the design phase, team members are frustrated with formal, abstract design and want to get into realizing the project. Prototypes are a great way to get people involved in the building process and signify the eventual transition to manufacturing.

Traps in Prototyping

All this said, prototyping should be approached carefully and at the right time.

By making systems more tangible, prototyping also serves to lock down certain system parameters. It’s much harder to think outside of the box if you’ve just built a box. Prototyping should be avoided early in design and become increasingly necessary later in the process. If started too early, it is easy to become locked into the constraints of the prototype and not see other alternative solutions.

Continuous iteration of a system is also helpful and sometimes necessary. At times, it is preferable to redesign completely based on lessons learned from successive prototypes rather than make another sketchy fix. Although it is possible to add a quick code fix, solder a jump over an incorrect circuit, or drill another hole next to an incorrectly drilled one, too many iterative fixes of the sort can show the final product as poorly designed. At times, it is necessary to compile all lessons learned from iterative design and create a new, well-integrated design.

4. 3. DOCUMENTING RESULTS

In order to collaborate with large teams of people working on the same project, proper documentation of work and tests completed will prevent confusion along with providing a concrete transcript of events transpired. Later, this record of prior proceedings will prove invaluable in training new members, making design decisions and assessing what has or has not been working for the project. A team that does not log data and results will be doomed to repeat past failures. A succinct, accessible logbook of activities will keep a team organized and pointed toward their goal. Team Leaders should be held responsible for the upkeep of such data logging, but all members should understand and contribute.

How to Record Information

Recording information in real time is essential in producing quality reports—it is very easy to forget particular details that may prove to be important down the road. The traditional manner of doing so is through lab notebooks. Notebooks provide a simple way of recording information in one central place. Pages are bound so that information can’t be lost or removed without evidence of its missing. This makes a notebook superior to binders, scrap paper, writing on one’s hand, etc. In cases where one’s notebook is not available and other means of recording are used, notes should be transcribed, stapled or otherwise appended to the notebook as soon as possible so disparate pieces of information are not lost.

Notebooks should not be edited documents but rather a means of documenting data in real time. This includes failures, incorrect assumptions, faulty drafts, and questions that may later seem to be pointless or poorly thought out. Notebooks should be seen as a documentation of process, failures, and observations that can provide the raw data required for reports, not as a formal report itself.

In many respects, a working directory on a computer network is an electronic notebook, comprised of many files at various stages of development. Again, the important consideration is to maintain numerous iterations to document progress and evolution. Computers make it all too easy to save over older iterations, thus destroying evidence of how a final version emerged and sometimes destroying information that is later recognized as useful.

Programmers should be well conditioned to saving iterations and often use formal “version control” software systems to help organize what can quickly become a huge and complicated database of previous iterations. Less formally, it’s possible to do this simply by remembering to save multiple iterations of files and naming files in a way that makes the iterative development process clear. Tools like Microsoft Word change-tracking can also be useful in noting iterations in progress for written documentation.

Electronic mail can also be a useful means of documenting progress over time. In a well-used e-mail network, it is possible to trace the evolution of a project simply be reading through old e-mail archives. E-mail has the added benefit of sharing progress with other interested team members in real time. Too often, notebooks and personal files are individual artifacts; if the problem requires more than one person’s input, these notes need to be shared. E-mail is a quick and easy way to do this, although excessive use can become its own source of information overload.

Importance of Real Time Data Logging

Documenting in real time takes time. Real-time documentation should happen as soon as possible. It is often a good idea to budget a small amount of time each day simply to document what transpired in whatever form most convenient. It is all too easy to drop this in particularly stressful situations, but this should be avoided since it is very likely that the current stresses will encourage one to forget important details that will later prove to be important.

Thus testing and maintenance logbooks need to be updated upon completion of any test or alteration. Without adherence to a strict logging procedure, team members can easily waste the work of teams.

Numerous times the FSAE team has made undocumented adjustments in stressful situations and later found to its regret that the information gained had been lost due to a lack of logbooks or other data recording.

4. 4. Formulating and Reformulating Project Timelines

A daunting task is best done by breaking it down into manageable chunks of work. The result is what is called a work breakdown structure, which is basically a chart laying out to the work needed to carry out and integrate the components of a project. It includes the sequences necessary to design, build, integrate, test and operate the various parts and the overall project. This leads to a set of interim deadlines, which are devised in the planning stages of a team project. These deadlines should be seen as nominally fixed -- but in practice must be manipulated to suit the actual circumstances and actual progress. Team leaders and advisors need to assert the importance of such milestones because they mark important progress on the project. Without small deadlines and victories celebrated in the course of a long project, morale and motivation can be adversely affected.

Inevitably, unforeseen conditions will lead to missed deadlines which must be tracked by leaders and advisors. At this point, the group must return to the planning stage and reformulate new realistic plans, keeping in sight the end goal. Quoting General/President Dwight D. Eisenhower: “Plans are nothing -- planning is everything.”

Foreshadowing Problems

After determining the overall and sub-team work breakdown structure, and documenting it in some manner such as a series of Gantt charts, deadlines should be set and used as a means of benchmarking progress. Deadlines can also foreshadow potential weak links and failures before they occur.

Missing milestones regularly is the first sign of incipient problems. Team leaders and advisors should evaluate why such interim deadlines are being broken and adjust future schedules and milestones.

When achieved, milestone deadlines are important points of punctuated equilibrium (Gersick, 1979) that help motivate a team to tackle a larger project in more manageable blocks of activity by creating a sequence of easily resolved minor points of crisis vs. a singular end point crisis. Minor slippage in these deadlines is inevitable and not cause for alarm if resolved very shortly thereafter. The February 1st deadline FSAE sets for preliminary fabrication was achieved in 2004—if you set your clock to Honolulu time.

Teams can work to avoid major deadline slippage by continuously monitoring progress and making changes in plans as changes occur (“Planning is everything”). However, re-planning consistently put off until tomorrow accumulates and can lead to potential disasters. Although one individual missed deadline is generally not important, the team must be careful to ensure that missed deadlines don’t accumulate and spiral out of control. In addition to milestones, day-to-day activities should be monitored by leaders to anticipate problems down the road.

Interim and subteam deadlines are complex to monitor but essential to track in order to make sure that milestones and mission-critical deadlines are not compromised. A very useful technique is the use of publicly- posted Gantt charts that the entire team can see. Colored highlighting or pens on printed Gantt chart or background colors in excel Gantt charts can be used to make progress rapidly visible. FSAE uses red for serious delays, orange for slight delays, green for on-schedule, and blue for fully completed tasks.

Failing to meet the occasional interim deadline is a fact of life for project teams, especially because student team members are juggling a range of competing professional and personal priorities. It is rarely a good idea to come down hard on reasonable excuses for missing a particular deadline, because this can be demoralizing. Instead re-planning is needed.

With respect to mission-critical deadlines, the whole team will likely be aware of potential deadline slippage and try to avoid it. Generally, a team that is in danger of missing mission critical deadlines has a range of other problems as well.

A good way of ensuring adherence to interim deadlines is tying deadlines to system dependencies; this can easily be shown on Gantt charts or a PERT chart. It is less socially acceptable to miss a deadline that causes inconvenience to others than one that is tied to one’s individual project. Visible, nested, interdependent interim deadlines allow peer pressure to be a strong force in ensuring compliance.

Regrouping and Re-planning After Missed Deadlines

Given that deadlines are inevitably going to be missed, the important question is how to cope with this inevitability. Ideally, team members will react with concern to approaching deadlines and work double-time to correct the problem. This is why activity nearing milestones reaches a peak and after the milestone is usually followed by a considerable lull.

Sometimes, however, no amount of accelerated work will compensate for a missed deadline. At this point it is sometimes more advisable to pause, reflect on the situation, and regroup. Regrouping is especially common for interim deadlines to avoid seeing them accumulate. Once off-track, new plans refocus teams to guarantee mission-critical deadlines are met.

As President Eisenhower said: "Plans are nothing -- planning is everything," or another quote from him is: “No battle was ever won according to plan but no battle was ever won without a plan.” A plan that is broken often needs to be jettisoned, along with its deadlines, in favor of a new plan that will work out better. However, one must realize that if a team cannot make some deadline or goal there are basically only three choices available:

1. Cancel the project or sub-project.
2. Add personnel or financial resources to the project or sub-project.
3. Accept reduced performance expectations for the project or sub-project.

Team leaders and Faculty advisors should institute a brainstorming session to assess the situation and set up plans for which course of action will be pursued.

---

Acknowledgements

In addition to Professor Al George, the following Cornell University students worked on various parts of this project:

Michael Jones, Anna Scott, Ryan Jacobs, Michael Hypes, Whitney Brenner, Erin Fischell

I would particularly like to acknowledge Mike Jones who wrote many of the initial versions of this material while a member of the Cornell FSAE team and as a Cornell employee.

This website was created by Gabe Terrizzi based on the original documents.