]]>The BABOK (Business Analysis Body of Knowledge) guide offers an extension for agile, and in an article at Project Times, Liza Laya discusses how this extension might be applied to PMOs. She considers the PMO and agile according to strategy, initiative, and delivery horizons respectively. On the strategic horizon, the agile PMO reacts to the environment and customer expectations to make fast changes. On the initiative horizon, the agile PMO identifies needs that must be satisfied, as well as how to satisfy them. And on the delivery horizon, the agile PMO builds a prioritized backlog informed by business goals, which it continuously updates over time.

]]>The Search for Practical Project Reportinghttps://pmojournal.com/2017/12/21/search-practical-project-reporting/
Thu, 21 Dec 2017 01:01:45 +0000http://aits-org.aits2018.wpengine.com/?p=78423Reporting is one of the eternal headaches of project management and the PMO. You need to report enough to convey critical information, but not so much that stakeholders disengage or get frustrated with you. In a post for the Association for Project Management, Tim Lyons discusses different approaches to reporting used by PMOs. Reporting That …

]]>Reporting is one of the eternal headaches of project management and the PMO. You need to report enough to convey critical information, but not so much that stakeholders disengage or get frustrated with you. In a post for the Association for Project Management, Tim Lyons discusses different approaches to reporting used by PMOs.

Reporting That Matters

In the first place, reporting done badly might create undesirable new “cottage industries”:

Agile PMOs allow different levels of reporting, proportionate to the complexity or duration of the project. Rigid PMOs impose fixed formats, templates and software which teams must stick to, regardless. Sometimes this leads to a grand job-creation scheme of unofficial reports done ‘on the side’ which often tell the real story!

A common tactic of immature project management teams is to carpet-bomb stakeholders with a huge amount of detail, though this frequently leads to pleas for executive summaries and single paragraphs that can be lifted into board reports. This approach can create more cottage industries, dedicated to writing reports that are too long and which are often more about justifying than demonstration of control.

A more desirable arrangement that PMOs often use is “satisficing,” combining “sufficient for” and “satisfying conditions,” where PMOs report just enough information for important project decisions to be made. To make this strategy viable, you need to have conversations with the sponsor and stakeholders about their individual needs and expectations for reporting—type and depth of data reported, frequency, etc.

Modes for reporting are evolving gradually. Gantt charts and S-curves are as reliable as ever, but additional techniques are now entering the conversation. For instance, some people are experimenting with just making a single-page report out of data snipped from dashboard visualizations. And this is fine, as long as it satisfies the ultimate goal of reporting—to provide clear intelligence to make relevant, informed decisions.

]]>Introducing Agile Flavor to the PMOhttps://pmojournal.com/2017/11/01/introducing-agile-flavor-pmo/
Wed, 01 Nov 2017 01:00:53 +0000http://aits-org.aits2018.wpengine.com/?p=78381A PMO that exists purely to implement structure for the sake of structure is going to get in people’s way, and it is that sort of PMO that gives great PMOs a bad name. In an article for CIO magazine, Michael Dougherty discusses how he has implemented aspects of agile in the PMOs he runs …

]]>A PMO that exists purely to implement structure for the sake of structure is going to get in people’s way, and it is that sort of PMO that gives great PMOs a bad name. In an article for CIO magazine, Michael Dougherty discusses how he has implemented aspects of agile in the PMOs he runs in order to better enable project success.

He uses the Agile Manifesto as his starting point, making the PMO a servant leader organization. He emphasizes education opportunities, exploring new ways to deliver solutions, and offering “clear parameters to balance consistency with creativity.” Of particular value is how Dougherty recommends considering each element of a PMO in the light of automation and DevOps. He refers to this as the “PMO infinity chain,” and he applies it in a practical way to project reporting and automating executive summaries.

]]>7 Things PMOs Should Know about What Makes Digital Projects Differenthttps://pmojournal.com/2017/10/18/7-things-pmos-know-makes-digital-projects-different/
Wed, 18 Oct 2017 01:01:02 +0000http://www.aits-org.aits2018.wpengine.com/?p=78370For most businesses, going digital is the current strategic imperative. That means digital projects and initiatives are becoming a core area of focus for PMOs in turn, but digital projects come with some nuance of which you should be aware. In an article for InformationWeek, CEB’s (now Gartner’s) Matt McWha and Veena Variyam highlight seven …

]]>For most businesses, going digital is the current strategic imperative. That means digital projects and initiatives are becoming a core area of focus for PMOs in turn, but digital projects come with some nuance of which you should be aware. In an article for InformationWeek, CEB’s (now Gartner’s) Matt McWha and Veena Variyam highlight seven things that make digital projects different:

