DEFINING YOUR PROJECT DELIVERY
It is easy to lose your way at the very start of strategic planning of the project portfolio.
​
As the first hazy outlines of new ideas and opportunities start to form, the excitement of discovering them can draw you into charging forward toward them.
Every company can pull together a history of projects that either failed to deliver on their original promise, or those that failed completely and faded from view. Often there is a healthy dose of hindsight applied, with judgment on the competence of those involved, and that they had been bad ideas that should never have been attempted.
But they were.
​
How certain are you that your current team are any more able to pick the winning projects than the teams of the past? If you consider the project selection decision making processes that those earlier teams took, are the methods that you use significantly different. If you had been presented the initial information that they were, would you have really followed a different path.
It is obvious that leaping into projects prematurely, no matter how compelling they seem, can be inefficient and potentially lead to a waste of time and resources. Even more damaging are the missed opportunities to have pursued the right projects.
If you’ve read our previous articles, it should come as no surprise that the best way to avoid this is with the consistent application of processes that monitor delivery against expectations and will identify and correct a project that is heading in the wrong direction.
The appropriate delivery process will include check points to ensure that each project remains healthy and on course, but there is not one delivery process that will suit all types of project.
So, we need to start with a method to sort the projects to match the most appropriate delivery process.
​
Delivery channels
​
There are countless development processes; there are often multiple processes within most companies.
We will pull them into three broad categories: operational, introduction, and Innovation.
This separation is determined by how well defined the deliverables of the project are and the workstreams that will be used to deliver the projects - the methods that each stream uses to allocate and manage projects.
​
When considering risks, you can consider them to be either “known unknowns” or “unknown unknowns.” If you can identify most of the ways in which a project could go wrong, you can consider those to be “known unknowns.” You can then build a risk management process that will mitigate or eliminate them.
If you are trying something particularly novel, you potentially won’t know if it will even work; you may not know specifically what will go wrong, but you suspect that something will. These are the “unknown unknowns.”
​
Innovation projects are those where there are significant “unknown unknowns.”
The project may not have an end to end process with pre-determined outcomes or objectives at each stage but will be a journey of discovery through a series of technology proving gateways.
There may be unproven features or benefits that you expect. Innovation projects are usually structured so that gateways will be passed with the demonstration of one or more of those features. You are likely to be using a fail fast process that re-targets the project for subsequent stages. The overall goal is to create a shelf-ready piece of technology that can then be implemented though an introduction project.
​
Introduction projects have a defined timeline, scope of delivery, and will have resources allocated that can deliver the scope within the timeline. The risks that the project is expected to encounter are the “known unknowns.” The team knows what the likely risks are and have stable management plans. Their delivery is not only well defined, but also protected from outside priorities resulting in an achievable, committed project plan.
​
The operational projects tend to be smaller, less complex projects. Their objectives will typically include local process improvements, enhancements to products or markets, or quality investigations and fixes. These will be well defined projects but are likely to be managed alongside the current product support activities and may be subject to a dynamic system of priorities. The projects may be sorted into a delivery hopper until resource is available and may potentially be paused once started as a higher priority operational project is identified.
​
Types of work
With the processes defined, you now need to define the type of work you are considering. The most effective way to do this is to sort the work into either product development or market development.
Product development relates to changes to any aspect of the actual product that you create. This includes everything that you offer the customer including hardware, software, services, and aftersales support.
Market development relates to any changes you make to the intended recipient of your product. This may be the location you sell to, the age group, or the pricing strategy.
​
Bringing it together
We now have three separate elements that we need to bring together: the process you will be using, changes to the product, and changes to the market. Of course, it’s possible that you will be changing both the product and the market at the same time, adding a further complication.
We will build on the well established Ansoff matrix, also known as a growth matrix, to provide a map between each of these concepts.
​
We will divide product development to three levels. The first level is to have no significant change to the current product. The second level is an iterative change to the product, and the third is a complete change
Every product and process should be in a continuous cycle of improvement.
Any product you offer will either have opportunities for improvements or may require you to respond to quality issues. There will be initial stages of those processes that will further define the opportunities: quality issues will start with defining the specific issue, improvements will start with quantifying which improvements will be made. The point here is that you know what the problems are, and you will have clearly defined processes to deliver them through projects with defined scope.
An iterative product change will have a known project delivery workstream, such as NPI (New Product Introduction), with committed resources and timeline. The expected product may be different, but the problems that you expect to face, either in delivery or technical challenge, are known and have risk management plans in place.
​
A completely new product development may have a loose definition of the output, or be subject to unclear risks, but it will have a defined delivery process to ensure that new information and decisions are managed in a controlled manner, whether it is the discovery of a new opportunity or the occurrence of a new problem.
We can map market development into the same three categories on the vertical axis to create a 3x3 grid.
This is a perfect opportunity to get lost in debates about how a project should be classified and for this entire process to stall. While there is some subjectivity and blurring of the edges between the categories, you must remember that the purpose of this exercise is to map the projects into the process that will be used to implement them.
​
So, before we start adding the projects, we will add the workflows to the grid. This should help you with most classification issues: you should know which team is best placed to deliver each project.
Adding projects
Your teams can now start mapping their lists of projects based on their understanding of the level of change and the level of uncertainty and map them to the delivery workstreams.
In this case, Projects A, and B are projects with development of the products, but with no change to the market that the products are being offered in. Project A is an innovative new product, and project B is an upgrade to an existing product.
​
Projects D, and E are projects where the market is being developed for existing products, perhaps project D is a revised pricing or targeting strategy, and project E is an entry into a new geographic location.
Projects F and G are combinations of revised products and revised markets.
​
Project C is a project where neither the product or the market are undergoing significant change, perhaps there is a quality fix to be investigated, some minor product improvements or a manufacturing process change to be implemented.
If you show the workstream overlay on the projects, you can see that the operational workstream has project C to deliver. The introduction workstream has projects B, D, and F. The innovation workstream has projects A, E, and G to deliver.
At this point, you can reconsider the edge cases that were mentioned above, those projects that could be delivered in more than one of the workflows. The number of projects being requested of different teams may need balancing.
You should not expect this to be a magic process that solves all your project selection automatically. The value of tools like this is not whether they give you a shortcut through your strategic planning process. The value is in how they help you consider the projects that you are mapping: filling out the grid is secondary to how you reflect on whether a delivery process is appropriate based on the nature of the work and the uncertainty in each project.
