Building the IT Process Framework – Part 3 – Blending Culture Before It Curdles

Neal Leininger Project Management Consultant Veris Associates, Inc.

As the Fall season approaches, we are all reminded of the never-ending changes that life brings. The cycle of life if you will. It also reminds me of the ways we adapt to change and embrace it in our daily lives.

The last few sessions we reviewed some PMO Pitfalls and Process Framework Highlights. In this article we will be discussing key strategies to introduce IT Service Management (ITSM) into your culture, and to ensure continual commitment and momentum.

As with change in any culture, it often is met with resistance. In my opinion, there are a number of ways to re-direct and harness that energy:

• Leading by Example
• Mentoring / Consultative Actions
• Employing Top-Down Leadership

For those un-familiar with the term “curdle,”curd is a dairy product obtained by coagulating or curdling milk with an edible acidic substance, such as lemon juice or vinegar, and then draining off the “whey,” or liquid portion. It is essentially cottage cheese or paneer; an unaged, acid-set, non-melting farmer cheese. Milk that has been left to sour (raw milk alone or pasteurized milk with added lactic acid bacteria) will also naturally produce curds, and sour milk cheese is produced this way.

This brings the question:

Q: Is “Curdling your culture” a bad thing? It does, in fact, yield a useful product.

A: I think in some examples, there comes a tipping point, where a cultural decomposition is necessary; as it is said in our Declaration of Independence “But when a long train of abuses and usurpations, pursuing invariably the same Object evinces a design to reduce them under absolute Despotism, it is their right, it is their duty, to throw off such Government, and to provide new Guards for their future security.”

Call me a patriot, but there comes a time when the “long train of abuses and usurpations” of a company’s right to a good process requires throwing off the old, and establishing new guards for their future security.

I don’t think it’s a bad thing, but to obtain curd, you must practice patience and deliberate precision in its preparation. This is no going back after you’ve made the curd, so before you go down that road ensure you’ve exhausted all other alternatives.

Let’s take a step back and look at ways to prevent unplanned curdling in your culture.

Q: How do I instill change in a culture?

A: There are a number of approaches for enacting change.

First, leading by example will show people that you’re serious, and more importantly, successful at what you’re doing. By adopting a “Lead by Example” approach, those key members of your staff will see the vision and direction, and will feel more comfortable walking outside their comfort zones, which is a large part of the battle.

Secondly, by mentoring and taking active consultative actions, you’ll demonstrate you are confident in the direction you are leading, and will also begin to add value at a very tactical level. Maybe it’s helping someone put an action plan or continual improvement plan in place. Or perhaps it’s taking a leadership role in building a communications tour, or helping someone put together a presentation and being his or her sounding board. Either way, it demonstrates that you’re serious, and you don’t mind “getting your hands dirty.”

Lastly, show them the vision. The best way to do that is to have it come from a high visibility and known-quantity leadership individual or body. It is one thing for you to have a vision, and to drive it; it’s another thing entirely if they hear it from an Executive Leadership figure driving the direction of the company. Everyone wants to feel connected to their company, and by knowing that the path you’re paving is the same as Executive Leadership, it will help alleviate fears of being left in the cold.

Q: How do I ensure continual commitment?

A: Engage your experts. Seek out Subject Matter Experts (SMEs), whether consultants or full-time employees. Don’t be afraid to be mentored or to solicit the help of experts. The key is to trust that knowledge and expertise.

Understand this is part of delegating responsibility and letting go of those “pieces,” when things don’t go as “planned” according to your view; give those experts a wide berth. Even if you feel they are truly failing, or not achieving a particular bullet-point on a particular roadmap, you must demonstrate that they are truly empowered.

We learn best by our mistakes. Encouraging those experts to lead, for others to grow wings and fly on their own, will also reverberate in your organization. If others see the first misstep is a “Career Limiting Move” (CLM) for that person’s upward mobility, they will surely avoid every aspect. On the other hand, if they see those “experts” being given the support and latitude to empower experts of their own, those key individuals will seek the same. Those are the “Future Experts” that will help take your wonderful “Process Garden” and translate it into bountiful profits.

So to answer the question at hand, “How do I ensure continual commitment?” I say, show them continual commitment; not commitment that dries up during a hiring freeze, tough market conditions, or an unpopular presidential candidate. Nay, you must foster the roots of your organization and the roots of your experts, so that they can withstand the fiercest of storms and droughts. Dare I say, they may serve as an oasis for you and yours when the time of need arrives.

