Enterprise Navigator

Project Sponsorship is Not a Spectator Sport

I mentioned the title phrase a while back in my 3-part rant on accountability (What You Tolerate Becomes Your Standard, et al), and promised to more fully explore it at a later date. Later is now.

I was involved in leading the implementation of our application in one organization several years ago, and not once did I ever lay eyes on a mythical person I shall call Rocco the Sponsor. The name was on the contract, but he was not there at the Kick-off meeting, nor did the business strategy session lure him out. As the project manager struggled without luck to establish some sense of momentum with an ill-staffed team and no clear objectives, there was no Rocco. I was starting to think this was all a ruse when there was no response to my request for an audience. The PM swore she had met with him, but Rocco apparently wasn't coming out of the cave. After months of making little or no progress the whole effort simply faded away. The key members of the project team finally left the organization in disgust.

In time I learned to recognize that if executive or functional sponsor was absent or remained standing against the back wall in silence with arms folded during the kick off meeting, it was often the ominous indicator of what I termed Plausible Deniability Syndrome (PDS).

PDS is a condition where the sponsor provides little in the way of active support for the endeavor, apparently because they have little confidence in a successful outcome. By avoiding direct participation, there would be no blood on their hands in the event of failure. In the off chance that it was somehow a success despite their lack of involvement, they could still claim victory as well. PDS led to incorporating the title of this entry as a key theme in our consulting repertoire.

Implementation of a significant new business management application is often fatally mischaracterized as a technology project. If you take on one of these efforts thinking it is simply a matter of installing some servers, a little set up, and some keystrokes training, your success will be limited to more efficiently confusing the daylights out of the users and stakeholders.

Whether it is a new CRM tool, ERP application or a financial management platform, such projects will predictably create a bit of process and personal upheaval. They are best approached as an organizational change initiative that happens to have some software involved.

And, if you think about it a minute, the sponsor should know this. It's relatively rare these days that someone goes on the hunt for such a platform because they find themselves simply lacking pure technological horsepower — let's face it, no one is motivated enough to go through a new general ledger system deployment solely because of the productivity of some poor staffer in accounting shuffling spreadsheets. I doubt anyone has ever taken on SAP as an impulse buy, or picked up Oracle at a conference because of show booth special pricing.

More often than not, the real motivation is a significant amount of chronic and deepening pain. That pain is usually in the form of disparate systems and processes that have fractured business data into a kaleidoscope of colorful nonsense that is crippling the business. A veritable Tower of Babel made up of isolated applications and workflows, linked only through a patchwork of human hand-off's that introduce delays and errors. It's like everyone paying in cash at a swap meet, when you walk up with a Visa card and they have to stop and dial in authorization on a cell phone. In a word, we are talking integration and streamlining of tools and processes that produce information. PEOPLE are gonna be impacted. This is usually the highest risk and least understood variable of the project.

There is little more frustrating to a project manager that has been tasked with such an initiative than to have an absentee sponsor. Securing funding and sitting in on checkpoint meetings is not good enough. The PM is battling the sheer size of the effort while coordinating the technology, configuration, vendors, team, and a billion other nuts and bolts details. To expect that individual to also take on single-handedly selling the change to the organization without enthusiastic and tangible support from the leadership team is to invite disaster.

In the first place, most aspects of organizational change are out of the span of control of a project manager. They are usually not in a position to even significantly influence adoption issues, especially when the scope spans multiple departments. Organizational and individual acceptance of changes in roles, responsibilities and new expectations must be driven through the management chain. It is the responsibility of the sponsor to garner the buy-in of their peers (and when needed, at the CXO level) to help these elements along, and it takes real leg work.

Let me quickly say shame on the PM who doesn't feature these aspects prominently in the project plan and fails to actively lobby for such support, but shame on the sponsor who doesn't belly up to the bar when duty calls.

One of our more successful customers who deployed the product across thousands of IT users in over 60 countries started out one of their training videos with the camera looking over the shoulder of someone using the system. After a moment or two, the person turns around to face the camera and it is the CIO, who then proceeds to state her expectations for use of the processes and system. They have nearly 100% compliance. Now that's what I'm talking about.

