Strategic Project Planning
index
In my experience I’ve seen the effects of good and bad planning on product outcomes. Good plans and their execution follow a set of specific steps that relate and depend on each other. These steps form a process which I call strategic project planning. The steps of this process are:
1. Goal formulation
2. Research
3. Planning
4. Execution
5. Assessment
For projects in large-scale highly complex domains these steps often have to be repeated iteratively over time. In that case step five returns to step one and information from the previous iteration is used to reformulate the goal, researchers investigate how past progress (or failure) informs the next plan, and execution begins again. As such, strategic project planning produces a feedback loop that guides a high level initiative toward its goal.
**Goal formulation**
Before a project is started it is necessary to devote some time and thought to the goal of the project. This step is often overlooked if the goal seems obvious, but it is important not to skip it for a number of reasons. First, mistakes at this stage will propagate down through successive stages and ruin the project or limit its success. People often start with the solution to a problem and call that the goal, but this approach leapfrogs the research step and in doing so dispenses with all the value gained at that step. Goal formulation allows researchers to work out the domain of possible solutions and identify the best options. Clarity around the actual goal is also necessary for decoupling the evaluation of execution from the assessment of project success, which constitute two different standards of measurement. This can be understood simply by recognizing that one may choose the wrong solution, execute it successfully, and find in the end that your goal has not been reached. Explicit goal formulation prevents this confusing situation by identifying a high-level goal with its own success criteria before researchers and planners start thinking about a specific solution.
**Research**
When the goal of the project is clearly formulated, you may proceed to the research stage. The kind of research required will vary depending on the nature and scale of the project. At a high level, research provides planners with project requirements and measurable outcomes that will be used to assess project execution. For example, if your goal is to increase the efficiency of a process, then research can provide metrics on time and resources used by the target process and a guideline for expected attainable improvement. A description or diagram of the process can help planners determine how best to streamline the process without impacting the quality of its output. Research and planning are closely related, as the researchers provide the raw materials used by planners to understand the domain and model solutions.
If a project domain is complex enough, it may be necessary to have a trial run of project execution. In software development requirements research is sometimes followed by a minimum viable product (MVP) launch which is a simple product that meets the requirements. If the MVP is successful then a plan is made for turning the MVP into a proper product. If the MVP fails, that failure hopefully provides valuable information to the researchers about what a successful product will look like, and the planners can use that new information to change course.
The MPV strategy is a special case of iterative planning where a compressed version of the entire process is carried out inside of the research step. This variant of project planning looks something like this:
1. Goal formulation
2. Research
a. Initial research and requirements
b. mvp plan
c. mvp execution
d. trial run
e. assessment
3. Product plan
4. Execution
5. Assessment
**Planning**
Project plans are useful for budgeting, for the coordination of individuals over time, and for establishing assessment expectations. A plan helps an organization understand when and in what amounts individuals and resources should be allocated to a project. If resources are requested as needed instead of in advance it will take time to acquire them (if they are available at all) which will stall execution. Project plans facilitate coordination by revealing if and when the project will have impact across the organization and what kinds of collaboration will be beneficial. In the absence of a plan, other teams may be blindsided by project impacts which they did not expect. Finally, a plan gives the organization expectations about when to assess progress. If the assessment schedule is dictated arbitrarily instead of derived from the project plan, then assessments may be made at inappropriate times. This could lead to incorrect or low-quality assessments and may even damage relationships within the organization.
While plans vary greatly according to the nature and scope of the project, it is a general rule that foundational work should be identified and placed at the beginning. It can be tempting to fast track directly to the project components that bring value, as early progress makes project execution look good. This is unwise. Foundations reduce the cost of later work in the project and often reduce the cost of downstream projects within the same domain. If there are changes in project requirements it is likely that the foundation may be reused, but work done to implement requirements directly will be thrown out. An additional benefit of putting foundational work at the forefront of planning is that it allows the organization to identify shared foundations and eliminate duplicate work across multiple projects. The challenge here is that broadly useful foundations require more time and resources to develop, so the planner must balance these tradeoffs when choosing the appropriate foundation.
**Iterative Planning**
In large scale complex environments it may be necessary to repeat this entire process iteratively to achieve the project goal. Causal networks may be orders of magnitude more complex than the system itself defined in terms of its components, and as a result it is common to dramatically underestimate the complexity of interactions in large systems. Causality and determination are surprisingly complicated even in simple systems, and the intractability of casual networks in large complex systems makes prediction of project effects difficult. As a result, research and planning will necessarily have gaps and mistakes.
When faced with such uncertainty it is advantageous to break the project into deliverable chunks. The first deliverable contains the smallest set of core product functionality required to begin operations. After each deliverable, primary and secondary effects can be observed and gaps in knowledge gradually filled in. The plan for the next deliverable is adjusted according to the outcome of the previous one. If the product is small enough to be delivered in a single iteration, subsequent iterations are confined to product research and planning around additions, adjustments, and assessment of project outcomes.
Changes in the project domain as a result of project execution may challenge the project goal itself. For this reason it is necessary not only to repeat research and planning but also to revisit the goals of the project and re-assess whether or not the guidance provided by them still make sense given the observed changes. This is especially true when there are other projects or processes (known and unknown) simultaneously perturbing the domain and affecting project outcomes. Iteration integrates the observation of secondary effects and system changes into the project planning process and in this way the goals of the project can be checked against project outcomes within a changing system over time.
**Execution and Assessment**
Execution by itself is very project specific. Whatever kind of work that needs to be done to execute the project should be done and the project can move to the assessment phase. The first step of assessment is to determine whether or not the project was an overall success, which provides a frame of reference for the rest of the discussion. For example, successful projects have risks and failure modes, but if you have not established project status first then the discussion of these problems may be incorrectly interpreted as signifying project failure. The evaluation of project success provides the context for further assessment, helps determine who is responsible for that assessment, and guides the individuals carrying it out toward a useful outcome.
If a project is successful, further assessment can be used to develop a plan for maintenance and monitoring. The assessment of risks and failure modes will inform staffing and other resource requirements for the prevention of disruptive incidents. Organizational leaders and researchers may take stock of progress gained in order to begin the planning process for the next project. If the project is not successful then ideally you can figure out at what step things went wrong. The strategic project planning process allows the contribution of each step to be clearly evaluated in light of project outcomes. Knowledge gained of the project domain in the process of project execution can also be used to identify mistaken assumptions. Whatever the problem is, failure assessment should be aimed at deepening organizational knowledge and improving the project planning process for future projects.
**Conclusion**
The five steps outlined above describe a process for formulating a desirable outcome, identifying the best way to achieve that outcome in a particular domain, making a plan for executing a project, and finally assessing whether or not project execution brought about the desired outcome. Irrespective of whether or not this process is able to be followed exactly, it may be used as a guide for finding the best way to operate when taking part in projects of any kind. No matter what step of the process you are responsible for, the resources available may be utilized more effectively using the lens of strategic project planning, and the comparative advantages and disadvantages of an imperfect process can be ascertained and accounted for.