Examining a Case Study
Welcome to the MATT project case study. The goals of the project were to engineer a software product that automated testing of real time system models built on the MatrixX platform using simulation. The project had a staff of twelve people deployed at two development sites on hundred miles apart. The end product was to provide identical functionality on the window and Sun Solaris platform. Our customer was NASA, which provided funding and a hard delivery date of May 1, 2000, which gave the team nine months to produce MATT.
During project preparation, we identified a number of important stake-holders. First, out funding agency, whose stakeholders included the funding office (betting resources we would be successful), wind tunnel technical staff (hoping we would provide them with time-saving testing tools), and NASA colleagues (needing a valuable contribution to ongoing NASA efforts to help secure future funding). The organization, project manager, and project team were major stakeholders; all needed a successful project that would sustain them for years. Another important set of stakeholders included MatrixX customers in general and the MatrixX technical staff, both groups that were to support the project. MatrixX customers invested time in requirements specification, and MatrixX technical staff provided key technical guidance on tool development. Another stakeholder, a major reaserch university, ahd funding diverted to the contracting organization to support the MATT project. (Their best wishes for our success never did arrive.)
Project needs MATT included the usual focus on reliability, ease of use, robustness, and accuracy. In addition, we placed a high priority on maintainability and portability, as we saw MATT potentially in use for years, moving to other platforms and being modified to operate with Matlab. Consequently, the product was not feature rich or complex in functionality, it relied greatly on functionality provided by MatrixX. Given our fixed sacrificed some user-desired functions while keeping a clear focus on core functionality. We struck a balance between features and time: All project needs were weighed against our ability to finish the project on time.
Specifying projects payoffs was much more difficult for MATT than for a typical software development project. The team worked with a contracting agency and a group of users, both twenty five hundred miles from the development site. Interaction between users and the development team was restricted to phone and email. Many times the developers expressed confusion over exactly how the product was to be used in production. The team had to trust the manager and the team member in the customer interface role to acquire requirements, clarify open issues, and illustrate the intended end use of the product.
As this case study develops across the remaining chapters of this book, you will see the project manager did not succeed in communicating a clear project vision to the team throughout the project. Certainly the distances between the development team and the users contributed to this problem, but the project manager (the author) could have better job.
Among the lessons he has learned from this experience: write, draw, discuss, and explain the project vision repeatedly during the project, and never take it for granted the team can see your vision (see the web site supporting this book for MATT artifacts.)