I am pretty sure I test the patience of my coworkers because I tend to be on the over-prepared end of spectrum, so with the request for something "high-level" I have to remind myself to scale back my desire to do a full blown proposal and estimate. But, still, when the project is completed, what is a fair variance from the high level estimate/rough order of magnitude? 10%? 25%? 50%? And what does the client consider fair? Their expectations may be different than mine.
Of course, there are standard parts of an upgrade. Those high-level tasks serve as a starting point for the estimate, as they are things we have done time and time again.
- Pre upgrade meetings
- Upgrade and test customizations and modifications
- Upgrade and test integrations
- Complete test upgrade
- Complete server and company upgrades
- Complete workstation upgrade
- Perform testing and review
- Complete training
And many of those high-level tasks generally fall within a range of hours assuming no extenuating circumstances. Now, in my scenario, the upgrade would be to GP2010 which introduces another level of complexity and additional questions since it is not yet released. We simply don't yet know what issues may come out of the upgrade process.
So, as I went about pulling together some numbers, here are the guidelines I came up with for myself to keep the scale in check with the request:- Identify what is considered in scope and out of scope for the upgrade. In this case, it meant identifying the customizations that would be upgraded and those that would not. It also meant specifically excluding upgrades to crystal reports, but including upgrades to existing modified Dynamics GP reports. Not necessarily task by task, but area by area thinking about the project at a high level.
- Keep estimates at a high level, striking a balance between assuming complex issues would occur and hoping that everything goes smoothly. Yes, this is easier said than done. So, I reviewed the modified reports to make sure there was nothing extreme involved but I did not go field by field to determine what would need to be addressed in the upgrade. Considering past upgrades, I then came up with a number that will hopefully allow for some issues without being blown away. The customization functionality is reviewed relative to upgrade enhancements. If a customization interacts with new/upgraded functionality, then chances are the upgrade of the customization will be more intensive than if it affects functionality that has stayed the same.
- Gather all of the basic information for the upgrade including number of companies, number of workstations, and training requirements. Estimates for these items usually come easier to me, given that there aren't dramatic changes in the amount of time it takes to upgrade a company or install a workstation.
- Ask for feedback from those that do the work. I know this sounds obvious, but I will admit to sometimes thinking that I know more than I do :) So, I ask the developer, the upgrade person, etc for their feedback on whether the numbers look realistic.
- Disclose my expectations of the high level estimate to the customer, and ask for theirs. I don't know that there is much more to add :) But if we are on the same page, it minimizes the chance of confusion and frustration if the full project planning for the upgrade results in a different estimate.
So, in the end, I strive for realistic numbers but not necessarily identifying every potential risk and task that the project may include. The result being an estimate that is hopefully close to the end result for the scope proposed (but not including additional items, tasks, or revision to scope). And I had a bit of an epiphany as I completed it. A high-level estimate is only as good as our relationship with the client. If both parties feel that it is approached in good faith, and a relative level of due-diligence is applied on both sides, then the estimate becomes an initial step in the project planning for the upgrade. If the relationship is not positive, then the estimate simply becomes a trap for both client and consultant which can lead to frustration and distrust during the upgrade process and on future projects.
What do you think? What are your tips and tricks for preparing high level estimates without spending a disproportinate amount of time on them? Customers, what are your expectations when you ask for a high level estimate?
2 comments:
Well said. Another option that I have had to exercise is to simply decline requests for such "high level" estimates where I had insufficient information.
I was recently asked to provide a "ballpark" or "order of magnitude" estimate for a custom integration to replace an Integration Manager budget integration that was taking over 20 hours to run.
Since that was all the information that I was given, I declined to offer any estimate at all, and instead offered to have a call with the client to better understand their requirements and some of the issues that would likely need to be considered in such an estimate.
I feel it's better to spend some non-billable time gathering a few requirements and getting some background on a project than throwing out a wild uninformed guess that may set expectations with a client that eventually lead to dissatisfaction.
I completely agree, Steve :) I should have pointed out that generally a high level estimate for any customization/integration without some degree of scope definition/due diligence is pretty meaningless and (in my opinion) can only result in frustration for both the consultant and the client since the number is not rooted in anything factual. Of course, there are exceptions to this for training/implementation costs...where you can say "Implementing the GL module generally takes 12-16 hrs" or something to that effect as you already know some facts about the scope.
Post a Comment