Q: How do I keep momentum?

A: Understand that this is not an easy task; leading change will often challenge you to re-evaluate everything you know about Business, Technology, and Life at large. Keeping momentum is so very important because without it, all your vision, your hard work, and sweet “milk” will succumb to the acid of the old guard. Whether or not you like cottage cheese, it will be the only thing on the table.

Momentum can be felt in several areas.

• Tactical change: The day-to-day changes; both from what is worked on to how work is done on those things.
• Strategic change: The horizon will change for those leaders and future experts. They will realize your organization is heading to a new place, and will exhibit renewed fervor.
• Communal change: The self-imposed status-quo will be lifted and redirected; those around your “area affect” will recognize a change in the tempo and tempest of your organization.

So the important piece to this is recognizing those three areas, and addressing them in a methodical manner. By enacting steady tactical changes -- not too fast, not too slow, and at the right time -- it will be in their faces, undeniable proof that change is happening. For them, not to them.

By enacting Strategic change, they too will recognize the change in the tone at the top. By knowing and seeing how they tie together, it will reinforce changes are necessary and important, and subsequently, they will feel a connection unlike anything they’ve felt before.

Lastly, I feel Communal change is one of the most important and influential aspects. It is palatable at the water cooler and at lunch tables. It’s that sense of belonging to something bigger, and also the sense of being accountable to your peers -- that if you don’t get behind this change, it will let your peers down.

Q: So what does culture change have to do with Curd?

A: Nothing, and everything.

Curd is a by-product of milk standing still and spoiling, the milk would be wasted, so the cycle of life takes over; it makes something useful from something useless; in this case, perhaps an IT department, in a town not too far from your own. In a business sense, when an organization stagnates, and spoils, there rises to the surface these “clumps,” which when strained and repurposed, makes a wonderful new product.

However, if it’s unintentional, it’s disastrous.

So my advice is this: When you’re blending change into your culture, don’t put your precious resources in the position to spoil. Frequent communication checkpoints with your Subject Matter Experts will keep you in tune with the process. Also, ensure proper precautions are in place to let you know when you’re reaching a resource’s “expiration date.” Lastly, if your intent is to let it curdle, make sure you have good recipes for that curd, and of course; make sure the executive branch likes cottage cheese.

To Recap:

• Curd isn’t a bad thing, but it’s an acquired taste, and requires some careful planning;
• Change keeps your culture from spoiling, tune for desired results;
• Communication keeps you in tune with the process, regardless of the desired end product;
• Continue to lead by example, and to build executive leadership’s buy-in; and,
• Commitment and Momentum will keep you on track.

Thanks for your time; I look forward to your feedback at nealleininger@verisassociates.com, or in our blog’s comment section at http://veris-pm.blogspot.com/

Copyright (c) Veris Associates, Inc. Unauthorized use is strictly prohibited. Comments contents are the opinions of the person posting the comment (commenter) and not necessarily those or endorsed by Veris Associates, Inc. Veris Associates, Inc. reserves the right to remove any and all comments it wishes without any recourse of the commenter. Decision of Veris Associates, Inc. is final.

Building the IT Process Framework – Part 2 – Translating Alphabet Soup into Satisfying Results

Neal Leininger Project Management Consultant Veris Associates, Inc.

In Part 1 of "Building the IT Process Framework," we covered some of the common PMO Pitfalls, and a few suggestions on how to improve “Everyone’s PMO.”

In this article we’ll discuss some common “Alphabet Soup” methodologies seen in Project Management Offices (PMO) today; how to best leverage their advantages, and explore some of their weaknesses. This article provides information about:

· ITIL
· SDLC
· Six Sigma
· COBIT

Vegetable Soup?

As I was planning my garden this year, I was contemplating some of the “Companion Plants” to compliment my tomatoes and peppers.

For those un-familiar with the term, Companion Plants are combinations of different vegetable, herbs, and spices. They benefit from each other’s flavors, but also provide other benefits of their natural characteristics, such as:

· Attracting Butterflies and Bees for pollination
· Repelling pests and other detrimental insects
· Enhancing the flavor and aroma of surrounding vegetation
· Providing nutritional and structural support.

I use this analogy to illustrate an approach that I’ve used numerous times with PMO implementations, as well as multiple process improvement efforts. By combining different methodologies, the overall process becomes stronger and more vibrant than any single framework could ever possibly attain.

