Early definition is critical, changes late in the game are killers.

Most things humans build, be they physical or virtual, are intended to solve a problem of some kind.  When setting out to make something new, solving the problem is the only focus for development right?  It seems straightforward enough, but many engineering projects get side-tracked for some period of time, spending lots of resources and schedule with not a lot to show for it.  Why?  How can we avoid this?

There are lots of reasons for engineering projects to exceed their schedules and budgets, but there are a couple that are most common:

1. Incomplete or Incompatible requirements developed during product specification
2. Design changes after initial system design has been completed
3. Project focus on non-essential elements or features

All of these causes stem from an incomplete understanding or definition of the project’s end goal.  In any case, the further the project is in development, the more expensive making any changes becomes, both in terms of budget and time.  

Conversely, changes made early in a program will reduce the greatest amount of cost, schedule overrun, or risk.  The worst possible position for a project to end up in is to have product already on market and then to discover a necessary design change (requiring costly recalls or production delays, as well as incurring a reputational hit).

Generating really good specifications and gaining a detailed understanding of what development for a project will entail is the critical element to planning and budgeting for any engineering project.  However, it is also frequently the most depressing and difficult part of any engineering project.  It is common to find ourselves caught on the horns of intractable dilemmas; requirements that must be met for success may be in direct opposition to each other.  The product must be perfect in every way, and also must be on market in 3 weeks and cost nothing to design and build (obviously not feasible).

A project manager’s job is to navigate these contradictions to find the best solution.  However, if these trade-offs are not fully understood (or worse, not even identified), it is nearly certain that the project will get caught in one of these paradoxes and will have to expend significant program resources to solve the problem.  Once an engineering development is underway, changes to even minor requirements and specifications should only be implemented after careful review and consideration so that the risks and impacts of doing so are fully understood.  

The normal engineering development process as used by NASA and other large technical organizations can be summarized as shown in the figure above: Concept→Design→Develop/Test→Produce→Operate.   

BES uses an abbreviated version of the cycle: Discovery (where needed)→Design/Prototyping/Test→Production.  

Many of the formal review steps defined above are also performed at BES:

• MCR/SRR/SDR are the product from a Discovery Phase
• PDR/CDR are the mid-stream and final products from Prototyping
• SIR/ORR/DR/DRR are not as applicable to consumer products, but are fundamentally still products from Production phases 

The really important concept, which holds regardless of specific engineering approach, in the figure above is Committed vs. Completed costs.  When design choices that affect end product cost are made early in the project, those are considered Committed costs, because they will be paid later, perhaps for the entire life of the project.  However, these choices may be made very early in the program life-cycle, when only a small fraction of the Completed costs have been expended.  If the project then proceeds further through the life-cycle before determining and necessary change (perhaps because Committed costs have grown too high), there will be a concomitant increase in Completed costs that may be many times what was budgeted while the project is still far from completion.  

In extreme cases, a design change might warrant an entirely new Discovery phase prior to being adopted.  Spending some budget and time to determine that making a change is not a good move will always be cheaper and better than implementing a change that creates programmatic impacts that outweigh the positive benefits.  However, this may not seem immediately obvious, so a detailed investigation/evaluation of even a small a change is always warranted.  Changing horses mid-stream wasn’t a good idea in the Revolutionary war days and it still isn’t usually a good move now.

Figures taken from NASA Systems Engineering Handbook, NASA/SP-2016-6105 REV2, available at: https://ntrs.nasa.gov/archive/nasa/casi.ntrs.nasa.gov/20170001761.pdf

Interested in learning more about Boulder Engineering Studio? Let's chat!