Vision is a recursive loop

In my previous article here, I explained how to plan and execute when we have to develop an evolvable product. This kind of planning is mostly called as forward planning. It begins with determining end goal and then starts with design, estimates, POC, plans etc. to achieve the goal.

There is, however, another way to create the same plan and artifacts, generally called backward or reverse planning . Let me put down my chain of thoughts here and see if it resonates with you and help you create your own framework for planning.

Everything starts with Vision. Purists do not want to mix vision with goal, but I would use them interchangeably here. A vision can be described by answering 3 questions.

1. What to deliver (The Artifact)
2. When to deliver (Timeline)
3. How to measure outcome (Quality)

I will explain all three below in the context of delivery stage. And before I go deeper into them let me throw two more tools which help in backward planning.

1. Risks and mitigations
2. Dependencies and resolutions

Now that we have all the jargons in place, let me decode the title of the article. Every project goes through multiple stages and each has its own vision and goal. The vision of immediate lower stage is the dependency of current stage. So, if we keep defining dependencies of current stage (which is vision of previous stage) and create a plan to resolve them then we recursively reach to the vision of the lowest stage(Dev/QA). This way we create an execution plan which is tightly mapped to the final goal (well.. is there a final goal or a final vision? :)).

Let's try to understand this with an example - Phase 1 prod deployment(current goal) and its dependencies.

Let's use the three tools mentioned above to define our vision.

Artifacts : The artifact requirement can be the executables which are to be deployed on production.

• Dependencies : The dependencies are a) the executables should have been deployed on UAT, b) it should be tested and certified by users and c) there should be a CD pipeline to deploy the same artifact on production as well. And if we have a plan to resolve them then we are ready for the production.
• Risks : Risks could be that there is no automation test suite to test all the scenarios. And this could be mitigated by planning on bringing in more people to do manual testing.

Timeline : The timeline requirement is to have a deployment date.

• Dependencies : The dependencies are a) there should be a runbook to deploy it on production and b) the UAT is completed on time. And if we have a plan to resolve them then we are ready for the production.
• Risks : The risk could be that users need a day more to complete their tests. And the mitigation would be go ahead with deployment and users test in parallel. If there are issues then there should be a rollback script to rollback in time.

Quality : The quality requirement is to have a reliable and functionally aligned with business user requirements.

• Dependencies : The dependencies are a) Users should have tested it against the requirements shared by them on UAT and b) there should be report for reliability test done either on UAT or a lower environment. And if we have a plan to resolve them then we are ready for the production.
• Risks : There could be a scenario which was missed and the mitigation could be understanding from users if that can be fixed and deployed a week later.

So, the bottom-line is - If we have a plan to resolve dependencies of current stage (which is the goal of previous stage) and mitigation plan for the risks, we can recursively create a plan for the smallest of the delivery and that delivery would be tied to the final goal.

A vision is a vision of a vision.