For those unfamiliar with the alphabet soup of IT acronyms, I’ve summarized a few of the methodologies which have strategic relevance in today’s information technology industry.

ITIL – Information Technology Infrastructure Library

A framework which defines how IT delivers services to the business. It is often the basis on which the organization begins to define IT’s role to the business as a set of services delivered to customers (the end users). ITIL’s strength identifies “what” should be delivered, but it is not prescriptive about “how” it should be delivered. Often cited as a deficiency, ITIL best delivers a customized solution based on the business’ initiatives. There are no “out of the box” process improvement frameworks that effectively deliver services congruent to the business. By defining the “what,” companies can align their solution to business needs. Technology is fitted to the business, not the other way around.

SDLC – Software (or Systems) Development Life Cycle

A framework designed for managing the development and deployment of applications or systems, typically using a Waterfall, Spiral, Rapid Deployment or “Tinker Till It Works” methodology. As disparate programming languages and the methods in which they were developed matured, this methodology adapted accordingly.

Six Sigma

Six Sigma, originating from the manufacturing industry, focuses on removing defects or errors in manufacturing or business processes using the DMAIC methodology cycle - Design, Measure, Analyze, Improve and Control.

COBIT - Control Objectives for Information and related Technology

COBIT, a control framework, concentrates on definition, implementation, auditing, measurement, and improvements of controls across a specific process. As you can tell, it is very pertinent to the auditing and compliance world. In fact, auditors created it to place measureable controls on processes. A control measures the performance of a process or method against its defined objective or goal. For many, it means, “It makes sure your garbage is certified garbage, it doesn’t necessarily mean your garbage is good.”

Q: So what makes the best methodology?

Good question, however the answer requires some due diligence, research and dare I say, soul searching.

A: No super seedlings here. The methodology of choice varies with the maturity of the organization, the level of IT governance, the integration of matrix organizations, the complexity of the IT solutions deployed, and the Regulatory restrictions of the business – Just as the soil pH balance and water sources must be carefully accounted for in planning a garden, all of these aspects will help you determine the appropriate size and complexity of your “Process Garden.”

Here is what I’ve learned:

ITIL is a process oriented framework. Seriously consider it if you’re deploying SDLC or Six Sigma methodology. Both require massive amounts of data. Without a firm process framework, you will quickly outpace your staff’s availability and willingness to change. The scalable ITIL process framework allows you to tackle the age old question of “How do I eat an elephant;” and the answer is “One bite at a time.” Its scalability makes it a perfect choice for organizations that are planting their first “Process Garden.”

Q: Which comes first, the process or the controls?

A: Should I plant the garden, then put up the fence, or vice versa? As silly as these questions appear at first glance, it’s a discussion that warrants attention. Controls are typically seen as detrimental knee jerk managerial decisions. They seem to only benefit the receiving end of the control, and not the user. At first glance, that is.

By utilizing a process-based approach, we can see the critical path, and thereby determine the best place to “put up fences.” Without a comprehensive process plan framework, we have increasing difficulty illustrating the overall picture to our neighbors, not to mention the tangible benefits of putting controls in place.

Process engineering can leverage any methodology you throw at it, whether it’s SDLC, Six Sigma, or COBIT for that matter. So long as the process comes first, you will always win.

Control methodologies, like COBIT, use metrics and measurements to ensure control. Without a process methodology first, where these data points are identified as viable, and then collected and evaluated, the control points are empty. You may build the perfect fence, but to the determiment of your garden’s health and prosperity.

Q: How does a methodology differ from a framework?

A: Quite simply, a methodology systematically approaches the measurement of quality against a framework. A framework provides governance and overall accountability to a process. Without a framework, measurements typically fall out of focus and lose their context. Without a methodology, a framework is simply a picture on the wall, without the context of “how does this help me?” A framework keeps you on track, and helps explain why you are tilling the ground and researching fertilizer, instead of just throwing seeds on the grass; and hoping for the best.


Q: Which combination do you prefer?

A: As my career has evolved, I’ve found a correlation between the number of methodologies available and my propensity to utilize less of the “whole” and more of the “pieces.” I think that without a PMO, process improvement frameworks become almost useless. Without project prioritizations and clear connections between the business and IT, executive support withers faster than a garden fed by saltwater. Define your “water supply” and irrigate accordingly.

