Forward Momentum: Delivering Results

By Vicki Wrona, PMP

I would like to share an invaluable resource for running effective meetings. This concise book goes beyond the obvious high-level discussion of running effective meetings such as what to do before, during and after the meeting, but really gets into the heart of how to practically run an effective meeting, both with large and small groups. The book is called Great Meetings! Great Results by Pam Plumb and Dee Kelsey.

What I like about this book is that they discuss everything with regard to getting people together and getting results. This includes everything from understanding the purpose of the meeting and the audience to the techniques used to generate then classify and then select ideas to handling conflicts to breaking through creative blocks to making sure everyone clearly understands the outcome. Where else can you get so many concrete ideas in one concise place? I have found this to be a good reference book and have recommended it in my classes for years with good feedback from those who have used it.

One strength of this reference book is the section on breaking through creativity blocks to generate, evaluate and select ideas. We have all heard of various analytical techniques, but rarely are they used well. The most basic technique of all, that of brainstorming to generate ideas, is presented in ways to help your group avoid the most common pitfall of evaluating ideas too quickly. There is also a section on getting and keeping everyone involved at the appropriate level. Never again will you have meetings where people are allowed to sit and not participate. Anyone with ideas or knowledge will be engaged.

One of the techniques outlined in the book for large groups is an exercise called “Something in Common” which lets team members get to know each other a little better and to break the ice. Even if people have been working together for a long time, this is a fun and quick exercise.

First, pair participants up and ask each pair to find something unusual they have in common that they are willing to share with the larger group. Encourage them to go beyond the obvious and get creative. It is always amazing what people will come up with. Quickly go around the room and have each pair share their findings. I have had a lot of fun with competitive groups who try to outdo each other and be the pair with the most outrageous and true similarity. Then put two pairs together so that four people are now finding something in common. Again, encourage creativity and something else besides the items previously found. You can go around the room again and let each group share their results. Again, I direct them to do this quickly or else this exercise can take all day. J Lastly, you can let 8 people meet each other and find something in common if you choose. Obviously, the larger the group, the more “common” their similarities will be. The important thing, though, is not what they come up with but the sharing and discussion beyond normal work that they have.

I like that the book offers practical tips. For example, there are 3 case studies of one page each in length outlining how to handle:

• An undercurrent of hostility between group members
• When a participant attacks the facilitator
• The nay-sayer during brainstorming sessions

There is a nice section with tips and examples on staying true to your values as well. I like that reminder, because we get tempted to stray from our gut and don’t hear that message often enough.

I hope this helps you. Please let me know what you think of this reference.

by Rob Zell

I imagine you could survey employees on any day in any company and they would tell you that meetings are the bane of their existence. Too often, meetings are conducted without an agenda or even an overarching purpose. Attendees jockey for organizational position or display blatant apathy, checking email on mobile devices or laptops.

Meeting derailers are well documented and websites abound for coping with them. One challenge is that we work in an information age in which knowledge workers spend their time gathering, analyzing and synthesizing data, rather than producing or manufacturing. In meetings we have a desire to share what we know, rather than work to completion or decision. We all have a data set that we bring to the table and we need the time to process the data that others have before we can make a decision.

One way to manage this confusion is to have “pre-meetings”: touch base sessions with participants to set the stage and gain buy-in and commitment. Of course this means that a one hour meeting turns into a series of meetings; not the way to increase productivity! I would propose that this is the best reason to integrate the technology of a social collaboration tool into your workplace.

I can already hear the groaning in some corners of your organization. “Just what we need,” the CFO will say, “Facebook for work.” The COO will argue that the organization doesn’t need people “tweeting” on the job. This is what we often think of when the topic of “social” collaboration comes up. What if we took “social” of the term and instead called it “enterprise collaboration?” Few people would argue that engaging more people in the conversation, at least more people with relevant information, improves the quality of the decision.

A collaboration tool for business might be the answer to creating productive sharing prior to the decision meeting. Inviting employees to discuss and share adds value by increasing the knowledge and awareness of the participants and giving them time to process and synthesize. Furthermore, the content and discussion becomes a shared database and with proper use of tagging and cataloging, the information is available to the organization speeding the time to productivity. In a workforce that is generationally shifting, capturing this “tribal knowledge” is critical to the organization’s long term success.

