Project Planning

This chapter continues the inception phase and describes the second iteration of the Online Photo Shop sample project. The goal is to define the project and to get it started. Therefore, the main focus in this iteration is on project planning.

In the inception and elaboration phase it is crucial to achieve agreement between the project team and the customer on the requirements and on the expectations for the functionality (expectations must be set to a realistic level) as well as to agree on the procedural approach that is to be taken to implement the project. A good practice is to plan the project in very close collaboration with the customer and transparently to all parties involved. This sets the groundwork for open communication and collaboration, which in the end is the base for success. Even though our customer may not be interested in the coding standards used by the development team or in how the reference documentation is created, these details should be discussed with, or at least communicated to, the customer.

Close collaboration and information exchange with the customer can help to build trust and additional confidence in the abilities of the project team, especially if a realistic, structured, and well-thought-through approach can be shown. In addition, transparent project planning lets the customer and each project team member know exactly what is expected, and we can immediately incorporate improvement suggestions from all involved parties. Usually, projects have major problems with communication between customer and project team only when there is too little communication, and never when there is too much (if indeed there can be too much communication).

As described in Chapter 2, the main focus in the inception phase is on the requirements and analysis workflows. Nevertheless all iterations must work through all five core workflows. More specifically, the following goals are set for the various workflows in the inception phase:

• Requirements: Requirements are captured to help to scope the project.
• Analysis: A business analysis is done, and the risk is analyzed.
• Design: The initial architectural design is developed.
• Implementation: A proof of concept or technology prototype may be developed.
• Test: Testing is usually not done because the prototypes are typically thrown away. In case the prototypes will be evolved to a product, the team may develop tests for the prototype.

We spend most of our time in this iteration on capturing and analyzing requirements. However, the design workflow defines and describes the architectural framework. The implementation workflow in this phase usually does not focus on actual coding but instead focuses on the implementation of procedures such as coding conventions and prototyping (as described in Chapter 3). Because there is no actual coding other than throw-away prototypes, the testing workflow does not really apply to the inception phase. Nevertheless, if the definition of test is stretched a little, it could be stated that software development artifacts (documents in this case) are usually "tested" by document reviews before they are released.

The inception phase defines the following go/no-go goals that are to be met:

• Prototype (if necessary)
• Project vision (considering main requirements and constraints)
• Business case
• Initial use case model (10 percent to 20 percent complete)
• Main requirements with unique identifier key
• Initial project plan (including iteration planning)
• Initial risk assessment
• Initial architecture

These goals define the to-do list for the project that we must complete to move to the next phase. This chapter addresses all the defined goals (except the prototype development for feasibility study) to finish the inception phase.

Unlike many real-life projects, the documentation for the project described in this book is not split into many different documents; instead, all the artifacts and information needed are collected in the software engineering sections of each chapter. For a small project team working on a small-scale project, this may be the most efficient way to produce the artifacts. Nevertheless, we should mention that, depending on the type and environment of the project, one or more documents may be produced. This means that each of the artifacts or groups of artifacts described in this chapter could be split into additional documents if needed (most likely this would be done for larger projects). On the other hand, in small projects (such as the Online Photo Shop project) all the information is collected in one document. It is the task of the project management to decide which approach will best fit the particular project.

As stated before, for this project all the information will be in one document: this book. Each chapter will define clear go/no-go criteria at the beginning of each iteration. At the end of each iteration or chapter (one chapter is equivalent to one iteration for most of the book), the go/no-go criteria are evaluated. Depending on the evaluation, either we enter the next phase or iteration, or we must do some rework before proceeding. Having these strict go/no-go criteria in short intervals enables accurate project tracking.