Forward Momentum: Delivering Results

By Vicki Wrona, PMP

An important tenet in management or project management is to understand and meet your stakeholders’ needs, including your boss, customers, other management, etc. How is it best to do that? There is (or at least was) the Apple approach, where customers are presented with the product or solution rather than asked up front what they want. Then, there is the prevailing wisdom to ask your stakeholders and have them tell you exactly what they need and you deliver that. Which is correct?

Neither. And both.

Don’t Ask, Just Tell Approach (Too Hot)

Henry Ford is quoted as saying, “If I’d have asked my customer what they wanted, they would have told me, ‘A faster horse’”. When DSL technology was initially developed in the 1980’s, customers could not imagine the capabilities it brought or how they would use the new technology. For example, without someone explaining it, they couldn’t imagine caller id, call waiting, and all the other niceties we can no longer live without. If Apple asked customers what they wanted by holding focus groups, we wouldn’t have requested the iPod, iTunes, iPhone or so many other products we can no longer live without today. Who knew we all wanted to have earbuds permanently attached and be able to carry our music around with us? Certainly not us.

Ask and Fulfill As Described (Too Cold)

The other end of the spectrum is doing exactly what the customer says they want. What’s wrong with that? Well, often they don’t know what they want until you deliver something… and then they know exactly how that doesn’t meet their needs. At that point, they need something more or different.

Combined Approach (Just Right)

As you guessed, the best approach is one that combines some of each of the above philosophies. Certainly, that is easier said than done.

To do this, we need to not only listen to our stakeholders (cold approach) but really listen and gather their real needs. This means not just accepting what they say as is and without question, but using all of our analytical tools to determine how to best solve their problem. Use analytical techniques, observation, surveys, prototyping, proof of concept, whatever you can to get their true requirements. Here is where your expertise comes in, because you may see things they cannot. This means that while we are listening, we know how to ask the right questions to draw out requirements that our stakeholders don’t even know they have, yet (getting warmer). Tim Berry wrote that “understanding the question is often more useful than knowing the answer.” To me, that statement reflects our ability to ask the right questions to get to the true need. Developing prototypes in any form will help stakeholders see what it is they will get, so they can verify earlier rather than later that the end product or service you are creating will truly meet their needs.

Part of this process involves thinking about solutions that may not be what the stakeholder describes or can imagine at this point (getting hot).

This takes much practice and time to get “just right”. With persistence, though, you can master this skill.

by Rob Zell

I am a runner and I love it. I enjoy the challenge of speedwork Thursdays and my long- run on Sunday mornings. It is hard to describe the sense of accomplishment you feel after completing a good run; a feeling like you have really conquered something. Then again, maybe it’s just runner’s high.

Back in my high school teaching days I coached Cross Country and I used to take my team to a particular part of town for a hill workout. I knew that by having the kids train on hills they would be better prepared to deal with them in races. In fact, they would have the confidence and endurance to “charge the hill”; they would pass runners on the hill and leave them behind.

Maybe that’s why I include hills and speedwork into my weekly workouts. I want the challenge and I want to build the muscle memory and confidence for whatever I might face down the road.

Learning organizations often find themselves in a rut. Requests come in and are summarily processed. Courses are developed and posted in the curriculum library. We use the same tools, the same process, the same format, every single time. My challenge for you today is to work in some new routines to your “training workout” and see how it enhances your performance.

Try something new
Occasionally it’s nice to add in a new twist to my workout. I’ll run the last half mile at race pace (which isn’t that fast, don’t get too excited) or I’ll decide to chart a new running path and explore parts of the community I’ve never been in. I always learn something new on these runs, usually about myself.

As learning professionals, we need to be ready to model the most important part of our title: learning. That means getting out of the comfort zone and trying a new technique, testing a new process, delivering a new topic or designing a new tool. It doesn’t mean you have to do it forever, just long enough to give yourself some perspective.

Take a longer-term view
This week I’ll be running a measly 24 miles. For many runners, that’s half their weekly mileage (for optimists like me, that’s double some people’s mileage!) but I have some longer term goals. My goal is to complete a triathlon and maybe a half marathon in the next year. That means I’ll need to continue to build my weekly mileage to reach that longer distance.

