PMP Protein: Requirements Management and Requirements Traceability Matrix

 By Poornima Nagaraja, PMP

Mediocre requirement management processes are major causes for project failures. Continuous research studies constantly mention this aspect of management. Unfortunately, it continues till date. 

Many organizations believe (and rightly so) that utilizing the right set of project management processes would lead to high probability for project success. Hence, if you are working as a management professional and/or practitioner in any organization, you need to understand Requirement Management Processes and its advantages.

One of the fundamental aspects of requirement management is this: 

Do what is required and deliver based on available time, money and resources. Over committing has been known to be one of the biggest reasons for project failures.

What is a Requirement?

The Project Management Institute (PMI®) defines requirements as follows: 

A condition or capability to be present in a product, service or result to satisfy an agreement or other formally imposed specification.

Requirements are needs and expectations of project stakeholders. Requirements are usually in the language of customers. Requirement gathering starts from the early phase of pre-project work, where needs assessment happens. 

If a Business Analyst (BA) is available for the project, then all requirement related activities will be part of that role. Project Managers should be collaborating with the BA to manage requirements.

Before further going into details of Requirement Management, let’s understand the difference between Scope and Requirements. 

Requirements can be vast, because when you consider all possible items as per customer expectations, the coverage becomes large. However, the scope of the project, program sets the boundary conditions. The scope will have: 

• The elaboration of project scope.
• The deliverables to be given to the customer.
• What is included in the project.
• What is excluded in the project within available time, budget and resources, which is tacitly explained by the “inclusion” part.

While managing scope, the Work Breakdown Structure (WBS) plays a key role because when the scope of the project is broken down, you get a WBS. A WBS is applicable irrespective of project life cycle being used. In some life cycles, the term WBS may not be used, but effectively you get it when you break down the scope of the project. For example, in Agile, you take the epics and break it down to user stories.

Now, let’s understand requirements management.

Requirements Management

Requirements Management is a repetitive set of activities that includes determining, documenting, and managing stakeholder needs and expectations during project lifecycle to meet project objectives. Do read this line again. It’s repetitive as it’s both iterative and integrative in nature.

Requirements management also includes tasks, which will establish a requirements baseline and maintain the traceability of requirements, which we will see shortly. In Adaptive/Agile life cycles, requirements are consistently managed with Backlog Refinement. Dedicated time is allocated for such activities. 

Requirements management is very crucial to consistently engage with stakeholders and understand their needs and requirements. This ensures the project manager and the team to prioritize requirements appropriately and implement the deliverables in a right way which leads to Customer Satisfaction. 

After all, a project is declared successful only when our customers are satisfied. Meeting the requirements of the customer helps achieve customer satisfaction. 

Now, requirements are usually managed with the Requirements Management Plan. This plan is the output of a planning process, i.e., Plan Scope Management. This plan tells how project and product requirements will be analyzed, documented and managed. Some organizations may call it the Business Analysis Plan. If a BA is available, it’s his/her responsibility to maintain the Requirements Management Plan.

Contents of Requirements Management Plan

One can think of the following contents for the Requirements Management Plan:

• How requirement activities will be managed.
• How configuration management activities for requirements will be done.
• How requirements will be prioritized.
• What metrics will be used.
• What will be the traceability structure/matrix.

In the previous line, I introduced a term called (requirements) traceability matrix. Let’s understand it. 

Requirements Traceability Matrix (RTM)

The Requirements Traceability Matrix is one of the outputs of Collect Requirements process – other being the Requirements Documentation. Requirements documentation lists out all the requirements for your project. In your organization, you may have different names for Requirements Documentation, such as Product Requirements Documentation (PRD), Product Requirements Specification (PRS) or any other name.   

Coming to the RTM, PMI defines is as follows:

Requirements Traceability Matrix (RTM) is a grid that links product requirements from their origin to the deliverables that satisfy them. 

The RTM creates a clear way to track requirements throughout the project life cycle. It thus ensures the requirements approved in requirements documentation are delivered at the end of the project.

As per PMI, the RTM components can be:

• Business needs and objectives
• Project objectives
• Project scope and WBS deliverables
• Product design
• Product development
• Test strategy and test Scenarios 
• High-level requirements to more detailed requirements

A sample of RTM is shown in the below figure. It’s taken from PMI’s Project Management Body of Knowledge (PMBOK®) guide, 6th edition. 

As shown, the RTM is a grid/matrix like structure. There are attributes such as Unique ID, Requirement Description, WBS deliverables, Test cases among others. One can have other attributes such as Owner, Requirement Priority, Versioning etc.

With this, I believe you got an introductory understanding to:

• Requirements Management
• Requirement Management Plan
• Requirements Documentation
• Requirements Traceability Matrix 

Brief Profile:
Poornima Nagaraja, PMP. I’ve over fourteen years of experience and currently working as a Quality Assurance (QA) Manager at Infor.

You may also like:

• PMP Protein: Conflict, Conflict Management and Conflict Management Techniques
• PMP Protein: Top PMP Apps to Assist You
• PMP Protein: Understanding Risk Attitude
• PMP Protein: Information Gathering Techniques
• PMP Protein: How To Be A PMI-PMP
• PMP Protein: How To Prepare and Submit PMP Applications
• PMP Protein: Types of Organizational Structures
• PMP Protein: Identifying Stakeholders
• PMP Protein: Earned Value Management – Basics
• PMP Protein: Strategic Planning, Analysis and Alignment
• PMP Protein: Earned Value Management – Advanced
• PMP Protein: Critical Path Method – Basics
• PMP Protein: Seven Basic Tools of Quality
• PMP Protein: Gaps in Project Management in India’s Construction Industry
• PMP Protein: Organizational (Project) Management – A Facelift
• PMP Protein: Facing the Sun
• PMP Protein: Project Management Practitioners’ Conference 2018 - A Feast of Knowledge
• PMP Protein: Requirements Gathering Methods
• PMP Protein: Emotional Quotient – A Risk Factor
• PMP Protein: Ensuring Effective Communication by Team Members and Middle Management
• PMP Protein: Leadership and Team Building
• PMP Protein: Understanding Brainstorming
• PMP Protein: Changing Work Cultures and Organizational Impact

