Skip to main content

Tag: Technical Project Management

Can a Product Manager be the Scrum Master for Leadership

The Challenge

Agile (specifically Scrum) gives business analysts, Scrum Masters, and project managers a framework to prioritize work within a project or domain which has already been identified, scoped (somewhat), and approved. However, Agile does not help determine which initiatives to work on nor how to prioritize conflicting initiatives with limited resources. Additionally, Agile doesn’t prescribe methodology on how to deal with cross team dependencies and cross team coordination. Finally, Agile does not define how to deal with release planning nor release dependence.

Some extensions to Agile such as the Scaled Agile Framework (SAFe) attempt to provide an infrastructure for being Agile while identifying, scoping, and approving initiatives within an organization. Full SAFe is a complex process which is focused on program management. SAFe has released some different flavors that include Portfolio SAFe, Large Solution SAFe and Essential SAFe. Nevertheless; even Essential SAFe comes with a relatively large overhead for small organizations.

In working for a small software company (approximately 30 employees) I have found that Agile of any type was not enough as my company needed to coordinate cross team dependencies and align initiatives with business objectives. When looking into SAFe, it was quickly realized that the layers of management/decision making needed to do even the Essential version of SAFe did not exist. But, the need to have methods which could align business strategies with Agile team implementations still remained.

My Organization’s Solution

How did my company handle this dilemma? Ultimately, we took the principles of Agile and applied them to our planning processes. The leadership group within our organization eventually looked at ourselves as an Agile team and identified the product manager to serve as the Scrum master for itself. While the product manager was involved with making the decisions and prioritizations, the senior leadership group was ultimately responsible for such decisions (self-organizing team). As such, the product manager treated the leadership team as an Agile team and facilitated team meetings to help the team collaborate and select priorities just like a Scrum Master would do for an Agile development or engineering team.

Further, the leadership team looked to Agile (Scrum specifically) to determine what types of meetings might help us coordinate our prioritization efforts. A Kanban tracking approach was utilized to encourage adapting to change while still tracking all items actively in flight. These items would serve as a singular representation of all engineering and analysis priorities.


Advertisement
[widget id=”custom_html-68″]

Results of Our Approach

Applying the Agile/Scrum approaches to leadership became a logical approach towards remaining Agile, while still having more mature prioritization and strategy sessions. However; this approach required less overhead than implementing a full-blown Project Management Organization (PMO) or implementing the Scaled Agile Framework (SAFe). Rather than worry about processes and approvals, we viewed the leadership as an Agile team, met regularly and applied the Scrum ceremonies to the leadership group. The team used longer iterations than the development teams (using months or quarters rather than two-week iterations) and worked to determine priorities which could then be assigned to the Agile teams for development or analysis.

This transition came with some growing pains, however. The organization has ultimately experienced better alignment of priorities and improved the throughput of work. Just like no team is “fully Agile”, this management Scrum team continues to evaluate our processes and continues to seek for internal process improvements to adhere to the Agile principles. Rather than continually questioning the priority of work, we created a method which could adapt to change, yet still clearly report on progress of initiatives. The approach also helped align business objectives with development work and adapt to change as needed.
The specifics of our implementation may not make sense for all organizations, but ultimately, we treated the leadership group as an on varying cycles based on agreed upon organizational needs. These included standups, biweekly release planning, monthly and quarterly work prioritization.

To further the approach, the leadership group implemented a Kanban board using Jira. This Kanban board includes major initiatives, general software improvements, and urgent / immediate code changes needed in production. Further, the Jira Kanban board then linked to the team boards to allow each individual team to create child stories which linked to each item on the leadership/planning Kanban board. This approach added some additional tracking overhead but provides complete traceability and reporting from ideation to deployment. Further, the Kanban approach created a backlog which serves as a dynamic product roadmap.

Next Steps

If your organization is struggling to be Agile while also adhering to strategic prioritizations, consider using an Agile approach to product management and view your leadership stakeholders as an Agile team. Assign one person to be the Scrum Master for the leadership team and evaluate what Scrum ceremonies might make sense to apply to the leadership group. Once the leadership group adapts the cadence of the meetings, the same benefits that the engineering teams get from Agile can be applied to program management. This may work well if your organization doesn’t have a fully structured PMO and have not been able to implement the Scaled Agile Framework (SAFe).