Strategic Planning, or, If It's Football Season, Then That Means...

Ah, the days grow shorter, the leaves begin to turn, and the air grows thinner in a familiar and strangely palpable way that somehow still defies description. It's about this time that corporate fancy turns to an annual rite of organizational passage, marching at the same inevitable pace as the season itself.

Yes, it's time for the big kick off to the strategic planning season.

As if for months, innovation has been lying dormant, just below the hot tarmac of the parking lot, or had migrated to some obscure section of the ventilation ducts. Bring out your projects! Bring out your projects! The cries echo from board room to cubicle. Like salmon, we respond to the ancient mystical cue — our Good Idea gland reawakens and we become anxious to put forth inventive progeny. Initiatives battle against the swift running fiscal current to find a strategic niche in which to spawn, hoping innovation may someday spring forth into the cool clear pool of budget approval.

OK, that's about all the metaphors I can fit in the blender at one time. On a more prosaic note, now would be a good time to reflect on this whole exercise, your part in how you go about it, and whether you are really satisfied with the results you are getting. Of course, it's too late to do anything about it this time around, but if you start evaluating your process now, maybe you can submit an idea to improve how you submit ideas in the future.

In particular, if you are still on an annual planning cycle, I would encourage you to seriously examine why that is. Perhaps you are a retailer, doomed to the tidal rhythms of holiday shopping, seasonal wardrobes, new fashion lines, or the release of the latest gadgetry. Sorry, you are about as stuck rotating your business around the sun as Jimmy Johnson making left turns at Talladega, so you get a hall pass (for now).

Thankfully, most organizations are not in that situation.

Still others will lament that they are driven by their fiscal year, as deemed by accounting. Alrighty then, why is accounting on a rigid fiscal year with a defined beginning and end? See where this is going?

