Well IÆm back with more questions. IÆm now reading the project manager part of PSDP. It's been pretty enlightening. Here are my questions:
6.3.3 Requirements Phase Paths #4 û You state, ôUnless forbidden by the agreement, the development team continues on to the design phase while waiting for both revision/approval of the requirements specification from the end user participants and the Go/No Go decision by the executive sponsor.ö If youÆre waiting for revision/approval from the end user participants and a Go/No Go decision by the executive sponsor, how can you move into the design phase?
6.4 Design Phase Tasks û Overlapping Phases with the Design Phase. You discuss overlapping of initial coding with design phase. Then you say that the project manager must take care not to rush into the initial coding and a way to guard against premature coding is to do proof of concepts. In 6.3 Requirements Phase Tasks, you indicate that this phase is where proof of concepts would be done.
6.4.8 Detail Design Paths û Formal #7. You state, ôThe goal of the formal path is to have a fairly accurate requirements specification at the end of the project. Regardless of the path, wouldnÆt a developer strive for a requirements specification that is ôfairly accurateö before design and perfect by the end of the project?
The design phase contains two sub-phases: general and detail design. You can proceed with the general design phase and even parts of the detail design. Remember, phases often overlap so the development team should have already started design at this point. So, really we're talking about continueing with design.
You want to keep the project moving. The only exception is when the executive sponsor has authorized ONLY a specific amount of work. That's why I used the phrase, "unless forbidden by the agreement".
Your interpretation is correct. Although the project manager must take care not to rush into initial coding, you can start initial coding of well defined areas. It's a matter of confidence in your design. Proof-of-concepts are a great way to proceed with coding tasks without tying them to anything.
Proof of concepts can be done during any phase (including the inception phase).
Not necessarily. With many projects it is acceptable to strive for a fairly accurate requirements document by the end of requirements and then NEVER update it. This approach isn't approapriate for all software projects, but it is often acceptable especially on smaller projects. That's what the informal path is about. Only the Robust path "requires" updating of the requirements specification and design specifications documents throughout the entire process.