Day 98 - New Proposal

The project is stopped, but there's still management work to do.
The political battle, with the consequent interruption in July, resulted from the fact that the proposal price was considered too high by the sponsor and our partner.

The project has been planned according with Data Fusion methodology and our know-how, which is over 10 years. I recall that we are data migration specialists, I don't have number but I believe there's not many people who have migrated as many banks as we did nor as faster as we do it. This said, we know what we're doing but obviously the sponsor, and unfortunately the partner, does not.

This said, the proposal has been presented according to what is most convenient to the client.
But this time we had to cut costs and in order to do it, we had to cut one resource. This means we've rethought the planing with one less specialist. But in order to do it, we had to force some constraints:

1. The client must give the functional mapping rules in up to three blocks. The first block must have the minimum required in order to be possible to execute the mapping. The second block must cover at least 75% of the rules and the third block must be complete.
2. There's a dead line to deliver the last block. It depends with the complexity and development time of the area being mapped. It usually must not exceed 4 weeks after the first block delivery, which must be delivered by the end of the initial week of the area being mapped.
   
3. The functional mapping deliveries must be of high quality. This means that there's a maximum number of changes programmed. This threshold has been calculated as 25% of the total number of mapping rules, e.g. a project that has 1000 mapping rules can have up to 250 change requests. If the client requests changes above the maximum number of changes planned, that will cost him extra.

We had to include these two rules because we need to have high quality functional mappings delivered fast and we can't spent much time changing recoding the rules, that's why there's a threshold on the number of changes. There's one less resource, so there must be less work to do.

The main difference from our regular methodology is commodity for the client.
In the usual model, the client can request as many change requests as he wants and we, usually, accept that functional mappings are finished late in the project.
This has obvious advantages for the client in contrast with a limited number of changes and no late deliveries.

I think this is a great example were the client has not been well treated, since the price battle actually was more a problem for our partner than for the sponsor.
But the main goal has been achieved, the proposal is now cheaper, with an obvious cost.