Sometimes, in a software development project, it is not a matter of having or not having a technical skill but to be able to count on the right roles depending on the project. Here, we will go deeper into the Project Manager and Project Leader roles, that every software project must consider.
There are many discussions about the necessity of having a technical background to properly manage a software development project. There is even a role to describe those people that can combine being both technical and manager: Technical Manager.
However, it is not a matter of having or not having a technical skill but to be able to count on the right roles depending on the needs of the project. That is why, sometimes, what your project needs is a good Project Manager (PM) and a good Project Leader.
In the next paragraphs, I would like to go a bit deeper into these two key roles that I believe every software project must consider. Hopefully, understanding what each of them really implies will help you to understand how they differ and when they can be merged into one single entity.
This might be interesting: Lessons learned in software: from Junior Dev to architecture manager
Do we need a Manager, a Leader, or both?
Small, simple projects may not need a manager at all, they may not even need a leader, but as the project grows in complexity and size, you will get into serious trouble without any kind of management.
Having been a developer for more than a decade, whenever I heard about managers, my first thoughts were that Project Managers were those dumb men-in-the-middle who just cause communication delays and interference. I also thought a good technical Project Leader could deal with anything the team and the client would need and consequently get the project done.
In a few words, my thinking was, “Managers don’t do any real work”. This is perhaps one of the most common myths about managers, but the reality is that not producing any actual piece of code, document, or any tangible material does not mean the task accomplished by a manager does not count towards the product being built.
As the time went by, I realized I was plain wrong: managing a project is quite different than technically leading a development team, and having a very strong technical background and excellent communication skills won’t suffice.
Do not miss this: Communication in Agile Software Development… Does it matter?
Just to clarify: There are two different approaches to building a software: development based in projects (the traditional approach) and development based in products (where the roles of management, as I’m trying to explain on this Blog, are completely different). In this opportunity, I am referring to software development tackled as software projects only. I will dig more into the differences with product-based development and its distinct characteristics in a separate article.
Having said this, let’s continue…
The main reason software developers think about the PM as an unnecessary invention, created mainly for big corporations, is because they often see him/her as a leader which knows very little about building software. In most cases, the misconception is actually caused by a bad PM, but I will come back to this later on.
Although this might be the case for some small projects, a PM and a Project Leader work on orthogonal tasks. Overlapping responsibilities and duties between the 2 roles might work OK for some small projects (as I mentioned above, in certain projects you may not even need a Project Leader at all), but it can be really hard in other situations.
Planning and executing both roles
Project Management Body of Knowledge (PMBOK) defines a project as “a temporary endeavor undertaken to create a unique product or service”.
Under this definition, we can include very simple tasks (preparing a sandwich or building a software function to parse an email) to very complex ones (organizing a dinner for a wedding or building an entire CRM product for a financial institution). These projects can be defined and planned independently of the industry they belong to. Having a technical background in the field helps, but what is important are the common patterns that need to be mastered for all projects.
A PM’s main responsibility is to design a plan that takes into consideration the needed resources, the required time, and the expected results. PM expertise includes carefully analyzing the resources associated with the events that the project will hold during its lifetime, have in mind all possible variables and constraints (risks) affecting the project, and estimate and adjust the project’s forecast as the events occur.
This is highly important about management: A PM is not in charge of keeping a project on course, is not even responsible for finishing the project successfully, or on time, as expected. What a PM is responsible for is gathering the necessary information to accurately estimate the different paths the project may navigate.
He/She is also in charge of providing the required information to the stakeholders with the aim of allowing them to decide what to do (should the project continue? should we invest more time and effort? what are the chances of any possible scenario?). In other words, the PM (including the development team) is not responsible for whatever decisions are made by the stakeholders but to provide them with the most accurate information.
Did I mention anything related to how the team decides how to build the artifacts that the project requires? No, because that is a labor of the Project Leader, and it requires different skills and thus, a completely different toolbox.
A Project Leader is involved in the technical details and makes decisions about how to build/complete a task. Ultimately, he/she dictates the course of action for all the development team. Of course, tracking and making sure everybody understands what needs to be built requires some kind of management, but that is a very different skill than one we can find in a PM.
The Project Leader and development team are not responsible for the delays introduced by the chosen plan either; they are responsible for building a product given the constraints and restrictions previously analyzed.
The change as part of the plan
But then, what happens if the plan designed by the PM could not be met for any reason? This depends on whether we have worked with a good or bad PM; a good PM would have taken into account all the risks and therefore, elaborated a contingency and mitigation plan in case some of those risks arose.
The PM will apply the mitigation plans, and the project will continue (or it will be cancelled) based on that plan previously agreed on by all the stakeholders. With a good PM, there won’t be any need to analyze why a project was cancelled or succeeded; what happened would be a consequence of the designed plan.
On the other side, if you have a bad or inexperienced PM, he/she might not have taken into consideration some of the risks involved or not have been able to cover the expectations of the stakeholders. Under these conditions, when deviations or bad results occur, the PM would be tempted to assume a leader role in order to rush and increase the pressure on the development team to put the project back on track (according to the PM’s original plan). If this ever happens, there will be many people disappointed, frustrated, and uncomfortable with the results. In this case, having a PM becomes a recipe for failure.
In both situations, the role of a good Project Leader is what can make the difference complementing the PM. Citing the father of modern management theory, also known as the man who invented management, Peter Drucker, “Management is doing things right; leadership is doing the right things”.
Traditional Project Management consists of mastering the art of doing (wrong) things right (that is, on time and under the defined scope and budget). Modern management acknowledges the problems faced by constantly changing requirements, embraces leadership all the way to the end, and builds the right thing to fulfill the stakeholders’ expectations.
To Sum Up
Managing and leading a development team are two very different tasks that are commonly overlapped and carried on by the same person. Something similar applies to management and leadership: The skills and toolbox used by a Project Manager are quite different than the one you would find in a Project Leader.
Project Leaders and Project Managers are very different roles. Whether you can combine them into one single person or not, it is up to the complexity of the project and the skills of the person you can work with.
As a side note, the key to success with any software project is that both Managers and Project Leaders embrace the change as part of the plan execution.
In most complex software development projects, change is the only certainty.
Comments? Contact us for more information. We’ll quickly get back to you with the information you need.
