I support a large enterprise software project which frequently receives enhancement requests from our customer. The customer will only pay for the work up front in fixed-price contracts. We provide a SWAG estimate first, then provide a detailed estimate after they green light the SWAG. The detailed estimates are time consuming and we are only compensated for the estimation time when they sign off on the enhancement, so the SWAG estimate provides a level of protection for us.
We communicate our SWAG estimate as Small, Medium, Large, or Very Large, and we have communicated ranges associated with each of these values. For example,
Small: < 5 days
Medium: 5 - 15 days
Large: 15 - 50 days
Very Large: > 50 days
Having put this into practice for a couple of years, I have some concerns:
- Sometimes the SWAG estimate is expected to be at the high end of a range. This form of estimate can make it difficult to manage customer expectations, a 15 day effort is very different from a 50 day effort, and the customer can green light a SWAG under the optimistic assumption.
- If the customer approves of a SWAG estimate, we can feel obliged to cap our detailed estimate at the high range of the SWAG. If we move up a range then there are usually additional billing discussions which are painful, slow, and lacking guarantees for compensation.
Are there any kind of standard practices, or tried and true methods for communicating SWAGs that can help us better manage customer expectations?
Is it better to use use ranges on a per case basis, rather than the fixed ranges that I have noted? Should I switch to single number instead of a range?
Best Answer
There's actually an old approach that addresses this kind of problem that comes from the PERT and CPM practices. You might get resistance if you mention that since this is associated with waterfall and PMI. But it really has nothing to do with waterfall and I haven't seen much evidence that certified project managers know anything about it (despite it being part of certification).
You come up with 2 or 3 estimates for each item. You give a best-case scenario i.e. in lower bound i.e it will not get done faster than this. Then you come up with a high-end estimate i.e. it should never take long than that. Optionally, you provide a 'best-guess' estimate that falls somewhere in between. This helps to weight the estimate towards the high or low end but it's not strictly needed. You do this for each high-level deliverable. Part of what people get wrong about this approach is they try to do it at an extremely fine-grained level. That doesn't work / isn't worth the effort.
Then you lay out and dependencies and using a well-known algorithm, you can come up with an overall estimate with a confidence level for the entire bundle. One thing that's good to understand that the more items you estimate this way, the more reliable the overall estimate as things tend to even out.
You could use this approach with t-shirt sizes for the component deliverables. If the ranges are pretty reliable, then it should be fine. Some people may try to tell you that this is incompatible with agile methodologies but that's really not the case. It's simply a way to take a bunch of estimates and turn it into a composite one using well-studied statistical approaches. Really good agile practitioners use statistical methods. It's generally not something most of the team sees, however, and much of Agile has become simply a cargo-cult process.