Secondly, depending on the maturity of the PMO, some methodologies must first be introduced to facilitate that preliminary PMO framework, such as SDLC or Project Management. These methodologies typically help the PMO, and IT as a whole, simply because they help everyone “DO” a lot better.

Thirdly, at a critical threshold, as the PMO’s portfolio has started to take root and the framework you have chosen has reached it’s breaking point; it is best to re-invest through an overall process improvement framework such as ITIL. It helps build the continual improvement plan across all disciplines, regardless of the methodology. It’s best to realize the weakness of the organization and the frameworks or methodologies early. Without organizational self-awareness, the propensity for day-to-day interruptions will turn a tool into a self-destructive force of its own.

Lastly, a governance model is an important piece to the puzzle. Without a fence, varmints and well wishers alike, will trample your garden.

So to recap:

· Keep it simplePick framework and methodology “companions” that compliment your organization
· Be self-awareUtilize a process based approach, so your controls don’t starve or saturate your organization
· Just start doing it, within your meansCareful planning will foster a bountiful harvest of efficiencies and profits
· Don’t forget to re-evaluate your executive “water sources” and lessons learned after the first “harvest.” What may work one season, could ruin your “soil” the next.

I look forward to hearing about how these strategies affected your organizations, please give me feedback by way of the comments section on this blog.

In the next article of this series, we will address how to blend methodologies, and more importantly, how to do it without being tarred-and-feathered. Until next time, choose your companion plants carefully!


Copyright (c) Veris Associates, Inc. Unauthorized use is strictly prohibited. Comments contents are the opinions of the person posting the comment (commenter) and not necessarily those or endorsed by Veris Associates, Inc. Veris Associates, Inc. reserves the right to remove any and all comments it wishes without any recourse of the commenter. Decision of Veris Associates, Inc. is final.

When Solving A Problem, Get To The Root Cause, Don’t Redefine The Symptom

David A. Zimmer Practice Manager Corporate Learning & Training Veris Associates, Inc.

I recently read an article appearing in CIO Magazine titled “Common Project Management Metrics Doom IT Departments to Failure” where the subtitled mentioned a report by Forrester Research stated the metrics used to measure IT project success influences the perceptions of failure. It goes on to say that we need to change to increase the perception of success instead.

We’ve all heard the adage “perception is fact” implying perception is not fact, it only has the allusion to be factual. I don’t know if it is my sense of humor, but the statement of “increase the perception of success” was strangely funny. Did it mean the project was actually a failure but we make it appear successful? Does it harken to another well-tread cliché, “In project management, we simply redefine the parameters and declare victory. That’s how we have successful projects!”

The article further details four things the PMO can do to help increase the perception of success. While I agree with them:

• keep project steering committee on task,
• improve communication with project sponsor about changes,
• improve reliability of project plans, and
• better communicate estimates of costs, schedule and resources;
  

I believe they miss the fundamental basics of the problems – the root causes.
According to the Standish Group, IT projects have only a 29% chance of succeeding. You would think with the advance in technology, the development of quality processes and increase of understanding humans; we’d have a better shot of being successful. In 2003, the Standish Group estimated we spent $382 billion on IT projects in the US alone. They further stated $82 billion was an outright waste. Using the 71% failure rate, we spent $271 billion on failed projects. Maybe that’s why we need to increase the perception of success – so we can balance the books!

Based upon my years of managing IT projects (I’ll admit, not all were successes, perceived or otherwise) and experience training more than a thousand people in the art of project management, I believe the following are the root causes for IT project failures.

1. Project managers are chosen, not trained.

In my training seminars, I ask how many people actually chose project management as a career. I have had only three people raise their hands. Usually, we are selected because we are doing well in our “real” jobs and seemed to be organized getting things done. One day, as we arrive in our office, twang, we are dubbed project managers. No training.

Then I ask how many have any sort of formal training in managing projects. Regardless of the industry, the percentage is basically the same, only 20% have had any form of training. I reduce the definition of training to the ridiculous of a one hour discussion and very few additional hands go up. Only 5% have more than a day and 1% go on to be certified through Project Management Institutes’ Project Management Professional certification.

It is not we aren’t intelligent and can’t learn the ropes, but usually we learn by observing others who have gone before us. They learned the same way – by observing others. As a result, improper methods are learned and used rather than industry accepted practices. We just gitter dun – whatever it takes, nights, weekends, extra shifts, Herculean efforts – we gitter dun.

