Don’t do anything without a clear purpose
You shouldn’t do anything unless it has a clear purpose. Imagine two parallel worlds where everything is the same except for the thing that you’re considering doing: How different would those worlds be? Is the difference worth the effort to do that thing?
If you don’t have a clear purpose in mind and are only doing something because everyone else is doing it, or everyone says that it’s important to do it, then
- it may not have a real benefit in your case, and therefore you may not get anything out of it; or
- it may still have potential benefits in your case, but because you don’t have the purpose in mind, your way of doing it may not help realize the benefits.
Example: Portfolios and programs
If you’re involved in selecting and initiating projects, you should make sure that you focus on the benefits and the problems that are required to be solved rather than the product that is going to realize those things. The classic example is the manufacturer of elevators who used to receive complaints about the speed of their elevators, and so had ran multiple projects to increase speed, without complete success. That continued until they decided to focus on the problem (people’s boredom or discomfort) instead of the “natural” solution (faster elevators). The result was that they added mirrors to elevators, and it solved the problem simply and cheaply.
Remember that project management is mainly about doing things right, while portfolio management is about doing the right things. It doesn’t matter how well you run your projects; it won’t work well if you’re doing the wrong projects. It’s all about having a purpose.
Example: Project as a whole
The flexibility of the product varies between projects. In some IT development projects, the product is completely flexible, and its final form depends on the feedback that will be generated by the increments of the product during the project, which requires an adaptive (Agile) approach. This is in practical terms a combination of the portfolio, program, and project layers, and needs maximum attention paid to the ultimate goal. It is a good idea to document the purpose and have it accessible; it’s one of the purposes of “product vision”, as used in some Scrum projects. The attention to business value in Agile projects is their way of ensuring alignment with purpose.
In other types of project, where the product is relatively fixed and there are other mechanisms to ensure that the identified product will satisfy the purpose, it’s possible for the project team members to shift a large part of their focus from the purpose to the product (hence the “focus on products” principle of PRINCE2®), but at least minimal attention to the purpose is still required to ensure that what is being built will satisfy the purpose, which can be done by comparing the forecasted benefits with the expected benefits (hence the “continued business justification” principle and the “business case” theme in PRINCE2®).
When a project is run for a external client, the client would have their own purpose for the project, and your company would have a different purpose. You should understand and use both of these to really succeed.
Example: Project monitoring
Focusing on the ultimate purpose is necessary, but it may be too abstract for many of the day to day uses. That’s why a hierarchy of drivers is needed to make it more practical. First, the justification and benefits of the project are defined based on the ultimate purpose, and then you will have explicit and implicit targets for project variables (e.g., time, cost, and quality) to satisfy the justification, which in turn will satisfy the ultimate purpose. These are lower-level purposes that are useful for many of our daily tasks.
When it comes to monitoring, the low-level monitoring of the project will be done using the lowest level of variables, because it may not be possible to track the ultimate purpose. In this case, you should still have the purposes in mind: what is the purpose of monitoring?
A normal and acceptable answer is to see whether we’re on track, and if not, to trigger a certain reaction that will bring us back on track or adjust the targets and see whether it can still satisfy the ultimate purpose. Our measurements should therefore be able to help with this low-level purpose, and the appropriate measurements are forecasts for the variables at completion; e.g., when would we be able to finish the project? How much money would we need to finish the project?
All other measurements, such as the planned and actual values to date, are just interim values that you need in order to calculate the forecasts, not the final values that you use for managerial purposes.
Example: Documents
No matter what development approach you use in the project, planning is always necessary. The important question is the level of detail in each type of plan. If there’s not enough detail in the plan, the plan won’t be able to contribute enough, and executing the project will be based on ad hoc decisions rather than integrated, holistic ones. On the other hand, many people try to be cautious and add too much detail to their plan, which makes it too difficult to prepare and maintain, and too rigid for the uncertainties of the project. As a result, the plan becomes unrealistic and useless.
The best way to decide about the level of detail is to have a purpose in mind for every element in the plan. For example, if you’re considering the addition of resources to the plan, you should have a purpose for it: How are you going to use it? How will it help the project? How much effort will it take? and is it worth it?
It’s sometimes about deciding whether you want to have a certain element in your plans, and sometimes about the way you want to plan or prepare something. Whether it be a business case, a project charter, or a report: you should still ask yourself why you’re preparing that document and how it can help the project.
Looking for a “template” is the opposite of doing something based on a purpose.
Example: Status reporting
It’s common to have really long status reports in many projects. Based on this NUP, we should ask ourselves what the purpose of the report is and how we can achieve that purpose regardless of what most other people may be doing.
This can, in many cases, lead us to prepare very simple one-page reports that stakeholders really read and understand instead of long reports. This is paying attention to purpose.
If you prepare one-page reports, though, some people may object about you and think that you don’t have a “proper” monitoring system in place. In practice this creates a second purpose for you (besides the first purpose, which is helping stakeholders understand the status of the project), and to satisfy that, you can simply create a second type of report that is very long. However, you won’t mix that with the first report, because these two purposes are not the same.
Example: Business case and project charter
Preparing documents such as a business case and a project charter is usually a boring, fruitless, bureaucratic necessity for most people, while these documents all have valid purposes that apply to most projects. If you try to find a “template” and fill it in, the work is just wasted; whereas you can instead check the real purpose of those documents, see whether and how they can be helpful in your project, and then prepare the document in any way you like, just to satisfy those purposes: that will be the right document.
While you’re thinking about the way you can prepare the documents to satisfy their purposes, you may not think of every scenario and may miss something. To avoid that, you can check to see what resources such as PRINCE2®, PMBOK® Guide, P3.express, and DSDM® suggest, and then evaluate those suggestions based on the purposes.
Example: Post-project
While the project has a specific purpose, and we can consider that purpose throughout the project, the realization of the purpose is mainly evaluated based on forecasts made during the project. We should not, however, forget about it when the project is finished. It is important to check the realization of the goals after the project is finished, because
- we can see how the ultimate goals are achieved and learn from that for future projects, and
- sometimes the goals are achieved only when we carry out some additional tasks after the completion of the project, and understanding the necessity of those extra tasks needs monitoring.
Post-project monitoring is a necessary step in being purpose-driven. It’s mainly the responsibility of program and portfolio management systems, and because most companies do not have such layers of management, this step is usually neglected. That’s why methods such as P3.express and DSDM® add this step to their project management methodologies.
Example: Simplicity
The world is complex and chaotic, but our models are abstract approximations that reflect parts of the world, and hence, they can be simple. On the other hand, simple systems usually work better, because we can be focused on the main idea.
Many of us try to get better results by adding complexity to our systems, hoping that it will match the complexity of the world, even though in practice this makes the system difficult to work with and usually blocks us from satisfying the purpose.
Example: Tailoring
A piece of software for streaming music has a very different condition from one that will be used for equipment in a hospital or a on plane where people’s lives may depend on it, or from a piece of software that will be used in a satellite where it’s supposed to work for many years without crashing, and they are all different from building a summer villa, a fire fighting station, and a process plant.
When you have the purposes in mind, you will better understand how to tailor the systems and artifacts for different projects.