Building the PMOPMO TrendsProject Management Office

Aligning the PMO to Lead Agile Transformation

More than one-half of the agile community identified Culture as the leading hindrance to agile adoption in organizations.1 But what exactly is culture, if not the behaviors and operating norms of an organization? Culture impacts the planning, funding, and reporting of work. The Project Management Office (PMO) is typically the entity for executing leadership expectations related to project performance.2 Leadership often touts its aspirations to, or its arrival as, an agile organization. But the day-to-day activities and decisions of the organization often violate known agile principles and values. Knowingly or not, the PMO and its practices can be an impediment to organizational agile success.

Admittedly, the previous statement is bold. Here are four afflictions that you may want to consider before dismissing the possibility that your own organization is suffering the same fate.

1. Necessitating “requirements document” to be signed off before work can be “planned.” The 2nd Agile Manifesto Principle (more colloquially “agile principle”) “welcomes changing requirements even late in development.” Agile-based development is about discovering the value-based needs of the business as the work progresses, that is,

“agile is best suited for organizations with the courage to admit that they don’t know exactly or entirely what they want when beginning the work.”

The “signed off,” in essence frozen requirements document, provides a false sense of confidence in the needs of the project before it begins, and it provides a weak foundation for the “planning the project.” But first…

2. Onerous change processes (OCP) perfectly complement frozen requirements documents. As the true needs of the project work are understood and the scope takes shape, OCP discourage the refinement of existing requirements. Committee presentations, reviews, signoffs, approvals, justifications, excuses, and apologies from the team, all detract from completing value-added work. Often, this work is discovered through collaboration between the business and the provider after the work has started. The 5th agile principle trusting motivated individuals gets trumped again by the “processes” of the culture. Sadly, controlling scope3takes precedence over delivering on constantly evolving and emerging business priorities.

3. Project planning to identify all the resources, skillsets, and costs needed to complete the work which has not yet started. The prevailing culture rests assured that scope, schedule, and cost is well understood and now easily tracked with red-yellow-green charts. And in the unlikely event that the early estimates are somehow incorrect, the organization still can remedy those nuances with their OCP.

4. The estimation process conducted by a group/ committee/ board that often has no insight into the team that will perform the work, the relevant details about the technology or platform through which the product is delivered, or the actual emerging needs of the business. The output from this “panel of experts” is often expressed as a rough order of magnitude (ROM), not to be confused with Read Only Memory. Today’s environment of rapidly changing team composition, continuous stream of released products, and constantly evolving business needs renders these estimates as virtually useless. But the culture finds a false sense of security from a premature understanding of the perceived scope of work. Where estimates do not align with actual scope, cost, and schedule, organizations can once again rely on the OCP. As #2 enables #1 above, so #4 enables #3, project planning above.

Four antidotes in agile, certainly within Scrum, respectively address the preceding challenges:

1. Maintain requirements in a product backlog that is recognized as subject to change at any time. The needs of the business as conveyed by the product owner may even seem to be whimsical, arbitrary, capricious, and ephemeral (WACE (pronounced wac-E)). The product backlog never reaches a “finished” state, and may seldom reach a stable state, until project funding or product expires. Even then, the product backlog may be resurrected with additional resources

2. Acknowledge grooming (aka “refinement”) as the “change process” for agile work. The product owner serves as the arbitrator of the competing needs of the sponsors and stakeholders whose dollars flow reflecting the value delivered by the team. Perhaps the most under-valued option available to agile projects is to mitigate investment risk by canceling a project that is under-delivering. Projects that are not positioned to deliver value can be terminated before the organization spends the funding on expectations that cannot be delivered in the current environment. Tools, business operations, scarce specialists, organizational readiness are likely barriers entrenched in the current environment.

In addition to using agility for what is traditionally described as a project, organizations are realigning work into products or product groups. In these instances, teams are responsible for all the activity—development or support—associated with the product. Annual funding is then allocated to the product rather than to a project. Teams are sustained for the life of the product versus the shorter duration of a project. This stability accretes other benefits as teams and business partners develop longer-term relationships and deeper understanding of products and their underlying technology. Grooming and the following roadmapping are examples of agile activities impacted by the broader product team notion.

3. Perform release roadmapping—carefully asterisked as WACE—reminds sponsors that any future value-delivery is based on the changing and the evolving needs of the business. The product backlog reflects those changes as might other backlogs in a scaled environment. Combining release roadmapping with short-term planning (e.g., sprint planning) provides a current and accurate reflection of the project’s value delivery capacity. Task boards and burn down charts provide daily visibility and transparency into the progress of work. Accumulated Value Delivery charts provide insight for decisions related to continued funding and support.

