BABOK 8.4.4.3 Exploration - Outlier Condition To PMO Failure?

On a given day, I'm might read three or four project related resources. These can include Body Of Knowledge publications, books, subscriptions (like the PMI Network magazines, which I adore) or doing a deep dive on someone's blog I just discovered. On occasion, I might be reading something from two different resources that seem to blend their content in my mind. 

One of my resource readings today was on how a PMO may struggle to get its own team members to adhere to its own policies. For example, a project manager declares they will not use the official schedule building tool or a business analyst that takes every opportunity to forego creating a business case document. It really doesn't matter what PMO leadership tries to implement as a solution, they just cannot get individuals to conform to the process. Because of this, the process cannot get any momentum. Then the process gets a bad reputation (due to lack of compliance) and then is killed because it was not effective. 

Not sure where I took this picture, some pub or brew house is my best guess.

In a worst case scenario, the entire PMO looses steam, support from executive leadership diminishes and the PMO eventually dies a slow death. If you do a Google search for "Why PMOs Fail", you will see stats that a significant number of PMOs are closed within three years of their startup. Later on that same day, I took a CBAP practice exam and missed a question related to the Access Enterprise Limitations task (8.4 in the BABOK Third Edition). The stated purpose of this task is as follows: 

"The purpose of Assess Enterprise Limitations is to determine how factors external to the solution are restricting value realization."

So this was a pure coincidence that I came across two separate narratives regarding a solutions inability to return expected value due to an enterprise limitation. This is a loose connection, I admit. However, it gets a bit more focused when we drill down into the Elements section of this task and specifically a section labeled "Organization Structure Changes" (8.4.4.3). 

When I saw the title of “Organization Structure Changes”, I assumed this was about how an organizational change can impact the ability of a solution to produce its perceived benefits. However, here are two sentences from that section that tell a different story. The sentences are not even next to each other but my mind stitched them together automatically. 

"The use of a solution and the ability to adopt a change can be enabled or blocked by formal and informal relationships among stakeholders. On occasion, informal relationships within an organization, whether alliances, friendships, or matrix-reporting, impact the ability of a solution to deliver potential value."

Translating this in to a fictional scenario, say that PMO leadership builds and presents a process flow for projects at a 9 AM meeting to the PMO team. Members of that team can go to lunch at noon and via their friendship/alliance, they discuss any number of personal topics and then one of them mentions the new flow presented at the morning meeting. 