Work Breakdown Structure (WBS) in Traditional and Agile Life Cycles with MS Project

Work breakdown structure (WBS) is a key element for management planning, monitoring, and control of a project or a program scope. Regardless of the chosen life cycle (predictive, iterative, incremental, adaptive, or hybrid), WBS plays a role in almost every project. A WBS is important to further estimation—cost, duration, or resources, planning for resources, risk identification, schedule development, among others. It’s also used in earned value management (EVM).

In this article, I will cover the fundamentals of WBS with the definition, the key concepts which drive WBS development such as rolling wave planning and progressive elaboration, and best practices for using WBS in predictive (Waterfall) and adaptive (Agile) life cycles. I’ll also show how, with MS Project software, you can build a WBS in all possible project life cycles. We will conclude with the importance of a WBS in a project or program. 

WBS Definition

The project management institute (PMI®) defines WBS as follows:

A WBS is a hierarchical decomposition of the total scope of work to be carried out by the project team to accomplish the project objectives and create the required deliverables.

The definition looks quite simple, but it’s a very significant statement for understanding the WBS. Let’s break it down.

• Hierarchical structure: The WBS is usually a hierarchical structure. It can present in a graphical format, tree form, or a tabular structure, but it will always be hierarchical in nature. The highest level of the WBS is known as Level-1 and followed with Level-2. It can continue to Level-N.
• Decomposition: The total scope of project work is considered and the team breaks down the work into manageable chunks. That’s why in the name WBS, we have a term breakdown. The decomposition or breakdown of the WBS creates the various levels, deliverables, and work packages. As you follow the breakdown, each descending level of WBS represents a further detailed definition of the work to be done.
• Deliverable: The deliverable is the unique, verifiable product, service, or result produced. The WBS is usually deliverable oriented when you do the decomposition. Based on the WBS, deliverables are created by the project team.

The previous statement of deliverable-oriented breakdown will enable us to understand how to actually break the project or program scope down to create the WBS. 

WBS Examples

Let’s take, for example, the writing of a book. Say you are writing a book on risk management. You want to have deliverables in terms of “Manuscript,” “Write Book,” “Edit Book,” and finally, “Publish Book.” Under “Write Book,” you have the individual chapters to be written (Chapter 1, Chapter 2, and so on). Similarly, under “Edit Book,” you’ll want to edit the individual chapters. In such a case, the WBS would be represented as shown. 

At the highest level, i.e., Level-1 (L1), we have the name of the book. In the next level, i.e., Level-2 (L2), we have the phases of writing, such as “Write Book,” “Edit Book,” and “Publish Book.” Next, “Write Book” is broken down into “Chapter 1,” “Chapter 2,” “Chapter 3,” and so also with the other WBS elements in levels. At the lowest level (L3), we have more details on each chapter (“Project Risk,” “Project Risk Management,” and “Agile Risk Management” and so on).

You may have noticed that I’ve assigned a numbering system to each element of the WBS, i.e., “1.2.2.2 Enterprise Risk Management.” The number used is the WBS identifier (ID), and is called the WBS code. This code or identifier uniquely identifies each element of the WBS. The WBS code is part of the WBS dictionary, which has detailed information about each element of the WBS.

But, let’s say you want to have a delivery in terms of your book’s chapters, i.e., Chapter 1 followed by Chapter 2, which in turn is followed by Chapter 3, and so on. In this case, the WBS would be shown as below. 

Can you see the differences between the previous WBS and the current one?

In the first WBS, the breakdown is in terms of writing the complete book, followed with editing the book, and finally, its publication. However, in the second WBS, the breakdown is in terms of writing, editing, and publishing individual chapters.

Depending on how you want to deliver, the WBS is built accordingly.

The lowest level of the WBS is known as the work package, where you can estimate for cost and duration. A work package is further broken down into activities, but these are not shown in the WBS, because activities are used in schedule management. The WBS can also have planning packages, which unlike work packages, are without the activities. Planning packages are put in the WBS for known, but unplanned work, whereas the work packages will have both known and planned work.

Above the work package level, there is a control account, where management control is exerted. The approved version of the total scope of work or scope statement, WBS, and WBS dictionary constitute the scope baseline.

At this stage, some questions may be coming to your mind:

• What should be done when one can’t decompose to the level of the work package?
• How can we implement further schedule or cost planning as they are based on the WBS?

This leads us to the concepts of progressive elaboration and rolling wave planning.

Progressive Elaboration and Rolling Wave Planning

Many management practitioners mistakenly think the concepts of progressive elaboration and rolling wave planning are only applicable in Agile environments. It need not be the case. In fact, these concepts apply both to traditional/Waterfall and adaptive/Agile projects.

Let’s first consider the definition of progressive elaboration. As per PMI:

Progressive elaboration is the iterative process of increasing the level of detail in a project management plan as greater amounts of information and more accurate estimates become available.

It’s highly possible that in a traditional project, there will be elements in the WBS which can’t be broken down further. As and when more clarity comes to those WBS elements, this can be done iteratively. This is progressive elaboration.

One key aspect of Agile development is its iterative nature. The concept of progressive elaboration fits with iterative development—more of which we will see shortly. Decomposition in an Agile project can happen with progressive elaboration, i.e., while building the product backlog, the backlog items are detailed progressively according to their priorities.

