Executing Project Plans

Even though how to proceed with building a solution is dependent on which build methodology is used, it should be clear to everyone as to when and what each subteam should be doing throughout this track. This is because this knowledge should already be embodied within the various project plans, schedules, and designs; and taken together provide an understanding of what, how, and when the different aspects of a solution, broken down into work items, need to be completed.

Because a project team is typically augmented with additional personnel to help build a solution, each build team should review and validate the plans, designs, and schedules developed in the Plan Track that affect them before starting construction to make sure they completely understand the scope of their work, including tasks and deliverables. As part of the review, each build team needs to work with the architect team to flesh out details should any plans or designs not be sufficiently detailed enough as per the build team. An important aspect of this review is to make sure each build team understands the release criteria for their work items (i.e., what does it mean to be "done"). Not understanding the release criteria likely leads to over or under delivery on work items. An example of a common release criterion is that a solution meets a defined minimum acceptance level of functionality and capability within the three requirements categories (i.e., delighters, satisfiers, and dissatisfiers) as discussed in Chapter 8, "MSF Plan Track: Planning a Solution."

With build teams working concurrently, it is important to leave enough time to work out cross-team issues and inconsistencies. This plays out especially as the team starts to integrate and test their component parts.