Planning an initiative
Whatever we people do; planning is always a necessity. The more people that are working together, the more and better planning we need of the activities we need to do. All in order to avoid waste of people and material, which in the bottom end adds up to waste of time, money and the resources of earth.
But of course, we always need to understand the context of our activities, to be able to understand which activities are plannable, their possible accuracy, and which activities that are unplannable. A good rule of thumb is that the more complex an activity is, the more knowledge we need and the more unplannable length it has, maybe it is not possible to perform. Another good rule of thumb (and common sense), is that the further a planned activity is, the less accurate we can plan it in time. Here we also need to take into account that the further the activity is, the more uncertainty we also increase, since people can quit, competitors accelerate, new technology appear, etc. This indirectly means that the time range for the finishing increases for any initiative, both regarding start time of the activity and the length of the activity, even in a non-complex context.
As introduced in Planning from the purpose needed, with the term "scaling down", we therefore need to plan every initiative with a top-down approach, where we take both the functional and non-functional requirements into consideration to make a proper systems design, please see the page systems designed architecture for further information and details.
Since it in big systems will be many components, there will be many teams that are developing the system at the same time, where every team and their component in turn can require systems design within the component. Having many teams makes it important to have an interdependency and delivery board to keep track of all the dependencies, interdependencies and deliveries between the teams and the deliveries to outside the team-of-teams' constellation. Very big systems require many team-of-teams' constellations to deliver, which in turn requires an interdependency and delivery board on also on the wholeness level. In extreme cases, for example with development of concurrent software, hardware and firmware, there may be another level. But, with the scaling down approach, any appropriate number of levels can be used.
A release plan is also a suitable planning tool that shows the different output from the initiative in the future, when sub-releases are possible. A visual release plan is also a terrific communication tool to management and the rest of the organization. It is then possible to be updated with what is the coming output, and when, from any initiative, as well as track the progress, until the final release. If release on demand is a necessity for the customers, that can also with short notice be added to the release plan.
Every level also needs to keep track of their own backlog, which can be of different kind, like; incidents, maintenance, further enhancement and completely new products (systems).