Rolling wave planning is a form of progressive elaboration. PMI defines rolling as planning as:

An iterative planning technique in which the work to be accomplished in the near term is planned in detail, while the work in the future is planned at a higher level.

In Agile, rolling wave planning happens with project planning, release planning, and iteration planning. For example, while at the release level, the plan is at a higher level, and for the immediate next iteration, the plan is more detailed and granular. 

Agile – Iterative and Incremental

The Agile life cycle is both iterative and incremental, i.e., the product, result, or service is delivered in a series of iterations in an incremental way. To understand all possible life cycles in a project, refer to this article, Why and When to Go for Agile Life Cycle.

Let’s reuse our book example from earlier to understand how we can apply WBS in Agile mode. We want to write a book in an iterative and incremental way.

Iterative development is based on this premise:

We rarely get anything right for the first time, and it takes time to get anything right! Hence, iterate.

This is especially true in an environment when change is high, requirements are highly uncertain, and scope has differing perceptions among stakeholders. In such a case, we iterate. The focus in iterative development is learning optimization, rather than speed of delivery.

When writing a book, I wouldn’t complete ONE chapter in just one go. I would write, edit, delete, and rewrite the content of a chapter many times. The first version is usually a poorly written one, which gets better with feedback and iterations. In fact, while writing this article, I’ve followed the iterative mode of development, where I iterated the sections of this article multiple times.

Incremental development, on the other hand, is based on this premise:

It is better to build some of it (the product, service, or result) than to build all of it! Hence, deliver incrementally.

Again, taking the example of the book, I wouldn’t complete ALL the chapters in one go. Rather, I’ll write one chapter at a time and deliver it to an initial audience who wants to have a look. While editing the first chapter and writing the second, I’ll incorporate their feedback. The next chapter is built on top of the first chapter, and the subsequent chapters will be built on top of the previous ones – hence, the book develops in an incremental way. The focus in incremental development is speed of delivery.

While writing this article, I’ve also used incremental mode, i.e., I completed the first incremental cut and shared it with Jana Phillips, my editor. Jana has checked, added, and edited the article, providing me with her feedback. There may have been a new section added for the next incremental stage. In the final build, I’ll review it again and advise if anything more is needed. Finally, we go live with publication by the MPUG team (republished here).

Agile development combines and leverages both iterative development with improved or optimized learning and incremental development with speed of delivery. This is depicted below. 

WBS in Predictive Life Cycle

In a predictive life cycle model, requirements are fully known, change is low, and risk is also low. Hence, the phases in a project can be sequentially executed, though the final product (or service or result) is delivered at the end of the final phase.

Taking our book example, one can say the following phases of the project create the book. (I’ve made the phases a bit more formal compared to the previous example.)

• Research
• Design
• Development
• Delivery

With the adoption of these phases, the WBS will become as is shown below. 

At L1, you have the project name, i.e., “Book – Risk Management.” At L2, you have the various phases. The level-2 elements of the WBS are further decomposed to finally give us the work packages:

• “1.2 Design” is broken down to “1.2.1 Front Cover” and “1.2.2 Back Cover.”
• “1.3 Development” is broken down to “1.3.1 Write Book” and “1.3.2 Edit Book,” which are further broken down to the individual chapter level.

With Microsoft Project as your tool, you create and plot the WBS quickly as I’ve shown in the next figure. 

The default WBS code for the WBS elements (i.e., 1.1, 1.2, 1.3 …) can be shown by enabling the “Outline Number” under the Format tab. You can also create custom WBS codes with the help of this tool. The graphical side has various timescales, and, in our case, it has three tiers—the top tier in quarters, middle tier in months, and the bottom tier in weeks. 

WBS in Agile Life Cycle

In Agile approaches, the scope of a project is not clearly known from the beginning. It evolves throughout the lifecycle. All the requirements, features, epics, and stories for the project are part of the (Product) Backlog, as this article explains.

Though WBS is often associated with predictive lifecycles, in Agile approaches, WBS can be used. The scope of an Agile project is supported by the backlog. In Agile development, epics are decomposed into user stories, just like high level elements in a traditional WBS are finally decomposed into work packages. Also, as the work package represents the lowest level in a WBS, (user) stories will represent the lowest level of a WBS in an Agile project. In other words, you could say work packages in an Agile WBS will be equal to the (user) stories.

You may be wondering how to decompose from the project level to the user story level. There are many approaches, but for this piece we will explore a Project to Release to Iteration to (User) Stories scenario. The project is divided into multiple releases. Each release will have many iterations, and, in every iteration, we will deliver a set of features (an entire chapter, part of a chapter, or design of the book). The features can be estimated in story points. I’ve selected this decomposition approach to be consistent with my previous article on Agile Release Planning.

As we already know, Agile is both iterative and incremental. Hence, we have to deliver incremental value in every iteration. 

As shown above, at L1, you have the project name, i.e., “Book – Risk Management.” However, at L2, you have the various releases shown. The level-2 elements of the WBS are the further decomposed iterations (L3), and in every iteration, we will deliver the chapters (L4) estimated in story points. This level could be considered the work package level for this Agile WBS.

Like with the traditional WBS, with MS Project, this WBS can be as easily created. The software tool supports a Scrum framework, where iterations are known as Sprints. The created WBS is shown below. 

As shown in the above WBS, we have releases broken down into Sprints, and in each Sprint, we will be delivering a chapter or part of a chapter. This is a tabular view of the WBS and can be seen in Sprint Planning Sheet view.

You can switch to the Gantt Chart view to see the graphical depiction of the chart, which is shown below. 

Conclusion

While the scope defines the why of the project, the WBS tells the what of the project. It doesn’t inform how or when the deliverables will be produced or who will produce the deliverables.

