REAL-WORLD APPLICATION OF IDEAS

A Challenging Experience

Some of the authors worked on a proposal for a program that was designed to be an enabler of net-centric warfare. The technology developed in this program would provide greatly improved connectivity and data transfer to users and systems that would not normally have reliable internet access, thus connecting commanders with enhanced information and ability to see the battlefield.

The proposal effort was very large, with a significant number of personnel working on it. In early discussions with the proposal leads, the newly minted IDEAS process was shared. There was interest in talking about the way that the method allows for rapid prototyping of design concepts. The proposal leads were enthusiastic about the in-house capabilities the human system engineers could provide, and were excited that this approach would offer a competitive advantage. As the proposal process continued, circumstances emerged that tempered the initial enthusiasm. The proposal team had more than 50 members, and the proposed design process followed a strong waterfall software development approach with very distinct phases for requirements, design, implementation, and verification. There seemed to be no obvious way to build in an iterative model that allowed for early user feedback that could serve not only to get the requirements correct, but to reduce later risk.

The proposal process itself served as a microcosm for the proposed project design process. There were frustrating months advocating for a user-centered process, but it was extraordinarily difficult to make a meaningful change in either the proposal process or the proposed waterfall design process. In retrospect, there were at least two sources of failure. First, assumptions were made about the flexibility in the design process. From a human systems perspective, the waterfall approach was difficult to work with because it did not allow for flexibility through the process which would make it difficult to use the results of the evaluation to modify the system. From the systems engineer perspective this was a tried and true method that had worked previously and that the customer was comfortable with, so there was little reason to change. It was simply perceived as either too risky or too challenging to modify the process to accommodate the flexibility that would be needed for meaningful modifications based on a user-centered approach.

One of the lessons learned from this effort was a recognition that the IDEAS steps had not been adequately layered onto the existing software design methodology. Granted, there was a fundamental mismatch of a rigid waterfall process vs. an iterative user-centered approach. Still, had the HS engineers better overlaid their process onto the other engineering processes there may have been a chance to modify the process and introduce spirals into an otherwise straight sequential process. This was a lesson that proved crucial in the next major proposal opportunity.

 
Source
< Prev   CONTENTS   Source   Next >