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?