Nobody likes problems during a project. But if you come in to a project thinking that it’s going to be perfect during UAT, or even after launch, you’re always going to be sorely disappointed.
Project budgeting
Risk averse organizations, or project managers that try to pre-plan for every bit of time against a set of granular tasks tend to stifle project progress. That’s just not how real projects happen.
As you plan your project, add a user story within each epic for risk, or unallocated time. The amount of risk (% of the development estimate) should consider real world factors - how many times have you done this type of task before, does it have 3rd party dependencies, etc. As you need to borrow from the risk bucket, deduct time from the bucket and add it to the needed task. Tracking where you need to borrow from risk will make you a better estimator in future projects. If you plan for the unexpected, you’ll be better prepared to handle issues as they come up. That covers the budget side.
Expectation management
The next side is client/stakeholder expectation management. It’s helpful to get the project team aligned with the expectation that we will do some level of running with scissors throughout the course of the project. We may even have to build small bits of functionality twice, because we got it wrong. In my experience, that approach produces a better project, a better product at the end, and at a lower cost. One would think, documenting functionality down to the most granular level would take the risk out of a project and produce a better first time deliverable. What we’ve found, is that overhead associated with that causes the project to drag out to the point that things change during the project.
The other thing that happens, is that users/stakeholders don’t really get to try out parts of the project until they’re built. Dynamic prototyping solutions like InVision can help make prototypes more realistic, but most front-end designers don’t have the time (budget) to build in all the dynamic interactions that makes the prototype real. Even the best wire frames and prototypes are only a facsimile of how your system is going to function once it’s built — Just like a paper map is only a facsimile of the real world world.
Set stakeholder expectations at the beginning of the project. If you’re bringing them into a work-in-progress view of the project, make sure they know what you think works, vs. what definitely isn’t ready. Give them an easy way to give you feedback - We use mostly video for stakeholder feedback.
The last thought - Make sure you invite the right kind of customers / stakeholders to the project. In his book, The Messy Middle, Scott Belsky speaks to this. He groups customers into the Willing / Forgiving / Viral / Valuable / Profitable.
“At first you want customers who are more akin to testers, willing to try, and likely suffer through, the barely viable version of your product. Then you want customers who may not be testers, but are forgiving of the inevitable bugs and gaps in a new product.”
Pick your stakeholders carefully, to make sure you get the kind of feedback you need.