Release Management using “team management” • Software projects are often large and complex • requiring multiple skills • requiring more time • requiring more team work • Monitoring and Making Adjustments are becoming more complex and confusing because of the amount of overlaps/dependencies of phases, people, organizations, departments, competition, etc. • Higher Risk of Making Mistakes under fire, especially for unplanned actions • Utilize “team” management concept • “shared” responsibility • “shared” authority • “leverage”diverse resources
Release Management • Team management using: a) “formal” management reviewing of project status and b) joint decisions and consensus on actions: • Includes all the stakeholders: • Application analysts (requirements analysts) • Designers • Constructors (detailed design, code, information material) • Testers • QA (process, quality data) • Library & Configuration management • Tools and components providers • [Customer support] • [Marketing/Sales/Training] • [major customers] • [finance] • [personnel]
Release Management Stake- holder Stake- holder Stake- holder • Conducted regularly (daily, weekly, or bi-monthly) • Must make decisions and take actions • Must have authority to move resources,schedules,functionality,and escalate issues Stake- holder Stake- holder Stake- holder Stake- holder Stake- holder Stake- holder
Release Management • Meant for physically co-located, but may be remote (with proper team tools) • Must be “inclusive” and discourage pockets of “islands” • The actual meetings should follow an agenda • Must make “difficult” decisions such: • Delaying schedule => implications ? • Increasing resources => implications? • Decreasing resources => implications • Decreasing functionality => implications • Increasing functionality => implications? Must decide on : Ready to Release the Product ?--- Are we done with the project?