As a result, we don’t put the proper measures in place to give the information business people need. Worse, we really don’t know where we stand in our own projects. We can’t repeat our successes because we don’t know what we did to be successful. We don’t always learn from our mistakes so we are doomed to repeating them. And finally, many projects we considered successful really weren’t causing us to repeat bad habits because we believe they are good practices.

Through training, we learn proper techniques, why certain processes should be followed and the tools we need as project managers. To contrast untrained project managers with a failure rate of 71%, studies have shown using trained and certified project managers – PMPs specifically – succeed close to 75% of the time.

Root cause #1: project managers aren’t trained to do the job we ask.

2. No formal change process in place to determine success or failure.

In the CIO magazine article, someone placed a comment contrasting construction project management with IT project management. He stated IT methods are primitive to constructions processes. I agree totally.

First, construction follows a methodical, time-proven method. They work from blueprints with every detail shown. They research the site and understand what lies hidden before digging. They understand the necessary inventory of materials and labors in advance of the start date. But most importantly, they have a change process.

Once the deal is signed, any changes to the agreement require a change order with signatures. The change order details the impacts to schedule, increase to budget, amendment to the project scope, etc. Each party must sign before the change occurs, otherwise, the original plan holds. No changes are made unless the boss says so.

In IT, we take a different tack. Again, from my survey of many attendees, only three or four people stated their company had a formal change form and process. Worse, they reported changes to the project can come from any where through any channel to any member of the project team. Since many things are considered “easy,” the impact to the rest of the project and beyond is never considered. If a change is formally documented, no one dares sign it. Accountability is forbidden.

As a result, what is defined to be the project is not really the project. As time passes, changes are requested but not tracked. The project morphs and twists into something other than the original definition. As a result, the original project may have been successful using the traditional metrics, but no one can prove it because no clear definition of the project exists.

Additionally, changes come through various portals. There might be a formal request sent from the CIO to the IT project manager. Another request comes from the sales manager tapping someone on the shoulder in the hallway. A third and most insidious is the IT staffer who “sees something needs to be done, and does it” without tracking the impact to the overall project.

Solution for such a situation is two-fold: a well defined and followed project scope and a formal method for requesting changes.

Root cause #2: No formal change process which defines a single point to funnel change requests.

3. Project Expectations Not Defined In Detail

A successful project must meet the expectations of the stakeholders. Even if it comes in on budget and on time, if it doesn’t meet their expectations, it failed. Unfortunately, we don’t document the expectations. We document the technical requirements, the inventory list of hardware and software needed, select the team of implementers, etc., but we don’t seem to jot down the expectations.

If we don’t document the expectations, how do we know when we are finished? If the expectations are met, we would have success by definition, correct?

Of course, the stakeholders don’t always reveal their expectations for us to conveniently document. In fact, their expectations change over the course of the project. Even if we met the original expectations, we still fail because we didn’t meet the current list of desires.
As a result, project managers must spend a good deal of time understanding the stakeholders’ motivations, desires, intents, and rationale for the project. Periodically, he must check in with the stakeholders to verify current understanding of their needs and make adjustments accordingly.

Root cause #3: lack of understanding expectations leading to no formal documentation listing motivations, desires, intents, etc. of stakeholders.

Conclusion

I don’t feel it is right to simply change the perception of IT project success. To me, that’s cheating and we don’t solve the real issues. We need to change how we “do” IT project management to be successful. Proper training is key number one. I, like many, managed many projects before I was formally trained. Boy did I learn about my bad habits and improper ways of managing projects. As I instruct others these days from my lessons learned, I see the same transformation in them.

IT doesn’t have to suffer the fate of poorly run, failing projects. Solving the root causes for those problems would go a long way in better return on investments, fewer dollars wasted, and happier IT people. Once these are fixed, we can begin to work on the list from the CIO article.

Veris Associates, Inc. offers a series of project management seminars to equip your project managers with the proper knowledge, processes and tools to be successful. Click here to see our topics and schedule. We help companies implement functioning PMOs through proper, industry-accepted practices and procedures.

Copyright (c) Veris Associates, Inc. Unauthorized use is strictly prohibited. Comments contents are the opinions of the person posting the comment (commenter) and not necessarily those or endorsed by Veris Associates, Inc. Veris Associates, Inc. reserves the right to remove any and all comments it wishes without any recourse of the commenter. Decision of Veris Associates, Inc. is final.

