PMO Setup T3 - Tips, Tools, and Techniques

What is the mission of a PMO? What is the mission of your PMO? What should the mission of a PMO be? Well, there is no one right answer. And as always, the answer lies in what is right for you and not so much what is categorically right. But, more and more PMOs are expanding their vision and mission beyond the traditional views and approaches of the PMO as a department and stepping up their leadership position and value they deliver to others within the entire company. After all, project management is a skill that all business professionals, not only benefit from but in many cases, require. Hence, forward thinking PMOs are increasingly seeking to introduce and establish project management as an enterprise wide core competence and skillset.

For example, take Dynamic Scheduling. All PMPs and every formal project manager knows what dynamic scheduling is, the benefits of dynamic scheduling, how to do it, and how to use at least one if not several tools to create and manage a dynamic schedule. Many people create schedules in Microsoft Project. Their schedule consists of a Work Breakdown Structure, tasks to accomplish the Work Breakdown Structure, descriptions of deliverables, estimates of task duration, dependencies between the tasks, and advanced practitioners would also include cost and resource information. The schedules can be presented in a number of ways and are commonly presented as Gantt Charts with taskbars in a timescale. But the important thing is that the way the schedule is entered determines if the schedule is rigid or dynamic. That is, if you enter fixed dates for your tasks, you will end up with a rigid schedule.

Now, odds are, that if you are reading this blog, you know the difference between a rigid schedule (simple ad hoc task list) and a dynamic schedule as shown in the figure to the left. And you know the problems inherit with rigid schedules and how difficult they are to effectively use and keep up to date. But, do you think the average, occasional, informal project manager in your company that has one after another project effort to manage and deliver, say a marketing executive or a sales executive, knows? They don’t.

We can debate whether or not the PMO has a responsibility to ensure that the non-PMO projects are undertaken with some degree of skill and project integrity or that such informal project managers have a place to go within the company to get what they need to manage and deliver their project via appropriate and perhaps limited techniques rather than simply via ad hoc best efforts.

A dynamic schedule is not just a fashionable term. Nor is a schedule dynamic just because it was created in a scheduling tool like Microsoft Project. Finding the dependencies between the tasks and entering them into your schedule takes a considerable effort. So, a legitimate question therefore can be raised: Is dynamic scheduling worth it? And, what is wrong with that static task list and rigid project schedule?

Well, if your project is just a handful of tasks tasks, then maybe your ad hoc rigid schedule is just fine. But if your project effort has more than a handful of tasks, say thirty, fifty, or one hundred, then you can expect many changes to occur. And, every time a change happens, you need to change your schedule to reflect the new business reality. If you have a static model, you will need to review all future tasks and make changes to all of their dates. If you have a dynamic model, you don’t need to make nearly as many changes. If you did a good job on task dependencies, you probably don’t even need to review the future tasks since you can rely almost blindly on the dependencies to adjust their dates appropriately and automatically.

We could talk about the expected time management gains from using Dynamic Schedules and why even occasional and informal project managers should take the time to learn this technique. I have even seen well reasoned approximations to quantity how much time you can actually gain by applying the principle of dynamic scheduling and how much time you have to invest in order to make the schedule dynamic. I have to admit, I skimmed through the detailed analysis and skipped to the conclusions which stated that the expected gains from applying the principle of dynamic scheduling are a savings of fifty-six hours of project management time per each project of one hundred tasks.

But, to me, that is the wrong way to go about it. The value of Dynamic Scheduling verses ad hoc rigid scheduling to the occasional or informal project manager isn’t time savings, but rather risk management. Take the ubiquitous multi-million dollar sales projects that enterprise sales executives and account managers manage each and every day. They call it pipeline management and this has nothing to do with oil in Alaska. These multi-millions dollar sales can take months, even years to close, implement, and revenue recognize. And within the sales cycle, there is very much a prescribed process that all sales professionals follow. And, every CRM tool has the ability to list these pipeline opportunities and add sales and marketing tasks to the opportunity. Some are even aligned to the de facto standard Miller Heiman Sales and Marketing approach and their Blue Sheets for strategic selling of complex enterprise systems. But are the tasks and timelines that are created by these CRM tools dynamic? Of course not.

