Project Management with the IBM Rational Unified Process: Lessons From The Trenches - page 76


Summary

  • Ensure that all contractual commitments allow adequate contact between end users and requirements analysts.

  • If the outsourcing organization and the contracting organization are geographically separated, use tools such as audio and videoconferencing, high-bandwidth network connections between sites, and exchange of project personnel where possible.

  • For projects involving global outsourcing, implement cultural sensitivity training, including all team members.

  • Give advance notice to management of the outsourcing organization that you will require significant amounts of time from the organization's end users and business process experts.

  • The contractor team should create a contact list of all personnel in the user community, including name, e-mail address, phone number, role in the organization, and so on.

  • When using user interface prototypes, be sure to caution users that the interface is only a facade. The real work remains to be done.

  • Be sure to monitor requirements growth and revisit it regularly, and be sure that existing requirements can be implemented within the allotted time and funding.



What's Next?

The next chapter discusses issues in the Construction phase. First, how can you tell if your project has successfully concluded the Elaboration phase and is ready for Construction? How long should an iteration be? What can the team expect in Construction? What are some of the common pitfalls experienced during a project's Construction phase? Developers, project managers, and test professionals will benefit the most from reading the next chapter.



Chapter 10. Construction Iterations: Staying on Target

In the Construction phase, the project's emphasis shifts away from Requirements Elicitation and more toward Implementation. Indeed, the major goal of the Construction phase is to reach the Initial Operational Capability (IOC) milestone. This represents a point where the product has most of the key requirements implemented. The prime features requested by the users are functional and can be demonstrated to the users. At the conclusion of the Construction phase, the product is suitable for beta testing or end user testing. This chapter includes checklists for determining whether the project is ready to move into the Construction phase. This chapter also discusses some of the common mistakes made by projects moving into the Construction phase and what you can expect from your customers and project team.



How Can You Tell if the Project Is Ready for Construction?

A project's readiness for the Construction phase is largely determined by what happened in the Elaboration phase. In some respects, the shift from the Elaboration phase to the Construction phase is subtle. In other respects, it is a major change in emphasis. Simply stated, during Elaboration, risk reduction is emphasized. This task is accomplished through choosing a suitable architecture for the system and testing it by implementing the requirements that affect the architecture. The project is ready to move into the Construction phase after the following two things happen:

  • The team is convinced that the chosen architecture can accommodate all the prime system requirements, especially attributes such as response time, throughput, capacity, security, and reliability.

  • Their conviction is proven through demonstration of the implementation of the key requirements.

Staffing-wise, Construction is the phase in which the bulk of the product funds and resources are consumed. If the project is truly ready for the Construction phase, the team will settle into a smooth, rhythmic pattern, somewhat resembling an assembly line. If the project and team are not ready for Construction, they lose forward momentum while their "burn rate" (the rate at which money and resources are being consumed) is at its highest. This is a difficult situation from which to recover.

Although the architecture is perhaps the most significant risk that must be mitigated during Elaboration, it is by no means the only risk. For example, is the project infrastructure ready to support the Construction phase? Is the entire team in place, and have they received any applicable training? What about the software development environment and associated tools?

Assessing Project Readiness for Construction: Checklists

When the project is believed to be approaching the end of the Elaboration phase, it is useful to hold a group meeting. The people in the following roles should be present:

  • Project manager

  • Software architect

  • Lead developer or technical lead

  • Lead requirements analyst

  • Testing lead

The key topic of the meeting is to determine whether the objectives and exit criteria of the Elaboration phase have been reached. During the meeting, discuss the items in the following checklists.

Checklist for the Product in Development

Has the systems candidate architecture been established?

Have the functional requirements that affect the architecture been implemented and successfully tested?

Has the architecture been validated against the systems supplemental requirements? For example, if there is a requirement that the system must support 1,000 users, and that response time with 1,000 users must be within 2 seconds, has the architecture been demonstrably proven to meet the requirement?

Is the system suitable for partitioning development in such a way that portions of its development can easily be allocated to groups of developers?

Have all other risks, in addition to the systems architecture, been identified and mitigated? At the very least, a plan should exist for any significant risks that are not mitigated by the conclusion of Elaboration.

Checklist for the Project Environment and Staffing

Is all of the required staff (developers, testers, and so on) available to staff the project?

Have all the necessary software development tools been acquired and installed?

Is the staff proficient with the tools and technologies used on the project, or have they received training?

Is any Commercial Off-The-Shelf (COTS) software required? If so, has it been acquired and set up? For some COTS software, setup and configuration may not be trivial. The software should be ready for use so that the team can be productive with it.

images/U2713.jpg border=0> Has a viable test plan been created, and are testing resources in place?

Checklist for the Customer

Has the customer reviewed the projects status?

Is the customer satisfied with the projects progress in terms of the schedule and budget?

Have projections to completion been made, and is the customer comfortable with these projections?

Have the end users reviewed the systems major artifacts, such as the user interface design? Have they signed off, signifying their approval?

These checklists are not exhaustive, but they cover the major areas. The importance of performing a thorough, accurate self-assessment cannot be overemphasized. Resist the temptation to plunge into the Construction phase until you know the status of these issues.