Initiating a Project

In this chapter, we will discuss what the Project Management Book of Knowledge (PMBOK) refers to as initiating processes as they relate to the out-of-the-box experience of Microsoft Visual Studio Team System. In its simplest context, these activities consist of the work required to start a new project or a new phase of a much larger project. Initiating activities focus on finding and recording requirements of the system in addition to attempting to gather and quantify the objectives of a project as set by the project sponsors and ultimately those who are the source of the requirements themselves. Activities performed during initiation also focus on gathering initial assumptions and understanding constraints that will ultimately limit the boundaries of the project and the software that is about to be constructed.

Project initiation might seem very straightforward; however, these activities should not be taken lightly. The work produced during project initiation will form an important foundation for the rest of your project. You will meet with the stakeholders to clarify exactly what you’re building, whom you’re building it for, the resources you will build it with, and how you will define success. In addition, realizations produced during initiation will also form a baseline from which variations will be tracked.

Traditionally, the primary deliverable from this phase of a project is the project charter, which is used by project managers to obtain authorization for a project or phase to begin. To do this, project managers must capture and document the objectives of the project sponsors and the expected results of the project. In the project charter document, the scope of the proposed project is linked into the big picture of the organization detailing information such as the underlying need for the project as it relates to overall organization initiatives or objectives. In large initiatives, where work must be broken into a series of projects or phases, the project charter works to confirm requirements, assumptions, constraints, and expectations for the next phase of the project. To produce a project charter, project managers need to gather base stakeholder and user requirements and constraints regarding budget, environmental, and organizational assets that will be either impacted or required during project execution. A project charter takes as input the overall statement of work and the initial set of constraints that have been identified by the stakeholders.

Another common deliverable produced during project initiation is the preliminary scope of work. This is a more detailed description of the project and includes the constraints captured in the project charter. The preliminary scope statement works to identify deliverables, specific requirements, project boundaries, acceptance methods, and methods by which the team will work to control scope.

The requirements and scope outlines in the project charter need not be extensively specific at this point. Compare building a house to hiring a contractor to build you a new house. The builder will typically ask questions like “How much are you willing to spend?” and “When do you want to take possession?” Given some of these constraints, the builder will also work with you to specify the house plans that can help fit your budget, likely allowing you to fine-tune many of the house’s features, such as general type of material that will be used for flooring and cabinetry, before solidifying an overall quote. It is highly unlikely that very specific questions, such as the color of the walls or the style of handles used on the master bathroom door, will need to be asked at this point. Many of these decisions will not significantly impact the cost of the house and can be made much later in the build process. The architecturally significant decisions are the ones that need to be focused on when building a house; the same is true in many ways when building software.

60–80 Percent Rule

Project managers who embrace an iterative requirements-gathering-and-planning approach recognize that you can gather only a certain amount of requirements of the software before it becomes a futile process. You should embrace the fact that it’s virtually impossible to specify all aspects of the software you are going to build before actually starting to build that software. A good rule of thumb is if you can specify 60 to 80 percent of what you are going to build, you should likely move on and expect to squeeze the remaining details later in the development process.