The how part of the project comes later and is informed by the activities or tasks of the project. The how much part of the project also comes later and is typically addressed under the umbrella of cost management. The when part is best described by the project schedule. The who part of the project is addressed by resource management, i.e., the team members who will be executing the projects to give the required deliverables.

Nevertheless, it’s the what part of the project, the Work Breakdown Structure, which drives these other aspects—the how to do, when to do, how much money will it take, and who will do it. The WBS provides a clear vision of the total scope of work involved in a project and is the beginning stage of defining the deliverables—both intermediate and final deliverables—to be created. Due to its visual nature, the WBS is an effective communication tool used by managers in a project or a program.

--

This article was first published by MPUG.com on 18th August, 2020. This is a refined version.

 

References

[1] PMP Live Lessons – Guaranteed Pass or Your Money Back, by Satya Narayan Dash

[2] MS Project Live Lessons with Money Back Guarantee, by Satya Narayan Dash

[3] Project Management Body of Knowledge (PMBOK) Guide, 6th Edition, by Project Management Institute (PMI)

[4] Book: I Want To Be A PMI-ACP: The Plain and Simple Way, 2nd Edition, by Satya Narayan Dash

Videos Courses on MS Project Agile and Hybrid-Agile: 

[1] Mastering MS Project Agile (Scrum and Kanban) 

[2] Certified Hybrid-Agile Master Professional

ACP Live Lessons Success Story: ACP Live Lessons is the Best Way to Earn Your PMI-ACP Credential

 By Sindhu Pillai, PMI-ACP, PMP

Introduction

One year ago, I attended an interview and the interviewer asked me a large number of questions on Agile methodologies. I couldn’t even answer a single question properly. 

I took it very personally and felt very offended by it. I made up my mind to master this topic and decided to earn the PMI-ACP credential. 

At the end of my journey, I’ve not only earned the ACP certification, but also understand the Agile mindset and I want to pursue this understanding in my career path.

ACP 21 Contact Hours Experience

I bought Satya's PMI-ACP Book and PMI-ACP Live Video Lessons because I believe in the guarantee he claims. Both the video course and the book have helped me crack the ACP exam. In fact, I was sure that I would crack the ACP exam with Satya’s help. 

After going through all domains, I wrote a test conducted by Satya (as a part of ACP Live Lessons, FAQs). After completing the test, I received the needed 21 contract hours to fill the ACP exam application form.

Own Study

I first bought Satya’s course material (bought both the book and video course) to kick-start my preparation. However, I couldn’t stick to a regular routine of keeping in touch with the course as my official workload increased. I also had a few family emergencies because of which I had a gap in my studies and was finding it very difficult to get back on track. 

When I took PMP training from Satya, I remember his words: “Everyone is enjoying their weekends. But you are sitting here and attending classes. MAKE IT COUNT”.  I kept telling myself, “make it count Sindhu for the weekends and hours you have already put in by sacrificing all the weekend time.” 

I did put my heart and soul into preparation and went hard during December 2021, when the workload reduced. In this month and previous one, I could invest up to 8 hrs a day in preparation. 

Preparation and practice of questions will be the keys and there is no shortcut to success! I’ve gone through Satya’s Live Lessons course a couple of times till my concepts were clear. Simultaneously, I made my notes, which I could refer to whenever needed. And I did a lot of Mock Questions, which were provided by him. 

I did have my ups and downs during the preparation. Satya was always available to help me with all queries and guide me through any obstacle I came across.

Review – PMI-ACP Live Lessons

The ACP Live Lessons course comes with a money back guarantee with no conditions applied, except you appearing in the exam. I was very certain that this course is a complete package to earn this certification. Also, I’ve already used Satya’s PMP Live Lessons, which helped me to clear the PMP exam. Hence, I didn’t have any second thoughts before getting the Live lessons and the I Want To Be An ACP book from Satya. 

The ACP Live Lesson course covers every possible aspect of Agile and associated concepts. Satya has created short and long videos and broken down the lessons in such a way that it makes our life easier. At certain points Satya asks a few questions which act like revisions automatically. There are a set of Smart Card questions after every domain which ensures you have the fundamentals in place. 

After every domain there are a good number of mock questions provided. This helps you to gauge your understanding with respect to the specific domain. Once you are done preparing with all the domains, there are lessons available with video exercises which gauges your overall understanding of this course. 

I found this course very helpful in understanding the Agile principles, values, methodologies in a very insightful way.

After you are done with all the domains and practice tests provided at the end of the individual lessons, there are six full-length questions sets provided in this course. These question sets get tougher with each set. 

These question sets will train to face the exam questions where you get 180 minutes to appear 120 questions. My score was consistently above 95 to 100. Satya informed me these scores are good.

Finally, in my ACP exam, I was able to score Above Target in five domains and Target in two domains. This I did in a few months after the knowledge I gained using this course material and by doing 6 full length questions provided by Satya.

ACP Exam Experience

I booked a centre close to my house to avoid longer travel in traffic. I visited the exam centre a day prior to the exam and enquired about the documents required on the day of exam. The full-length mock questions had given me a feel of the actual exam. The more seriously you take it, the easier it will be for you in the exam.

Following are highlights from my ACP Exam:

• In the ACP exam I faced a lot of questions on Scrum, Retrospectives, Kanban and Velocity. 
• There are not many mathematical questions. I had faced one on Velocity.
• The exam follows the domain distribution closely. The better prepared you are, the higher chances of you clearing the exam.
• During the exam, keep a tab on timing and ensure you don’t spend much time on a single question. There is an option to flag the question which can be reviewed later. 
• There is an inbuilt calculator on the screen. Hence, you don’t have to carry a calculator.

Suggestions for ACP Aspirants

Dos: 

