Back to The Basics: Project Management
The Art Of Making Stuff Happen
Hey, fellow Leader 🚀,
I am Artur and welcome to my weekly newsletter. I am focusing on topics like Project Management, Innovation, Leadership, and a bit of Entrepreneurship. I am always open to suggestions for new topics. Feel free to reach me on Substack and share my newsletter if it helps you in any way.
Project Management is the last frontier for making products a reality.
It’s almost a great way to start a feature film or a motivational piece of knowledge written in a post-it glued to a monitor. To understand what project management really is, we need to start with the basis of what a project is.
A temporary endeavor undertaken to create a unique product, service or result
For the lucky ones who completed the PMI certification, this statement was tattooed onto our memory to clearly differentiate a project from anything else. The word “project” is written and spoken in contexts that are not technically accurate. For example, in companies, a team is often called a “project” when, in practice, it is a team (sometimes linked to an application) that is actively working on BAU (Business-As-Usual) tasks.
Projects are temporary in nature and have a clearly defined objective or deliverable. Consider a company wanting to launch a new product: evaluating and measuring the tasks and budget required to achieve a set of features for this launch can safely be called a project. If a company wants to set up an infrastructure by cloning the same digital assets and reusing existing procedures, then this is probably far from being a project because that outcome is no longer unique. The company has already standardized it into a process. If there are still any doubts about what defines a project, let’s consider the example of painting a house. The first time we need to do it, we might go to YouTube (yes, I am a millennial of sorts…), visit the store to ask a bunch of questions about the different paints, get information on the brushes, figure out what to buy, and so on. Then, we start painting the house until we are happy with the result. This painting job was a project because we defined a scope, estimated the work, built a set of procedures, and executed the job with some adaptability regarding quality standards (Big smiley face). The moment a friend asks us to paint their house, since we already have some of the material and know what to do and buy, it becomes routine: It’s a BAU task for us now.
WTF Do PMs Actually Do?
I was going to add the meme from “WTF do DJs actually do”, but the poor girl was emotional, and I felt bad using that clip. So I will leave it as an idea. Use your imagination.
The PM as the Sponsor Trustee
For the lucky ones who took Business Management in college, it’s often said the Manager’s role is to provide value for the stockholder. In a Project Management setting, the goal of the Project Manager is to provide value for the Sponsor: the person who makes funds available to execute a project for a product or a service. This authority held by the Project Manager is granted by the Sponsor. So a question might pop up: Why doesn’t the Sponsor lead the project themselves? It can be done, but typically, Sponsors have multiple endeavors running at the same time, so they need to delegate. This means it is on the Project Manager to act with the authority delegated by the Sponsor. This authority and autonomy might differ between projects. However, the PM is typically the Sponsor’s “Bestie”. The PM is the Sponsor’s eyes in the field and the person whom the Sponsor trusts to act on their behalf to a certain degree.
The Defender of the Scope
Consider the moment someone sends an email asking for that 'simple thing' that seems so easy to develop, only for it to turn out that it's impacting major milestones. This is why PMs are obsessed with Scope Creep. Whether it originates from external stakeholders or from within the development team. Once objectives are agreed upon, metrics are in place, and expectations are set, the team needs to deliver. The worst thing that can happen is to have a Change Request mid-course that threatens to throw it all away. And for the ones working in Scrum who might argue (screaming with all the air in their lungs!) that Agile teams must be adaptive: How would you feel if mid-sprint someone sneaked in a Story that hindered the upcoming demo? Not great, right? No matter the methodology, changes need to be carefully evaluated, risks need to be assessed, and if worst comes to worst, the Sponsor should arbitrate the solution, fully aware of the consequences of each option. In practice, the PM is constantly trying to keep the project’s scope under control.
The Project’s CFO
Just as the PM is the keeper of the scope, they are also responsible for the project’s budget. Remember, the PM acts as the Sponsor’s trustee: the entity funding the project. Consequently, a key value the PM provides is being mindful of how this money is spent, not only avoiding wasteful decisions but also guaranteeing that every euro (€1) is being well spent. While the level of authority may vary, the PM is typically the one who approves estimates and gives the green light for tasks to begin. Therefore, the PM is often the one approving day-to-day expenditures, which could include task-related costs or payments to external providers.
Uphold the Quality Requirements
If the project is delivered after weeks of effort and high expectations but isn't working, it's not the developers whose heads the stakeholders will want on a spike: It's the Project Manager's. In all textbooks about Project Management, it is said that quality is one of the major variables under the responsibility of the Project Manager. It is not the role of the PM to perform the tests, but it is the role of the PM to ensure that quality metrics are set and to define the capacity in which the product or service must be delivered. If the Sponsor is paying for a spaceship that can land on the moon, the requirements must clearly define how much cargo capacity, how many people (if any), and what operational parameters (like mission duration) the spaceship is required to have. If the spaceship lands on the moon but only carries 1 kg of cargo when it was expected to carry 100 kg, then despite being a remarkable achievement, it doesn’t comply with the quality requirement; therefore, the project has partially failed. Project acceptance criteria are of immense importance, and the PM is typically the one overseeing the process to guarantee the project is delivered according to the expected standards and capacity.
The Time Manager
This is probably the most notable function or role of a project manager. The moment when a PM channels Donkey from Shrek and starts asking around: “Are we there yet?” is perhaps my least favorite part of the work, yet it is one of the most important aspects. Having someone hitting the drums to ensure the project stays on track and that everyone is doing what they are supposed to do is key to guaranteeing the project will be delivered on time. At first glance, people perceive this part of the role as annoying (to put it mildly), but the goal is not to call people lazy or nag them about their work. In complex environments, people have shifting priorities, and sometimes communication doesn’t flow as expected. Often, I start a call by asking the “Are we there yet?” question, only to find out that a developer had to stop to address an incident, or someone from another department insisted that a task be delivered, overriding project priorities, or that a technical issue is blocking progress at the expected pace. Numerous reasons can be found to explain why a task isn't delivered on time or why it costs more than planned. The Project Manager is constantly keeping track of progress to make sure the project stays on track.
Focused on Delivery
There are so many ways for a project to fail. The exact percentage is difficult to determine accurately, but if you search around on Google, research often suggests a failure rate as high as 70%. Based on my experience, this seems like a significantly high number, and when I try to drill down into the data, I can't find any raw figures that substantiate this claim. However, I do agree that the chances of a project failing are significantly higher than those of it succeeding. This means that regardless of the specific tasks a Project Manager performs, they must remain mindful that the ultimate goal is ensuring the project is delivered.
One of my negative experiences involved an automation project that was part of a larger company-wide program. The program faced many hurdles, including internal governance issues, making it challenging for me to get new automation initiatives approved by the Program Leadership. A team of 30+ developers needed projects to work on, yet we faced excessive bureaucracy from program management simply to get initiatives approved. Ultimately, the Program was completely cancelled, and the people managing it were kindly reassigned to other company areas. The Program failed because there were few deliveries relative to the investment, and those deliverables that were completed offered low added value.
If a Project Manager gets lost in fantasy theories of how things should work, processes, and methodologies to the point of hurting delivery rates, the project will likely fail. Lean is key, and maximizing value is critical. Combining these two is the secret recipe for success.
That’s it. If you find this post useful please share it with your friends or colleagues who might be interested in this topic. If you would like to see a different angle, suggest in the comments or send me a message.
Cheers,
Artur
Hi Artur, I am very please to see that someone is writing on project management and its roles. I love the article. You are addressing the magic project management triangle: time, cost, quality with dedicated roles, which find interesting. I have a different model in mind, but anyhow, good input. Thanks!