Choosing the right project
Choosing the right project may seem trivial. No one would propose a project that is not the right project, would they? In order to answer that question, we must first consider what is right, i.e. what is right from an organizational perspective. The decision as to what is right is made by what long-term and short-term goals the organization has and which strategies are in place. To be chosen and become a part of the organization's project portfolio, the project must contribute to the goals and strategies. I would argue that a project that will deliver a very high yield should not be carried out if it does not also contribute to the organization's strategic direction and goals. In order to choose this project, the goals and strategies should first be changed, and if you are not willing to do that then the project should not be started.
There are many examples of product ideas that did not lie within the company's strategic direction and were sold to outside parties or carried out by a group of employees that started their own company where the product became very successful. Perhaps the strategy should have been changed to include this new line of business?
The number of examples of projects that did not support business strategies, but were still started, is even bigger. Often the combined total of the effects on the organization were negative and at times even devastating. The effects might be that the organization becomes sprawling and diversified and that more and more resources go toward coordinating the business. Other effects include spending enormous resources on projects that would either never be finished or not deliver any benefits equal to the cost even if they are finished.
To choose the right project, the organization has to have established goals and an established strategy. I would argue that practically all organizations have them even if they are not documented in nice sounding phrases and attractively packaged in glossy brochures. The way in which goals and strategies have been produced or, rather, developed over time is another question of great importance, not least for how wide-spread and accepted they are. This has been discussed in a variety of articles and books and will not be dealt with here.
Another aspect of choosing the right project is striving to have a balanced portfolio. The meaning of "balanced" varies between different kinds of organizations and between different organizations in the same industry-it is an individual consideration. Essentially, balanced means not putting all your eggs in the same basket but instead distributing your portfolio in ways that include:
- Short and long term
- Maintenance and new development
- Modifying existing products and developing completely new products
- Developing both existing customers and new markets
- Streamlining the workday and future changes in technology
The first section of the points listed above must be in place to successfully navigate the second section. At the same time, you cannot focus solely on this because then there will be nothing to create the organization's future and long-term survival. There has to be a balance.
Choosing projects and programs to be included in the organization's project portfolio also means choosing those that will not be included. You cannot include all of them, and the organization also has to actively exclude the projects that will no longer contribute to its goals and strategies. Some projects may need to be excluded due to the fact that the organization's goals and strategies have changed and the project has changed by shifting the scope, increasing costs, or falling behind on a schedule that has a "best before" date.
In conclusion, the projects and programs you choose must correspond to the organization's goals and strategies; otherwise, resources are being spent on areas that are not part of the organization's area of interest and that will take resources away from the organization's target business. The organization has to survive in the short term if it is to have a future, but to reach that future there have to be projects and programs that create that future and the organization's part in it. There are a number of ways to weigh different aspects in order to determine whether a project should be included in the portfolio or not. It is important to do this in a consistent, conscious, and communicated manner. |
Setting the right priorities
All organizations live with some form of limited resources and have to budget important resources. Resources often take the form of money, funds for the business. But there are also limited resources such as people, knowledge, skills, critical raw materials, etc. Therefore, it is not only important to choose the right project; you also have to be able to set the right priorities between your projects and programs in order to benefit as much as possible from your project portfolio as a whole.
Priorities can be expressed as a strict list, in which the highest priority is number 1 and all subsequent projects are ranked according to a falling scale. In such a list there is no discussion about which project has a higher priority than another project. Even if this method is the best and one you should aim to use, it is difficult to keep the list continuously updated with several projects. It is more common to divide projects into different priority categories. There should be at least five categories, preferably more. The following list is one common way of classifying priorities:
1. Absolutely essential projects. Projects that must be carried out in order to follow laws and regulations. If these projects are not carried out, the organization risks its very survival.
2. Top priority. Projects that are considered very important in order to successfully navigate the organization's strategies, and if they are not carried out it will not be possible to achieve the organization's strategic goals.
3. High priority. Projects deliver considerable benefits to the organization's strategies, but they are not alone in supporting those strategies.
4. Medium priority. Projects contribute to the strategies and will deliver important benefits to the organization (profit, savings, increased customer satisfaction, etc.).
5. Low priority. Projects deliver benefits to the organization (increased profit, savings, increased efficiency, etc.) but contribute little to the organization's strategies.
The majority of projects will normally end up in categories 3, 4, and 5. Three should only be a few occasional projects in category 2. Normally, the organization has no control over category 1. On the other hand, most of these projects can be divided into two or more projects so that only the specific part of the project that is necessary for the organization's survival is classified as priority 1.
The disadvantage of classifying priorities is that if there are conflicts between projects in the same category, the organization will still need to set its priorities, often without having the time to conduct an adequate analysis.
Starting projects
The fact that a project has been included in your portfolio and been classified with a certain priority does not necessarily mean that it will, or even should, be started. When selecting a start date you must take into consideration the other projects and programs in the portfolio, their priority, and the latest date when the different projects must be completed. There are absolutely essential projects that can be put on hold if the final completion date for the project minus the estimated project time for the project (i.e. latest start date) is some future date and if the organization's resources are already tied up in other projects, which may then be completed without interruption.
Sometimes the clearance to start a project will entail placing another project in savings mode or even temporarily suspending it.
Making decisions at the right time
Most project models have fixed decision points or "toll gates". The most common decision points usually include the following:
1. To initiate the project, i.e. to include a project idea in the portfolio. Often called BP0.
2. To start planning or set-up, BP1.
3. To begin execution, BP2.
4. At some larger milestone during execution, which is determined by the development process. This decision point is called BP3.
5. Once the project has delivered its final result and prior to the completion of the project, BP4.
6. Once the project is complete, all resources have been returned, and information retrieval is complete, BP5.
7. Once the result, benefit of the project has been secured, BP6.
Kjell Rodenstedt |