Something that we have struggled with is keep the expectations of shareholders realistic without making the project sound incredibly expensive before it even begins. I like using estimated range of costs, and I like what the the author say about how we only have enough information if the project budget is outside those bounds. But a problem I’ve experienced is that stakeholders balk at the higher-confidence but higher-cost upper bound estimate, while having a hard time accepting the uncertainty of being within those bounds. 

We’ve fortunately been able to build trust with a lot of our customers through our previous projects– trust that we are giving realistic estimated ranges and not trying to deceive or overbill them. Transparency along the way is necessary to maintain that trust that that we’re making convergent progress.

The Monday demo I’m about to give is one of the best (and fairly inexpensive) ways we are implement transparency. Nothing makes people feel better about spending money than seeing what that money is going towards. For a recent large project, we built a POC that showed them how we develop things and how we do “transparency”. Seeing weekly/biweekly releases and demos is sometimes a shock for a customer not used to scrum and gives them a lot of confidence that things will get done (or even if there are problems, it’s transparent and a resolution can be worked on very quickly).

Plus demos get us great feedback from the people who actually use and maintain the system.