• Always stay focused and always stay in touch with the course during preparation. 
• Do a lot of practice questions and revisit the areas where you go wrong.
• Pay special attention to topics where Satya says: it’s important. 
• I did prepare thoroughly on Scrum, Kanban, Velocity, Charts, XP, Retrospective and I did get a lot of questions in my exam related to them.
• I’ve always visualized myself clearing the exam and returning home with a pack of sweets and that did happen, so it’s important to stay positive.

Don’ts:

• You should always remember that by failing to prepare you are preparing to fail!! Hence, leave no stones unturned when you prepare. Success will follow you.

Conclusion

Sindhu Pillai, PMP, PMI-ACP

I’m currently working as a Project Manager in Kyndryl (previously IBM). Now I would like to work in an Agile Environment and use the knowledge & skills earned with this course and the ACP credential.

More on ACP Live Lessons - Guaranteed Pass:

• ACP Live Lessons – Guaranteed Pass or Your Money Back

ACP 21 Contact Hours Course:

• ACP 21 Contact Hours Online Course - Full Money Back Guarantee

Book for PMI-ACP Exam:

• Book for ACP Exam Prep: I Want To Be A PMI-ACP, Secon Edition

PMI-ACP Success Stories:

• PMI-ACP Success Story: Agile is Essential for Delivering Customer Value and ROI – Early and Continuously
• PMI-ACP Success Story: Learn Agile Concepts in Greater Depth To Earn This Credential
• PMI-ACP Success Story: Innovation Games Make The Difference!
• PMI-ACP Success Story: Agile is Transforming The IT Industry and ACP Credential Equips You to Lead this Transformation
• PMI-ACP Success Story: Being Agile and Thinking In Agile Way Help To Crack The Exam

The Value of an Agile Project Management Office in 2020s

Imagine this scenario as you start-off your day: You open your business site and the message says: “it doesn’t exist.” You then try to login to your email account, which also displays the same message. Your heartbeat goes up and you rub your eyes in disbelief. You remember receiving emails from customers about payments via payment apps, but there too, the same message is displayed, “this account doesn’t exist!” Overall, you feel like the character of the 1998 movie, Enemy of the State.

Is my imagination running wild? Not really.

Such a scenario happened to many in mid-December 2020. A number of service providers’ sites and applications were hacked and systems were brought down. In fact, I thought my personal computer had been hacked, and I rebooted a couple of times without knowing what exactly to do because my service providers’ status dashboards were all green–a good 10 minutes into the internet outage.

Now imagine that a senior executive starts off his day and decides first to have a quick look at the project dashboard expecting to see metrics such as the current status of projects, earned value indices in terms of money and performances, and top risks. Instead, he sees story boards, iteration and release burndown charts, and velocity graphs. Can you feel the frustration, confusion, and possibly anger? What could have been done differently?

Welcome to the concept of the Project Management Office or PMO.

In this article, we will learn about PMOs as organizational structures, about various types of PMOs, and about traditional roles within a PMO. Then, we will dive into the topic of Agile PMO, its relevance, and a number of roles that can be played by such a PMO.

PMO Definition

Any organization exists primarily to provide business value to its stakeholders–internal or external. A PMO, like the service providers I mentioned in the example at the beginning of this article, also exists to provide value and insight into project performances.

The Project Management Institute (PMI) provides a broad definition of PMO as:

A project management office (PMO) is an organizational structure that standardizes the project-related governance processes and facilitates the sharing of resources, methodologies, tools, and techniques. 

As noted in the definition, a PMO is an organizational structure. If it exists, then a number of Project Managers (PMs) can be a part with various roles and responsibilities.

Do note that the “P” in PMO can stand for a project, program, or portfolio, and the “O” can refer to the organization itself.

With a standardized set of processes, practices, and metrics, enabled by a PMO, the executive stakeholder would not have faced the “it does not exist” situation as previously mentioned.

Types of PMOs

As per PMI, there are three types of PMOs:

• A Supportive PMO largely plays a consultative role such as providing templates, imparting training and coaching, and storing lessons learned across projects.
• A Controlling PMO plays a role in project compliance to standards and/or regulations, and it ensures conformance with various governances and associated frameworks. It can also be involved in audits of projects and project works.
• A Directive PMO exerts highest power and has the ability to initiate and/or terminate projects in an organization. You can say, this PMO directly manages all of an organization’s projects.

While the degree of control provided by the supportive PMO will be low, controlling and directive PMOs will have moderate and high degrees of control, respectively.

Traditional Roles of PMO

If a PMO structure exists in an organization, then the main role in a traditional set-up is to support the PMs. Beyond that, the PMO holds some or all of these listed responsibilities:

• Standardization: Standardization of processes, policies, procedures, templates, and other documentation, along with compliance.
• Knowledge sharing and retention: Acting as a repository of lessons-learned and providing access to projects as and when needed.
• Training: Facilitating or conducting, providing coaching, and mentoring.
• Consulting: Adopting various project management frameworks or methods.
• Resourcing: Managing shared resources across projects.
• Communication: Coordination communication across various projects.

For a PMO, unlike a program or portfolio, it’s not necessary that the projects are related or managed as a collection.

With this background, let’s proceed towards the concept of Agile PMO. The first question that comes to mind in having a PMO coupled with an Agile approach is this:

Is a PMO really needed at all in an Agile setting? Are not Agile teams cross-functional, self-organizing, and self-managing?Isn’t there a leader who serves the team and removes the impediments?

At first-glance, having an Agile PMO may look contradictory–not only to the way Agile teams operate, but also to Agile values and principles. However, it need not be the case.

As noted in the definition, a PMO is an organizational structure. Your organization may or may not have such a PMOstructure, but if your organization does and your organization is transforming itself to adopt Agile practices, then it must change to have an Agile PMO because agile creates structural, as well as mindset changes.

Agile PMO

