As users tried different elements of the tool and provided feedback about how well they worked, the team made modifications that affected not only the content and its presentation but also the tool's functionality. For each release, the development team demanded changes in functionality that required significant rework for the software developers. The indisputable fact that the train had to leave the station on time focused the technical and strategic teams on overcoming adversity rather than on giving up with good excuses. Yet adversity abounded. The process of creating a software application follows a generally linear path.
Developers design a framework into which they slot blocks of code that execute various tasks.
Creating a framework at the front end yields an elegant and simple systems design. Yet the side effect of this approach is that very early in the process, functionality and the outcomes it permits become fixed, and the only way to change it is to start over. The software application development process collided head-on with the process the GBP team was creating to respond to user demand for a more flexible and dynamic tool. As each new GBP development cycle began, the software application group insisted on receiving a complete set of user requirements. The GBP team struggled to obtain feedback from users about new functionality as they began to use the new release.