The planning and requirements documentation developed during the early phases of the project guides the development of software work products (e.g., SWE-013, SWE-014, SWE-102, SWE-106, SWE-109,and SWE-131). Project management and the software lead(s) work together to construct software plans that are logical and achievable in the allotted time. The schedules, activities, and applicable resources estimates that result from these plans are submitted for approval and commitment by the relevant stakeholders and the performing organizations.
During the course of the software development life cycle, results can deviate from expectations, and funding or workforce levels may be altered. Baselined requirements (see Topic 7.8 - Maturity of Life Cycle Products at Milestone Reviews in this Handbook for phases of the Space Flight Project life cycle at which software plans typically become baselined) changes and work plan revisions become necessary based on these and other factors. Once it becomes clear that plans need to be changed, and/or schedules need to be altered, the software development lead and the relevant stakeholders recommit to these revised plans. The new commitments assure availability of resources and unified expectations regarding the revised project.
Several avenues exist to obtain formal commitment to changes in plans. First, the change control process requires formal evaluation and agreement and signoff by relevant parties. The software development team must involve all the relevant stakeholders and other interested parties through the exercise of its configuration management change control system (see SWE-082). Less formal methods may be used, e.g., jointly written and signed memos of understanding between or among the various parties involved. The concurrence and signature to these documents is usually sufficient to provide binding commitments. Finally, organizational policies can also provide the required formality. Software development team organizational charters may require the team to automatically support any changes, subject to resource availability, because of Center, Agency, or national priorities. It is still important for the project and software development teams to strive for concurrence and commitment by the customers and stakeholders to mitigate risks engendered by unhappy and dysfunctional team members.