Trying to Popularize a Two-Phased Approach to Fixed-Bid Projects

Lately, when asked for proposals for fixed-bid projects, I've been trying to convince prospects to take a two-phased approach. The first phase would be some sort of a feasibility study, to make a more precise cost of the second phase. Below is a discussion of how this two-phased approach would go. (FYI, I haven't been successful at convincing prospects so far.)

The first phase would correspond to RUP's Inception and Elaboration phases. The duration of this phase can be anywhere from one week to three months, depending on the scale of the project. The team can be as small as two people - one architect and one business analyst - and the occasional help of a user-interface designer.

The goals of this phase would be as follows:

• Business requirements analysis.
• Architectural design and prototyping.
• Project plan, including schedule and cost estimates.

Note that this is not waterfall. Design will be validated by working code and automated tests.

The benefits to the client will be as follows:

• Less "padding" on construction estimates.
• A chance to decide if the project is worth pursuing before engaging in a more expensive commitment.
• The client can choose to use a different contracting firm than the ones that did the initial phase. The client will have business requirements, an initial codebase, and a project plan which another contractor can start with.

The benefits to us, on the other hand, are avoiding gross underestimation a project's cost, and avoiding scope creep during the construction phase of the project.

I'm trying to think of a good name for this phase, something that business people and traditional IT people can appreciate quickly. I've thought of calling it the "Feasibility Phase" (ugh), the "Business Analysis and Design Phase" (B.A.D.?), or the "Analysis and Architecture Phase" (A.A.A.? A.A.P.?).

The second phase, would map to RUP's Construction and Transition phases. Again, this is not waterfall. Delivery will be in regular iterations, say every month or every two weeks. The client will be able to test working code after each iteration, and can thus are able to give their feedback in short cycles.

Furthermore, we allow the client the privilege to change their mind. At any point in the project, the customer can say, "I want a new feature.", and we can accomodate that, of course with a corresponding change in pricing and schedule. The iterative nature of the process will allow us to work in the new feature efficiently.

Also, we will allow the client to end the project at any iteration. We allow a client to say, "Ok, we're happy with what we'll get after this iteration. Let's not continue anymore." They will be able to do that because they have a working, usable application at the end of each iteration. It is therefore up to us to continue to bring business value to the client with each succeeding iteration. (I don't mind an abrupt end to a project, we always have lots of other pending work for people.)

The second phase can probably simply be called the "Construction Phase", even if it covers both Construction and Transition.

Update: Looks like there's a company that's already successful in doing this.