A case study in bureaucracy
This is one aspect of NASA I will not miss - I have changed the names and details in order to legally write this here, but the idea remains clear. From an e-mail I sent to my management entitled "A case study in bureaucracy."
Dear all,
Let me be clear before I begin - this is not a complaint directed towards the individuals involved in this decision tree but rather the rules which force them into these decisions. The events detailed below occurred on the afternoon of Wednesday, March 11.
As book manager for [a requirements document], I am responsible for designing and tracking [a software designer]'s implementation of a set of [unspecified vehicle] overlays used to aid in [that vehicle]'s approach and capture. Part of this software package is a tool titled [software algorithm 1] which allows a user to XXXXXXXXXXXXXXXXXX. Without going into a level of detail unnecessary for this case study, the calculation involves an over-defined system. Thus, the requirements dictate a two step process - first calculate a solution in closed form (i.e. ignore one of the equations), then use this solution as the initial guess for an iterative filter in order to calculate a more accurate solution.
On the afternoon of Wednesday, March 11, I spoke with the lead programmer at [software designer] regarding the software status. The software delivery date was two days away and a code freeze was planned for later that evening. The programmer informed me that the first block of the [software algorithm 1] algorithm (closed form solution) was complete but that the second block (iterative filter) was giving them lots of trouble and the end position as displayed on the monitor was essentially garbage. I asked him to allow me half an hour to discuss the situation with my manager and he agreed.
I presented the situation to my manager and suggested the following solution.
- We inform [software designer] that if the filter is not working by day's end, to display the results of the closed form solution. Though this would not be as accurate as we desire, it was much better than the alternative and could still be used in the verification test which is fast approaching.
- We then tell the program office that [software designer] will need to make a delta delivery with the updated code once they find the bug in their filter.
I was told this was not an option for the following reasons:
- If we tell [software designer] to implement something other than what is detailed in the requirements, we [my division] will be blamed for the software delay.
- We cannot tell the program office that [software designer] will deliver an incomplete product as that word should only come from [software designer].
- We must follow the proper channels - [software designer] will attempt to fix the filter by day's end and will likely fail. The product will be delivered along with a note explaining that the [software algorithm 1] algorithm is faulty and needs to be fixed. At that point, the program office will request impacts to this and we will explain that our verification testing will need to be either pushed to the right or adjusted to test everything except the [software algorithm 1] method.
I explained that following these channels will result in a [software algorithm 1] which yields garbage. On the other hand, one conversation with [software designer] would result in a [software algorithm 1] which yielded a slightly less accurate but still very usable solution. I was told that to interfere as I suggested would put [my division] at risk of being blamed and was unfortunately not an option.
This is a classic example of a situation I have seen often during my five years at NASA - avoiding blame is considered more important than exercising sound engineering judgment. I don't have any illusions that this one e-mail will change anything, but perhaps a hundred will…I feel only too confident in surmising there are more than 99 others who have similar stories. Please let me know if you need any further details and please understand this is by no means a complaint against my manager (who agrees with me wholeheartedly) but rather a call for change to a system drowning in its own bureaucracy.
Sincerely,
Me
As book manager for [a requirements document], I am responsible for designing and tracking [a software designer]'s implementation of a set of [unspecified vehicle] overlays used to aid in [that vehicle]'s approach and capture. Part of this software package is a tool titled [software algorithm 1] which allows a user to XXXXXXXXXXXXXXXXXX. Without going into a level of detail unnecessary for this case study, the calculation involves an over-defined system. Thus, the requirements dictate a two step process - first calculate a solution in closed form (i.e. ignore one of the equations), then use this solution as the initial guess for an iterative filter in order to calculate a more accurate solution.
On the afternoon of Wednesday, March 11, I spoke with the lead programmer at [software designer] regarding the software status. The software delivery date was two days away and a code freeze was planned for later that evening. The programmer informed me that the first block of the [software algorithm 1] algorithm (closed form solution) was complete but that the second block (iterative filter) was giving them lots of trouble and the end position as displayed on the monitor was essentially garbage. I asked him to allow me half an hour to discuss the situation with my manager and he agreed.
I presented the situation to my manager and suggested the following solution.
- We inform [software designer] that if the filter is not working by day's end, to display the results of the closed form solution. Though this would not be as accurate as we desire, it was much better than the alternative and could still be used in the verification test which is fast approaching.
- We then tell the program office that [software designer] will need to make a delta delivery with the updated code once they find the bug in their filter.
I was told this was not an option for the following reasons:
- If we tell [software designer] to implement something other than what is detailed in the requirements, we [my division] will be blamed for the software delay.
- We cannot tell the program office that [software designer] will deliver an incomplete product as that word should only come from [software designer].
- We must follow the proper channels - [software designer] will attempt to fix the filter by day's end and will likely fail. The product will be delivered along with a note explaining that the [software algorithm 1] algorithm is faulty and needs to be fixed. At that point, the program office will request impacts to this and we will explain that our verification testing will need to be either pushed to the right or adjusted to test everything except the [software algorithm 1] method.
I explained that following these channels will result in a [software algorithm 1] which yields garbage. On the other hand, one conversation with [software designer] would result in a [software algorithm 1] which yielded a slightly less accurate but still very usable solution. I was told that to interfere as I suggested would put [my division] at risk of being blamed and was unfortunately not an option.
This is a classic example of a situation I have seen often during my five years at NASA - avoiding blame is considered more important than exercising sound engineering judgment. I don't have any illusions that this one e-mail will change anything, but perhaps a hundred will…I feel only too confident in surmising there are more than 99 others who have similar stories. Please let me know if you need any further details and please understand this is by no means a complaint against my manager (who agrees with me wholeheartedly) but rather a call for change to a system drowning in its own bureaucracy.
Sincerely,
Me
posted by Nicholas at 5:21 PM
1 Comments:
I love how outspoken you are, Nicky. If only everyone had the confidence to express their righteous (and justified) indignation, we might render ourselves capable of having efficient government agencies. How novel.
Post a Comment
<< Home