Building the IT Process Framework – Part 1 - PMO Pitfalls

Neal Leininger Project Management Consultant Veris Associates, Inc.

As a technology consultant working in and around technology for over a decade, I’ve seen my share of false starts and good intentions being driven to the end of long dark alleys to be put out of their misery. Due to confusion, redirections and busyness of daily life, valid ideas are driven into oblivion.

The concept of a successful Project Management Office (PMO) rings near and dear to my heart. However, many of today’s process frameworks have interdependencies woven so tightly I find it indistinguishable when departing from one methodology and into another. Which one or two . . . or three or more should the PMO use?

This article is the first in a series to clarify the limits, purposes and blending of four frameworks as they relate to the PMO:

• ITIL
• CobiT
• SixSigma
• SDLC

Q: So what makes the perfect PMO?

A: Boy, talk about a loaded question. Process implementations are a lot like beauty, much belies the eye of the beholder.

For those who have worked in the software industry for any amount of time, we recognize the old adage “Fail Early, Fail Fast, Fail Often.” I think that summarizes the best approach for a PMO and process improvement in general. (One hint: learn from the failure, don’t repeat it.)

Perfect is a four letter word in most production engineering departments, meaning: Perfect never ships. At the end of the day, we all are very imperfect animals, trying to build very perfect processes. The quickest distance between two points is failure. Only by failing do we learn the true weaknesses and stress points identified. It’s about keeping ourselves accountable to the process, no matter how gruesome the image is in the mirror.

Q: What About Overzealous Advocates?
A common approach for most PMO implementations is to “reign in” the factions causing chaos within IT and putting policies in place that are not conducive to the typical business environment.

A: Walk a mile in their shoes: Make it everyone’s PMO. A true PMO is guided by the principle that made all great teams work together - “what’s in it for me.” Regardless of how unpleasant those factions may be, use the friction to weld them together. Heat makes two pieces of metal one, cleanses the surface and prepares it for another wave of improvements whether it is a complete refinish or some touch-up on the glazing.

Q: What About Overloading the Process?

Even a good process fails under over-utilization. Even though it seems like a good idea at the time, ramping up too quickly slows you down. It starts to feel like you’re fighting a counter-insurgency battle as the plights and wailings of overburdened process users fire emails at you at an alarming rate. These resistance emails seek exceptions and various special accommodations because, after all, their application, project or process is “special.”

A: Start simple and stay accountable. The measure of a process isn’t how fast or big it is. The process’ efficiencies, effectiveness and compliance to the framework win in the end. The visible success of the process encourages others and moves the organization to the next level of process implementation. As the adage says, “Nothing breeds success like success.”

Q: “Kill Switch”-ophobia

One of the telling metrics for a PMO is its kill rate: the rate at which projects are rejected or “killed.” It’s often too easy for a technology department to say “YES” every time there is a request made. The measure of the alignment between the business and a technology department is evident as you examine the kill rate and the justifications behind it.

A: Start simple and kill things. This isn’t an advertisement for the NRA. By failing early, fast and often, you learn a lot by understanding the issues that caused you to stumble. Even if it means creating a PMO request that you know will be killed, go through the exercise and understand the process: engage the business and understand their true alignments. Set criteria and provide evidence for projects to survive or die. Set a metric on the kill rate.

By walking through the process with a very simple, controllable example, you build the template for those un-imaginably complex projects that need to be killed. Remember, not all projects get killed at the request stage. Prepare for killing those “woefully poor initiatives that just aren’t going according to plan.”

Understand several facts:

• Killing projects sooner than later saves tremendous money and effort.
• Any project can be killed at any stage.
• Unsuccessful or never-ending projects impact morale, other projects, budgets and your credibility – your most important asset.
• Before recommending a project cancellation, do your due-diligence, have all evidence organized, readily accessible and in front of you. While Superman could stop a speeding bullet with his teeth, only your hard, cold facts stop the one fired at you.
• A high kill-rate is good. Some companies are aiming for 66%! A low kill-rate can mean two different things: you’re letting too many projects through or your not keeping up with the changing business with improvements.

Warning: Beware of the landmines – those special pet projects of someone who has major, impacting power on your career. These types of projects must be handled with special detail. Before suggesting a pet project be cancelled, conduct a full study with extra detail and evidence as to why it should die. We should never back away from killing such a project, but our reasoning must be mine-proof, otherwise, you will blow-up instead of the project.

