Project initiation is the project manager’s first opportunity to take steps that will give the project the best chance of success. The five chapters in Part II address several of the activities an astute project manager should perform at this point. In the frenzied rush of assembling the team, exploring requirements, and creating a plan, it’s easy for a project manager to overlook these kinds of foundation-laying necessities. Nonetheless, the activities described here are an important aspect of getting your ducks in a row so they can all quack in unison.

At the beginning of every project, the stakeholders need to reach a common understanding of how they will determine whether this project is successful. Chapter 4, provides considerable guidance on defining explicit success criteria during the project’s inception. Setting these success objectives helps to keep stakeholders focused on shared objectives and establishes targets for evaluating progress. To help you determine where your project is heading, this chapter describes a four-step process for defining project success criteria.

Before I begin a major activity I always like to contemplate how I will know when I’m done. Hence Chapter 5’s focus on the critical question "Are We There Yet?" Defining your product’s release criteria is another essential part of laying the foundation for a successful project. This chapter provides examples of how—and how not—to write effective release criteria.

The project manager spends a lot of time contemplating what he must do to make the project succeed. The flip side is to imagine everything that could prevent the project from succeeding. As with a military campaign, Chapter 6 describes why it’s important to "Know Your Enemy." This chapter introduces the principles and practices of identifying and managing risks on a software project. I identify numerous typical risk factors in several categories. This chapter also presents two forms for documenting individual project risks. Even a small project team should take the time to identify its biggest potential barriers. Smaller projects can handle risk management and other activities more informally than should large projects. Nonetheless, the time spent contemplating risks, recording them, and determining what to do about them is a good investment for every team.

Many organizations are in the custom of creating project charters. A carefully conceived charter describes why the project is being undertaken and aligns the stakeholders toward common objectives. Chapter 7, describes the purpose of the project charter and proposes a template for that critical project deliverable. Small projects (okay, all projects) wish to avoid unnecessary documentation. Therefore, a small project could create a trimmed-down version of the charter that contains just enough information to get all the stakeholders on the same wavelength. But every project can benefit from a charter.

There are literally hundreds of tools available to assist every stage of the software development and management processes. You will live with the tools you select during project initiation for a long time. It’s important to choose appropriate tools and help your team members learn how to use them effectively. Incorporating new tools and methods into a software organization has technical, managerial, and cultural implications. Chapter 8 presents several "Lessons Learned from Tool Adoption," both successful and unsuccessful.