5 ways to improve benefits realisation by the PMO

Establishing the benefits that can be derived from a project remains one of the most elusive things for the PMO to achieve.

Each season, it tops the delegate issues agenda and this year’s #gartnerppm conference in London is no exception.

Without an effective benefits realisation process, it is difficult to measure the business impact of projects, the contribution made by the PMO to achieving strategic goals or to justify ongoing expenditures and investment in PM maturity initiatives. According to PwC, only 62% of programmes can demonstrate a relationship between project objectives, company strategy and the resulting benefits. This is an essential aspect of strategic portfolio management to master and this article outlines 5 ways to improve benefits realisation in your organisation.

A continuous lifecycle

The first thing to understand is that benefits realisation is not a single step, but a process that can be sub divided into lifecycle components. This starts with the planning of anticipated project benefits and concludes with understanding how a project has not only been concluded successfully, but has also contributed as expected to strategic objectives.

Secondly, there needs to be an initial baseline against which benefits can be measured. Without it, there is nothing to compare and track. For instance, taking operational efficiency as a simple example and target to improve that can be measured, how long does it take to generate reports today? If getting the monthly reporting pack out takes a week to prepare, use this as the baseline and then by putting in the right sort of assistance to create reports in a day, you can easily see what the improvements are.

The diagram below created by Serra & Kunc, 2015 illustrates the complexity of all the inter-relationships very well as an interconnected ‘Chain of Benefits’. Starting with project outputs, how can the PMO help to steer the outcomes towards a clear realisation of strategic objectives? What needs to be in place and understood?

PT June1919 1

Firstly, the use of IT systems – PPM and EPPM software – can significantly improve measurement outcomes, through built in reporting and tracking features. IT solutions can provide the PMO with a clear view of the interdependencies between portfolios, programmes and projects. It is also possible to utilise integrated PMO dashboards and control sheets to support improved decision making, monitoring, reporting and measuring. Before IT can contribute at this level, foundations need to be in place.

These are as follows:

The five foundations for successful benefits realisation

  1. Benefits realisation needs to be an integrated part of the whole project management process and built in from the outset. It sounds obvious, but projects should be started with a clear view of what ‘success’ looks like – and all too often this isn’t present at the planning stages. Together with PwC, we recommend creating a framework from which to measure the achievement of strategic objectives at a high level, including how project governance and metrics will be applied
  2. Stakeholders at all levels need to be engaged to avoid a disconnect between strategy and operations. Using PPM software makes this significantly easier to achieve, by providing a central communications portal through which all aspects of the projects can be recorded, tracked and measured. At the top of the organisation, the C-suite needs to understand the strategic benefits and those who manage outputs at a tactical level should be able to see that their individual contributions are on track to achieve the required changes.
  3. A benefits dependency map helps to ensure the right stakeholders and decision makers are both engaged and aware of their involvements. Who needs to do what, when, why and how. This helps to crystalise how project goals will link to wider strategic objectives.
    • What are the project objectives?
    • What are the measureable end outcomes?
    • How can project outputs be transformed to business outcomes?
    • What specific deliverables are required?
  4. Identify what is important to measure and how to go about it. One key aspect of this is to ensure that all the stakeholders are equally engaged to be able to agree a common starting baseline for measurement. This ensures that future disputes about what benefits have actually been realised are avoided.
  5. Communicate the proposed benefits realisation plan widely. How this is achieved will vary between organisations but there needs to be a consistent way to communicate how benefits are being achieved with all the stakeholders, in a way that is relevant to them. For example, Network Rail achieves this using a graphical benefits tracker and visualisation boards, with clear accountability and ownership at each stage.

It is important that organisations try to embed benefits realisation into their project and portfolio management and to make it as scientific as possible. This means having a clear view of the ‘why are we doing this’ at the outset and creating a set of processes, which can be supported by software tools to take away any subjectivity and make it objective and clear for all stakeholders to appreciate.

OUTSIDE THE BOX Forum:A Practical Project-based Model of the Enterprise, Part 4 of 4

Who are the Participants in the EPMM?

Across the 6 phases of the EPMM several managers and professionals will be involved. This section defines these participants and gives examples of typical position titles.

Line of Business (LOB) Managers or Directors