Now, who cares? What is the big deal over the fact that virtual every formal project, even a three month software development or IT project, would be scheduled dynamically and with some degree of integrity while at the same time outside of the PMO a nine month multi-million dollar sales opportunity would be managed, from a project schedule point of view, via ad hoc best efforts and static task lists. Well, your CEO and your shareholders care, because when your sales executives and account managers fail to deliver these kinds of deals on time, there can be and almost always is serious problems such as not being able to recognize revenue or worse, not being able to meet quarterly earnings commitments.

Let’s take a real life example. I won’t mention that company name, but the story is not unique to them anyway. A few years back, a highly respectable, and publicly traded, enterprise software firm forecasted their quarterly revenues based upon a number of inputs such as the sales pipeline, consulting services contracts, and annuity revenues from maintenance and support. Of all of the inputs, the sales pipeline carried the most risk. Some of the pipeline came from low end product sales and trials, you know the twenty-five thousand dollar pops here and there, but most of the pipeline consisted of the few and very large enterprise deals such as a one or two million dollar enterprise license. Well, the sales executives and sales VP managed the pipeline somewhat ad hoc and by the seat of their pants. This was fine in the old days when the company was merely a division of a large corporation. But now, after being spun off, and as a stand-alone publicly traded company, the stakes were much higher and much more visible.

Let me fast forward and get right to the point, the sales VP forecasted one of these mega deals by the seat of his pants and toward the end of the quarter it became clear that this deal just wouldn’t be able to close in time. So, at the quarter end, the sales VP had good news and bad news. The good news was that the customer was totally committed to the deal and that it was, as they sale in sales, good business. The bad news was that the transaction would slip and could only be revenue recognized in the next quarter resulting in a miss of the current quarter revenue and earnings forecast. In the previous days when the company was just a division of a large corporation, this would be no big deal and would provide no cause for concern. The champagne would just need to sit on the ice a little longer. But now, as a publicly traded company, there was cause for concern as missing quarterly forecasts doesn’t sit well with the institutional investors and market pundits.

After the dust had settled, this multi-million dollar mega deal that was more than a nine month project effort of significant and complex proportions closed ten days late, it slipped from one fiscal quarter to the next, and it resulted in the quarterly revenues and earnings of the company being missed. Within twenty-four hours of the quarterly earnings release which disclosed the miss in revenue and earnings, the stock price of the company fell from 83 to 42. The resulting loss in the company’s market evaluation was more than one and a half billion dollars. All, on account of a project that finished a few days late.

In conclusion, would dynamic scheduling have prevented this tragedy? Maybe, maybe not. We will never know. But what we do know is that one after another significant project effort, albeit informal and outside the official project portfolio of the PMO, are being managed ad hoc and by the seat of someone’s pants from a scheduling and overall project integrity point of view. And, that the ability to manage such projects better via techniques like Dynamic Scheduling is not and should not be a secret or special technique to be known and held exclusively and used by only the formal and certified PMP brethren, rather Dynamic Scheduling is a key business skill. There are those advocate making the use of Dynamic Scheduling commonplace, not just by your formal project managers in your PMO, but by anyone and everyone in the enterprise that has a project effort of value to deliver.

Is Dynamic Scheduling a key business skill? Maybe the answer isn't so much of a yes or no, but that it can be.

What is MBWA..? Chances are, if you are a manager and are over 50 years old, you know what MBWA is. Back in the days when we had our business departments, in some cases divisions, all in the same office building and we managed face to face, MBWA was just one of many leadership techniques. But, in today's business environment with all of its organizational constructs such as satellite offices, remote offices, virtual offices, home offices, corporate "hoteling - desk and phone on demand" offices, if you are a new manager or just a young guy or gal, you might not have ever heard this term, MBWA - Managing by Walking Around.

Though I formally learned about MBWA in new manager training years ago, I experienced it first hand even before that. The year was 1983 and I was an Account Manager in Dallas. I was having lunch with my customer, a value added reseller of ours, and point of contact for our relationship. We were at their company cafeteria and it was a Wednesday. Now, you might be thinking, after twenty-five years, how could I possibly remember that it was a Wednesday? Well, I remember for a fact that it was a Wednesday because on Wednesdays the company cafeteria served Prime Rib and every Wednesday we would have our customer/vendor status meeting and working lunch. Just me, from the vendor side, and my point of contact, from the customer side.

On one of these Wednesday’s and for no particular reason, a well dressed gentleman sat down and joined us for lunch. I immediately recognized this gentleman, though he had no reason to know of me. The only thing stranger than his sitting down and joining us were the two egg rolls and small ice tea on his tray. Not that I have anything against Chinese food, but it was Wednesday, prime rib day. The finest prime rib in Dallas and at a price of less than five dollars.

