I’ve never really had a problem running waterfall projects because I think I understand how to manage expectations.
Whenever I do process design, I make sure I get plenty of time to:
1. make mock-ups
2. identify various scenarios and use cases, and storyboard them out.
By the time I’ve walked them through the design, the mock-ups, the use cases at design sign-off time, they will have a pretty good idea of how they will be using the system.
We didn’t do many in-build demos or show & tells then (because we didn’t price it in) but I’d get snapshots of screens, or talk through where we’ve got to at regular intervals.
I know that not many people do that, and not many clients will pay a Consulting Partner for a Business Analyst activity on top of a CRM Functional design and Requirement gathering task a Consultant is meant to do.
Luckily, I am charming, and persuasive, so I do get away with quite a lot.
The key message here is – it isn’t the framework, or methodology that’s defective.
It’s making sure we are on the same page.
It’s making sure that we go beyond the words on the document, and the slides on the wall, that we truly understand.
That’s why Agile’s frequent Show & Tell’s or Demo’s work so well in aligning expectations with users and stakeholders.
That’s when everyone can see what they’re getting, and have the opportunity to provide feedback and shape the final outcome.
Users become excited, engaged, invested.
Frequent check-ins like this mean that we can avoid surprises, or meetings where we get ‘blindsided’ by something we should have seen coming from a mile away.