Like this article? We recommend
Like this article? We recommend
Like this article? We recommend
Making Things Real
Let's apply some of what we've talked about to a real project. Think about your favorite software development project. Assume that you are the team lead for its development, and that you are late in the Construction phase for the software.
Your Project Lead comes into your office in an agitated state and gives you a list of changes to the product. The number of individual changes is twenty-five.
The source of changes are product customers, sponsors in Senior Management, and developers who have new thoughts about how the product should be architected.
Most of the changes are minor enhancements to function, data, and user interface features. The changes are not likely to cost more than four to eight calendar hours each. Each of these changes is isolated, and can be implemented by individual developers from your team with no impact to other areas.
However, there are five large and complex changes with significant impacts to functionality, database, and the user interface. The changes probably are in the multi-day and multi-person category; that is, multiple people are required to make product changes, and multiple calendar days are required for each change. The work of other project teams will be affected as well.
In addition, Senior Management has decided to reduce current project development personnel by 15%, make performance and usability requirements more stringent, and move the team to less-expensive facilities within two weeks. Of course, the new facilities will be more crowded, without development labs, and with fewer features such as phone and LAN lines; and network access speed is expected to be slower.
The Project Lead wants to meet tomorrow to talk about how these changes will be handled. You have one hour to determine how to proceed.
At this point, it is probably a good idea to research information about change management during development. Consider how these changes should be handled during the following phases:
- Planning
- Requirements
- Conceptual Design
- High Level Design
- Low Level Design
- Construction
- Test
How many of these changes should be allowed in each of these phases?
Recall that there are multiple deliverables to consider including code, UI, information, infrastructure, prototypes, specs, test plans/specs, and test results.
Any questions?