This is a collective manager type. There are no positions named “LOB Manager”. A LOB is a Manager or Director of a business unit that directly produces business value, usually but not always financial. An LOB Manager or Director has responsibility for a product, process or service that uses resources to directly interacts with customers or clients to produce business value. 

Functional Managers

This is a collective manager type. There are no positions named “Functional Manager”. Some functional managers are resource managers. The key differentiator is whether they manage resources directly or use resources to produce business value. So, for example the Director of Marketing is a functional manager. They use the Data Warehouse (a resource) to produce a marketing plan which generates business value through increasing sales. On the other hand, the Director of Human Resources is a resource because they directly manages the human resource. One might argue that they could also be a functional manager if they manage a professional development program which produces a skill and competency inventory that is aligned with the project, program and portfolio needs of the enterprise. If we think at the role level the apparent conflict is easily resolved. In the role of managing the human resource they are a resource manager. In the role of managing the professional development program, they are a functional manager.

Resource Managers

This is a collective manager type. There are no positions named “Resource Manager”. Anyone in the organization who has total and direct stewardship responsibility over a resource that has business value.  It includes those functional managers with responsibility for resources that have business value (for example, Human Resource managers (human assets); financial managers, (financial assets); sales, marketing and public relations managers, (intangible assets); IT and engineering managers, (IP and knowledge assets) and plant or equipment managers, who have stewardship over and manage the physical assets of an organization. Depending on the specific circumstances, these people are often those who, in their role function as project SPONSORS. They have decision making authority over where the assets under their charge are deployed to create expected business value. A less comprehensive set or resources was introduced in earlier editions of Effective Project Management, 6th edition (EPM6e) and can be consulted for further discussions that are out of scope for this article.

Strategy Portfolio Managers

These could be any of the above. The Strategies are established as part of the Strategic Planning Process and their managers assigned at that time. They constitute a Strategy Team whose major responsibility is to assure the delivery of expected business value through the effective use of resources across all Strategy Portfolios. 

Project Managers

The project manager is the critical supporting participant who takes the resources delegated to him or her by a Strategy Manager and utilizes those resources to produce a project deliverable which hopefully will achieve the strategic objectives defined by the project sponsor. That could come in several forms: 
  • New product development or improvement
  • Process design or improvement
  • Service enhancement
So, the project manager facilitates the process of change and manages the risk of achieving that change. They are the enablers of the projects in a Strategy Portfolio.

Business analyst

It is important to distinguish between two types of Business Analysts. They can be generalists or specialists.
I’m a firm believer in complex projects having a team comprised of both specialists and generalists. The argument in support of the generalist is that they have the ability and skills to keep options open and may see solution details that would otherwise be missed.  The specialist is constrained to their span of knowledge and experiences and can easily miss a clue about the undiscovered parts of the solution. The argument in support of the specialist is that only they can know if a suggested approach will work in the environment they represent. The generalist would not be able to make that call. 
We know that the project manager (PM) takes the lead in managing the process for defining and solving the problem and the business analyst (BA) takes the lead in solving the problem and installing the deliverables. If you hold to this, then it is obvious that both the PM and the BA are involved in the project from beginning to end. This brings up a discussion of the role of generalists and/or specialists on the project. Calling the PM a generalist and the BA the specialist is too simplistic and usually not correct. A detailed discussion of generalists versus specialists is beyond the scope of this brief article but a few observations with respect to their roles on a project are within scope.
These five professional manager groups interact throughout the entire life span of the Strategy Portfolios from birth to death. In later chapters we will expand on each of these three manager-types and discuss their roles and interactions between and among one another.

What is the Enterprise Project RASCI Matrix?

The RASCI Matrix identifies the relationship between individuals and the major processes, phases or steps of an effort. In our case we link responsibilities of the 3 major managers and 3 support professionals to the 6 phases of the EPMM. Figure 1.8 is an operational RASCI Matrix. 
Robert Wysocki June 10 1.jpg
Figure 1.8: EPMM RASCI Matrix

Complex Project Profiling

For our discussion of complex projects I reference a recent book by Kathleen B. Hass (2009, “Managing Complex Projects: A New Model,” Vienna, VA: Management Concepts, ISBN 978-1-56726-233-9). 
There is no simple accepted definition of a complex project. The best we have to offer are some of its characteristics from the proceedings of the 2008 NASA Project Management Challenge Conference (Mulenburg, Jerry, “What Does Complexity Have to do With It? Complexity and the Management of Projects,” 2008): 
Details: number of variables and interfaces
Ambiguity: lack of awareness of events and causality
Uncertainty: inability to pre-evaluate actions
Unpredictability: inability to know what will happen
Dynamics: rapid rate of change
Social Structure: numbers and types of interactions.”
 

Advertisement
[widget id=”custom_html-68″]

Complex projects are filled with uncertainty and unexpected change. Complexity, uncertainty, and the pace of the project all contribute positively to project risk. Risk increases as any of these three variables increases. In most cases these projects are trying to find solutions to critical problems whose solutions have evaded even the most creative professionals. These projects can also be seeking to take advantage of heretofore untapped business opportunities without a clear path as to how to do that. If organizations are to be successful in this environment they must:
  • employ management processes that are flexible;
  • empower the client and the project team;
  • provide an open environment in which creativity can flourish;
  • base decisions on what is best for adding business value, and
  • avoid encumbering project managers with non-value added work. 
These are significant challenges because they require senior managers to step outside of their comfort zone and embrace frequent change and high risk. 
The first bit of business for you as a member of the SMT is to understand the project environment within which your project, program, and portfolio managers and their teams must work and within that environment the challenges you will face in establishing and supporting an effective project management environment. The needs of that environment have changed dramatically in the last 15 years especially with respect to the tools, templates, and processes that support it. The result is confusion and the introduction of yet another silver bullet every Tuesday. Those silver bullets appear very enticing but let me make it clear that there are no silver bullets now nor have there ever been. There are strategies and you are going to learn them from this book but they will require work on your part in order to implement them and continuing attention from your office for them to become and remain effective in your organization. The reactions of my client organizations as they attempt to support complex project management is predictable. I offer you what I have learned over the years.
Let me try to put this in a context that relates directly to the SMT. A recent worldwide survey (IBM, 2010, “Capitalizing on Complexity: Insights from the Global Chief Executive Officer Study” GBE03297-USEN-00) conducted by IBM from September 2009 through January 2010 reported that over half of the 1541 executives from the 60 countries that they interviewed admitted that they were not prepared to support the complex and uncertain environment in which they were forced to conduct business and they didn’t know what to do about it. If that isn’t a wake-up call to action, I don’t know what is.
The following quote from that IBM report highlights the efforts of standout organizations to manage complexity. Their efforts provide a roadmap for us.
“The effects of rising complexity call for CEOs and their teams to lead with bold creativity; connect with customers in imaginative ways, and design their operations for speed and flexibility to position their organizations for twenty-first century success. To capitalize on complexity, CEOs:
Embody creative leadership.
CEOs now realize that creativity trumps other leadership characteristics. Creative leaders are comfortable with ambiguity and experimentation. To connect with and inspire a new generation, they lead and interact in entirely new ways.
Reinvent customer relationships.
Customers have never had so much information or so many options. CEOs are making “getting connected” to customers their highest priority to better predict and provide customers with what they really want.
Build operational dexterity.
CEOs are mastering complexity in countless ways. They are redesigning operating strategies for ultimate speed and flexibility. They embed complexity that creates value in elegantly simple products, services and customer interactions.”
The messages from this survey are clear and validate the goal of this book. The solution offered herein is a logical approach to mitigating the complexity problem that over half of the CEOs interviewed admitted having. Which half of the population do you align with? If you want to prepare yourself to handle complexity, this book is mandatory reading and prepares you to take action. If you are a standout organization, congratulations but you should still read this book because in these pages you will find some gems to help you stay on top of changing complexity and uncertainty. 
There was a time when you may have distanced yourself from projects. Your feeling was that projects were operational level activities and of little importance to someone at your management level. In the past 20 years you’ve probably rethought that position and now see projects as investments and part of a portfolio that has an investment strategy. You may in fact be the manager that determines that strategy. For that reason you are challenged to do what you can to maximize the return on investment (ROI) to your organization from the projects you recommend for the portfolio and that you support directly. How you have responded to this situation depends on your roles and responsibilities with respect to the project, the project teams, and the portfolio. You may have primary responsibility for supporting or managing project managers or have a role supporting those who do have primary responsibility for supporting or managing project managers. In any case, this book offers you the advice you will need to help you and your organization succeed.
The business environment has changed significantly in the last 20 years and has ushered in new project management challenges that the old ways simply cannot support. Business as usual with respect to projects no longer works and may have never worked. Contemporary projects are projects of high complexity and great uncertainty and you must deal with them under those conditions. All of the simple projects have been done! Specifically, 
  • Complex project managers need the confidence and support of their management
  • Complex project teams must be empowered so they can be successful
  • Complex project portfolios must be aligned with staff resources
  • Complex projects are unique and so are their management approaches
  • Complex projects are high-risk projects
  • Complex projects require a creative approach to discovering solutions
  • Complex project require meaningful client involvement
  • Complex projects require flexible support services
In the pages that follow you will see just how you can and must positively impact all of these challenges. So let’s get started with a brief introduction to the complex project environment. Understanding that environment is the foundation on which you will be able to build your support strategy.
Kathleen B. Hass (2009, Managing Complex Projects: A New Model, Vienna, VA: Management Concepts, ISBN 978-1-56726-233-0) offers the most in depth treatment of complexity that we have. She describes complexity in terms of:
  • Time, Cost, and Size
  • Team Composition and Performance
  • Urgency and Flexibility of Cost, Time, and Scope
  • Clarity of Problem, Opportunity, and Solution
  • Requirements Volatility and Risk
  • Strategic Importance, Political Implications, Multiple Stakeholders
  • Level of Organizational Change
  • Risks, Dependencies, and External Constraints
  • Level of IT Complexity
In a paper written shortly after her book was published (Presented at the 2010 PMI Global Congress Proceedings, Washington, DC) she updates the complexity definition with a four-point scale (Independent Projects, Moderately Complex Projects, Highly Complex Projects, and Highly Complex Programs) and displays the values for a specific project in the form of a spider chart. Figure 1.10 is a hypothetical example adapted from her updated definition and published with her permission.

OUTSIDE THE BOX Forum:A Practical Project-based Model of the Enterprise

The Enterprise Project Management Model (EPMM)

At a very high level of abstraction the EPMM can be reduced to 5 simple questions by adapting the Graham-Englund Project Selection Model (Graham, Robert and Randall Englund, 1997. Creating an Environment for Successful Projects, San Francisco, CA: Jossey Bass),  as shown in Figure 1.4  below and introduced in Effective Project Man 

 PM June3 1

Figure 1.4: Adapting the Graham-Englund Selection Model to the EPMM

The Graham-Englund Selection Model is an intuitive model and derives directly from Figure 1.4. It gives a very simple introduction to the EPMM and relates to the EPMM as follows:

  • What projects should we do? This decision follows from the Market Opportunities. 
  • What projects can we do? This decision follows from the Enterprise Capacity.
  • What projects will we do? The Strategic Alignment Model defines these in terms of the Tactics identified in Figure 1.2. The decision on portfolio contents must include all portfolios because they are interdependent by virtue of their resource requirements and schedule availabilities.
  • Will the portfolios be balanced? Balance is in the eyes of the beholder. There are two points of balance in a portfolio.

The first is with respect to the business strategy and there are several models that might apply (See EPM6e Chapter 14: Project Portfolio Management Process.).

The second is with respect to resource capacity, especially the human resource inventory of skills and competencies. If every portfolio requires senior level project professionals, what do you do with the lower level project professionals. Alignment of supply and demand across all resource types is a critical component of the EPMM. As Strategy Managers balance staffing needs of their projects against available resources a common practice is to replace “A Team” players with “B Team” or even “C Team” players. EPM6e has a lot more to say on these compromises.

  • How are the portfolios performing? Projects are included in a Strategy Portfolio because they expect to deliver acceptable business value to the Strategy Portfolio. Each project’s performance is continuously assessed against that expectation. At regular intervals Strategy Portfolio reviews are conducted. Under performing projects may be revised or terminated and its resources assigned to a replacement project.

To achieve the Business Strategy and Strategic Plan of the enterprise requires a comprehensive process that I will call an Enterprise Project Management Model (EPMM). As defined below we will come to realize that it is an interlocking and interdependent collection of processes involving several different managers from C-level executives to department managers and several different support professionals.

There are two views of the EPMM that will help put projects into proper perspective. The project level process flow diagram is described in Figure 1.5 and the process flow diagram of the Strategy Portfolios. 

PM June3 2

Figure 1.5: EPMM – A  Portfolio-level EPMM Process Flow Diagram

The history and development of the EPMM begins in the early 1960s. I was a newly minted system engineer enjoying my first real job at Texas Instruments in Dallas, Texas. I was exposed to the annual planning process called TI/OST. That process has evolved over the years and is still monitored by the Harvard Business School (reference?). The learning opportunities it afforded me are reflected in much of my project management publications and the EPMM as well.

The EPMM takes the Strategic Alignment Model described in EPM6e and puts it in the context of the enterprise. Figures 1.5 gave a high-level view of the EPMM. This offers a fresh perspective on how projects, programs and portfolios arise and how they are in fact interdependent due to the fact that they draw from a finite and dependent set of resources. That elevates decision making to the highest levels of the enterprise.

The Vision, Mission and Objectives statements drive the specification of Strategies to be implemented over the strategic planning horizon through the submission and selection of Tactics aligned to those Strategies. Six phases trace the life span of a project, program or portfolio – from birth to maturation to death. Below is a snapshot of each phase.

COLLECT Phase

The net to collect these ideas must caste a wide berth across the enterprise. This is both a top-down and a bottom-up effort. The top-down effort is guided by the resource, functional and LOB managers. The bottom-up effort is to support a process that encourages anyone in the enterprise to submit their ideas to their appropriate managers. At this point every idea is a good idea and the process used to gather these ideas must facilitate ideas coming from anywhere in the enterprise. The ideas that form this initial set are discussed and vetted by C-level and other senior level resource and operations managers through a collaborative model. All of the ideas are submitted using a one page document called a Project Overview Statement (POS). Comments and observation are added to each POS and then forwarded to the ANALYZE Phase.


Advertisement
[widget id=”custom_html-68″]

ANALYZE Phase

The successful execution of this phase depends on input from the appropriate business analysts. Their analysis will collect more detailed intelligence on each of the ideas for the purpose of reducing the set to a much smaller set of feasible ideas. In the process of doing this analysis more detailed information on each feasible idea will be appended to each POS. These amplified documents are forwarded to the SELECT Phase. One of the critical activities in the ANALYZE Phase is the alignment of Feasible Ideas to Strategies. There are two processes for completing this activity.

PROJECT Scope Phases

The Project Scope Phases are repeated for each Strategy. The next three phases (SELECT, INITIATE and EXECUTE) bound project management as we know it. The interesting feature of the EPMM is the positioning of the choice of best fit project management life cycle (PMLC) within the INITIATE Phase. The process for making that best fit decision is portrayed in Figure 1.6 below.

SELECT Phase

The first step in the SELECT Phase is to prioritize the feasible ideas that came out of the ANALYZE Phase. There are several ways to do that depending on the needs. From that prioritized list choosing the Best Idea is a complex process. First of all, we are not just picking just one project. We will pick the best from among a short prioritized list that is aligned with a “bucket” that includes projects that are aligned with a Goal and one or more of its Strategies. At this level we are picking a portfolio that spans all of the buckets and are constrained by the applicable set of resources. A further complicating factor is that many of the resources are finite and more than one resource is needed for any feasible idea. In that sense, resources are not independent from one another and that complicates the choice of  Best Idea. So in effect what we have is a machine with lots of moving and dependent parts.

INITIATE Phase

The INITIATE Phase begins with the preparation and sponsor’s approval of the project plan. The INITIATE Phase begins with a process to choose the best fit PMLC Model for each project in the Strategy Portfolio (Figure 1.6). These plans are then consolidated into a single portfolio and final decisions are made about the final portfolio and the resource availability dependent schedule. To accommodate as many of these projects as possible, adjustments to project schedules might be needed to accommodate resource availability.

PM June3 3

Figure 1-6: A Robust EPMM Process for Choosing the Best Fit PMLC

EXECUTE Phase

Producing the deliverables according to the requirements can be straightforward (traditional projects) or risky and very challenging from a management perspective (complex projects). In the final analysis, the sponsor has to decide if the expected business value can be realized. Maybe yes; maybe no. If yes, everyone is satisfied and the deliverables can be installed. If no, any number of further actions might be approved.

DEPLOY Phase

The deliverables are put in operational status according to one of several implementation strategies and the deliverables are monitored for compliance during a warranty period before full responsibility is transferred to a resource or operations manager. Actual business value delivered is tracked against expected business value.

Can the Same Person Function as a PM and BA on the Same Project or Agile Effort?

Ten years ago I wrote an article entitled, Can Same Person Function as a PM and BA on the Same Project.

I wrote that there we need to distinguish whether the same person “could” (sure they could, but with sometimes questionable results) and whether they “should.” I explained that it made complete sense to have one person play both roles in certain circumstances, like when a project is known to be “small,” or on high-performance, self-directed, cross-trained teams, when an organization lacks funds for both roles, and when an organization doesn’t recognize both roles. I said it is helpful, however, to know the differences between the roles and know when each is being played.

Ten years later I still agree with what I wrote. However, there is another question that needs to be put into the mix—what about Agile? Before we answer the question of Agile, let’s a have a quick look at some basic differences between the PM and BA roles.

Generally speaking, there is an inherent difference of objectives between the two roles. Project management is more about the project and business analysis is more about the product. The project manager’s role is to meet project objectives. The BA’s role is to help organizations reach their goals by recommending value-added solutions that solve business problems. This is a subtle but important difference. Put another way, the project objectives help the organization meet its business goals and objectives. The PM focuses on the former; the BA on the latter.

I mentioned that the PM typically focuses on the project, including resolving issues about the project, managing project risks, and getting the resources working on activities and tasks. And that the BA typically focuses on the end product, like managing risks related to the product, eliciting questions about a new product, and specifying the details of the product so that it can be developed and delivered.

Although the PM may do some work related to the product and the BA may do work related to the project, there is still a need, I think, for both roles on most projects. It seems to me that because there is a different focus and different objectives, there is often a pull in opposite directions, especially when both roles report to different organizational functions. Project managers want, among many other things, to deliver the product on time and within budget. Business analysts want to ensure that customers can actually use the product once it has been implemented.


Advertisement
[widget id=”custom_html-68″]

But wait—what about Agile?

With Agile there may or may not be a BA and PM on the team. Our question, then, is can the same person focus on both the product and the delivery of that product at the same time? For the product we mean not just the product backlog, but the details of the features that comprise the backlog. By delivery focus we mean someone to protect the Agile processes and remove roadblocks so the team can move forward. Someone who can develop burndown and burnup charts to know what’s been completed and what’s left to do.

The answer of course is yes, it’s possible to have one person focus on both. While not ideal, it may be necessary when there are not enough resources to have a dedicated product owner and scrum master.

It would take someone with the skills to specify the features in enough details so they can be estimated and built, like a product owner—if, and this is a critical constraint—they are authorized to make business decisions. But someone who also focuses on the delivery of the features. This can work in small organizations and on small projects. It can even work in larger organizations when the organization needs to “make do” with less than an ideal number and types of resources. And although there are inherent risks with this approach, it can work.

Let’s look at a real example. A small organization used an outside IT resource to develop a product and a member of the management team to be the product owner. This manager not only was able to make business decisions, but also had both a BA and a development background. The features were developed “agily” and were scheduled to be delivered every few weeks. The acting product owner and developer worked through complex design issues and the features were implemented almost flawlessly. So far so good.

The difficulty was that although the PO and developer worked together superbly on the product features, there was no one looking after the delivery of those features. There was no one, in other words, to support or protect an Agile process. There were occasional Scrum meetings, but no daily meetings to review status and issues. The progress was not routinely monitored, and weeks would go by with no results delivered and no clear idea of when the next feature would be released. There were no retrospectives and not many reviews of the features with other key stakeholders. Because this was a small company and everyone was doing a million other tasks, this process more or less worked. But the lack of focus on the project proved frustrating for almost everyone involved.

Finally, I want to emphasize again that we’re talking about focus, not job titles. We’re talking about someone who not only has the skills to focus on both the project and product, but the time. So even on Agile projects, can the same person be both a BA and a PM, that is, be able to focus on both the product features and the delivery of those features? Sure, but when the main focus is the product, the delivery might suffer and vice versa. On projects of any size, there is less risk when these job functions are separated.