Last time we were talking about Aggressive and Invested Requirements Gathering. It was all about taking ownership and putting some passion into figuring out what this thing needs to be so that you get it right and you make something you and the client can take pride in.
This time we’re getting into the fun part - the brainstorming period. We like to call it “Relentless Ideation”. Ideation is a fancy word for brainstorming, conceptualizing, dreaming, etc. But just like requirements gathering, everyone does those things in some form or another and understands the concept. It’s the relentless component that gets me excited. Here at Ashday, we really run the ideas through the paces, mainly because we’re obsessively particular and don’t like to live with ambiguity and we don’t like feeling arbitrarily optimistic about our ideas.
Here’s the shape it generally takes.
If no question is a dumb question, that alludes to the fact that some ideas are dumb ideas. Ok, maybe not dumb - but ill-fitting or inappropriate most certainly. We ask a lot of probing questions when we’re brainstorming - of ourselves and the client - because we want to nail it at launch and we also want to nail it a year later. It may start at “We could use the domain access module for this!”, but it quickly turns to “Are their other modules or solutions we may possibly use that aren’t compatible with domain access and what happens if they want to upgrade to Drupal 8 next year?”. This is because we don’t want to paint ourselves in a corner and we want to also have a larger guidance in place as we make a bunch of those small daily decisions during build-out.
Estimating is an amazing tool regardless if you are doing fixed-bid work or asked for cost in advance. We team-estimate everything at Ashday using Planning Poker (unless utterly impractical due to extreme scheduling/budget constraints) because it guides our developers, it creates an easy check in point, it gives quick oversight of progress, and it aids in our scheduling. It also sorts out a lot of inconsistent understandings and promotes idea sharing because if people disagree on the time, it usually means there are unspoken requirements or technical understandings that need to be brought to light.
We approach most things with a pessimistic attitude. Not of our ability, but of what can possibly go wrong. So what if the stakeholder says they don’t need this but then change their mind? Does that mean a 10% refactor cost or 90%? What if the client wants to be able to edit something we currently handle? Is that near impossible or does that require a small bit of additional work? These types of keep-you-up-at-night risk-based questions guide a lot of our decisions because if there’s one thing we’ve learned - you never know the future and no one ever fully knows what they want. Factoring in risk in all significant decisions reduces this stress immensely.
So there you have it. You can start to see a theme developing throughout the project of heavy investment in what we’re doing and digging deep into all the corners. That will continue in the next part of the series as we start to talk about preparing for the build out. Can’t wait!
UP NEXT: Web Design & Development Process: Part 3 - Atomic Preparation