Project/Product Managers act as leaders for teams performing critical communication roles, dealing with stakeholders, coordinating with other teams, mitigating local risks, driving continuous improvement etc. Not all teams need Product/Project Managers as some teams perform these functions as a group.
Project Management is a well-established function in many organizations and yet traditional Project Management is often perceived as a source of many software development problems sitting as it does between the technical development teams and the Business Leaders. Project Managers exist to manage a project which means we need to understand what “managing” is and what a “project” is.
In Holistic Software Development we define a Project as:
A Project is a temporary collaborative endeavor undertaken to create a unique product, service or result
(through a series of Releases)
This definition of “Project” is close to the PMBOK standard and points out some key features of a project:
- It is temporary, once its aim has been met it finishes
- It is collaborative, it uses people and resources
- It has a specific goal, normally one primary goal
Strictly by this definition most work to create a product can be considered a “project”. In HSD we often talk about “product development” and “projects” fairly interchangeably because of this. However, the word “project” also invokes ideas around traditional “project management” that can be counter to modern ways of working with embedded bias towards waterfall methods. As a result, we see a lot of focus on “teams”, “cells”, “delivery units” etc. The software industry needs to move past this discomfort. When we use the word “project” in HSD, we mean a temporary collaborate effort to meet a specific goal or create a product through a series of Releases
Project != Project Management
Traditional Management is defined as:
Coordinating the efforts of people to accomplish goals and objectives using available resources efficiently and effectively.
Because in HSD we apply systems thinking to organizations we can also define management as:
Human action, including design, to facilitate the production of useful outcomes from a system. This view opens the opportunity to ‘manage’ oneself, a prerequisite to attempting to manage others.
In Holistic Software Development we deconstruct the traditional Project Management and progressive Product Management functions into:
- Leadership (team-forming, cohesion)
- Communication (both internal and external)
- Coordination (helping people, customers, suppliers and peers work together and understand each others needs)
- Stakeholder Engagement and Management (done properly this is the same as “Coordination” – done badly it involves writing lists of names)
- Local Risk and Issue Mitigation (tracking risks, finding ways to mitigate risks and resolving issues)
- Continuous Improvement (driving the culture of continuous improvement throughout teams)
- Conflict Resolution (facilitating the resolution of conflicts in teams and between teams).
Effective governance involves pushing decision making to the lowest possible level where the person or people best qualified to make a decision can do so. This means that Project Managers and organizations need to make an important decision in terms of how they wish to interact with the people who generate their business value: Do you tell them what to do or help them do what they need to do?
If a team of people is skilled in all of the necessary specialisms it needs to deliver, demonstrates mastery and motivation and is trusted then it doesn’t need a Project Manager from an external point of view. It might still need a Project Manager from the team’s point of view however if the team feel they don’t have the right characters and inter-personal relationships to perform the other Project Management functions listed above.
Project Management and Scrum
Many organizations adopt Scrum as an agile process in development teams. In our experience, Scrum is an excellent technique for getting teams to truly iterate and internally communicate however it tends to cause some difficulties with Project Managers.
Scrum introduces the role of the “Scrum Master” whose responsibilities include guiding the team’s ways of working, facilitating planning, tracking team workflow metrics and above all the Scrum Master’s primary responsibility is the removal of team impediments (or local risk/issue mitigation). Often the scrum master is one of the most experienced team members and is looked towards for leadership, conflict resolution, planning guidance and external communication. It’s not surprising that a lot of scrum teams expect a Project Manager to fill the role. However, the Scrum Master role is not meant to be a Project Manager in charge, the role was in part designed a backlash against dysfunctional traditional project management.
Many organizations adopting Scrum will naturally put Project Managers into the role of Scrum Master. The conflict that may arise with this appointment is that traditionally project managers have managed the planning, with agile Scrum teams this is explicitly a team responsibility, as is self-organizing rather than “command and control” management.
In our experience few Project Managers make good Scrum Masters. Job adverts for “Agile Project Managers” with experience of “running Scrum teams” are similarly missing the point. These approaches are using new words for old ways of working.
Effective Project/Product Management
Where the project/product manager role can become invaluable, is in organizations with multiple development teams and complex projects is as a coordinating and stakeholder management function at each, progressively higher integration layer. Project Managers can facilitate internal team and external communication smoothing the transition of a Product through the increasingly complete levels of Done.
Most development team members have little interest in the coordinating, managing and financial functions that are required in any development project so are quite happy for someone else to take that responsibility.
Developing software products is a balance between a creative and scientific pursuit, with products ranging from tiny smartphone apps, websites, router firmware, enterprise finance systems to big data processing system of systems etc. The only thing these types of system have in common with each other is how different they are. The traditional approach to managing these diverse kinds of work has been “one size fits all” project management approaches that apply the same management approaches to radically different products. This is similar to the “manufacturing line” approach described in Lean Principles which treats software development as a repeatable standard process, unfortunately, manufacturing metaphors do not fit software development.
Effective software product management requires a deep understanding of people, software, technology and ways of working.