As learning professionals, we add value by encouraging our clients to take a longer-term view of the business and consider how this intervention will affect performance today as well as performance down the road. How will the solution be used in the future? How well does it fit in the larger curriculum? How do we build connections between existing learning? How can we keep the solution from becoming irrelevant? With these answers in hand, you have a view to create training that accomplishes today’s goals and tomorrow’s.

Overcome an obstacle
There are plenty of days that I wake up and don’t want to run, much less run uphill. But I know that if I challenge myself, I improve my chances of completing the task in the future. Succeed or fail, I will have learned something about myself and about running hills. By learning I am better prepared for the next hill and have increased confidence overall.

I’ll bet there is someone you dread having to work with. Maybe that dread is felt for an entire team or function unit (“Oh %$*^,” you’ll say when assigned the project. “I hate working with them.”) The challenge is to examine why and look for ways to overcome it. When you do, you will learn more about them and that can only help you serve them in the future (and you will have to again at some point). You will learn more about yourself and why you react to them the way you do. By tackling the obstacle head on, you demonstrate leadership to peers and supervisors. By demonstrating leadership, you build the credibility of your organization.

I love learning and I love running. Running is a metaphor for life. By the simple act of getting out of bed in the morning and strapping on my shoes I prove to myself and the world that I can face up to the challenge of the day. When I take in every run as a chance to learn and grow, I return home healthier, stronger, smarter, and more confident and not the least bit tired.

Have you challenged yourself or your organization? What challenges have been successful in your experience?

By Karey Rees

It seems like there has been a lot of discussion lately about how the role of a Business Analyst differs from the role of a Project Manager. The answer can be a tricky one especially depending on the organization you work for.

In a larger or more well-defined organization, the roles of Business Analyst and Project Manager can differ quite a bit and be held by two different individuals, but for a smaller company the roles can overlap or even be held by one person serving both roles.

Larger or Defined Organizations
In a more formal or larger organization, the BA typically manages project requirements throughout the project process including analyzing, validating, and documenting the requirements throughout the project to the desired outcome.  The Business Analyst’s key role is to serve as a liaison between the stakeholders (including business units, IT and others) to gather, plan and document requirements. The Business Analyst is a SME (subject matter expert) and should have deep knowledge of the business to answer questions and pass along all requirements to the PM who formulates them into a project plan and then assigns tasks accordingly. A Business Analyst also assures the end product is in line with the requirements.

The main role of the Project Manager is to serve as the main or “head” coordinator for the planning and execution of the project. They develop the master project plan and coordinate project resources (hours, resources, costs, etc.) A PM tracks all progress of the project and assists in working through issues.  Conducting project status meetings and updates, handling any issues that arise and identifying and helping to mitigate risks are all important roles of a Project Manager. The PM is just that, a manager, coordinating the various aspects of the planning and completion of the project. Here, it is less likely that the Project Manager is a SME, although they still can be depending on the organization.

Smaller Organizations
As I mentioned before, in a smaller company, the two roles may overlap or be managed by one person.  Due to resource constraints, in this environment, the person serving those roles doesn’t have the luxury of either being a SME (subject matter expert) or a manager, but must be both.

In your organization you probably see one to two main individuals who do these jobs.  Some organizations do have a lot of cross-over with each role, but no matter what their title is, their purpose is an important one – to assist the business in completing a project successfully.

How does your organization treat the roles of Business Analyst and Project Manager?

By Bruce Beer, PMP

Note: This is the fifth and final post in a series on PMOs.

In the previous four blogs in this series we looked at defining a PMO, the business value that they bring to a company, why your company might need one, and how to establish one. In this final blog of the series I want to look at how this new bright and shiny PMO might be integrated into the organizational structure and not just be regarded as a new “toy” that will shortly outlive its usefulness once the novelty goes away. In other words how do we internalize the necessity and contribution to strategic goals of a PMO to provide maximum contribution to your company and justify the high cost in terms of its even higher value?

There are two main types of PMOs in my experience:

1. Those that are created to manage a major project or a program (for the duration of this article I will use the generic term “program”) and will disassemble itself at the end of the program, or
    
2. A Company PMO that is established to form a “Center Of Expertise” for project management. It is there for the benefit of all projects undertaken by the company and remains in existence as different projects form and finish.