After joining us, this gentleman proceeded to ask us our names. He needed no introduction. He went on to ask us about our areas of responsibilities and our measurements as well as how business was going. And by how business was going, he didn’t mean good or bad.  He asked for details such as "Year- to-Date" percent of plan, forecast for the year, and top three opportunities for the month. Throughout the conversation, he offered ideas and suggestions. And as our little lunch chat was coming to an end, he gave me his business card and offered that if I ever needed any help or had a problem in working with the company to give him a call. He also asked for my business card and told me how important my efforts and support were to the company. He then told the two of us to give him a call as soon as we achieved our reseller objective for the year so he could congratulate us. And, the sooner the call, the better. We learned quite a bit from this man’s suggestions and ideas. We are also quite inspired to achieve our goals and we continued on with our working session with renewed vigor and resolve. We were pumped up and it felt great.

That is the effect that MBWA, Managing By Walking Around, can have on others. It is a leadership technique that has withstood the test of time and that can be used by any manager, from first line to executive. And, in today's businesses, MBWA doesn't need to be limited to just walking around as there are far more opportunities, tools, and techniques for "informal" management. The key is to be involved and to add value. Making a habit to share expertise and inspire others is a management technique that just about any organization will benefit from.

Oh, a few more details of that day some twenty-five years ago:

• The company I was with - IBM
• The customer I was with - EDS
• The gentleman who MBWA'ed us over lunch - Ross Perot, the founder and Chief Executive Officer of EDS
• What I had for lunch - Prime Rib (it was Wednesday at the EDS cafeteria)

MBWA - Managing By Walking Around. Give it a try..!

