The Project Management Triangle
After six years into my software engineering career, I started as Project Manager of a three-year project for a major European Institution operating in the Space market. Now, as I write, this project has been successfully delivered and was merely the first of many projects I have managed since then.
As a proud owner of a modern Master’s degree in Software Engineering, I had some of the tools I needed to succeed at this task, but! Tools are not enough. An expensive computer with a powerful IDE full of auto-complete and linting features is not enough to be a software engineer in the same way that six months of classes of company management, investment analysis and software estimation techniques in academia are not enough to become a project manager. I had to learn how to use these tools and how to craft a whole new tool bench fitting the specifics of the market, customer and company yielding the project.
The project management triangle is the first tool I have created to support my duties as project manager of customer projects. Akin to a Software Engineer who implements a script or pipeline to automate some tasks so that he can proceed with his fascinating lazy life, I had the urgency to continuously measure the distance between the current project status and its holy success — a place that only exists in the head of the PM and represents unreasonable perfection. In simpler words, I had to find a way to check-up on the project’s health routinely.
At first, I tried to make the customer happy and full stop. Naively, I started shaping the idea that I was probably born to become the most successful project manager that the world has ever seen. I was reporting how satisfied the customer was. The customer was also verbalizing this very same satisfaction to my management and I was on a roll. For a few days... At some point, I had to check the balance sheets and they were pretty bad, of course. At this point, I learned my first hard lesson:
Pleasing the customer is usually expensive. In the end, we are all customers of someone, and actually we feel totally in love with our service providers when they charge us for a fraction of what we receive.
This hard discovery was a major blow to the equation I was formulating to calculate how successfully my project was being executed. Inspired by Newton, I decided to introduce another variable: My management’s satisfaction — let’s call it the satisfaction of the project board. Now, in my mental model I have a gravitational field with two equal masses:
- customer’s satisfaction, and,
- satisfaction of the project board.
The challenge now is to place the project well in the middle so the distance to both masses is the same. Although very graphical, this task is hard to achieve.
Basically, the satisfaction of one comes at the expense of the other: Overcommitting, overdelivering or overspending may please the customer but not the project board. It is a dance though: find the right balance between being on-time, being on-budget, being on-quality without jeopardising the planned resources. I learned that planning is probably the most useful instrument to keep the project within control. Planning, communicating plans, monitoring and re-planning is a circle that is repeated over and over again during the project execution. Plans are shared with the project team, and, if justified, to the project board and customer. By planning, I am able to quantify progress and establish feasibility. As bonus, plans are fertile communication landscape. A customer is more willing to accept deviations that are properly quantified and whose impact is already taken into account by the project plan. The same applies to the project board, which can benefit from the anticipation of potential hazards and threats before their consequence becomes unbearable.
Make no mistake: Planning is fundamental but is also an exercise in honesty, in which you have to fight wishful thinking. Honest planning also implies that the volume of each existing black-box is kept to a bearable minimum. The sum of these volumes is the plan tolerance.
Million dollar question: What is the problem with my gravitational field approach? Strict satisfaction of customer and project board may harm team motivation. The team may not find the right setup to remain creative, inventive, solution-oriented and flexible. In the end, the team is only required to execute the project to absolute perfection delivering everything on-time, on-quality and on-budget in an increasingly competitive and intolerant business world where margins are shrinking, making it hard for projects to be executed by humans who are famous for making mistakes.
How to engage a software development team to remain flexible if the project is strictly managed and conducted?
It is equally important to satisfy the project team. In the end, it is the team who can decisively please the customer and the project board.
Good software teams tend to value quality work (sometimes even overvalue) and the budgetary and timeline constraints may often de-incentivize it. Software teams enjoy replacing legacy code with new technologies, paradigms and architectures. Customers may not perceive the value in it, decreasing the willingness of the project board to satisfy project teams’ ideas. Software teams may lose their complete faith in the project and even in the PM if they are tied from employing their engineering skills and best practices to the project. As PM, I find it fundamental to ask and collect feedback from the project team. I try to filter and transform the collected feedback into project and business opportunities: these can and should be conveyed to the project board and eventually to the customer. Experience has taught me that, when correctly communicated, tangible and quantifiable opportunities are often accepted. It is likely that a customer refuses to spend extra 5% of the available budget improving the quality of the code. Actually, I would likely refuse it myself if I was given this chance with no further details. Instead, to be a de-facto opportunity, it is important to provide the customer with the expected concrete and tangible benefits from this extra investment. For instance, improving the underlying software quality can reduce by X% the anticipated cost of the upcoming backlog.
I try to satisfy the project’s requirements and KPIs by maximizing customer satisfaction, the satisfaction of the project board and the team’s satisfaction. In fact, this approach generates the right incentives to manage the project correctly. It implies that team concerns are vocalized upwards to management and transformed into opportunities for the customer which may translate into project sugar for the team and management. Customer expectations are managed realistically from the beginning and a transparent relationship is established granting enough room to share concerns openly, taking the project plan as a basis. Issues are identified, often anticipated in a proactive manner by continuously considering different scenarios and avoiding any surprises to the project board.
As PM, I keep asking myself: How satisfied is the team? And the customer? And my project board? The answer often unfolds in a concrete action plan to keep these three actors equally happy. I focus my attention on the actor requiring higher attention.
Empirically I have observed that if none of the actors are actually happy, addressing the project’s team issues first is the most successful approach.
It is rather straightforward to keep one out of the three absolutely pleased about the project. It is harder to satisfy two of them (as exemplified earlier, there might some conflicting interests between these actors). It is actually pretty hard, to keep everyone entirely satisfied for most of the projects. Of course, there are very favourable project contracts that provide a lot of room to please everyone. But that’s exceptional, not the default.
The project manager role contains an intrinsic leadership aspect to it, and successful leaders tend to agree that to lead is to serve. Serving the customer, the project board and the project team as main priorities helped me cope with the project’s objectives and implications more naturally, maximizing the collaboration between all parties involved.
