INCOSE 2008 - Technical Team Accountability for Requirements and Delivery

James Andary, Maria So & Barry Breindel from the NASA Goddard space center presented “Systems Engineering Technical Authority: A Path to Mission Success”. The goal behind this program they call “Technical Authority” (TA) is to give a voice to the engineers on projects. Under the previous model, project managers were the central path to communicate with upper management. Looking at a history of success, this old approach worked well on their robotic missions, but not for human space flight missions. As an example from the Challenger report, there were specific technical warnings from people that were ignored, never making it up the chain to the people who had the authority to delay a launch to investigate them.

Under a TA model, the lead systems engineer on a project still has a dotted line reporting to project managers, but ultimately they report up to the engineering director, up to the center director and finally the NASA chief engineer. This means that an engineer can take an issue to the top of the chain if they believe it’s not being addressed properly. Part of the reason for using this model is that, there is a natural conflict between engineering (who wants to build a perfect system) and program management (who wants to launch on time), and this model is supposed to help eliminate issues from this conflict. They gave an example of a battery engineer who was about to quickly escalate an issue – there had been a series of launch delays which meant some specific batteries on the flight had expired. He brought the issue to the attention at a director level and they employed the appropriate people to quickly research it to determine if it should delay the launch again.

A result of this organizational model is that the engineer now has accountability for the product – and while generally a positive thing, this will probably be hard for some people to accept. The engineer now also has responsibility for understanding and implementing both enterprise requirements and project specific requirements. I admit that when I first heard this, I thought “You mean they were not accountable before if the space mission failed for a technical reason?” I think the point is not that they were negligent, so much as they were not being heard – more of a communication failure.

With this model, there no longer should be finger pointing “the project manager didn’t listen to me” and instead a focus on everyone doing their part to have a successful launch.

One final point made - when dealing with large systems project, it is important that someone on the project has a holistic view of the project. This team is working with MIT to study how you infuse that in people. They are trying to do a few things to improve this, such as exposing engineers to more of the overall mission activities, holding focus groups to share experiences, and requiring engineers to participate on peer review panels. I think there are some great take-aways from this that we can apply to all organizations, encouraging cross-project awareness.