Demand for greater speed

Uncertain financial returns

Greater business ownership of project management

Coordination with non-digital demand and governance processes

Funding flexibility

A premium on project manager’s entrepreneurial skills

An increasing focus on products over projects

The Digital Difference

According to the authors, 86 percent of barriers to project speed that PMO leaders encounter fall into the categories of “sponsor-driven decision delays, subject matter expertise bottlenecks and a lack of clarity that speed should be a priority for project teams.” These are all areas that must be addressed with more scrutiny then, if the PMO is to move at the speed that agile development teams desire.

Another thing to remember is that identifying financial value in a digital project will not always be a straightforward process. By its nature, digital experimentation will have wins and misses, so the authors say it is important to allow for looser definitions of “value” when judging the merits of potential investments. It is important to be flexible with funding in general, in that the old models of budgeting are falling apart in the face of increasing demands of agility. Just look at how businesses are gradually refocusing processes to center on products themselves, as opposed to the projects producing them. This refocus makes the value stream king, and it needs a funding process that can keep up.

A majority of IT projects are now run by business partners or contractors, meaning the relationship between IT and the business is getting closer all the time. Digital projects should serve to make these relationships tighter still. Project managers with an entrepreneurial mindset will be able to help these relationships along. With their strategic eye and urge to drive partnerships, they can perform many roles for the business, including become a scrum master or coordinate multiple agile teams.

Finally, about coordination with non-digital demand and governance processes, the authors say this:

Most companies will operate in a multi-methodology environment for the foreseeable future. That means IT needs to find a way to coordinate work being done in multiple ways (e.g., Waterfall, Scrum, XP) that have varying planning and delivery horizons. This requires PMOs to dramatically improve their approaches to surfacing, documenting and resolving interdependencies. In addition project management teams must also overcome challenges in coordinating with governance partners (e.g., Audit, Finance, and Information Risk), whose processes … often aren’t flexible enough to easily accommodate digital work.

]]>The Three Levels of Agility in the PMO Mandatehttps://pmojournal.com/2017/08/16/three-levels-agility-pmo-mandate/
Wed, 16 Aug 2017 01:01:33 +0000http://www.aits-org.aits2018.wpengine.com/?p=78316The efforts to marry the PMO with agility continue, not just for the sake of PMO survival, but for the good of business as a whole. However, agility means different things at different times. In a post for the PM Perspectives Blog, Lindsay Scott shares insights from Jesse Fewell on three separate levels of agility …

]]>The efforts to marry the PMO with agility continue, not just for the sake of PMO survival, but for the good of business as a whole. However, agility means different things at different times. In a post for the PM Perspectives Blog, Lindsay Scott shares insights from Jesse Fewell on three separate levels of agility that must be addressed in the PMO:

Personal agility

Project/product agility

Organizational agility

Slices of Efficiency

Agility has to begin with individuals. That means the PMO must commit to development and training opportunities that prepare teams for agile work. Or if it is clear new skills will be needed for an upcoming project in the portfolio, the PMO should start working now to address that need. With employee development, it is recommended to think about PMI’s talent triangle: strategic and business management, technical knowledge, and leadership competency.

The next level is project or product agility. There are of course many ways to approach this area in the PMO, meaning almost any suggestion is going to be met with apprehension by some. For instance, Fewell shares “mini-waterfall” and swarming as options. Mini-waterfall essentially breaks projects into recurring instances of requirements-design-build-test, and swarming works on a similar principle. Is that agile enough? Maybe, maybe not. Ultimately, the recommendation conveyed by Scott is that “the thinking should be about how much Agile depending on the benefits you expect to gain from choosing that approach and how much you’re prepared to put into it to gain those benefits.”

Lastly, the PMO must consider how to scale agility. Traditionally, the PMO is known for structure and standardization, so the business knows to expect these elements from it. However, the PMO must also be known now for cultivating the agile mindset (whether or not you choose to use agile’s traditional terminology).

Scott shares a few different templates for how to achieve this. One of them is the “agile competency pyramid,” consisting of exposure at the base, experience in the middle, and expertise at the peak. Or in other words: You build agile awareness, then undergo some pilot projects, and then designate “internal change agents to sustain an Agile competency.”

]]>3 Ways to Solve ‘Double Work Agile’ in the PMOhttps://pmojournal.com/2017/06/22/3-ways-solve-double-work-agile-pmo/
https://pmojournal.com/2017/06/22/3-ways-solve-double-work-agile-pmo/#commentsThu, 22 Jun 2017 01:01:15 +0000http://www.aits-org.aits2018.wpengine.com/?p=78276In a healthy organization with a mix of waterfall and agile projects, the PMO must devise separate ways of handling each type of project respectively. The PMO particularly runs the risk of agile teams crying “double work agile,” a situation where an agile team feels like it is doing double the work by updating its …

]]>In a healthy organization with a mix of waterfall and agile projects, the PMO must devise separate ways of handling each type of project respectively. The PMO particularly runs the risk of agile teams crying “double work agile,” a situation where an agile team feels like it is doing double the work by updating its backlogs and then having to do a separate report for the PMO. A post at PM Majik suggests three simple ways to avoid this concern:

