The other evening, I was returning home with my colleague who is in the marketing function preparing proposals for submission to prospects. She comes from the software delivery background and wherever her proposal is converted into an order, she keeps tabs on the project execution. She was mentioning that our change management function needs to be strengthened.
In one of the jobs, the customer, during project execution, ended up bringing more screens to the table than what was originally factored into the estimates contained in the proposal. And he maintained that he had not changed the scope of the application! Our Project Manager felt he could not strongly refute customer’s claim and present it as a scope change, though honestly more effort would now be required to implement the additional screens.
This kind of a situation often arises when thread with the customer is broken; the proposal along with the estimates is made by one silo in marketing and the execution being taken up by another silo in delivery.
There are two simple devices available to guard against these pitfalls. Both are concerned with the parameters that influence the estimates. Firstly, the estimates must explicitly mention in the proposal the external parameters (meaningful to the customer) which significantly impact the effort computation. It could be the number of screens, number of reports, number of events, number of roles, or function points, etc. Some kind of an indicator may flag a parameter to show how intensely sensitive is the effort with regard to this parameter. Secondly, when the project execution commences, the marketing function could verbalize in simple and direct terms for the delivery function, on what are the internal (implementation related, not visible to the customer) parameters that the estimates are sensitive to. This is in addition to the customary handing over of copy of the proposal and the estimation model used therein. Now the Project Manager has his eyes out for changes on these external and internal parameters. And for changes in external parameters, he could take up with the customer as changes in scope and effort. The simple verbalization is more readily comprehendible than a sophisticated and highly granular estimation model.
This is a simple-minded approach. For, all screens and all reports are not the same in terms of effort involved in their development. Hence some refinement may be made by classifying the parameters into subcategories like simple reports and complex reports and defining what these are. This is not a license to present the estimates as qualified by a complex knot of umpteen parameters. The customer should be able to understand and appreciate the simplicity and reasonableness of the rationale and the approach taken and not see it as a ruse for piling up scope changes.
Sometimes, the parameter is not numeric in sense. For instance, if some kind of local data caching is implemented for performance or reducing connection charges, it usually means more complexity and effort over directly accessing the data store. Another ready example is single threading versus multi-threading. These could be hard-coded as significant elements of the solution or the technical architecture. Often these appear innocuously somewhere in the middle of a long list of features or assumptions on the architecture with no clue to the customer as to what impact would it have on estimated effort if these were to be changed.
In principle, anything that affects the effort significantly is candidate parameter, external or internal.