4. Conduct estimation by the team completing the work increases buy-in and commitment. Contrast team-based estimation with a panel of experts that are not privy to the team’s skillsets or the full context of the proposed solution. The team is closer to the business, has deeper understanding of the product backlog (formerly requirements document), and has insider knowledge of their own capabilities. Excluding the insights of the team achieving the work is often blamed on the lack of availability or accessibility to the team. However, suggesting that “a bad estimate (or ROM) is better than no estimate” is akin to professional malpractice. Organizations striving to improve their estimating prowess can apply frameworks like the Team Software Process (TSP)4 and the Personal Software Process (PSP).5 Antidotes 3 and 4 reflect the intent of the Agile Manifesto’s 4th value statement “Responding to change over following a plan.”

The four Value statements captured in the Agile Manifesto reflect the consensus of 17 agile-inspired enthusiasts. Three new value statements could help to address the rigor and rigidness of a PMO-driven culture to better align with agile adoption. As in the original Manifesto, while there is value to the items in the right,6 the value of the items on the left is preferred. The Principle mapping supports the reasoning for the preferences.

To elaborate briefly on the Prefer column items above:

  • Early and frequent delivery accrues value to the business more concurrently with the cost of investment. Value accrual and visibility into progress affords stakeholders relevant insight into choices about investment flow. See also SAFe’s WSJF.7
  • Gantt, PERT, and CPM charts are common depictions of project timelines. An alternative—a focus on the frequency of release, driven by current needs and while minimizing technical debt—can provide more relevance to the business. A demonstrable working product is preferred to updated red-yellow-green charts.
  • Constantly managing scope creep and requirement changes is time-consuming and of little value when contrasted to clearly defined work priorities accompanied by frequent value delivery. In Scrum, requirements management is accomplished through product backlog grooming on a continual basis, primarily by the product owner. Iteration-based planning sessions ensure that the highest priority needs of the business are addressed next. The self-inflicted and endless rigmarole imposed by change management processes is replaced with collaborative interactions between the product owner and the development team.

While many project manager roles are fulfilled by members of self-organized, self-managed teams, PMO professionals can aid organizational agility by helping leadership to:

  • Recognize the value of natural work products and by-products developed by agile teams
  • Understand agile cadences, roles, value-based prioritization, feedback loops, and built-in improvement cycles
  • Remind leadership that an agile risk management approach—invest a little, receive a little, incorporate feedback—in conjunction with the visibility and transparency into progress can help leadership pinpoint projects that should be continued, postponed, or canceled
  • Encourage leadership to open their staff meetings with an agile principle, its meaning and how the organization itself may be nullifying intended behaviors
  • Dare leadership to practice servant leadership with their own staff and the work in their portfolios

A colleague recently shared in exasperation “we need a restraining order on the PMO.” Fostering an agile mindset throughout the organization is both possible and beneficial, be it for product development teams, sales, HR, marketing, or brand service delivery. Value creation and value delivery differentiate successful organizations. An aligned PMO is uniquely capable of fostering the cultural adoption requisite for organizational success with agile. Transforming the PMO from a command-and-control-driven mindset towards an embracing of, not merely an accommodation of, an agile mindset further enables organization adoption.

Acknowledgments: I would like to express my gratitude to the following colleagues who reviewed and sharpened the content and its expression in this article.

  • Carmela House; Program Manager and Agile Coach; Renard Business Solutions, LLC
  • Larry Marshall; Vice President, IT Business Services | Project Management Office; Station Casinos, LLC

References:

[1] VersionOne 12th Annual State of Agile Report; April, 2019

[2] What is a Project Management Office and Do You Need One; retrieved 4/27/2019; https://www.cio.com/article/2441862/

[3] Pulse of the Profession; PMI; 2018; page 7

[4] https://en.wikipedia.org/wiki/Team_software_process

[5] https://en.wikipedia.org/wiki/Personal_software_process

[6] https://agilemanifesto.org/; retrieved 4/28/2019

[7] https://www.scaledagileframework.com/wsjf/; as an example; retrieved 4/27/2019

Show More
Back to top button
X

We use cookies on our website

We use cookies to give you the best user experience. Please confirm, if you accept our tracking cookies. You can also decline the tracking, so you can continue to visit our website without any data sent to third party services.