Underneath every need is a problem. The problem is buried in misdirection and stories that have nothing to do with what is actually wrong. If you listen to the stories and solve what you think is the need you will be on the path of the never ending journey that solves nothing. Before you do anything. Find the problem. Dig dig dig. Ask 5 why’s. Then solve it.
The days of waiting for direction, standing by to be told what to do, or worst, throwing shit against the wall to get it off your plate and leave it for someone else to clean up, are over.
Today, we decide how we will get there, in synergy, with candor, taking bold steps that are synchronized, not directed, networked.
Reviews are expensive. Start with text, then simple wireframes, once agreed full colour mock ups, and then build it in html, JS, or whatever. Only bugs should be addressed at this final development stage. There should be no review changes after you start building because you caught them all in text, wireframes and mockups. You caught them when it was really cheap and easy to adjust and fix.
Whenever you post for review you open a new google doc if just starting, or the same doc you had the last review in, put today’s date right at the top, make it explicit as to who you want feedback from, you give everyone a reasonable deadline to respond by, and then you list all of the links to the review materials, and right below each link you tell your reviewers exactly what changed since the last review and finally what is still open to be changed or addressed.
As your reviewers add their comments you address and close all of them. You collate the feedback and confirm next steps.
You then repeat, adding the next review, with a date stamp, at the top of the doc, until everyone agrees it looks good and you can move to the next stage; wireframe, mockup or build it. The review doc should read like a diary of the review progress in descending order.
Solving the problem without solving the cause of the problem doesn't solve the problem,
Solving the cause of the problem without solving the structure that allowed the cause of the problem to exist, won't prevent the next problem,
Fixing the structure without knowing who owns it means no one is accountable for its maintenance and it will fail again,
Knowing who owns it without knowing if they have the resources to maintain it, means the whole exercise could be futile.
Figure out who is accountable, make sure they have the resources to get the work done, help them identify what’s wrong with the structure that caused the problem, eliminate that cause, fix the problem that was the result of all of this, and then, if worth it, get an indicator in place that is going to give an early warning if things start to go wrong again.
If we repeat an action more than twice, it should be a defined process.
If we define a process we must start with why? Why do we do what we do?
More often than expected there is no reason to do what we do.
Byron Darlison