Instead of a traditional directing or commanding/controlling PMO which first dictates and enforces standards, policies, procedures, an Agile PMO is more facilitative in nature. An Agile PMO takes the most effective practices used in other projects and shares them across the organization. An Agile PMO is useful when an organization is doing a transition to an Agile approach, and particularly can play a crucial role if the organization is planning to undergo an Agile transformation.

In the context of Agile, PMOs will have the characteristics shown in the below figure:

Let’s break these down one at a time.

Value-Driven

This is the most important aspect of an Agile PMO. The PMO’s goal should be to deliver the right value. An agile PMO should have a customer collaboration mindset. Customers, in this case, are the internal customers within the organization and can also be external customers. In many cases, this may result in PMOs working as a “consulting business unit” in an organization. The PMO can tailor their work to meet the customer’s need. For example, the PMO is responsible for providing the template for use story or the template for Product Review/Demonstration.

Multi-Disciplinary

An Agile PMO should have competencies other than project management, e.g., organization design, change management etc.

Center-of-Excellence (CoE)

With a plethora of Agile frameworks available, it’s easy to get lost in the woods. An Agile PMO deeply understands a variety of approaches available and can adopt or tailor the ones that best meets the organizational needs.

Change-Agent

An organization usually struggles while transforming to fully adopt Agile values, principles, and practices. It’s never easy to move into a different mindset and way of working. An Agile PMO acts as a change-agent and guide.

Invitation-Oriented

An Agile PMO invites for its services only the projects or project teams which are interested in PMO services. This kind engagement ensures that the practices are followed vs. a PMO forcing its practices on teams. 

Roles Played by Agile PMO

Let’s consider some of the roles played and responsibilities that can be taken-up by an Agile PMO. There are many applicable roles here, and I’ve highlighted a few of them in the below figure.

Let’s consider them one by one.

Multi-project Management

Whereas the Agile project manager is the obstacle remover for the team, many times an Agile PMO overlooking a number of projects is an obstacle remover for the program (defined as a collection of interrelated projects, sub-programs, and other works).

At the level of a portfolio, which is a collection of programs, projects, sub-portfolios, and operations, the PMO can work on investment themes, i.e., which project to take on or invest in.

Stakeholder Engagement

In the beginning stages of an Agile transformation, it’s highly likely that there will be resistances to the changes being brought in. The PMO, in this case, informs, communicates, educates, and gets buy-in from the stakeholders having Agile mindset, values, and principles.

Simultaneously, when a trial project is undertaken by an Agile PMO, the team members may not get the needed support from stakeholders across the organization. Here, too, an Agile PMO can help provide training to existing or aspiring POs, SMs, Agile PMs, and team members.

Standard Development and Implementation

Earlier we saw the roles played by PMOs in a traditional set-up. In the context of Agile, the PMO can provide:

• Templates for user stories,
• Tools to be used for wireframes,
• Samples for burn-down/up charts,
• Metrics to be used, among others…

If different teams have different metrics, it doesn’t help the organization at all. Sometimes, teams may even inflate data to show they have done more than planned. An Agile PMO helps to standardize on meaningful metrics such as release burndown, cycle time, etc.

Compliance and Audit

An Agile PMO can act as the informant on compliance issues and/or amplify the teams’ external department needs regarding compliance. The Agile PMO, in this case, should try to be facilitative, i.e., listen to what is working for the team instead of dictating or directing.

If it’s regulatory compliance, then the PMO can find ways to get it done, e.g., putting it as a backlogged item in the Product Backlog in collaboration with the Product Owner (PO).

The Agile PMO, like its traditional counterpart, can participate in audits, which is basically to see if project activities comply with organizational, as well as project policies, processes, and procedures. An example is participation in Quality Audit.

Resourcing

In any organization, there will be critical resources, which are shared across Agile teams, e.g., architects, database administrators (DBAs), technical writers, etc. Sometimes, non-human resources have to be procured from outside, and these are used on a shared basis. An Agile PMO can work with the POs, Agile PMs, Scrum Masters (SMs), and Functional Heads to satisfy the need of such resources.

The Agile PMO can also help in hiring resources and evaluating team members. An example is developing interview guidelines for Agile practitioners.

Training, Coaching, and Mentoring

Here the Agile PMO can act as a coach, trainer, and educator by themselves or by partnering (or coordinating) with the training unit of the organization or external training organization.

The Agile PMO can conduct sessions on:

• Test Driven Development (TDD)
• Behavior Driven Development (BDD),
• Retrospectives and intraspectives,
• Story writing workshops,
• Story mapping workshops,
• Backlog prioritization, among others.

Strategic Focus and Alignment

In an Agile PMO setting, the product backlog is executed over a number of iterations or with a flow-based cadence in order to move towards the vision or goal of the product. This, in turn, is usually linked with the strategic objectives, mission, and vision of an organization.

However, a large organization can have many initiatives with hundreds (or thousands) of projects running. In such cases, it’s possible to miss the strategic alignment for all projects in the organization. The Agile PMO defines and ensures a strategy deployment method.

In addition, an Agile PMO can also have additional roles such as that of a traditional PMO—facilitating learning by storing, managing, and dispensing lessons learned from various retrospectives. 

Conclusion

In the beginning of this article, I raised the question, Do we really need Agile PMO when Agile teams are self-managing and cross-functional? 

Over the course of this article, we discussed various utilities of having such an organizational structure. However, if it’s a small organization, if the owner of the organization is driving few projects on his or her own, or if there are dedicated departments for compliance, audit, training etc., then an Agile PMO may not be needed.

Nevertheless, for a large organization that requires a complete Agile transformation and/or has a large number of projects running, the Agile PMO structure will bring a number of benefits and business value. 

--

This article was first published by MPUG.com on 2nd February, 2021. 

References

