Talking about Project Management on a Scrum blog might lead to a controversy 🙂, but hear me out. I am no PMI expert so a lot of my experience with traditional Project Management is based on what I put to practice while learning from my then Project Managers and seniors.
The first time I encountered the term Project Management was way back in 2005, when I was a freshly minted Computer Post-Grad and joined a start-up whose primary business was to build websites and web applications. For us, every website was a Project. My director had a US counterpart who would get us clients. Me, my director and one more colleague (we were only 3 people in that company 😀 initially) would then do a Skype call with our client, understand the requirements, then take about a week to draft all of our understanding into a nice project plan for which my director would add a cost and time estimate and send it to the US counterpart to get it approved. And that was Project Management to me. Defining the Scope, Time and Cost of the project. A little later, at another organization, with another leader I learned a new trick. It was called adding buffer to the estimates.
However, the last 19 years in the industry have made me wiser and helped me look at things with a wider perspective. I have learned that Project Management when used as a “hunter/stick” to deliver specific scope, within a predefined budget and on a strict timeline might not be useful; especially if the work is neither defined nor repetitive. Instead, when used as any other tool to enable value creation, then Project Management can be helpful.
What is a Project?
From the PMI website -
A project is a temporary endeavor undertaken to create unique products, services, or a result.
When it is said that it is a temporary endeavor, I interpret it as having a fixed timeline. As it is used to create unique products or services, then there has to be a defined scope as well. For example - construction of a house or a road could be a project. Building an astronaut from lego blocks could be a project or developing a game for mobile could be a project. Even writing this article is a project.
What is Project Management?
Again from the PMI website -
Project management is the application of knowledge, skills, tools, and techniques to project activities to meet project requirements.
To me, Project Management is bringing together the right people, resources and skills in order to create/deliver products/services that provide value to its customers. To me, Project Management is also about empowering the people responsible for performing the activities of project execution in order to achieve a predetermined outcome.
In other words, Project Management is about creating a set of boundaries for project development and execution, such that it enables creation of value and helps reduce risks associated with it.
How does it relate to Scrum
The only purpose of executing a Sprint is to create a DONE Increment. To get to this DONE Increment, Scrum provides certain boundaries in terms of Events, Artifacts and Accountabilities. There are also rules and guidelines; values and principles that enable and empower people doing the work to do it in the right way. So, Scrum is an approach to Project Management.
Also, in Scrum, every Sprint has a Sprint Goal - which is a Specific Objective that needs to be met. A Sprint has a fixed timeline, one month or less. And there is an associated cost for every Sprint, typically the operational cost of the Scrum Team. Every Sprint, thus, can be considered as a Project.
To ensure that these Sprints create value for the users, it is imperative that the players on the Scrum team understand how to plan, execute, build, manage, deploy and track the value created by every sprint.
Why is it important for Product Owners
A Product Owner’s accountability within Scrum is to maximize the value of Product. For this the Product Owner has to perform many activities which include but are not limited to:
- Stakeholder expectation management
- Product Planning
- Product Strategy
- Customer Service
- Product Support
Scrum neither dwells deep into WHAT a Product Owner is supposed to do nor HOW the Product Owner does what is expected of them. Result, Product Owners will have to bring in their expertise from various areas including Project Management, Product Management, Release and Forecasting, Business Management and others.
For Product Owners, Project Management can be yet another tool that can enable them with insights into Requirements/Scope management, Costing of product development, Risk Analysis/ Identification and Mitigation, Tracking the progress if needed and more.
Why is it important for Scrum Masters
Scrum Masters on the other hand are supposed to enable Scrum and improve effectiveness of the Scrum Team. Again, Scrum provides a very high-level view of the services that the Scrum Master performs towards Scrum Team, Product Owner and Organization. How and What needs to be done is left to the Scrum Master to experiment with.
When starting off, if the Scrum Masters find it overwhelming to dive in the waters of Facilitation, Coaching, Mentoring or Servant Leadership then Project Management is a known territory with which they can start their journey into Scrum Mastery. My entry into the Scrum Master role back in 2011 was very much similar.
Initially, I used to create reports and share it with Management. Was it incorrect, nope. Not at least in my team's context. Later I learned, my focus should be on enabling Transparency and for that I need not send out a metric based report. Similarly, I came from the background of being a Team Lead and often used to tell team members what needs to be done. Then, I got to know the power of Self-Management.
So, in my experience if a Scrum Master does not confine Project Management to the traditional definition of - On Time, All Scope, Within Cost - delivery; and instead looks at it more objectively as any other tool set, it becomes an advantage.
Conclusion:
Just like any other skill or tool, Project Management is also a skill and it will often be useful if used properly in the right context for the right reasons. When a Product Owner uses techniques of risk identification, scoping or descoping work, forecasting releases in order to maximize value of Product, she is just putting tactics from Project Management to use; similarly if the Scrum Master facilitates the Scrum Team discussions to craft right goals, enables effective communication, creates transparency through visual indicators or other project management tools, they are using just one more tool from their toolkit.