Jumping to solutions

Is there a less respected 101 rule than this one?

To be fair.

'Jumping to solutions' will often get you somewhere, although with some bruises and lighter pockets than expected

…oh and that one important objective we couldn't realize (it's ok, let's put it as a mini-project in the backlog 😉)

But it's also because thinking entirely in abstracts without putting a form to something is a difficult mental exercise.

And in the end, concreteness is the goal. We WANT to think of how great and amazing our solution will be.

Yet it remains that a proper exercise of requirements gathering and mapping before jumping to solutions can yield immense benefits when done right.

I find one of the most defining skills I developed as a BA over the years is to think abstractly and develop a mental model of processes, stakeholders and business objectives.

It's a mindset fundamentally at the core of the BA role uniquely tuned to the exercise of gathering requirements and objectives.

A requirements gathering effort will never be perfect and shouldn't unreasonably delay a project but the exercise deserves its place.

To quote an infamous proverb of the Navy Seals (who know something about urgency)

Slow is smooth, smooth is fast