Behavioral Project Planning

Today (2.28.2018), I logged into my LinkedIn feed and saw a graphic that announced a concept called behavioral project planning. It turned out to be the name of a web site which contained nothing remarkable. All I could find was the same marketing focused content that you would find associated to organizations that are selling project management training. 

Get to the high ground first, look over the landscape and then review your next step options.

Get to the high ground first, look over the landscape and then review your next step options.

What a disappointment but still this company has submitted an interesting battle cry for organizations that might be struggling with culture behaviors that negatively impact project execution. To be fair, it is possible, this company is trying to protect and capitalize on their idea. Just because the site currently looks like a mcguffin, that doesn't necessarily mean they don't have some awesome concepts under the surface. 

However, I found myself thinking about the concept enough to draft and share what might be a definition of a behavioral project planning concept. 

  • Research organization behaviors
    • Create a list of behaviors that others have shared (books, white papers, blogs)
    • Determine which of these behaviors impact your organization
    • Do deeper research on those behaviors to see what others are saying
  • Perform a root cause analysis for behaviors associated to your organization
    • Note: This is NOT done to fix the behavior but to fully understand it
    • Review the list of root causes and group them logically
  • Align both behaviors and root causes to project impact
    • Again, NOT to fix either but to understand the big picture

After this is done, you have two ... well maybe three ... actually four possible choices.

1. Do Nothing
2. Try and fix the behaviors
3. Try and pivot processes to mitigate behavior impact
4. A combination of number 2 and number 3

Out of all of these, the one you have the most control over is the pivot (number 3). I wouldn't suggest creating a totally new project execution process. This would be like trading in your car due to a flat tire. I would recommend a surgical approach to modifying your process. It is quite possible that you can make small changes that go totally unnoticed by the organization as a whole but provide a significant boost to overall project execution efficiency. 

Finally, realize this is NOT a one and done endeavor. It is possible that some of your pivot tweaks cause as many or more problems than the original issue. Because of this, I recommend the classic iterative approach of making a change, gauge its effects, adjust as needed and then proceed to the next items on your overall backlog of identified pivots. 

© 2018 Dwayne Wright

The PMO - Being Good - Aligning To Strategy

Being a successful PMO is not easy. Often, the PMO is portrayed as "the bad guy", forcing processes upon the innocent simply because those processes exist and/or being a general hindrance to getting things done. Because of this, I've seen some project management organizations spend a lot of time self promoting, being a cheerleader for sponsors and try to accommodate everyone while sacrificing the spirit of their individual charter.

Then you have the really good project management organizations. They became good because they survived the above scenarios, stuck to their guns and began producing quality output. Some of them are so good at running projects, they make it look somewhat easy and then executives begin to think that project management is easy. However, that is a tale for a totally different narrative.

A early view of my 2017 garden, pretty happy with the turn out later on!

A early view of my 2017 garden, pretty happy with the turn out later on!

How Import Is It To Be Good?

Billy Crystal used to have a character during his Saturday Night Live days called Fernando and I guess it was based upon a real person called Fernando Lamas. It is rumored that Billy Crystal came up with the SNL character because the actual Fernando Lamas once said on the Tonight Show, "It is better to look good than to feel good." 

It seems like many a PMO have a similar attitude with a small twist, "It is better to look good than to be good." This is a shame, what a missed opportunity! The PMO can be a great wing man for organizations to get more out of strengths, mitigate risks associated with weak areas and execute a series of endeavors to achieve long term strategic goals. 

Strategy, It Isn't Just A Word To Use For Wish Lists

I am amazed by how many strategic plans I've seen that have very little actual strategy within them. They simply have flowery narratives about opportunities, opportunities and yet more opportunities. You cannot actual tell what the organization wants to focus upon because it never actually says what opportunities it WILL NOT pursue. This is called selling the sizzle and not the steak and it can put the PMO in a bad position.

If the organization doesn't have a strong strategy aligned to PMO endeavors, the PMO is going to underperform to its potential value. This is because the PMO will float from addressing one disjointed project request to the next and never build any actual momentum in making something great. To achieve greatness, the organization needs to successfully chain a set of compatible projects so that the end result is greater than the sum of each individual success.

So What Can Be Done?

Well, this is a potential area in which the business analyst can add significant value. The PMO can empower the business analyst to review opportunities, do an overall market analysis and provide a recommendation of projects that could lead to a core strategic objective. PMO leadership can begin to sell the overall strategy to leadership and continue to refine their approach. Current projects that have touch points to the larger strategy could be tweaked in order to compliment each other. 

This course of action would not be easy but the defined goals can be achieved through careful planning, effective measurements, monitored execution and cross functional collaboration. At least, that seems to make sense to me and I’m certainly open to your thoughts and opinions! 

© 2017 Dwayne Wright

How Do You Feel When An Article Mentions "The PMO Overlords"?

Today I was reading an article in the BAtimes titled "RIP BRD" and read it just to see if I could predict what it would say. In short, I imagined it to be another article that tries to take an imaginative swing at saying "Agile Rules and Waterfall Drools." 

I didn't really expect multiple paragraphs of PMO bashing but it does track that those that misunderstand Waterfall can often misunderstand the PMO value proposition. The second paragraph literally uses the following to describe project professionals worldwide, "corporate PMO overlords and template-police enforcers." 

Snapped this picture at our Fourth of July party and just wanted to share!

Snapped this picture at our Fourth of July party and just wanted to share!

The entire rest of the article is overly negative about what appears to be centered around years of bad experiences. It is quite evident to me this author has had to suffer trying to do quality work and he didn't get the type of support he needed. I've been there myself and it can really tear you down. I won't invest our time in a point / counter point narrative. However, I would like to make one general counter statement. 

In my experience, good to exceptional project management offices are rare and they don't come into being by accident. A good to great PMO requires exceptional people to run them and they often don't get them. It doesn't help matters when there are so many people trying to make their voices heard about frustrations they are feeling. Because many of these people are not highly skilled in crucial conversations, their frustrations can feel like they are trying to tear the PMO apart from the inside and the outside. 

When you are in a good PMO, the majority of the drama is about classic project problems involving making crucial decisions in a timely manner, supporting your executives and communicating effectively. 

For the record, I can pivot between Agile and Waterfall pretty well. I feel that I understand the strengths and weaknesses of both and can normally pivot my approaches to meet the need/goal. Neither method does exceptionally well when they are manned by individuals that don't know what they are doing, don't feel the need to change and have the authority to resist change. 

To me, I really cannot say which of the following demotivates me more, being forced to use bad templates or being forced to attend bad standup meetings. Which is worse, a bad waterfall change control process or the lack of a quality product owner (or any product owner at all) to manage the backlog? 

In summary, it isn't fair to say that PMOs worldwide are driven by overlords with a blind focus to documentation template adherence. Although, it could be quite fair to point at that one over there and make a statement like that. However, I would submit that the finger pointing approach has less value than investing the time to try and show that PMO that there are better ways to achieve success.

© 2017 Dwayne Wright

BABOK 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" ( 

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. 

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?

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. 

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.

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 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!