You cannot compare them! It’s like trying to compare oranges and lemons - you cannot and do not!
What is happening?
There is real confusion and/or mis-understanding, (and unnecessarily so), when it comes to “roles” within the change environment (I am referring to organizational change initiatives in the main – projects and programmes), as opposed to the description and usage relating to a “business as usual” environment, your normally daily “role” or job description. In particular the two roles of Project Manager and Scrum Master.
I will start by looking at the role and description of your “job” which describes what you have been engaged to do on a “routine” daily basis in your organization, your place of work. The Role description is based on the needs of the position the organization is looking to fill and therefore, (supposed to at least), help describe the skills, knowledge, background and experience of the candidate the organization is looking for to fulfil that role and hence the work the role needs to carry out, in a normal business as usual (BAU) situation. Looks at competencies and capabilities. Hence, we give these roles titles!
The confusion comes when the same role title is used in other areas, outside the Business As Usual environment for example, and used in the Project Environment – where we run Project-based change initiatives, and then a cross-over of roles from one approach to another, usually across the two environments, Operations and Project!
A little note here: Project as you see, has a capital “P”. In the formal sense of a Project – Governance rigor is high as is the “formal” management of the change initiative! As opposed to a project, lower case “p”, where the rigor and control is very much less – usually associated with change initiatives in the Operations Environment (BAU!).
Change initiatives – activities undertaken to change the current situation, product, process, structure, strategy – status of anything – for something better, whether as a different/replacement/alternative/new something, through “projects” in the Operations (BAU) Environment or Projects in the Project Environment (see my video on YouTube - A look at the Organizational Environment - Operations (BAU) and Project )
It is this differential, between Operations Environment changes and Project Environment changes and the different approaches that are employed in these two environments, that is not understood and hence the difference in the “roles” used for the change approaches in these two environments. These two environments and the associated approaches ARE different, and the rest of this article attempts to explain why.
Understanding the difference
As noted above, one aspect that causes this confusion, (comparison), is regarding the normal working environment role, the Business As Usual (BAU) daily activities to be carried out, and that for a specific activity, the “change initiative”, which is usually a temporary engagement. Sometimes the role titles used are the same, however, the description or definition, and therefore the related responsibilities and accountabilities, are NOT. For example, one is hired as a Project Manager, (to keep topical), as a general day to day title. This will have a description for the role relating competencies and capabilities, based on knowledge and experience and so forth.
When we define the role of Project Manager with regards to running a Project/project, then the definition becomes more specific. This could naturally be a subset of the BAU role description, however, which will also be tailored to the specific change itself. A Project Manager role definition for a ERP project will most likely be different to that of a relocation project. It’s usually a good idea to engage a Project Manager that has experience and knowledge with the product that the project is delivering!
The other aspect of all this comparison (expounding that one role is now redundant! Really?), has to do with different role titles in the different change approaches! This is the real subject of this article. To articulate the differences and help remove further confusion, misunderstanding and long running debates and discussions as to what roles are relevant, and those apparently NOT, in the various approaches, in particular, the two roles in this article’s title.
ALL (both) the roles are relevant – for the change approach they are related to/defined for! And it is this word “defined” that holds the answer.
The Definitions
The broad dictionary definition of “role”
- the position a person assumes or the part that he/she plays in a particular operation or process. ...
- the function assumed or part played/fulfilled by a person in a particular situation
One of the characteristics of a Project is that it is Temporary. This is true for all change initiatives, (or should be – they have defined starts and finishes). So the roles within them are also temporary. The definition above is therefore extended by stating that the “particular operation, process or situation is temporary one and so in variance with the normal working role”
The role definition for a change initiative is defining specific needs with regards to experience, knowledge and background for that change approach.
In the Project environment, there is a greater need for coordination, leadership, orchestration, engagement and management of the environment and the people involved in it, with respect to an operational change approach. In such a Project we have greater governance rigor, a need to track and control the deliverables (products, features – whatever is being developed built) to achieve the “beneficial change” – this last phrase being the key, of course! Changes of this sort need to run in a “controlled environment” (as one approach puts it!), because we need to ensure that the product/deliverable is not going to break operations when it is transitioned/released into that environment. This is vital, because it is through the Operations Environment, BAU, that the organization makes its money, and we certainly do not want to break that, do we?
At the change approach definition level, the Project Manager role, has defined responsibilities and accountabilities to help select the person who will the fulfil that role.
The broad dictionary definition of responsibility
- the specific tasks or duties that members are expected to complete as a function of their roles
The broad dictionary definition of accountability
- taking responsibility for the outcomes of their actions and decisions and successfully transforming effort into results
The key point here is that it is the role that has the definitions to help select the individual who would best fit that role, NOT the individual themselves. The role and how it is defined relates to the change approach being used and the type of change being delivered. The individual fulfilling that role often will be capable of taking on different roles in different change approaches, with different responsibilities and accountabilities related to THOSE change approaches! That individual is most likely capable of fulfilling various types of roles. The role itself does NOT move.
I have used the Project Manager role here for a particular reason. However, note, that the explanation for the Project Manager role is just as applicable to ALL roles in change initiatives. There are currently a lot of discussions around the role of Project Manager and the Scrum Master and why the latter makes the former redundant! This article explains why these discussions are not very fruitful, indeed, rather pointless and in the end, incorrect.
The Irrationality
The core of the discussions is that now we have Scrum Masters we no longer need Project Managers. There are two key misconceptions here.
The first is talking about the role and the individual in the same breath. As noted above, the role is a definition, the individual is the one who has the attributes to take on that role. They are not the same. Again, as noted above, an individual maybe engaged as a Scrum Master, or Project Manager, (or indeed any role BAU related role), but this does not mean that the individual is exclusively tied to that role, it is just a title which has a description for Business As Usual.
When we are discussing the roles with respect to approaches for change initiatives, then in the Scrum Approach, the Scrum Master is a role defining the responsibilities and accountabilities for that approach and the way that approach works (see YouTube video - An overview of Scrum - A Product Delivery approach) just as in a Project Approach and the Project Manager role.
Point being that in the Business As Usual capacity, a role has a job description. In a change initiative, the role has a definition for that approach being employed, which should then be enhanced for that particular change initiative. By this I mean that I am able to fulfil a Project Manager role for a change in the Project environment and also fulfil a Scrum Master role in another initiative, usually in the Operations Environment.
These two roles do NOT do the same thing, do NOT have the same responsibilities, do NOT have the same accountabilities and so do NOT function in the same way. The way a Project is managed is quite different to the way a Scrum is, and so the skills, abilities, knowledge, understanding and capabilities needed are different.
However, the point is that an individual may well be able to fulfil both roles, (usually in different changes). The role stays with the approach, the individual will be there, temporarily, for the duration (hopefully) of that change and then move on, or already taking another role in another change. That role could be Executive, Sponsor, Analyst, Developer, Tester and so on and so on!!!!
The message here really relates to ALL role definitions in change initiatives, however, as I wrote before, I high-lighted these two as they are the subject of much hot-air, unnecessarily debates and discussions, predominantly promoting the demise of the Project Manager role in favour of that of the Scrum Master. Alarm bells should be ringing at top decibels!
The Clincher
The fact is – a Scrum Master role has defined responsibilities and accountabilities for running a Team and working in a Scrum, whereas a Project Manager role has defined responsibilities and accountabilities for managing a Project. They do NOT have the same activities or carry them out the same way – planning and the delivery approach being two key ones (see another post on planning!), the focus is different. One role does not replace the other. It is the individuals fulfilling these roles that will change and move around and can fulfil the two roles if their skills, knowledge, background, experience and, ultimately, their understanding of the two different approaches enables them to do that!
Author Bio
Antony della Porta has experience of over 30 years in the project management profession. He is an established professional in the delivery of strategic business change and an advisor for programme and project recovery with critical systems thinking approach. He has been an Executive Advisor and Director at GPM Global and founded “The Sustainable PM” initiative, which is a platform that is set to help PMs become "sustainable”. He is also an accredited instructor and practitioner for a number of courses in the fields of management and project management.