"Experience, Empiricism, Excellence"
HSD is free, please donate to help support us
or

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).
Planning might be added to this list in some cases but it is not the primary purpose of a Project/Product Manager.
 
Project Management is a mechanism for local governance, Project Managers have a responsibility to align their Project Management style to the intended culture of the organization, the needs of the business and the needs of the team. Project Managers are not there to impose their way of working on everyone else.
 
Project Managers cannot deliver a Software Product, development teams do that, so Project Managers must ensure they are adding value to the team and organization.
 
There is significant value in the functions listed above, but planning isn’t one of them. Moving away from ideas of Project Managers in charge of low-skilled people we instead look towards modern Project Managers as people with extensive software development and business experience acting as Product Managers
 
Holistic Software Development also includes the Product Forum practice which is a group based method of doing some of these functions. The choice of whether to use a Product Forum, Project/Product Manager or (most effectively) a combination of both will depend on the quality of relationships between teams, on the development workflow pattern  (agile/iterativecontinuouswaterfall), trust and organizational culture. Most importantly, this choice is dependent on the individual people involved.
 
To work out if Project Managers are adding value in your organi\ation have them appointed, or not, by delivery teams.
 

Management Culture

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.

When teams are mature, trusted and skilled they can make decisions well and operate efficiently. Only someone more skilled than the team could guide the team effectively - organizations often put less skilled people in place to manage teams creating conflict. However, the alternative is also true. If a team is immature, has low skills and/or is not fully trusted it may be both effective and necessary to apply directive management, even to the point of "command and control" management. This is not a positive relationship though and is likely to lead to resentment, conflict and dysfunction.
 

 

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.

 

Please share this page

Submit to DeliciousSubmit to DiggSubmit to FacebookSubmit to Google PlusSubmit to StumbleuponSubmit to TwitterSubmit to LinkedIn