Let us start by looking at the characteristics of fixed-bid projects:
1) Time-bound
2) Predefined scope — normally immutable
3) Fixed set of resources
4) Predefined quality checks
Wow ! Isn’t the set above, a project manager’s nightmare. What we are essentially saying is that, out of the 3 allowed Project management variables of Scope, Resources, and Time (although there is a 4th parameter – Quality, it can obviously never be taken as a variable), none is allowed to be a variable in many fixed-bid projects. That also normally leads to the project not meeting the expectations, because the expectations were unrealistic in the first place. Does it mean that all fixed-bid projects are doomed to fail? Not really…if there is an upfront understanding among the different stakeholders that one of the 3 (Scope, Resources or Time) is allowed to change from what was agreed in the beginning of the project, that itself increases the probability of success of the project by a significant amount.
So, now that we have agreed (?! 
) that it is preferable to keep one of them as a variable even in a fixed-bid project, let us look at what Agile requires and recommends.
Although there are many Agile methodologies out there, one of the common threads among them is the allowance for a change in scope mid-stream. That automatically fits into (one of) the criteria for the increased probability of success of a fixed-bid project.
But then, if the scope is allowed to change, what is so ‘fixed’ about the ‘bid’ ? Here goes:
1) Out of the 4 potential variables, 3 (R, T and Q) are supposed to be constants.
2) Now let us zoom-in on the ‘Scope’ part. Let us say that the clients want to change the requirements in the middle of the project (sounds so familiar..doesn’t it?). You could do one of 2 things:
a) Remove lesser priority items for making way for the new high priority items. How? You would most probably have done a size estimation of your project in terms of Scrum-Story-points or XP-User-Stories or XP-Tasks or whatever. Use that for the barter. Pull in the high priority items, and push out the least priority items of equivalent size. Well, can/should it be as accurate as what was expected in/of the ‘Merchant of Venice’? Not really, but at least the gap is significantly reduced to the extent of being manageable…btw, the exchange accuracy expected in the Merch of Venice was also an overkill (no pun intended), wasn’t it ?
b) In your fixed-bid agreement itself, keep a provision of about 15-20% for handling the creepiness of scope. That way, you can still inject feasible scope without replacing any agreed scope. Why do I still use the word ‘feasible’? Because of 2 reasons:
i) We cannot obviously inject scope more than the allowed percent
ii) A more implicit reason is that scope cannot be changed (even within allowable limits) if it is coming in too late in the cycle, and if it has a serious impact on the design roots. Needless to say, there may be cases where the scope does come in too late in the cycle, and is also threatening the design roots. In such cases, it is better to re-work the SOW( Statement of Work) and start afresh rather than trying to squeeze the drastic scope-change into the ambit of the current agreement.
In summary, Fixed-bid projects can be done in an Agile manner provided some of the danger zones are taken care of. Is the above approach the only way to bring the obvious advantages of Agile project management to fixed-bid projects? Not really….pls do come back for more posts on this…
Tags: Agile, Aspire system, constraints, fixed-bid, quality, resources, scope, scope change, scope creep, time
January 10, 2008 at 6:31 am
The detail analysis of Agile Methodology fitting into the fixed bid projects looks good.
However, I’ve my own reservation for the allocation of 15-20% contingency towards the prediction of Change Request on that cycle.
The best part of Agile is scope defined, short and sweet (sweat too) execution model. If you assume that there will be some changes in the scope, its understood that the scope is not defined clearly. Also, as there is a room provided to allow the scope creep, it might lead to nazi concentration camp and end up in re-drafting the SOW.
Still, the model you proposed is definitely workable provided the scope creep doesn’t cross the saturation level.
Nice one!
January 16, 2008 at 1:56 pm
Poongundran,
Appreciate the point raised about scope creep. I am fully with you, in that scope creep will raise its head every once in a while. Here, we need to differentiate between a scope ‘change’ and scope ‘creep’. No matter what methodology we adopt, we have to get the right product in place, in terms of functionality (and then get it to work perfectly). This means that we should provide allowance for scope ‘change’… that’s something we might not be able to avoid. But scope ‘creep’ is something that we can avoid, by removing lower priority items of similar size when you are injecting high priority items.
So, bottomline, there is no point in fighting against useful scope change. Even if we win legally (based on the contract terms), there is no satisfaction of having delivered the right product/application, end of the day. But we must be careful that the scope ‘change’ does not translate to scope ‘creep’….some lower priority item/s must go.