Program PMO

Let us consider the program specific PMO first. This is created to manage a specific program and is created generally during Initiating and remains until the late stages, probably into the formal Close. It is customized for that specific program, so it’s forming and ending will be dependent on the specific needs of that program.

The value of the PMO in the overall control and management of generally a large program can justify the cost by providing significant value. The areas where value can be demonstrated are areas such as coordination between the projects within the program and understanding and managing the potential ripple effects of issues, risks, and changes on one project with respect to all other projects. With regard to change management, if a change is implemented in one project in a program in isolation, the impact on other projects may not be recognized until final acceptance testing or even worse, in initial live operation.  For example, understanding how changing a database record in one project may impact other projects using the same database is critical.

If a company starts using program-specific PMOs, the value should be immediately apparent, particularly by considering what might have happened if the PMO had not been in place. One major advantage for senior management is coordinated reporting at the program level rather than having multiple project reports. This allows them to now have the overview or “big picture” on the status of the program in one report.

Other key areas where a PMO provides significant value by overseeing all projects in a program are:

1. Scheduling – identifying the critical path of all projects in the program, plus the critical path within each critical path project. Any issue affecting an individual project completion date for a critical path project will impact completion of the overall program. It might be a good idea to recognize and incorporate this into the overall plan.
    
2. Risk – if a known or unknown risk occurs on a project and a contingency plan is implemented, does this impact the ability of other projects to complete successfully on time and on budget? Is the overall program under threat? It would be highly beneficial to the overall success of the program to know this.
    
3. Quality – having a common methodology and project tools/templates will result in a common look and feel for all elements of the program and enable interfaces between them to be more easily defined and implemented. It also opens up the opportunity for reuse both within this program and for future similar programs.
    
4. Cost – overall cost of a program is composed of the costs of each individual project, and escalation of cost on one project will impact the overall cost of the program. Forecasting the latest cost of a program will be significantly more accurate by taking an integrated view of the whole project and can lead to one overall financial report rather than multiple financial reports from each project.

For this type of program-specific PMO, the benefits and value of a PMO should be clear, so the use of PMOs should be easy to justify and institutionalize for large programs.

Company or Permanent PMO

A PMO that is established on a more permanent basis for use by all projects in the company has many advantages to the company.

1. It can be the creator and keeper of the company project methodology and historical database. It can create common tools for use on all company projects. (This will allow easy re-use of tools and templates). It can also create and implement a common approach for quality and risk management throughout all company projects.
    
2. It will encourage all company PMs to utilize the company standards, methodology, tools, etc., leading to a unified company approach to projects and project management. It can also provide project auditors to perform regular or adhoc reviews of projects in execution to ensure all project standards are being met and to gather lessons learned from each project throughout the project lifecycle.
    
3. It allows members of the PMO to mentor and coach company PMs, again to help institutionalize a company methodology.
    
4. It can accumulate “best practice” documents that can easily be stored in a library and re-used for all future projects, saving cost by having a group of standard templates such as a quality management plan, a risk management plan, a change management plan and most other “management” plans so that projects are not reinventing the wheel for every project.  Once the company quality policies and procedures are created, the quality management plan will be “standard” for all company projects.

 Integrating PMOs Conclusion

In conclusion, the value of either type of PMO should be clear, and the improvement in resulting projects will not only justify the cost of the PMO, but enable higher quality projects with an increased probability of meeting the key project baselines of scope, time, and cost. Once a PMO has been created and used on a major program or multiple company projects, the benefits should justify their use. The PMO will be incorporated into the company approach to projects and become institutionalized.

PMO Series Conclusion

Overall I hope that this series of articles on PMOs has shown what they are, the business value that they bring to a company, why your company might need one, how to establish one, and in this final post of the series I hope I have showed how a PMO might be integrated into the organizational structure. In this way, it can become a valuable asset for a company to use to improve their ability to manage large programs or to establish the framework for management of all projects in a company.

PMOs can be expensive but the value they provide to a company will normally far exceed the cost. They should standardize a company’s approach to projects, lead to time and cost savings, gradually improve the project management ability of the company, and make projects a valuable tool for a company rather than something to be feared.

How has your organization incorporated a PMO into its culture? If it hasn’t, what would it take to do so?