The other great advantage in using a tool like this is that it increases the commitment to the decision. Because the members had a chance to weigh in, discuss, process and be heard, the team can come to a joint decision during the dedicated time allowed without the posturing and politics that might normally occur in the formal meeting space.

And finally, for the naysayers who will argue that these kinds of tools don’t add business value, there is plenty of research out there that says otherwise. In organizations that utilize these tools, there is better alignment, better transparency, better community and better results.

I’d like to hear your thoughts: how might your organization take advantage of “enterprise collaboration” tools to support higher productivity? If you are already using a tool like this (in my organization we use Yammer) how is it paying off?

By Bruce Beer, PMP

Note: This is the fourth post in a series on PMOs. Read part 1 What is a PMO and What Does It Do?, part 2 PMO Business Value and Impact, or part 3 PMOs – Why Might I Need One?.

In the previous three blogs in this series we looked at what a PMO is, the business value that they bring to a company, and why your company might need one. In this blog I want to look at the steps to consider when actually planning and establishing a PMO – how many people, what functions, ROI etc.

If we reach the conclusion that yes we think we do need a PMO to make our program / company / project portfolio more successful, we need to create it. So as the overall maestro of this potential vehicle to success or failure, you need to sit down to consider how many and what skill types you want in it, and how you actually bring one to life. In the following sections I use the term “program” but it is also valid for larger projects.

Some of the questions you may ask yourself during this consideration are:

1. If there are multiple projects in the program, should the individual PMs be part of the PMO or not?
2. How well established are your methodology, tools, infrastructure, and previous project history database?
3. How technical is the project?
4. How inter-related are the projects? Are they mainly independent of each other or highly dependent?
5. What is the generic level of risk for the program?
6. What is the projected cost of the program (including the PMO)? If it is for an external customer, what is the projected profitability of the program and what is the potential cost of failure of the program to your customer and to your company?
7. What is the projected length of the program?
8. For an external customer, should customer representatives be included in the PMO?

Before we look into these questions that may affect the size of your PMO, one consideration that I do not think has a major impact on the size of a PMO is whether the program is for an internal or external customer. All programs need to be planned for success whether the customer is internal or external, so the size of the PMO should not be significantly affected.

1. PMs IN OR OUT OF THE PMO

From my own experience I can suggest that as a rule, the cost difference will be negligible because there is little additional time or expense involved if the PMs are established as members of the PMO or not, unless there are traveling expenses involved. On the other hand, having all PMs together to discuss status, progress, issues, risks, etc. will usually have a significant impact on the success of the program because of the level of communication between the PMs which will enable the PMs to be more proactive on their project. So I would suggest that there are substantial benefits to having individual PMs included in the PMO rather than have them hanging around the edges.

2. METHODOLOGY, TOOLS, INFRASTRUCTURE, PROJECT HISTORY DATABASE

If your company does not have a solid methodology, including tools, techniques, and historical project information to review, then it is likely that individual projects will be managed in the way their individual PM does it and are likely to be little islands of work that are unlikely to be well integrated, consistent, solid, or repeatable. They are likely to provide the overall program manager with a great opportunity for failure and a need to polish up their profile. In this situation, a successful outcome will probably involve more people in the PMO just to develop the missing infrastructure, train and support program team members, etc. Having a well established methodology, tools and techniques will not only raise the chance of a successful outcome but will enable your company to add this experience, lessons learned, plans, etc. to a database of completed programs to enable future similar programs to benefit by previous experience. So not having a well established project infrastructure will either lead to  increased size of the PMO or a decreased probability of success.

3. TECHNICAL LEVEL OF THE PROJECT

This will impact the number of technical leads and SMEs you may need in the PMO.

4. PROJECTS: HIGHLY DEPENDENT OR MAINLY STAND-ALONE

It is possible to have a program with multiple projects that although they are related, may not be highly interdependent. In this case, the size of the PMO may be significantly smaller. Where there is a highly dependent set of projects in the program, the issues of risk and scheduling in particular are a serious consideration. In this case you may need a PMO scheduling manager who will take each individual project schedule and combine them at the program level to identify dependencies and risks. There may be a need for a PMO risk manager who could assist PMs to be proactive in assessing and managing the risks on their project caused by other projects.

