How can an Agile approach facilitate the work of a Project Manager? Let’s explore together how and when it is appropriate to apply it to different types of projects.
After discussing the Development Team, Scrum Master, and especially the Product Owner in the previous article, we now turn our attention to analyzing another key role within any project, even though it is not strictly related to the world of software development: the Project Manager.
The Project Manager is a cross-functional figure who, like a skilled orchestra conductor, is responsible for coordinating various developers while also managing cost control.
Just like in a concert, the goal is to ensure that the sum of the soloists’ performances creates a single harmonious melody, which in our case is the delivery of a flawless product on schedule.
However, the question we want to answer today goes beyond the simple definition of who the PM is, to investigate a particular aspect related to how they carry out their activity.
It is no secret that the ability to make the most of the advantages of the Agile methodology is one of the strengths of the services provided by Hermes, so you might expect a rigid and inflexible approach.
Instead, the ability to constantly challenge oneself is the first driver of growth, so it is legitimate to ask: “Does the Project Manager necessarily have to be Agile?”
Being strong supporters of the cause, perhaps you would expect an elaborate answer with all the indisputable benefits of a 100% Agile approach; but it won’t be like that.
Many questions do not have a one-size-fits-all solution, so the correct answer often is: it depends.
There are indeed specific cases where a rigid Agile approach would represent a strategic mistake, because the reality is that every project should be managed in accordance with its nature.
The importance of evaluating each individual project
Every project has well-defined characteristics that need to be accurately interpreted to avoid turning a potential competitive advantage (the Agile approach) into a burden that hinders progress.
Let’s try to clarify this by starting with an interpretation of the project’s characteristics.
To better understand the added value of the Agile methodology, we need to consider four fundamental aspects:
- Project Control
- Push and Pull
- Iterative and Incremental Approach
- Lean Thinking
To answer the question about the correct role and approach of the PM, let’s consider the first aspect, which will help us better understand how to manage and properly set up the work.
We can evaluate each project from three distinct perspectives: defined, statistical, or empirical. Each of these approaches differs based on two crucial variables: cost and time of completion.
Each individual project is a challenge in itself, with different objectives and development methods, therefore the competence of the PM primarily lies in understanding the nature of the project itself.
Defined, empirical, statistical: the different types of projects
A project can be considered “defined” when we know exactly:
- The resources required for its realization
- The necessary development timelines
- The processes that must be combined to achieve the desired progress, within the timeframe (and costs) demanded by the client.
The most straightforward example? A production line, where the process is standardized, it’s linear, thus being less costly and faster.
An “empirical” approach, on the other hand, stands at the extreme opposite end of the spectrum, characterizing a project by:
- Uncertainty regarding the resources to be utilized
- Uncertainty about the completion timelines
- Uncertainty about the project’s costs
In such scenarios, at best, we can know only one of the three basic elements (resources, processes, and time). This extreme variability is typical for projects that stem from an abstract idea or a new vision, requiring setup entirely from scratch.
A classic example of an empirical project is indeed the development of new software.
We can rarely predetermine the processes; resources are identified along the way, and processing times can only be estimated during development, seldom beforehand.
You could say that the difference between a defined approach and an empirical one is akin to the difference between renovating a kitchen and remodeling an entire house, including changing the room layout. In the first scenario, you know exactly what you need and how much it will cost; your task is simply to find the resources to replace the necessary parts. In the case of a complete renovation, you can prepare as many estimates as you’d like, but ultimately, it will likely cost you about double your initial projection. There will be unforeseen issues, and the delivery will be delayed by at least 3-6 months from the initially stated date.
What about the “statistical” approach?
We certainly haven’t overlooked this third category. In fact, we’ve intentionally addressed it last, as it serves as a bridge between the defined and empirical approaches. The encouraging insight here is that, with accumulated experience, it is possible to transition an empirical project to a defined state, navigating through a statistical phase in the process.
But what does this truly entail?
Consider, for example, an e-commerce project: a client wishes to establish a brand-new platform from the ground up. This scenario undoubtedly falls under the empirical approach category. To optimize costs and timelines, while simultaneously fostering creativity, an Agile methodology becomes essential for the project’s successful execution.
If, as a result of the team’s stellar performance, an additional ten requests for similar projects were received, we could then begin to develop a highly realistic estimate for project development, thereby transitioning into the statistical category. In this realm, we would have a solid grasp on at least two of the three critical variables: resources, processes, and timelines.
As the team gains experience, collects data, and approaches a sort of process standardization, the response to another request for an e-commerce platform of that specific nature could almost be automated. At this juncture, we would possess all the necessary components to categorize the project as “defined.”
Now, you might be wondering, how does all of this relate to our initial inquiry regarding the role and approach of the Project Manager? Let’s connect the dots. This detailed explanation of the various project types is crucial for comprehending why a PM should not be confined to a single approach.
We could argue that the PM ought to be almost agnostic, seamlessly adapting to the unique context and demands of each specific project at hand. Therefore, it’s not imperative for a PM to be Agile. However, embodying Agile principles becomes a significant asset when managing projects with an empirical approach.
Mistakes to avoid
What often transpires with a more conventional, or “waterfall,” approach is the initiation of a project based on a set budget and a rigidly predetermined timeline. However, this approach lacks genuine certainty regarding the final outcome, timing, processes, and necessary costs.
This scenario is detrimental to the entire project as it pushes team members to their limits, stifles their creativity, and enforces adherence to a deadline that is most often unrealistic and constraining, subsequently compromising the quality of the final product.
Drawing a parallel with the house renovation example, treating an empirical project as if it were a defined project is a serious error. This forces developers to do their utmost to meet the deadline, so as not to disappoint investors, but often leads to a result that is less than precise.
Within the Agile methodology, such an approach is deemed restrictive and counterproductive.
Indeed, the principles of Agile methodology emphasize collaboration, peer-to-peer interactions, and the unfettered evolution of creative ideas, without rigid constraints. The outcome is a byproduct of these synergies, and in practical terms, this transforms the role of the Project Manager into that of the Product Owner, a topic we’ve already touched upon.
The Product Owner doesn’t impose decisions from the top down; rather, they are responsible for managing the backlog of tasks and, crucially, for facilitating clear communication between the Development Team and the stakeholders. This ensures that tasks are executed efficiently, and everyone is consistently on the same page regarding the project timeline.
This approach not only makes the work process sustainable and optimized but also ensures that goals are achieved more swiftly and effectively, all the while upholding the highest quality standards.A commonly misunderstood aspect is that, at the inception of a project, there are no adversaries. In reality, everyone is aiming for the same outcome. The challenge lies in tackling the project in the most effective way possible, just as the Product Owners/Project Managers selected by Hermes consistently demonstrate.
