Let’s talk about the biggest words used to describe the transformation of a business. They’re usually reserved for big teams and big budgets, but that doesn’t always have to be the case.
One thing we have to establish from the beginning is the fact that these words weren’t created in a bureaucratic effort. Instead, they came to be because the effort of coordinating resources was so big, that it had to be structured in some way. That’s not to say these concepts need to be used for all business transformations, but the larger the complexity, the better suited they are to aid in keeping things under control.
The Project
This is a word that’s used freely throughout organizations ranging from three people to ten thousand. It’s clear that it expanded well beyond its business context into the common language, and as such it becomes heavily dependent on the context. To a team of entrepreneurs, a project may mean an idea they would like to implement. A “new thing” they would bring into the world and the only word that’s flexible enough to accommodate this definition is “project”. On the other hand, for a corporate facilities team of 300 people, a project is a very clearly structured and defined effort that takes into account guidelines, budgeting constraints and work scheduling challenges. Although the word is correctly used in both situations, what defines a project is a very simple set of criteria.
Is it temporary ?
If the project we’re talking about has a transient nature, then we can continue to use the word “project” for it. This is what we can use to contrast with Operations, which are a permanent, ongoing endeavor. If a project was meant to “always be on”, then we are veering into the realm of operations and the term “project” doesn’t accurately represent what we mean. There’s a distinction here: what a project delivers can definitely be part of our Operational workflows, but the project itself can not. And speaking of what a project delivers..
Does it create a unique service, product or other result ?
The focus is on “unique”. Just like before, we need to contrast this with Operations. If what the project delivers is not unique, then we again fall square in the realm of Operations. Operations handles Business as Usual, which is what the team or organization already knows how to do. In the case of a car manufacturer, designing, building or repairing their current cars is something that they already know what to do. Building a new car, however, a semi truck or a motorbike, would definitely be something they don’t know how to do (yet). That would qualify as a project.
Let’s talk about another difference between projects and Operations. In the case of Operations, simplifying a bit, the people that are involved are relatively known and static. We have the organization’s management structure, the teams actually performing the work, suppliers and customers. We know this because one of the things Operations is very amenable to is getting optimized. In order to do things as cheap, fast and correct as possible, the whole pipeline is streamlined as much as possible.
A project on the other hand will have what we call Stakeholders. Because of a project’s unique nature, we can’t rely on the organizational Business as Usual approach. We have to actively look for, investigate, catalog and handle a multitude of actors that could and would influence the project in a huge way. These Stakeholders can actually be anyone. From environmental NGOs to suppliers to regulatory bodies or even teams in the same organization competing for the same internal resources, a project manager has to identify them all and take into account their influence on the project. Some may support the project. Others may actually oppose it and might even have the clout to put an end to it.
Now that we talked about what a project is, let’s see what people came up with in terms of how to manage it. There are multiple frameworks and ways to do so, some of them focused on governance and others on techniques. There is no one-size-fits-all approach, so the project manager has to choose a way to work on each project. This obviously needs the support of the organization and the project team, this is one of the foundations of successful project management. Let’s look at a few different project management approaches.
Predictive (the feared “Waterfall”)
This approach is usually used for projects where the scope is very well known. This is required because you can’t plan for things you don’t know. One other example would be heavily regulated industries like public infrastructure or aviation. Because there are so many regulations to keep track of, the project manager needs to have very clearly defined responses to meet them.
With this approach, the project team writes down everything they need to do, adding as many details as they can. The scope of the project is heavily documented, in both a descriptive and prescriptive manner. The scheduling of the project becomes a challenge in itself, since such projects are usually large enough to stretch over years at a time. It’s hard to plan for people or resources being available two years in the future, so things like contingencies and risk management become a very important part of the project.
Use this approach when you know exactly what your project is going to deliver, and / or when you have external constraints that shape your organization or field.
Agile
This approach gained more prevalence in the recent past. Having started in the software industry, it found a home in organizations that are managing less defined projects. In recognizing that a project’s scope is sometimes more intuitive than objective, we still need a way to manage the project. One of Agile’s fundamental premises is the fact that when it comes to shooting for the moon, we don’t generally know how to get there. So we need to iterate, to look at what we built so far and confirm (or not) that it actually provides the business value we hoped it would. This means that we can’t afford to build too large things, because if they don’t provide the business value we hoped for, we need to scrap them and all that effort is lost. Instead, we should strive to validate the smallest practical pieces of work. This way, when we discover they don’t actually provide the business value we hoped for, we can adjust mid-flight and explore other ways to fulfill our initial goals.
One caveat to this approach is that it is sometimes used as a way to bypass the need to define clear requirements. One of the largest sources of wasted effort is “working Agile” for things that are predictive in nature. In addition to that, if the Product Owner is not familiar enough with the organization to actually identify business needs, the goalpost will keep moving and the project will overspend and underdeliver.
Hybrid
The best of both worlds, hands down. It’s very rare that a project is truly only predictive or truly only change-driven. In general, there are parts that the organization or team has done before, even if not specifically in the shape required for this project. Let’s take procurement for example. Most organizations have a pre approved list of suppliers, with which they negotiate special business conditions as part of a long term relationship. It’s very likely that the materials or services required for a project could be acquired through this list of suppliers, in which case the procurement process would be quite predictable.
Creating a “comfortable seat” however presents its own challenges. A lot of factors would need to be taken into account, such as the demographics of the target market, average body sizes, cultural differences and so on. This part of the project would lend itself very well to an iterative approach, because we simply can’t know beforehand what a comfortable seat is for our new forklift design.
The Hybrid approach works best when the predictive parts of the project become its backbone, a fixed structure that helps minimize waste, while the agile part of the project is allowed to cycle, but also becomes constrained by the project’s otherwise fixed skeleton.
How do we organize our projects ?
This is a question that is very relevant in huge organizations and in small agencies that handle their customers via projects.
Since projects are meant to maximize value and minimize resources, we’ll use this angle to look at two big and complex concepts, Programs and Portfolios. Of course, each of them is a science in itself and we won’t describe them here, we’ll just use them as a context for how a project connects to the rest of the organization.
Programs
Sometimes projects are related. It could be that a new car design depends on a technology being developed in another project. In this case, since the projects are related in a way, they would benefit from being managed together. It’s clear that the car project will be delayed if the new technology project meets some roadblocks, so managing them together would surface all such consequences.
A program manager will work with one or more project managers to identify all the relationships and dependencies between their projects, aiding them by solving common blockers and maximizing resource usage.
It’s notable that in a program, we can have efforts that are not necessarily projects, so you can think of them as “a group of related projects and any other supporting work for them”.
Portfolios
This management field is very high level, and in fact directly connected to an organization’s strategic goals. These strategic goals are complex enough that no one project or even program can achieve them. As such, when such a goal is defined, it can come with many project or even program ideas to help achieve it.
A portfolio can contain programs (collections of related projects), independent projects and any supporting work that is required to facilitate reaching that goal.
Conclusion
A project is a temporary effort to deliver something we’ve never done before. We can fully plan them, iterate through them, or both. Related projects can be grouped into programs, and complex goals may require a multitude of programs, projects and supporting work arranged into a portfolio.