Simplify reporting.

Leverage agile assets.

Create a draft report.

Running Parallel Lines

When an agile team feels like it is losing too much time to reporting, they will get vocal about it to their sponsor. The sponsor will probably relieve the team of the added reporting, yet still somehow hold the PMO responsible for reporting on the project. Thus, the above tips are needed to avoid messy situations like that.

In the first place, there is likely some way you can simplify how much information must be reported. A single-page report hitting all key indicators is ideal. Of course, asking that might create the opposite problem of teams saying that is not enough space, but it is enough space. The PMO can coach teams on which elements are absolutely essential to reporting—and which are not.

About leveraging assets, this is discussed:

While agile uses the approach that only produce the absolute minimum, information is captured in respect of scope, activity and progress through artefacts like the product back log, sprint back log, etc.

The PMO should review [these] assets and establish what information can be re-used. For example, if a sprint burn down or story burn down chart is being produced, it may be possible to insert this into the single page report. This will then give a visual update of progress. However, it is important that there is still high level commentary to provide the important highlights. The reason being that the report audience may not fully understand the chart and / or they may be someone who likes to read updates in text form.

Lastly, it could be a good idea for the PMO to just start attending daily stand-ups. Then they will have current data to be inserted into a draft report, which can be signed off on by the project team. A lot of immediate benefits are apparent in this strategy, if the PMO can arrange it. Smart thinking like this is what keeps the PMO alive and coexisting with agile in the first place.

]]>https://pmojournal.com/2017/06/22/3-ways-solve-double-work-agile-pmo/feed/2Becoming an Enabling PMOhttps://pmojournal.com/2017/04/06/becoming-enabling-pmo/
Thu, 06 Apr 2017 01:00:22 +0000http://www.aits-org.aits2018.wpengine.com/?p=78225In a post for the PM Perspectives Blog, Lindsay Scott reflects on a PMI Virtual Conference session about the path to becoming a “strategic and agile project portfolio management office.” What this really alludes to is how we can create PMOs that are enablers amidst constant change. Scott says that such a PMO would, among …

]]>In a post for the PM Perspectives Blog, Lindsay Scott reflects on a PMI Virtual Conference session about the path to becoming a “strategic and agile project portfolio management office.” What this really alludes to is how we can create PMOs that are enablers amidst constant change. Scott says that such a PMO would, among other things, foster the following: doing the right things and doing them well, boosting team practices, placing the customer at the center, creating organizational partnerships, developing an agile mindset, and applying proper metrics to everything.

]]>Does Agile Kick the PMO to the Curb?https://pmojournal.com/2017/02/10/agile-kick-pmo-curb/
Fri, 10 Feb 2017 01:00:04 +0000http://www.aits-org.aits2018.wpengine.com/?p=78161If an organization is undergoing a wide agile transformation, is it time to sunset the PMO? Okay, that is a loaded question with a lot of variables. So in a post for Leading Agile, Marty Bradley considers one specific example that he sees frequently: The company is in an ad hoc state. They may be …

]]>If an organization is undergoing a wide agile transformation, is it time to sunset the PMO? Okay, that is a loaded question with a lot of variables. So in a post for Leading Agile, Marty Bradley considers one specific example that he sees frequently:

The company is in an ad hoc state. They may be delivering but it isn’t always on time. Scope creep is inevitable in this environment as they schedule 3, 6, and maybe even 12 month releases. As much as the teams try to be agile there are a number of processes in place to make sure the product actually gets out the door. There’s some release planning up front, expectations are set. Development may occur in sprints but integration testing and acceptance testing lag behind. Sometimes it is so complicated to do integration testing it has to happen in a big time box towards the end.

Many stage gates are required because trust is just severely lacking in the business. In such a scenario, strong governance will be required to refocus the organization on agile essentials—teams, the backlog, and software that gets to done. Bradley estimates that governance will have to occur at least at portfolio, program, and team levels. That very much means the PMO should stick around, at least for the time being.

