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.
Tags: Change, Estimation
July 21, 2008 at 1:18 pm |
I am a Nerd or an ego-centric person to fight with my delivery manager on issues of scope changes. I am a front-end sales guy who looks into the eyes of the client to make a committment. What I sell is change management encapsulated in service which is measured by SLAs. What I expect is a clrity of operation. Mind you to the deilvery person I am his/her customer FIRST. I need to be satisfied that WE will deliver what I promised.
SO does the ageold proposal can manage this expectation. Well Mr/Ms delivery manager you have written 40 – 50 pages of material stating what shall you do which is cut and pasted from your previous assignment expecting it to be true every time.
So what is change management ? deviation from the normal work program. Is it acceptable ? Yes as business needs it. How do you manage ? Well if I change my proposal to an Operational process of your portfolio then am I not getting in your shoes to understand your need of MY involvement ? I should first understand what you do . Then understand what you want . Thirdly say how do I deliver it. Well now I have my operational process in place then I ask the work streams to be placed in this operational process. The work streams are controlled by Statement of Work goverend by SLA s which arise from the Operational process. Is this not what quality process is all about ?
What are the merits – My estimation is a clear transparent document which is a subset of my operational process. My workflow is clearly defined which has the sign-off of the client as a method of going forward.
Do we still need the ageold proposal ?
July 21, 2008 at 10:08 pm |
The context here is akin to software development services for Product Engineering where a proposal, perhaps single-shot, is submitted and gets evaluated. The point made is that the internal and external parameters of the estimates in the proposal need to be clearly and explicitly communicated to the delivery function so that changes to these parameters are controlled as early as possible with well-informed alertness. Now it is possible to identify uplanned unprovided-for scope escalation as soon as it occurs so that it may be handled in an apprpriate manner.