5. COST AND PROFITABILITY OF THE PROGRAM

For both internal and external projects the cost of having a PMO should be compared to the risks and potential costs of not having one. In my experience, for external customers we assessed the optimum size of the PMO and if the customer will not accept the resultant price of the program our management quite rightly stated that we did not want “bad business”. Consequently we would not reduce our quotation unless requirements were de-scoped. If this were not acceptable to the customer, the decision was usually made to not pursue that opportunity as the likely lack of success would erode any anticipated profit.

6. LENGTH OF PROGRAM

This is a factor in considering the size, consistency and skill set of your PMO. Unfortunately people – even PMO members – tend to want to have vacations, be ill, and leave the company. On a long term engagement, allowance must be made for these inconveniences. One obvious way to reduce the impact is to cross train PMO members to allow for short term absences. In addition, they can perform other background tasks such as assisting and mentoring PMs, working on capturing lessons learned, training project team members in the company methodology, etc.

7. CUSTOMER REPRERESENTATIVES: IN THE PMO OR NOT

Having the customer represented on your PMO can have an associated risk depending on the maturity level of the customer. An immature customer who does not realize that all programs have issues can be a disruptive force when things go wrong; they may panic and want to implement short term fixes. The more mature customer will be an asset on the PMO provided they work with the PMO cooperatively, and resultant communication will be greatly enhanced. Ideally there will be no finger pointing when issues arise, just a cooperative approach to resolving them.

There are other questions that you, as Program Manager, may need to consider in planning the size, consistency, and skill level of your PMO, but I think the ones above are the main ones as you build your PMO.

The next and final blog in this series will consider how to integrate PMOs into the organizational culture and how to make PMOs a permanent and valuable asset to your company.

What steps have you taken in planning and establishing a PMO?

By Dr. Gerald Mulenburg, PMP

Have we (meaning me, at least) been missing what project management is all about? One of my favorite ways of thinking about the complexity of project management has been to compare it to completing a puzzle where you don’t have all the pieces and need to make some of them up as you go along. Another favorite of mine is to think about it is as if I were a juggler trying to keep several balls in the air (scope, cost, schedule, quality, etc.), experiencing only brief encounters with each important part on some rotating basis. But I am now convinced I’ve been wrong because of the simplistic ways I’ve assumed projects can be understood and managed.

At a recent PMI Chapter meeting I had an epiphany about my distorted approach during the speaker’s presentation. The speaker provided insight into problem solving by not only identifying that there are only six different types of problems and cautioning us that to solve them requires choosing the correct approach for each particular type (http://www.problemsolving2.com), but also that many problems may require using more than one approach.

Project management is one such type of problem where my single puzzle or juggler thinking is insufficient. I now know that it requires a triple problem type approach. These three approaches include the following:

1) Puzzle problem thinking works on most projects to identify the pieces involved (at least I was partially right on this method), the interdependencies of the pieces, the constraints on them (resources, time, quality, etc.), and then working with standard tools (network diagramming, critical path, schedule, etc.) until a reasonable solution evolves or something can be changed to create a more workable solution (crashing, fast-tracking, use of float, etc.).

2) Uncertainties abound on projects as risk. This is where my puzzle and juggler solutions were weak, and need to be applied as part of the solution more than they are in many cases.

3) Dilemmas, however, were the key problem-solving link I was missing from my thinking. Dilemmas result from an imbalance between stakeholder requirements and expectations, and what can be achieved with the time and resources available to accomplish the desired scope at the appropriate level of quality. The dilemma is that you want to do what the customer wants, but can’t do it within the imposed constraints. As the famous “you can’t have all three” has shown countless times, flexibility is required somewhere. NASA’s experience with faster-cheaper-better projects shows the fallacy of demanding all three, treating the problems in projects too simplistically.

In my own work with researchers and scientists on their projects, I made it clear they could demand any two of the three constraints (schedule, cost, quality), but the remaining one belonged to me. And it actually worked with them! I’m now convinced that we can do better in our project management by considering that there are often three types of problems intertwined: a puzzle to be solved; uncertainties to be identified and dealt with; dilemmas to be solved in the best interests of both the customer and the project. Considering all three together will achieve a higher level of project accomplishment and success. I can’t wait to try this, or hear from someone else who has.

How have you managed the complexity of projects?