Conclusion
It has been said, "Buy into a business that's doing so well an idiot could run it because sooner or later, one will." I think that rings very true to the embodiment of a successful PMO. If it’s not easily understood or articulated, then the PMO “Governance” will be jeopardized and those who truly believe in the concept will struggle explaining it to their customers, and subsequently, stop speaking at all.

Recap:

• Keep it simple, make it easy enough for an idiot to understand because, well you finish the sentence.
• Kill it, in order for us to say “YES” we must be willing to say “NO”; and mean it.
• Start small and simple, which is how we learn best. After we’re comfortable with simple arithmetic, we can throw some extra zeros on the end and start talking about calculus.
• Seek friction and make the best of it. Nothing beats free heat.
• Don’t cripple the business, they need to keep the lights on too. Engage them in the policy framework so they buy-in in from the beginning.
• It won’t be perfect the first time. . .or the tenth time. It’s a living process and the better we get at failing, the faster we can close that gap with perfection.

In our next article, we cover how IT framework methodologies are blended to minimize organizational confusion and optimize operational efficiency.

Veris Associates, Inc. offers training in Project Management and IT Service Management methodologies. See our calendar of events for specific times and places.

Copyright (c) Veris Associates, Inc. Unauthorized use is strictly prohibited. Comments contents are the opinions of the person posting the comment (commenter) and not necessarily those or endorsed by Veris Associates, Inc. Veris Associates, Inc. reserves the right to remove any and all comments it wishes without any recourse of the commenter. Decision of Veris Associates, Inc. is final.

Project Management - Like Crossing the Street

David A. Zimmer Practice Manager Corporate Learning & Training Veris Associates, Inc.

Recently while giving a presentation to a potential client, I used an analogy of crossing the street. I said:

"Project management is a lot like crossing the street. You can listen to others who have gone that way before and heed their advice. Look both ways, make sure the way is clear and cross before oncoming traffic hits you. Or, you can simply jump out into the street and see what hits you and then deal with the issues that arise."

Sadly, too many people and companies people take the latter approach. From our study conducted in January and February 2006, we learned that 76% of project managers are not formally trained in project management. They are intelligent people, probably very good at what they were trained to do. But somehow, they were volunteered to manage a project and were not given the training to do the job properly. As a result, they stuggled to make the project a success.

Experience shows that even though you are confident in what you are doing, it is always good to have someone watching your back and helping in areas that are new, even though they look very similar to the past. I learned this lesson, almost to my demise, while crossing a street in England. I was ready to cross a road, had my foot off the edge, when I was quickly yanked back to the curb. I was indignant at the person who would do such a thing. I had looked and the way seemed to be clear. I had successfully crossed many streets in my life. But just as I was going to say something to the person who yanked me, a car went whizzing by me and nearly clipped me. I had looked the wrong way! It would have been a fatal mistake. Another perspective on the situation saved my life. My indignation turned into gratefulness.

Veris Associates, Inc. provides that extra perspective. We have crossed many streets successfully - not always without incident though. We have the scars to prove it! Through our "coaching" services, we help you make more informed decisions. We help you see the way more clearly.

One of our clients used our service and saved over $5 million dollars! They were embarking on a new marketing campaign. They wanted us to provide a sanity check on the project plan and roll-out. While the intent was to make sure the "project management" was sane, our understanding of the market and the broader scope helped us to show them the fallacy of their thinking. Yes, we could have helped them manage their project successfully, but our greater understanding of project management show us that the stakeholders' expectations would not have been met properly - a successful launch of the product and the wise use of $5 million. The project would have been a failure and a waste of the valuable $5 million.

Another client asked us to determine how they would make money from a particular project. The project had already been underway for two years with more to follow. The annual budget for the project to date was $90 million ($180 M total) with increased budgets to come. So it was critical to understand the profit potential for such a project. After careful analysis of the business plan, we determined that expenses on the project were 77% of the potential revenue. That 77% of the revenue represented operation expenses and did not include the overhead of the ongoing development of the project or other corporate overhead! As a result, the project would never had made any money. We recommended that the project be cancelled based upon the financial analysis.

We felt like that person who saved my life in England by yanking me back from a speeding car coming for a direction I was not looking. These are just two examples of times when people, confident in what they were doing, looking the wrong way when something was coming from the other direction. We were there to help save them from certain disaster.

So, the next time you wade out into the street, make sure someone is watching your back!