Why Starliner won't go to Space today (or why development methodology is important)

A few years back there was a race between Boeing's Starliner and Space's Crew Dragon to capture the American flag on the International Space Station (ISS). The two companies were viewed as neck and neck in the race and yet Spacex retrieved the flag 3 years ago and Boeing aren't likely to launch human until next year. 

Why?

With the various failures of OFT-1 (Starliner's first test flight), Nasa declared a 'close call event'. During the resulting press conference Nasa had admitted they thought Boeing would do everything the Nasa way and hadn't paid much attention. Nasa quietly admitted to being shocked Boeing didn't have a System Engineering Management Plan (SEMP).

There are lots of methodologies for designing and developing a system. Each of these approaches have their strengths and weaknesses and all of them rely on various gates to monitor and control the development of a product.

When following Waterfall, the gates and controls are placed at phase transitions. Typically a 'Checkpoint Review' meeting is arranged when the lifecycle phase is completed (e.g. all requriements capture, all design completed, etc..). Each review meeting has a set standard of requirements for documentation and information before a project can move on to the next phase.

Agile Scrum gates and controls are found within the Sprint Ceremonies, each ceremony covers a different aspect of a traditional checkpoint meeting. The way the information is captured changes to fit in with Agile principles.

The next complexity is scaling the approach, for something like Starliner you will need multiple teams with different specialities coordinating together to deliver the end product.

A SEMP is used to scale Waterfall projects. A SEMP specifies how a project should operate, what processes does it follow, forms it need to complete, phases it moves through, general requirements, etc.. it provides a common set of gates and controls across all projects.

With Starliner each team was deciding how it would run itself, and coordinating with dependent teams as needed. This meant the gates and controls were all different and so useless when monitoring across multiple projects.

The original Starliner mishap was caused because no one ran a full end to end test of the launch scenario, the software team didn't think to run one and no one knew to ask.

Today we learn Starliner is delayed because the electrical tape used on the wiring loom is flammable. Had there been a SEMP, common flammability requirements would have been levied on all teams equally. Instead Nasa is having to painfully review everything and the process is taking years.

It really doesn't matter what methodology you follow, what matters is understanding how you will track performance and control the projects and your processes support the methodology.