On Spec resets and Re-iterations
Document re-iterations and resets feel like one of the most time-consuming and energy draining exercises that there is to encounter.
Having to reset means that most, if not all, of the work already done will be discarded. For the work that can be salvaged, energy must be spent rummaging through the words, ideas, and sentences that can still apply. Once new ideas are flushed out and applied, and ideas are carried over from the first set, then the re-work is done. While all this goes on, the time to completion has doubled. The ideas and final revisions go through the long process of approvals and reviews, and go through more iterations before the final product comes through.
Painful.
In economic terms, this is a terrible opportunity cost price to pay. Picture having these ideas reviewed early on, before any words and ideas are on paper, and all stakeholders have approved. The final edits are complete, reviewed as a formality, and the document is signed off and ready to go. Time can now be spent on working out other open issues, producing more documents, researching more features, and on quality areas.
Resets are so so so expensive.
Thus, avoiding resets and re-work needs to be a high priority topic and continue to be refined in the software development process. From my recent experiences, here are some ways to avoid resets and having to do major re-work.
1. Identify the right people approving your work early, and sit them down and get their ideas and buy-off on things. I did not do this soon enough and only too late into the process do I now face major feedback where things need to be re-written, and ideas need to be salvaged.
2. Understand your role and don’t sway from it. As a PM, your job is to ensure the functionality is complete, and aligns with the product vision. I spent too much time digging into the implementation details, and arguing about the best way to do things. If there are implementation questions, save that for the dev team to resolve.
3. Don’t start going into details until high-level ideas are completely bought off. I had a functional spec, and went deep into the details, only to realize that the supporting high-level scenarios may not apply, given the product vision. Now, all those details have gone to waste, and work is re-done. Now, don’t make the mistake of not WRITING THINGS DOWN. Just, make sure that everyone’s bought off into your vision before you write anything down. So, write down bulleted list or walkthrough on a slide deck, or create pictures, whatever works for you. But stay away from details until your high-level vision is achieved and everyone’s on the same page.
4. Do the right thing. It goes without saying that if you are implementing the right thing, then you likely won’t reset. Continue to ask yourself, what’s the customer value? What’s the best thing for customers? Why are things being done this way? What is the product vision? Does this align with the product vision? As long as you continually ask yourself these questions every few days, you will likely be on the right track to avoiding a reset.
5. Practice, and get feedback. If you find yourself resetting, figure out why. Look inside into yourself to see what you’re missing, what steps you’re skipping out on, where things are not going right. If you reset, it’s okay. Don’t expect to be perfect. Perfect is unattainable, for most normal people like us. But make it a goal to continue getting as close as you can.
Designing software is never an easy task, and resets are the most costly things that can happen to any of us. Delivering solid specs and documents that can quickly be signed off is one of the key attributes to a strong and successful PM.
