I wholly believe George Patton in that:
A good plan violently executed now is better than a perfect plan executed next week.
Of course, taking action does not always bear fruit, and I’ve certainly wasted time and burned myself out by working hard but getting little accomplished.
We’ve all had unclear direction, vague requirements and such; most times this boils down to having a problem with no input on how it might be solved. Perhaps, the customer doesn’t even know where to start.
In these cases we must constantly validate our course of action with our stakeholders. We should not be spending any large amount of time without gathering feedback and having a conversation with those that will live with the solution.
One of the things computer professionals struggle with is that we live in a high definition world, and as such we tend to go right for the keyboard. However, given the need for fast and constant feedback, the keyboard is not the place for us to start. That is to say, we turn off Word, Visio and the IDE and get back to paper and pens and validate early and often. Are we on the right path? Fire, motion and validation.
Here is an example:
We recently kicked off a small but highly visible project where a business unit wants to remove a hugely unproductive paper process. They are not however, the end customer, or the only office that our solution would affect. We weren’t given a lot of detail, just the basic problem facts and a few bits of information we might use to make the whole process paperless and more efficient.
Our first meeting started with a few core team members, and the talk quickly devolved into process questions, about who needed to be involved, etc. Engineers grumbled that none of this would get the problem solved and basically, we stalemated just 20 minutes into our first meeting.
Hold up. Stop. Wrong approach.
We fetched a ream of copy paper, white board markers for all in attendance, and forced everyone to flip chart out what they envisioned the final software would look like to anyone using it for the first time.
An hour later we had an initial prototype consisting of nothing more than a roughly drawn stack of paper, but which consisted of the best of each person’s individual vision. We immediately took this to other stakeholder teams, and to the customers who would use this and walked them through our proposed process.
We took that feedback, adjusted and adjusted again.
One week later, we have a 95% prototype, have mocked things up in actual HTML and are ready to do the road show with stakeholders again. Although we drastically reduced our rework (rework up until this point has been redrawing a couple of pages), the team would say being able to show other stakeholders how things will work whilst not actually showing them “what it will look like” helped us gather consensus and refine our design.
Invest in the Sharpie, it has consistently saved us time and gotten people on board more than any application ever could have done.