Have you heard the term, PMO 2.0? Do you know what it is? Well, PMO 2.0 is the brain child of Terry Doerscher, Chief Solution Architect for Planview (view Terry's profile). Terry has over 26 years of experience in project management, business strategy, and work and resource management and a few years ago, based upon his work with PMOs and his vision of where PMOs are going as well as what they can become, Terry coined the term PMO 2.0 and went on to describe his vision and thoughts in a series of articles and white papers. Additionally, Terry conceived of and started the PMO 2.0 Leadership Forum series, a forum designed to bring PMO executives together to address best practices, hot topics, and the state of the industry. This valuable and "free" leadership forum is open to the public irrespective of whatever PPM vendor application that you may have. Recently, I had the pleasure of interviewing Terry Doerscher in "Episode #124: PMO 2.0" of The PMO Podcast™. If you haven't heard Terry speak about PMO 2.0, you might find this 30 minute interview informative and insightful. Click on the link below for further information and/or to listen to Terry's interview.

• The PMO Podcast™ Episode #124: PMO 2.0, an interview with Terry Doerscher, Chief Process Architect, Planview

Happy listening..! And, don't hesitate to share with us what PMO 2.0 means to you and where you think today's PMOs are (or should be) heading..!

Project Management Processes provide value to organizations of all sizes, shapes, and charters. From large scale projects managed by senior project managers to small scale efforts performed by occasional practitioners with little if any project management training, a common set of processes improves project results as measured in quality, time, and cost. Whether discussed anecdotally or within the framework of a leading maturity model, of this there is no doubt. But, how does one make a case to convince executives of the value of project management processes to the organization? The precise argument will be different from company to company because each workplace has its own culture, a unique set of problems that it faces, and differing experiences and views on the value of processes and "best practices" in general.

Each workplace has its own culture. Some workplaces seek change in quantum leaps, others prefer step by step gradual change, and there are those that resist any kind and all forms of change. Knowing the culture of the workplace and making improvement recommendations in a manner that the workplace can accept is tremendously important in bringing about effective and lasting change.

What are the unique set of problems that the workplace faces? Some workplaces are short of staff and simply can not get the planned work done on time. Often, resources are reassigned, jeopardizing other projects. Other workplaces may have high incidences of errors and required rework, impacting project results. Some of these errors may be systematic while others may be related to the skill levels of not just the project manager, but all those involved in the project management process. Knowing the unique set of problems that you face, not just the remedy, will greatly help in getting others around you to understand and support your case.

Differing experiences and views on the value of processes and "best practices" exist in every organization. Some organizations embrace processes and "best practices" as a way of reducing defects, eliminating waste, and maximizing performance. Such organizations that have experienced first hand the business value of processes, will be likely to adopt processes and "best practices" for project management as well. Workplaces without a positive track record or focus on processes will be less likely to appreciate the strategic advantage they bring to a company.

Are you feeling any pain?

If your organization delivers projects okay today, then your business case would have to demonstrate how project management processes would bring improvements in measurable project results such as quality, time, and cost. To make this case, you need to present specific areas where your company is feeling pain today. These are "Pain Points." And, you need to clearly show how project management processes alleviate those pain pain points. Having reviewed tangible and credible evidence of achievable value, executives will be much more open to changes and actions required to bring about desired results. Consider the following:

Pain Point #1 - Unusable PM Methodology Manuals. Most IT organizations and project management offices have project management methodology manuals. While these guidebooks provide very good content and approaches, in most workplaces methodologies simply don't work. They are hard to access, difficult to use, too detailed, and can't be easily changed. In fact, seldom are they updated to reflect organizational changes and new approaches. They focus mainly on the "what" is to be done from a theoretical point of view and not the "Who, When, Where, and How" from a practical point of view. And as methodology manuals become out of date, they cease to be useful. The resulting pain is that the performance of the project team will vary greatly and project results will be inconsistent. Contrary to this, a well defined project management process clearly shows for each step of the process not only what is to be done, but who does it, who can help (mentors), what tools and information is available to save time and assist in the effort, "how to" examples, all in the context of the customer environment. Processes, unlike methodology manuals, remain current and are continuously improved saving time, reducing costs, and improving quality.

Pain Point #2 - Too wide of variety of performance. Most organizations have a wide variety of people with different titles and skill levels that manage projects or are involved in the project management process. In fact, in today's workplace, the title "Project Manager" appears in almost every line of business and department. And, even those without a project manager title find themselves managing projects from time to time. Though the IT group and project management office may provide tools and training, there typically remains a fairly large gap between the experience and skill levels of the IT/PMO project managers and all those in the organization who are de facto project managers. Systems, tools, and techniques that may be well understood and used by IT and the PMO may not even be accessible by other groups. Without a project management process that is easy to access and used by all, the resulting pain is that de facto project managers and lesser skilled practitioners will manage projects less effectively than they otherwise could. Execution difficulties, mistakes, and omissions, such as developing a business case poorly or not at all, engaging in project planning prior to or instead of developing a project charter, closing the project based upon assumed client acceptance, skipping key steps as well as review and approval gates in the process, etc, will contribute to project delays, higher project costs, and project results that may not satisfy the stakeholders.

Pain Point #3 - Lack of project type scalability. Many organizations do not have project type scalability. Rather, they have a "one-size-fits-all" approach to project management. The resulting pain is twofold. Not only are short term projects over planned and controlled, but long term, complex projects may not be planned and controlled well enough. Scalable project management processes alleviate this by providing project type selection guidelines that take into consideration such things as project size, scope and complexity, cost, work effort, resources, integration and procurement requirements, risk, strategic fit and benefits. Shorter term projects can be "fast-pathed" while longer term, complex projects can take full advantage of all of the process steps.

Pain Point #4 - Reinventing the wheel. Constantly reinventing the wheel is perhaps one of the biggest areas of pain most organizations face today. Project managers are constantly looking for reusable assets and reinventing project management templates, forms, and checklists and it goes much further than that. There are presentation agendas, analysis techniques, and untold tutorials, self-studies, and useful information including past projects archives that almost always abundantly exists, but in a private unshared manner. The end result is not only a great loss of time as project managers individually assimilate these items, but a great loss of an opportunity for knowledge sharing and performance improvement.

Pain Point #5 - Lessons learned are not applied. Some organizations do not take the time to document lessons learned feedback. Perhaps worse, other organizations so take the time to document lessons learned feedback but then simply file them away with no real intention, or ability, to take action. The resulting pain is that repeat mistakes and errors will be made continually. Many of these mistakes will be frustrating and some will be costly. Perhaps the biggest casualty will be that when lessons learned are not documented, reviewed, and acted upon, the resulting attitude and behavior in the workplace becomes one of complacency and "that's good enough" rather than one of continuous improvement and "how can we do better?" The value of the latter is priceless.

The case for project management processes can be built in many ways. Most workplaces within an organization have a mixed track record for delivering projects within expectations. Characteristics of these workplaces include:

• Consistently completing projects late, over budget, or not within agreed to requirements.
• Difficult to use or out of date project management methodology manuals.
• Inconsistent techniques and tools used by project managers.
• Applying project management as control reporting rather than providing value throughout the project life cycle.
• Consistent heavy stress, overtime work, and resource re-allocation to complete projects on time.
• Frustrated project managers, team members, and unhappy stakeholders.

Project management processes is the way to overcome these shortcomings. And going forward, in terms of setting up your project management processes, there are increasingly more and more options and alternatives to creating your processes from scratch that can quickly and effectively help get you to where you want to be such as:

• PPM Tools - many of the leading PPM tools such as Planview, HP/Mercury, CA/Clarity, Daptiv, etc. offer project management process content as part of their PPM platform.
• PM Communities - leading PM communities and websites like Gantthead.com and Tenstep.com offer corporate and premium memberships that provide processes for project management and a wealth of useful materials.
• Project Management Process Solutions- firms like BOT International (Processes On Demand) and Pragma Systems (ProcessMax) provide products for PMO setup and project management processes that are ready to setup and use along with existing PM tools.
• Training and Consulting Firms - leading training and consulting firms like PM Solutions, IIL, and ESI, etc. offer methodology frameworks and consulting services to assess and develop organizational project management processes.
• Website Toolkits - websites like www.method123.com and www.mpmm.com that offer project management templates and supporting information.
• Project Management Consultants - every project management consulting firm, large, small, and everywhere in between, offers methodology development services and can help you with your project management process needs.

Now, let's take a reality check. Having project management processes does not mean you will not encounter project problems, risks, and surprises. It does mean, however, that you will have processes in place to deal with all the contingencies and to perform consistently and predictably. And the end result of that might offer your PMO both an alleviation of those project management pain points and enough tangible evidence to convince those executives of the value of the PMO.

Setting up a PMO is not easy and there is no one right approach to go about. Some folks advocate focusing first on the kind of PMO that you want to have - the PMO Model. From there, organizational decisions can be made, PPM tools can be implemented, and the PMO is off and running. Sometimes this works, but far too often the PMO and the leadership team is faced with the reality that despite the investment in the organization and the new tools, project results have not significantly improved.

An alternative approach that is applicable to PMOs of all shapes and sizes is to focus less on organization and rushing to purchase a PPM tool (at least initially) and more on the processes of the PMO as the mechanism to predictably and consistently achieving the objectives for which the PMO was established. Toward that aim, four steps emerge as a practical roadmap that just about any project office can follow:

First, define a useful and usable process for project management that describes not just the "what", but the "who, when, where, and how" of the what is to be done. Don't think methodology such as "how to scramble eggs", rather think process such as "how to make breakfast for your mom and in her kitchen!" In defining the process, provide structure, and flexibility within structure with such things as scalable workflows, multiple process views, and tool options. And, don't forget the process owners, subject matter experts, and mentors.

Second, the setup of a workplace process framework. This involves a few things such as defining the PMO architecture (PPM application, collaboration platform, PMO content assets). Ensure that the content assets of the PMO are accessible and easy to use by all those involves; project managers, project team members, management and the leadership team. PMO assets to consider include processes and templates, policies and dashboards, and supporting guidance, tools and techniques, and subject matter expert knowledge. And seek to balance "technology vs. theory". Technologists often focus on the latest in product bells and whistles. PPM tool features help, but they don't replace the processes of the PMO. Likewise, theorists can sometimes focus too much on by the book knowledge and approaches that work better in theory than in practice with respect to the constraints of the organization. And lastly, in setting up the process framework, avoid project management methodology "blackholes" - such things as Gap Analyses, PMMM assessments, and methodology updates, etc. Don't take too long to learn (or have someone tell you) what you already know.

Third, use what you already know and have. Often, implementation of new project management systems are met with difficulties, to no discredit of the vendor’s application, rather on account of the fact that tool functionality was not the real problem in the first place. As Deming says, “95% of a problem is the process”. Seek to fully maximize the return on your "past" investment and use continuous improvement processes to identify, confirm, and drive changes in tooling.

And fourth, forgive human errors but not process errors. In a project management culture, every project is an opportunity for some kind of lessons learned. Expect and embrace human errors as they can serve to identify those things in the process (errors and/or omissions) that led to the problem in the first place. Some organizations even tie bonuses for project managers to their improvement suggestions.

These practical steps don't necessary need to take a lot of time or money to do. And, they can support and be performed periodically as well as before, during, or after such things as organizational and/or new tooling decisions. The end result offers to be a PMO with a improvement oriented culture based upon soundness of method that delivers projects consistently and effectively.