(A very wise and grizzled instructor I once had named Bill McNally (Texas A&M grad, and don't you forget it) once told me to forego all the fancy techniques I had learned about root cause analysis, and simply ask WHY to any situation 5 times to drill down close enough to the cause to start solving the problem. Bill is also a fellow ex-submariner, starting back in the age of diesel boats. Although now mostly retired, he has godlike status among those in the discipline of rotating machinery.)

But I digress…

So…once WHY is asked enough times, you may ultimately arrive at: Because That's the Way We've Always Done It. The annual cycle made a lot of sense through the Industrial Age — product designs and schedules were still being created at a drafting table, and the general speed of business was a LOT slower. Of course, now we are in the computer animated, web-based, on-demand, real-time global business world, which is significantly more dynamic. Five year plans are now two year plans, and even the idea that you can plan anything with much certainty 12-24 months in advance gets more questionable with every passing year. Should it be any wonder that most organizations still stuck on the annual planning treadmill are exasperated by both the process itself and the usefulness of the results.

When you focus on developing initiatives and budgets only once a year, several outcomes result. The subliminal message is that this is not part of your normal job, and it often perceived as a very disruptive, special event. It also ensures that those responsible for accomplishing these functions do it just often enough to be bad at it. Perhaps most importantly, it is generally regarded by most as a bureaucratic exercise (wink, wink, nod, nod) with little relationship to what will really happen, if not viewed altogether as a total waste of time.

Truths:

1. Generation of good ideas and general demand is not limited to the last quarter of the planning period. They emerge continuously.
2. Strategies, initiatives and projects are not limited to being one year long, starting in January and ending in December (or whatever your calendar dictates). They happen continuously.
3. Business influences and dynamics that impact your plans and strategies do not rear their ugly heads only at Halloween; they come up continuously.
4. Operational activities do not begin and end on a yearly basis. They are a continuum of support activities and services that are provided continuously.

Hmmm, just maybe we should consider how we define and manage our strategies, funding, budgeting and our portfolios of programs and services on a more ____________ basis. Anyone? Anyone? Buehler?

More and more, organizations are shifting to a rolling planning routine, based on whatever their planning horizon is. For some in highly volatile scenarios, it may only be 6 months, while for others 18-24 months is more appropriate. Regardless of your horizon, adopting a continuous planning approach allows you to better align to the realities of your business and position yourself to be more nimble, while making planning a normal part of business management using regular adjustments instead of it being a jarring, once-a-year event. Bruce Lee spoke of the Zen concept, Mind like Water. I think we can agree that in today's reality of accelerated change, striving to achieve Business like Water is the ultimate operational nirvana — calmly at peace and one with our shifting environment, able to immediately flow to whatever threats or opportunities are presented. The first step on this path is to remove major friction points where the planning process runs counter to our realities.

Next Port of Call: Sponsorship is not a Spectator Sport (really mean it this time)

PMO Special Interest Group at the Project Management Institute

If you are not already aware of it, you might want to peruse the PMO Special Interest Group (SIG) within PMI. You can link to their home page at http://www.pmosig.org/. I will add this link to my blog roll as soon as find the time to pull that together. This is one of a growing list of SIGs that PMI has developed over the years to cater to specific needs within a wide general discipline.

If you are not yet a PMI member, well what can I say? Their PMBOK (project management body of knowledge) is the de facto baseline reference for general project management, and PMI has amassed a huge global following over the last 20 years. With that growth, a huge bureaucracy has also emerged, but on par, it still offers more good than bad. I've been in PMI since the 90's, and have come to think of it much as I do religions or political parties. I rarely agree 100% with all the doctrine, but if the general approach is aligned close enough to my own values, then I still want to be a part of it. I am watching with interest for what the new OMP3, PMBOK, and Program and Portfolio Management standards updates look like when they are issued in 2008.

While the PMO SIG web site itself appears to be under development and currently has pretty limited resources on it, what makes it valuable to visit is the listing of local interest groups (LIGs). There are 26 listed in North America alone, so chances are there may be one in your neighborhood. I confess that I wasn't even aware of a PMO LIG in my own backyard here in Austin, but have since reached out to them and plan to check it out. Besides, even if the parent organization may sometimes seem distant and limited in personal relevance, the local fish fry is where all the action is anyway. Given that it may also be a case of misery loving company, a LIG gives you an outlet to network with others with like interests in your area.

How I Learned to Stop Worrying and Love Benefit Management

Benefit Management is an emerging discipline that has PMO written all over it, although it is still not widely understood or employed. We developed PRISMS best practices for this process area a few years ago, but the subject didn't initially attract much attention. While it was moderately well received as a discussion topic at our annual CIO Advisory Board in 2005, by 2006 at that same event, interest had really sparked. One of the presenters touched on it as an aside, and was assaulted by so many questions that they started getting visibly restless to get back on topic. This year, at the request of one of our major customers, I did a multi-city lecture series on those best practices for their North American program and project managers.

I have to admit that at first I didn't key in on its true significance, but have since come to really appreciate Benefit Management as an essential ingredient to achieving high levels of business performance, but one that is too often missing from the process repertoire. If you can employ this function with some degree of competence, it will drive the improvement and integration of many other main-line processes such as strategic planning, portfolio analysis, scope control, and product and service management.

So, what exactly is Benefit Management, or Benefit Realization as it is sometimes referred to? It is a formal mechanism for making sure that someone is keeping a watchful eye on business value versus cost and risk as a program or initiative is proposed, analyzed, approved, developed and deployed, and the methods applied to accomplish those functions.

Initial interest in Benefit Realization was actually generated by our European staff, based on some of the work that they had seen with their customers, and Pat Durbin quickly recognized how it fit within the overall process management structure we were developing (once again illustrating why he's the master of this dojo, and I am but a mere grasshopper).

This is one of a few process areas where best practices were not derived from our own internal expertise and research. Gunes Sahillioglu had successfully developed and employed Benefit Management processes and tools while managing a PMO for Reuters. Upon his retirement from there, we leveraged his expertise to author our PRISMS Benefit Realization Guide.

Gunes, now an independent consultant and author, is a most delightful chap. Turkish by birth but a long time Londoner, he is adept at many aspects of business management, speaks several languages fluently, tells wonderful stories, and works differential equations to stay sharp the way most folks do Sudoku. I also learned in Brussels that he is a valuable travel companion, as it became apparent he can deftly navigate any menu or wine list in the EU. His wife is beautiful and utterly charming, and his daughter is Parisian. Gunes and I share a passion for Jaguars, but that is where all comparisons end, as he has much more character and wit than I shall ever muster. So with all apologies to Dos Equis, I would like to nominate him as a serious contender for The Most Interesting Man in the World.

But I digress — again…

The role of the benefit owner

The Benefit Owner is the central figure to employ Benefit Realization techniques, working in conjunction with portfolio, program and project managers, sponsors and other common roles. Uniquely, the benefit owner is responsible for maintaining a consistent and detailed long term line-of-sight focus on results relative to risk and cost. They ensure benefits are defined, cataloged and quantified as programs or initiatives are created and developed, and challenge ROI, NPV, or IRR assumptions for accuracy. The benefit owner also ensures that benefit metrics are established integral to program approval.

During execution, the benefit owner is responsible for monitoring underlying projects to ensure they stay on track to deliver program objectives at defined cost-benefit values as they face scope changes, delays and technical challenges. If at any time it becomes apparent that achievement of benefit is compromised or in serious jeopardy, the benefit owner has the authority to recommend replacing under-achieving projects or killing the overall effort.

Post-deployment, and long after the project managers are on to other assignments, the benefit owner stays on point to measure how actual program results track to initial projections, recommend adjustments and communicate lessons learned. In some cases, they may remain engaged over the life of the product or service, assisting in continued evaluation of benefit and making end-of-life assessments.

The role of the PMO in benefit realization

The PMO's role in all this is to help sponsor the program and establish processes, train participants, assist the benefit owners with information gathering and analysis, and facilitate reporting. They are also a natural liaison between benefit owners and project managers to help develop a collaborative partnership.

While there are a lot of underlying details that go into this process, I think you can begin to appreciate how Benefit Management acts as a magnetic force to couple strategic intent with actual results. It fosters methodical analysis of investment portfolios relative to business need, and goes a long way towards countering a fire-and-forget mentality that sometimes takes root after the funding decision is made. By providing active value-based management oversight of deliverables as they are designed and developed, it mitigates the potential for a program or project to go on needlessly, or inadvertently lose the essential elements that deliver true business benefit when stresses arise.

Finally, it addresses the age-old problem of who will measure the value that a new product or service actually delivers compared to those fantastical promises of 4-digit ROI on the front-end. In business management, like most skill sports, a seamless follow-through is frequently the hallmark of proper form.

Next Port of Call: Sponsorship is Not a Spectator Sport

Chicken, Egg, Process, Tool

A question often asked is how to sequence business process improvement initiatives relative to selection of a supporting application. General consensus from the customer's perspective seems to be that process design should be undertaken first, followed by selecting the tool that best aligns to the resulting processes. The logic: We don't want processes to be dictated to us by an application.

As a chicken that has been on both sides of the road, so to speak, I certainly have a deep appreciation for that viewpoint — no one wants to find their business needs compromised by software limitations. But, I have also laid a few eggs in the past by being a stubborn and myopic do-it-yourself customer, and my stance has been further tempered by implementation experience and best practice R&D the last eight years. Certainly, in a perfect world, in-house staff would develop highly tailored processes specific to your unique objectives and the maturity level of your organization. Then, you would select an application which seamlessly integrated your processes at the touch of a button and without a hint of compromise. But, to borrow from one of our customer tag lines, we don't live in perfect, and that's why you have vendors.

It's also important to recognize that in today's heavily automated business environments, it is becoming increasingly difficult to differentiate between the tool and the process when all is said and done. With all that as a starting point, let me share a vendor perspective on the question and make a case for why process development and tool configuration should be approached as an iterative, partnered effort.

Take stock of your process expertise

When embarking on any process improvement initiative, you should begin by analyzing the depth and breadth of organic process design experience that you can bring to bear on the given subject area. While I don't want to infer that organizations aren't competent in process improvement (I've learned a lot from customer processes over the years), you only know what you know, and you need to be realistic about the depth and availability of in-house expertise.

You are better off than most if you have a process architect in your company that has personal experience developing a particular process two or three times in a few different organizations. More likely, this level exceeds the collective experience of the entire process improvement team. While you can read and research and go to conferences for a more educated perspective on the situation, it will do little to bolster actual experience. The question is, is this enough? If you choose to just go with whatever limited experience you have, it may not get you what you really need, and could end up costing you plenty if this ends up simply propagating past process design issues that you need to alleviate.

Standards, alignment, and when compromise is your friend

The need for significant compromise is most common in organizations that choose to rely exclusively on internal expertise to redesign their processes. That usually indicates they have been self-reliant about a lot of things for a long time, which can have Consequences.

When we vendors design our products, we do so to accommodate the widest possible interpretations of the most popular and successful methods of doing business that our target customers employ. This means that the majority of our customers do not have to make compromises of a magnitude that jeopardizes their success or objectives. There will always be matters of preference, technical considerations and differences in how we go about it, but vendors cannot stay on top for long by repeatedly failing to support the critical requirements of the customer base.

The reason this is important for customers to recognize is that if you find yourself routinely asking products to do things that the leading vendors can't accommodate, it could be an indicator that you are trying to accomplish something that is out where the buses don't run compared to accepted best practice. This should constitute a Big Red Flag to the selection committee and process design team. You could be that rare organization that is so unique or complex compared to the rest of the modern business world that your requirements have not yet been addressed. More often it is an indicator of what I call the Galapagos Effect — a condition where the organization becomes isolated because it lacks participation in industry forums and does not consider other sources of outside ideas. The result is that processes tend to evolve into strange animals over an extended period of time.

By not using outside support when time comes for redesign, you risk continued divergence from industry standards. Even if these processes are working for you, when it comes to finding a supporting application, you may be constantly forced to either heavily customize off-the-shelf applications, build your own, or do without — all of which are expensive and frustrating propositions. Like a carnival sideshow figure, a peculiar process can have great personality and be loved by its mother, but it will still draw concerned stares from the town folk and be difficult to dress off the rack.

Independent process consultants

If you are hell bent on developing you processes independent of a tool and realize you need assistance, you will most likely go to a business consulting service to obtain more experience. Many of these are highly respected and very good at what they do — but most of them cannot maintain the needed depth and range of contemporary tool expertise on all the latest releases of leading software applications. We are in such a cycle of innovation and competition these days that tool design completely turns over about every two years, so an independent consultant's past application experience becomes quickly outdated. Besides, you haven't settled on any one product yet anyway.

Bottom line, application-agnostic processes inherently limit the level of detail you can initially develop. Configuration and workflow automation details of the selected tool will likely surface a lot of considerations that haven't been addressed, and they may force some adjustment of the original process design.

I'm not saying using a third-party consultant is a bad approach to take — just be aware that process development will most likely be a two-phase effort, and you will still have to employ the services of the application vendor to provide technology expertise. Make sure you factor that into your budget and time line.

The case for parallel development with a full service solution provider

A good solution provider will be able to supply a flexible and full featured software product, as well as provide broad industry experience and a significant amount of product-specific process development and adoption expertise. For example, here at Planview, most of our business consultants have likely been through where you are today at some corporation, in addition to personally leading numerous product deployments, including process design. They are bona fide Crouching Chicken, Hidden Process ninjas.

Finally, the most compelling consideration that isn't often recognized is the degree of process innovation inherent in today's product design and support. While customers fret over concerns that they will have to compromise too much, they may fail to appreciate that application vendors have the greatest exposure to latest approaches on process design and efficiency — specifically, what works and what doesn't. This means we can suggest new approaches and insights into how best accomplish process improvement and integration that were probably never even on the radar of the in-house team. Best of all, they are in tool-specific context, so there is less potential for friction between process and technology. This asset often far outweighs any perceived liability of tool compromises.

Recognize that processes and tools are interdependent. An iterative approach to process design, tool configuration and joint validation often results in the best balance between leveraging latest innovations and highly functional processes. It also allows you to perform these steps in parallel rather than in series, shortening the overall project.

No one knows your business and its needs better than you do, but a good vendor adds specialized competencies that few independent consultants or in-house staff can provide. By combining the two, there is greater potential for quicker, lower risk, and more cost effective results. So, the next time you are evaluating how to approach a process improvement initiative, consider looking for a full service vendor that can provide not only software and technical expertise but also be a trusted process design and integration partner. Take as much time and care looking at these capabilities as you do software functionality, and insist that they come from a single source. This will ensure alignment and avoid you being caught in the middle between the consulting group and software provider pointing fingers at each other if conflicts arise.

Hey, if this sounds self-serving, it's because I know we do this right and I've seen it done poorly a lot. Besides, if your Mom and Dad would have told you this stuff to begin with as you were growing up, you wouldn't have to hear it off the virtual street from the likes of me.

Next Port of Call: How I Learned to Stop Worrying and Love Benefit Management

Proving the Value of a PMO

This entry is derived from an email I prepared in response to an inquiry to our PMO Resource Center several weeks ago, regarding how to prove the value of a PMO. It is a common question so I thought I might pass it on for your consideration and comment.

Since I focus on employing a PMO in knowledge worker-based, technology services organizations (IT, Product development, engineering services, etc.), please consider this response in that context…

One of the more difficult challenges facing any PMO is separating out specific benefits they provide an organization relative to other enabling factors. Whether a long-establishing group or newly formed, the PMO is often a target of cost-cutting when business retrenches, as it can easily be perceived as administrative overhead with no direct relationship to improving the bottom line. It's for this reason that I strongly encourage that the PMO establish specific metrics and reporting elements that constantly put benefits and achievements in front of sponsoring executives. Additionally, self-preservation is a significant driver for the PMO to elevate its functions as an enabler of strategy — by making sure the various steering committees are well armed with valid decision support information you make yourself invaluable to those who control funding.

I know of no current study that specifically calls out cost savings attributed directly to deployment of a PMO, specific to the knowledge worker environment. There are a number of variables that must be considered on a case-by-case basis to make that assessment, including:

• Type of implementing organization
• Placement, role and type of PMO; it's span of control & influence, charter and functions
• Pre-PMO state of process maturity versus resulting increases and their benefits
• Level of sponsorship and executive commitment
• Whether initiation of the PMO is done in conjunction with supporting technology improvements (e.g., implementation of an integrated PPM or EPM tool such as Planview)

With all those factors in mind, I believe the best overall indicator of PMO contribution and value is to take a careful measure of organizational work throughput at the time of PMO initiation, and trend that information going forward. A simple count of monthly demand and delivery by various work types, an average how long each type takes to traverse its lifecycle from initiation to delivery, the unit cost by type of work, the amount of effort consumed, are all data elements that should be easily obtainable through your work management system to prove the increase in organizational efficiency.

I use the following as a general rule: if an organization that doesn't have a PMO, integrated business management tool, or defined, integrated processes, and does a reasonable job of putting those in place (with the PMO as the motive force and custodian), they can expect to see an efficiency increase of 20-30% as measured by throughput improvements within a year of operation. This can be translated into bottom line savings by calculating the total annual fully burdened FTE cost x number of staff the PMO serves.

I use the following to assumptions to provide a general order of magnitude calculation:

Benefit per 1000 users: With a total average resource cost per yr of $100k resulting in an estimated total annual salary burden of $100M, each 10% of efficiency improvement is worth $10M/yr in recurring savings

As you can see, the real dollar savings are substantial when the PMO does a good job of aligning the business, coordinating priorities, balancing demand and capacity, streamlining processes and providing enabling technology. Compare that to the estimated cost of doing so at somewhere in the neighborhood of 10-20% of the benefit gained and the business case is a no-brainer. We focus on cost of resources because in knowledge worker environments, effort is the primary raw material used to deliver products and services, and the largest single cost component. There are many great reasons for this, as well as several secondary benefits that spin out of this, but throughput improvement so overshadows other contributions that it makes it rare that calculating them is even needed to garner PMO support.

Next Port of Call: Chicken, Egg, process, Tool — which comes first, and how to cross the road without being run over