[1] Book: I Want To Be An ACP: The Plain and Simple Way, 2nd Edition, by Satya Narayan Dash

[2] Book: I Want To Be A PMP: The Plain and Simple Way, 2nd Edition, by Satya Narayan Dash

[3] The Project Management Body of Knowledge (PMBOK), Combo 6th Edition, by Project Management Institute

A Deeper Look: Top Changes in the New 2020 Scrum Guide for Agile Practitioners

A new version of Scrum guide was released in November, 2020. There are quite a few changes in the guide, as well as new additions. While the outline and structure of the guide have remained almost the same, as you go through the guide, you will immediately notice three high-level changes:

• The new guide is a much lighter and smaller version.
• It’s less prescriptive and seems to be intended for a wider audience group, particularly non-software users.
• It contains commitments for each of the Scrum artifacts.

In this article, I’ll outline the top changes and the deeper meaning associated with each change. My perspective is based on my analysis, my own interpretations, and the interactions I’ve had with Agile practitioners who follow my publications, books, and/or courses. 

Product Goal

The Product Goal has been defined clearly. It’s not an introduction because it existed earlier, but in the previous version, it was mentioned along with the vision.  

As per the guide, the Product Goal is the future state of the product. This definition of the ‘goal’ can create confusion for many who understand project-program-portfolio management and how goals aligns with the vision, mission, strategy, and objectives of an organization.

Ideally, the vision is the future of a product or program/portfolio or an organization. A vision is always associated with goals, without which a vision has no value or meaning.

However, as you look closely at the new guide, a big picture emerges:

• The Product Goal is the long-term objective of the team.
• A team works on and fulfills a single objective at a time.
• Before tackling another objective, the team has to fulfill (or abandon) the objective they are currently working on.

In other words, the goal is written with one or more objectives for the team. As the product roadmap is prepared, it gives further directional clarity to the product goal. The product goal should be linked to the strategic goals of the organization. One could summarize this by saying:

• The Product Goal is more strategic in nature, whereas,
• Sprint(s), mentioned as a project in the guide, will be tactical in nature.
• With each Sprint (iteration), the product moves closer to the product goal.

The Product Owner (PO) is the person who is responsible in building, and clearly communicating product goal to the team. The items in the product backlog (PBIs) should map to the Product Goal. Product Goal also reflects one of the values of Scrum: “Focus.” The team, as earlier noted, should focus on one objective at a time.

Now, you may be wondering what happens when multiple teams are working on the product backlog?

Regardless of the number of teams, there will be a single product backlog, a single PO, and a single product goal. This is depicted in the figure below.

 

Commitment based Artifacts

Now, every artifact in Scrum comes with a commitment.

The formal artifacts in Scrum are three:

• Product Backlog
• Sprint Backlog
• Increment

Now, all these artifacts come with commitments to ensure transparency and progress.

• For Product Backlog, the commitment is the Product Goal.
• For Sprint Backlog, the commitment is the Sprint Goal.
• For Increment, the commitment is the Definition of Done (DoD).

While Product Goal is newly introduced, Sprint Goal and DoD (earlier called “done”) existed earlier. In the new guide, all of these have found homes. For example, the home of Product Goal is the Product Backlog. 

At this point, it may be useful to note that “Commitment’ is also one of the values of Scrum, others being Focus, Openness, Respect, and Courage. Hence, one can say that commitment-based artifacts are reflections of one of the Scrum’s values. Commitments also increase “Focus,” another Scrum value.

I’ve mentioned the values here, because I believe they are very important, but you shouldn’t confuse values such as openness, courage, honesty, etc. with the value that you get while delivering an increment, although the latter is also important.

As the saying goes, “Culture eats strategy for breakfast.”

In my view, it’s actually the values and value-system which eat strategy for breakfast. Strategy execution is the downstream of culture. Culture is the downstream of human, team, or organizational values. And values are the downstream of the philosophy on which civilizations (or a team/organization) is based.

At times, values are thrown around like punchlines, brandished as political weapons, or misused for self-serving interests. It’s true adherence to values that really matters because without values, nothing really works. This is true for a person, team, organization, or even a civilization.

As we proceed through the other changes, I’ll continue to reflect on the Scrum values. 

Multiple Increments

Earlier it was mentioned that an Increment will happen at the end of Sprint. Now, within a Sprint, multiple Increments can happen.

An Increment happens when a backlogged item meets the DoD. Hence, an Increment can be created at any point of time during a Sprint. This is depicted in the below figure. 

As shown, at the end of the Sprint, we have Increments. Increments can also happen at any time during the Sprint. The new guide clearly informs that Sprint Reviews should not be considered “gates” for releasing value.

As there can be multiple Increments, the sum of all these Increments are presented to the (key) stakeholder at the Sprint Review. 

Introduction of Cadence

For the first time, we are introduced of a concept called “Cadence.”

This is an important introduction, which is missed by many Agile practitioners. Cadence is used in other Agile frameworks such as Kanban, and is basically a rhythm that gets developed as one continuously follows a set of events over a period of time.

In Scrum, the cadence is provided in the form of five events:

• Sprint – the container event
• Sprint Planning, Daily Scrum, Sprint Retrospective, and Sprint Review – the contained events within a Sprint

I’ll suggest that you read this change along with the previous change of “Multiple Increments.” As you go through these updates together, you can see two things emerge:

• Development is happening in cadence, whereas,
• An Increment can be there at any time during the Sprint.

You can say development (or build) of the product and incremental delivery have been decoupled. In fact, they can be thought to be of two streams as shown below.

As shown, the stream for cadence is decoupled from the stream for increment. The diamond shapes in the cadence stream denote the Sprint Reviews. While there is an increment at the end of the review, on-demand increments can happen at any time, as we see in the increment stream.