Until trust and communication start to automate certain procedures, the PMO and its manual procedures will actually be very useful to get the ball rolling. In a way, the PMO can help to “fake it till you make it.” It would be hasty to dismantle it when it still has so much good to do.

]]>What Is an Agile PMO?https://pmojournal.com/2016/11/01/what-is-an-agile-pmo/
Tue, 01 Nov 2016 01:01:56 +0000http://www.aits-org.aits2018.wpengine.com/?p=78085Marrying a really rigid taskmaster of a PMO with agile teams is never going to work. Fortunately, a PMO does not have to be an unending series of toll gates and turnstiles in order to be effective. In a post at Managed Agile, Chuck Cobb describes how the PMO and agile can coexist and thrive. …

]]>Marrying a really rigid taskmaster of a PMO with agile teams is never going to work. Fortunately, a PMO does not have to be an unending series of toll gates and turnstiles in order to be effective. In a post at Managed Agile, Chuck Cobb describes how the PMO and agile can coexist and thrive.

A Different Management

Cobb begins by reminding us that agile and waterfall are not a one-or-the-other proposition and that a smart business is going to use both methodologies according to needs. A PMO should be ready to accommodate whatever project comes its way. But in the first place, a PMO’s standard responsibilities generally fall into these categories: (1) align projects and programs with business strategy, (2) provide oversight into project execution and reporting, and (3) provide guidance and training to project teams in the tools and methodologies espoused by the business.

In a general sense, none of this should change in an agile setting, though how these things get achieved will change. Cobb provides graphs at his website of how a traditional PMO might interact with a project compared to how an “adaptive” PMO would. Essentially, an adaptive PMO acts more as a project consultant than a controller, particularly where efficient processes are concerned. Meanwhile, the product owner takes on the responsibility of interacting with business users and dictating project direction. On the flip side, that means that the business side needs to be ready to support the product owner too. The PMO no longer provides any buffer in that regard.

Cobb believes it would be quite challenging for most businesses to adopt a completely adaptive PMO, though there are many ways to build a practical, good-enough hybrid PMO:

Some organizations may choose to implement a relatively complete top-to-bottom Agile transformation for their business – Dean Leffingwell’s Scaled Agile Framework (SAFe) is an example of such a model. However, that can be a very ambitious and gut-wrenching change for many organizations and it… also may not be the best solution

I think it is a mistake to believe that you have to force a company to do an extensive, top-to-bottom Agile transformation in order to adopt an Agile process at the development level…

]]>Ending the Agile/PMO Tug of Warhttps://pmojournal.com/2016/09/29/ending-the-agilepmo-tug-of-war/
Thu, 29 Sep 2016 01:00:56 +0000http://aits-test.com/2015/ending-the-agilepmo-tug-of-war/The project management office (PMO) is the bastion of best practices, governance, and structure. Meanwhile, agile wants to eye up a problem, address it immediately, and move on to the next task. Should these two things really be at odds? Dave West writes for SD Times about how, with some effort, the two can be …

]]>The project management office (PMO) is the bastion of best practices, governance, and structure. Meanwhile, agile wants to eye up a problem, address it immediately, and move on to the next task. Should these two things really be at odds? Dave West writes for SD Times about how, with some effort, the two can be reconciled.

Trading Tugs for Hugs

One thing most agile teams know is that becoming agile often requires introducing a lot more discipline, rather than removing it. Often, the PMO’s efforts to facilitate the transformation consist of a lot of manual, traditional processes to knit the dissonant pieces together. West says the knitting often occurs during the conversion of the portfolio plan to develop activities, and again during status reporting. Here is the problem:

Not only do agile teams need to have a clear direction at the start, but work their work needs to be grouped into much smaller batch sizes, encouraging more frequent feedback into the portfolio. That means that the PMO heroes will become a friction point in the process, either greatly reducing the effectiveness of the development teams, or having to increase their workload. The reality is these roles burn out, or the agile teams get so frustrated that they ignore the PMO, providing limited information back to the PMO. This lack of information results in… last-minute decisions and lots of emergencies.

What West says must occur instead is that organizations automate a process for the PMO and agile teams to work together, based upon defining what various “artifacts” mean and how they connect. One remaining discrepancy is how to handle the role of resources and timesheets in the face of agile’s preferred emphasis on team velocity. This will vary from one organization to another, but the important thing is to stay consistent about whatever method is devised.

One example is to allocate according to a sizing metric, in which work is agilely planned and tasks are estimated. In this case, the PMO would then take this information and reconcile it to the original work in progress. Putting together the PMO and agile is less like putting together a jigsaw puzzle and more like blending together two pieces of clay. You can read the original article here: http://sdtimes.com/guest-view-ending-the-agilepmo-tug-of-war/