Phase 1: Team Formation and Initial Client Interaction (Jan1 - Jan30)

Overview: The first thing that must happen when a team is formed is that the team must:

• Become familiar with each other. Often team members will not know each other or their skills. This is particularly true on a large team. Thus, it is important for the team to document the skills of all teams members, as well as strengths and weaknesses of the team as a whole. This helps everyone understand the challenges that will face the team over the course of the project. The team must also agree on the structure and overall standards that will guide their collaboration.
  Relevant Guidelines: Team Inventory Guidelines, Team Standards Guidelines
• Introduce themselves to the client. In many cases, initial negotiation of the project will have occurred between the client and the consulting firm as a whole --- the client has no specific information on the individuals who will ultimately be assigned to the project. Thus, one of the team's first tasks is to present the client with a coherent overview of the team: skills, roles, preliminary assignments.
  Relevant Guidelines: Team Inventory Guidelines, Client Contact Guidelines
• Establish mechanisms for coordinating, documenting and disseminating team progress. This includes creating a team website, beginning a project notebook.

(see Detailed Phase1 Timeline)

Phase 2: Requirements and Early Design; Fn Spec (Jan 30-Feb 28)

After you have established a robust relationship with your client, and have gotten a basic outline of what software design problem you are facing, it is time to begin working on the project in earnest. Initially, you will meet/interact intensively with the client, working to develop a solid Requirements Document. In essence, this document just captures all of the desirable features --- described from a broad, non-technical perspective -- that the software you are building will have to provide. In this way, it ensures that you and the client are on the same wavelength, i.e., that you have correctly understood what the client wants. BE AS CONCISE AS POSSIBLE! Effort invested in clarity and catching errors at this stage pays HUGE dividends, compared to trying to fix misunderstandings later, when the project is half-implemented.

The Functional Specification is the ultimate deliverable for this planning phase of the project. It establishes very concisely what it is that you will deliver to the client: the Functional Specification of the product. It establishes a contract between you and the client -- it is this document that lays out exactly what you are "selling" the client in exchange for their dollars. The importance of this document cannot be overstated. If you fail to communicate clearly about what you will deliver, it could well be that you will find yourself in court. For example, if the client is under the impression that you are going to do MORE than what you plan to actually deliver, they could withhold payment until you complete the extra work. Or they could sue you for selling them an incomplete product. The key to avoiding these problems is to write a very concise functional spec.

(see Detailed Phase2 Timeline)

Phase 3: Design and Implementation (Mar 1-Apr 20)

In the real world, the work on the project really begins after you've had your project proposal accepted. Up until this point, you are really working "on spec", writing up a proposal in the hopes that you will be selected to implement the project.

After the functional specification, your next task is to actually design the software. The relevant document here is the Design Specification, which details how you are implementing the project. In real life, this may not be passed by the client, but is used internally to document the architecture/design and keep the team on the same wavelenth as the design evolves.

Finally, there is a testing phase in which you explore/verify the usability and functional performance of the product before release. This is a very important phase that is often neglected in the rush to release, particularly with respect to Usability testing. Let's face it: there are an infinite number of possible implementations of some product that, technically speaking, address all of the functional requirements listed for it. But these vary widely in their performance --- which includes both execution speed and usability. Your application --- no matter how "functional" it is --- will simply NOT get used if users don't find it intuitive and easy to learn. Thus, an adequate usability testing regime must be design for the product.

(see Detailed Phase3 Timeline)