Act number 3, doing da plan, a.k.a ‘Planning’ This is the stage where you Plan on how to act on the input of the previous two (Identify, Define) and prepare for successful execution. This is the place where the number of questions will (and must) grow exponentially. The latter is related to how well you did during the Identify and Define phases. The less you did there, the more you’ll have to do here. The Plan stage is the time to let everybody ask, wonder, ponder, challenge, defy, disagree, go crazy. The other two stages matter a lot but this one is the key, a cross-point. Fucking up here will most likely fuck up the whole project. Be it delays due underestimation, faulty designs that need to be redone, or worst of all – vital piece of functionality missing or being so fragile it is unusable.
Here you have to take into account security (you don’t want service abuse), availability, reliability, scalability, performance. Depending on the context you may wish to clear out the user flow, how people would be doing things and to what outcome. It’s a must to focus on the alignment as well. Every builder, engineer, team member, anyone involved – MUST BE aligned about the desired outcomes, the reasons, the goals. This does not mean to be parrot who repeats over and over again the same shit (lots of companies do that), it means that you must ensure that everyone is aware-aware while accepting that at least 60% of the people won’t be.
Here you’ll have to identify and define the MPVs of the MPVs of the MPVs and be thorough about it. Tech, time, budget savvy. You’ll have to think how things should be prepared in a way that enables adequate execution, and the execution is where 99% of all projects die. Painfully. Why? Various reasons, some of which are due fucked, shallow and subpar planning.
During the Plan act, one can discover that the Identify and Define phases were pure crap, ambiguous, unclear, arbitrary, poorly executed. Better sound the alarm early on instead of waiting for the crash. It is not fun to work on something that will fail in dull ways (fun fail is a win).
Just like in the other posts – this one is incomplete and a bit superficial but hopefully providing good enough idea.
In our case, during this phase one must:
- understand what work would be actually required
- how long it would take (then multiply by 0.2, to be more realistic)
- what was missed but matters – capture, prioritize, figure out if/when to address
- cut the crap and focus on the MVP, size does matter, small but working is better than big and limp