As they discuss the pros and cons of the flow, one of them says they "cannot" use this flow for some reason. Although they said “cannot”, it comes across as “will not.” If it is a valid constraint, this should be submitted to PMO leadership for possible modifications. However, this is just a group of colleagues having a discussion over chips & salsa. The thing is, now that one of them has “said” they will not conform to the process (even if they didn't mean that), the seed is now planted. Each of them are thinking that if one of the members of the group is not going to do it, why should they? 

By 1:30 PM that same day, the process is already doomed and the PMO leadership is completely unaware of it. Just like the BABOK warned, the informal relationships within an organization, whether alliances, friendships, or matrix-reporting, impacted the ability of a recently baked solution to deliver the potential value expected.

Somehow, there needs to be way to change the chips & salsa conversation. If you can pivot that comment "I cannot do this process" to "I cannot wait to use this process", the results can be amazing!

© 2017 Dwayne Wright

Misconception: Multiple Active Projects Increase The Perceived Value Of The PMO?

I once worked in a PMO that had over 200 listed active projects and that might sound impressive. If anyone spent time looking under the hood, they would find it quite the opposite. The reason this PMO had so many active projects was its inability to find a solution for ongoing product maintenance. The issue was that the time tracking system was tied into the project management system. You couldn't close a project that produced a product, because no one could then log maintenance time to the product produced. 

From a Monday Night Football game a few weeks ago (Seahawks vs. Bills). Awesome game and as always, GO HAWKS!

Taking that aside for the moment, lets compare two PMO environments and see if a quantification approach can be used to judge which is better. To even the playing fields as much as possible, each PMO has six individuals and those individuals have the same titles in each PMO. Lets say that it consists of a program manager, three project managers, a business analyst and a quality assurance lead. 

WHAT ABOUT PROJECT QUANTITY?
If PMO A has 15 active projects and 10 project requests, is that PMO less important than a PMO that is tracking twice those numbers? A person might respond to that question with a question of their own in regards to other quantifiable values. Those questions could revolve around aspects such as project cost, risks, value proposition and so forth. If the smaller PMO is managing more risks that the larger one, is that PMO perceived as more important or producing more value to the organization?

HERE IS THE THING
What about a consideration that the PMO with less active projects is the better PMO because they actually close projects on a regular basis? Isn't that the whole point, to successfully execute a project, close it and then deliver value to the organization? If this is true, the quantity of content residing within a PMO project pipeline is much less important overall than tracking what projects have exited the pipeline and how quickly they move through it.  Am I wrong here?

© 2016 Dwayne Wright

Business Case 101

Although it is possible that your organization has a different impression on what a business case is, the traditional description is a document that provides justification for a change. You can have business cases that are not related to a project effort because not all changes that need to be examined go through the rigor of a project lifecycle. However, that is an outlier condition in my experience. Most business cases are the fundamental first step in getting a project off the ground and facilitates formal change justification to senior leadership.

Tanner at the peak of Little Mount Si in September of 2016.

A business case shouldn't be a manifesto but a somewhat lean document that contains information important to those that are going to approve the change or the next step in a change process. For example, a business case may not have significant details regarding the costs of the change because that information comes later down the road. 

Although the business case is an early project management core document, it may need to contain information that extends beyond the project. For example, an IT process that will be improved based upon the introduction of a new application. The ongoing support and maintenance of the new application will likely be valuable in a "go / no go" decision regarding the change. However, ongoing support happens after the project is completed, so it may not be something tracked in the project plan or schedule.

In short, a business case should try to communicate the benefits, costs and potential consequences of a change decision. This often comes in the form of describing the objectives of the endeavor and the impact it will have on the organization. That impact section can include information regarding the impact of making the decision to go ahead, postponing a decision or a decision to reject the change endeavor at this time.

What goes into a business case is a highly subjective decision. Again, I feel that it should be as lean as possible and then be expanded based upon the feedback of the decision makers that will rely upon it. The BABOK v3 sums it up quite nicely. 

A business case is used to:

• define the need,
• determine the desired outcomes,
• assess constraints, assumptions, and risks, and
• recommend a solution.

© 2016 Dwayne Wright

Documentation: A Cure For Meeting Déjà vu?

Documentation can be used to break endless loops on decision making. I have been in situations where I've attended the same meeting for months. I mean beyond the fact that it happened at 10 am on each Tuesday. Each gathering contained practically the same content discussed in a previous meeting and they normally go down something like this ...

- Agenda includes a topic like, "Update On Virtualization Issue"
- You think that we have clarity on that thing we talked about three months ago
- Meeting facilitator then starts to outline the problem
- You think they are doing a recap like "On a previous episode of Lost"
- The first few comments start coming in from around the room
- Your head starts to spin a bit and you think you are experiencing "Déjà vu"

and you are ... but not the cool freaky kind that goes so well with that equally freaky music that starts each episode of X-Files. It is just that this project has been going on so long (or is so troubled) that half of the team has been replaced since it was last discussed.

Fast forward to another approach.

- Agenda includes a topic like, "Update On Virtualization Issue"
- It also says to review the Meeting Notes From "__-__-____"
- It also says to review the "Virtualization" section in the System / Subsystem Design Doc
- It includes links to the SharePoint address for each
- Facilitator brings up both documents in the meeting room projector
- The first words they utter are "Here is the new information we have about "

Fundamentals Of Brainstorming Sessions

We have all been in meetings that regardless of the agenda, evolve into a brainstorming session. As I reflect upon this, I think that every brainstorming session I've attended started out as something else. We all know that not all brainstorming sessions are created equal. However, you can increase your odds of having a productive one if the group adheres to a few guidelines. 

PRE SESSION PLANNING
You should plan an official brainstorming session if too many of your other meetings turn into brainstorming sessions. For example, a brainstorming session starts about 10 minutes to a meeting that was supposed to go over the project schedule. True, talking about great ideas is generally more fun than defining, prioritizing and scheduling tasks. However, chatting about a brainstorming session with a sponsor is not a great idea when they are wanting to see a project schedule. 

The fundamentals of planning a brainstorming session are not that different from the planning process for other meetings. The facilitator will need to define some scope boundaries for the discussion, set an overall time limit (# meetings x meeting duration), the correct participants, the outgoing communication for the meeting and finally the ground rules. Yes, there should be some ground rules in order to keep the session on track and productive.

SESSION FACILITATION
After communicating the basic ground rules, the facilitator should be ready to assist the assembled group to get their brainstorming off the ground! You will want to encourage the free flow of ideas and discourage judgment of the ideas during the session. Make sure you have a scribe recording the ideas as they happen in a format such as a whiteboard or flip chart. This can help encourage the submission of ideas and to allow for participants to build upon the ones documented.

POST SESSION ACTIVITIES
Post session activities is the missing step where I see most brainstorming sessions fail. The ideas gathered from the session need to be organized, evaluated and presented in a format that adds value to the organization. The ideas should undergo some form of rating such as prioritization, impact or feasibility. The chosen rating method should be open, collaborative and easy to understand. 

Now that you have all those great and/or crazy ideas out of the way, you can have confidence that you can stay on track when having those valuable predecessor / successor task conversations during your scheduled planning meetings!