Cadence helps with inspection, which is one of the pillars of empiricism. This, in turn, drives another value of Scrum: “Openness.” 

Lean Thinking

Earlier the guide referred to empiricism. Lean thinking has appeared for the first time.

Empiricism is a practice which is based on knowledge coming from experience and what you know or have observed. The three pillars are: Transparency, Inspection, and Adaptation.

To include and encourage lean thinking, the wording in the guide has changed in quite a few places. For example, the guide notes: “Transparency enables inspection. Inspection without transparency is misleading and wasteful.” Again, remember that “Transparency” (or Openness) is one of the values in Scrum.

A key principle of lean thinking is to avoid “Muda,” a Japanese term meaning “waste.” When work is not done after being taken into a Sprint, the result is Muda. With DoD, Muda is avoided. Do remember DoD is the commitment for an increment. With DoD:

• You know exactly what it means to have an increment.
• The team is compelled to complete the items taken, not start taking new items.
• One can say it’s about: Start Finishing, Stop Starting.
• From that perspective, some elements of Kanban have been absorbed into Scrum.

Introduction of “Why” in Sprint Planning

Other than “what” to do in the Sprint and “how” to do it, the “why” aspect has been introduced.

Earlier, before the start of Sprint Planning event, two questions were emphasized:

• Topic – 1: What should be done in this Sprint?
• Topic – 2: How do we do it within the Sprint?

In the new guide, emphasis has been given to Sprint Goal. Hence, we now have three aspects:

• Topic – 1: Why is this Sprint valuable?
• Topic – 2: What should be done in this Sprint?
• Topic – 3: How do we do it within the Sprint?

This is shown in the below figure. 

Sprint Goal has to be collaboratively defined by the entire team. The introduction of Sprint Goal in the Sprint Planning event, reemphasizes a value of Scrum: “Focus.”

Single Scrum Team

Earlier, there was a Development Team within the Scrum Team. There is no ‘team within team’ now.

A Scrum Team is one, and it consists of the Product Owner, Scrum Master, and Developers. This is a step away from the “us-vs-them” mentality created with the term “Development Team” earlier. It also avoids a “throw-over-the-wall” mentality (i.e. my or my group’s work is done and now is the time to throw it over the wall, so that the other group takes care of it!)

Now, the team is considered to be a cohesive unit of people focused on the Product Goal. The PO, SM, and Developers are all intrinsic parts of the Scrum Team. The new version of the guide also notes that the team is the fundamental unit of Scrum.

The single Scrum Team concept enables two values of Scrum: “Respect” and “Openness.” With a single team concept, there is less likelihood of “us-vs-them” mentality.

Also, a single team concept with no hierarchies creates a culture where everyone knows that the team succeeds or fails together, hence candor goes-up. It’s likely to stop compartmentalization of members, prohibit group or community biases, reduce politics, and cripple finger-pointing, and eliminate blame-games and back-biting. If one team member is failing, it means the whole team is likely to fail with their ability to meet the goals of Sprints, the goal of the Product, or the honoring the DoD. The team moves towards, or strives to be, an indivisible whole.

Self-Managing Team

Instead of “Self-organizing,” the team is now “Self-managing.”

Agile teams are cross-functional meaning that they have all the needed skills to do the work and create value in each Sprint. Along with that, whereas the team was described to be self-organizing in the earlier edition, the terminology has now been changed to self-managing. There is a subtle difference between these two terms. Self-managed teams go one step ahead of self-organized teams.

A self-organizing team chooses who will work and how to do the work. A self-managing team, on the other hand, chooses who, how, and what to work upon. In my view, the team can consider the new aspect of “what,” because the PO is now explicitly part of the team.

It’s not that a team will be self-organizing from Day 1 or even within a few weeks of interactions. The team has to go through the stages of team formation, such as forming, storming, norming, and performing.

Also, with the introduction of “what,” the team decides which items are to be taken-up for the next Sprint. This, in turn, reflects another aspect of Lean Thinking: “Muri,” another Japanese term meaning “overburden.” As the team decides what items are to be taken-up, Muri is less likely to arise. When what items are determined at the beginning of the Sprint, it reflects another aspect of lean thinking: Just-in-time (JIT).

Not a Servant Leader, but a Leader who Serves

The Scrum Master being referred to as the Servant-Leader of the team has been removed.

The guide currently notes, “The Scrum Masters (SM) are true leaders who serve the Scrum Team and the larger organization.”

This enables the SM to play a larger role in the organization. The SM is not only now accountable for establishment of Scrum, the SM also leads, trains, and coaches the organization on Scrum adoption. He or she also advises the organization on Scrum implementation.

In my view, this is a positive change because I’ve noticed that the words, “Servant Leader,” have been weaponized by some teams. The SM is not a clerk or secretary to take notes during Sprint events and send meeting emails or reminders. The role of a SM is much bigger with a focus, not only on the team, but also playing a broader role in the organization. This larger aspect is emphasized by putting leadership first.

—

As you go through the new guide, you may also notice changes such as:

• The three questions of Daily Scrum are no longer mentioned.
• One process improvement item from Sprint Retrospective, which must be taken into the next Sprint’s backlog is no longer there.
• The term “useable” has been used in place of the term “releasable,” among many others.

In this article, I’ve elaborated on some of the top changes. I hope you are not only aware of these, but understand the deeper, philosophical reasonings behind these changes in the Scrum framework.

--

This article was first published by MPUG.com on 29th December, 2020.  

References

[1] Online Course: PMI-ACP Live Lessons, Guaranteed Pass or Your Money Back, by Satya Narayan Dash

[2] Book: I Want To Be An ACP: The Plain and Simple Way, 2nd Edition, by Satya Narayan Dash

[3] The 2020 Scrum Guide, by Ken Schwaber and Jeff Sutherland