The simplest path between any two points is a straight line.  The logic of geometry cannot be argued, however, geometry does not necessarily mirror the journey required to deliver a project on time and within budget.  Why?  Because the simplest path is not always the most reliable path.  There can be one or more obstacles.  Unless you have thought through the contingencies available, you may be missing the point (no pun intended).

A contingency plan, a.k.a. plan “B”, is a necessity.  In fact, there may be circumstances which really require more than one contingency plan in order to mitigate project risks.  You may need a plan “C” or perhaps even a plan “D” in order to achieve the milestones or deliverables you’ve defined.  There are generally two options available to you:

1.  Find one or more alternate routes.
2.  Return back to a known, secure state until the obstacle is removed.

Each option may have disadvantages.  Finding one or more alternate routes in order to reach your objective could result in compromising promised completion dates, promised functionality or some combination of both.  Returning back to a known, secure state can obviously compromise your time line, but may be appropriate in order to minimize the risk to existing systems or processes. 

Making the decision between these two choices requires a candid assessment of the lesser of two evils.  The important point to remember is to never put the project or client in jeopardy based upon wishful thinking or the desire to simply move forward.  Doing “whatever it takes” to get the job done within a fixed time frame can exhaust resources while escalating uncertainty.  Leave yourself some options, which should be exercised as early as possible.  The sooner you identify the problem and take corrective action, the less likely you are to miss deliverable dates.  And when considering options, it is worth your time to apply a little math to the analysis.  Each option should be judged based upon probability of risk multiplied by the severity associated with that risk.  The options with the lowest scores will point you in the right direction.

The value of contingency planning was demonstrated during one of my first consulting jobs as a project manager almost 20 years ago.  A very large bank had acquired another very large bank and needed to merge 401(k) retirement systems.  The director in charge of the IT department invited me to his office on the first day.  He offered to provide whatever resources I needed in order to complete the mission, which would last approximately 12 months.  But that offer came with one stipulation.  I remember his exact words:

“Craig, just tell me which you need as early as possible and I will make sure that you get it.  Just don’t come to me four weeks before the completion date and tell me that you’re going to be late in delivering.” 

 That initial heart to heart talk was my motivation for taking contingency planning seriously from the very beginning.  And that mindset continued right down to the final implementation script, which was critiqued in a meeting by approximately 40 people. During that review, the IT Director pointed to me and proclaimed to his staff:  ”This was a good hire!” 

Why? 

Because I never bet the farm.  There was always the plan “B” ready and waiting.

Goldplating. Say that word out loud. It sounds really great rolling off the tongue. But wait! As rich and wonderful as it sounds, it is a dangerous trend when it starts to become the norm on your project.

As conscientious project managers, we all want our customers to be happy. So what’s wrong with making them ecstatic? What’s wrong with giving them more than they need?

Although goldplating is typically a product-related term used to indicate that the technical team is overeager or trying to find an opportunity to use new technology, features or other “bells and whistles” on your project, the tendency to over-deliver may not be confined to the technical staff.

Maybe you can rein in your developers and impress on them that goldplating is not a bargain. You can give the speech on goldplating and how it can increase operation and maintenance costs and reduce quality. But what do you do when it’s your managers and you that start to over-deliver? How can you keep perfectionists and over-achievers from going that extra mile?

The prospect of delighting, not just satisfying, your customers is appealing. But if you and your managers spend precious resources on the extras, your budget and your project are going to be out of control.

Some critical keys to project success are managing expectations, managing scope, monitoring and controlling the project execution. And, after all, it’s an accepted tenet of project management that success is delivering to the customer’s requirements, not their wish list. This is a bitter pill for us baby-boomer over-achievers to swallow. We feel guilty, as if we’re shirking a duty. But, swallow it we must. Maybe it’s enough to know that by doing so we can deliver projects on budget, on time and within quality standards.

One of the benefits of enrolling in a hotel program is being able to specify preferences. Recently, after making my hotel reservation, I reviewed the options presented to me. What I found was this:

To better accommodate you during your next stay,
please provide us with your room preferences.

What I found interesting about this list is that even hotels understand constraints. You not only get to register your room preferences, you then get to specify which is the most important, just in case not all preferences can be delivered. That is what a flexibility matrix does. First I will explain the matrix and then I will show you one.

I have found the flexibility matrix to be an extremely handy tool for setting expectations and encouraging helpful dialogue early in a process or project. Early, open and productive dialogue is a good practice for anyone managing almost any kind of effort to follow.

Here is how the matrix works. Early in the effort, ask both the customer and the internal sponsor to identify which of the main constraints is the least flexible. The idea here goes back to the old saying, “Good, fast or cheap. Pick any two.” The customer can have the end product good and fast, but it won’t be cheap. Or they can have it fast and cheap but it won’t be good. And so on. While we would like to have it all, it is not realistic. Even the most demanding managers want to deliver successfully, too. They do not want to look bad to their peers or bosses.

As managers, if it appears that all of the parameters outlined for a work effort cannot be met, we need to know where we have some flexibility. Can we take a little longer on the effort, delivering small pieces of the end product in chunks? Can we get a few more people to help speed things up if we are falling behind? Can we adjust the scope of the product we are creating so it can be done on time and within budget?  Now we not only know what is expected of us, we can also better manage changes.

Below is an example of a completed Flexibility Matrix. The object of this table is to have one ‘X’ per column. No cheating! It defeats the purpose of this to put more than one ‘X’ under the Least Flexible column.

• Scope is least flexible, and should be delivered as negotiated in the project plan.
• Resources are moderately flexible as there are situations which periodically allow resources to become available. Though it is never assured that more resources can be dedicated to the program, the Sponsor has indicated that the Program Manager should request additional resources when necessary in order to maintain progress.
• Schedule is the most flexible, as long as a good faith effort is shown to produce the end result.

Try this and let me know how it works for you.

Why do organizations constantly rely on their PMs to also perform key technical work on a project? Several reasons. One is reality. We are doing more with less now, and the reality is that we may not have the personnel available to assign different people to those roles. Another reason is that most projects are small enough that working within both roles is not a problem. Still another reason is because often the PM is assigned because they are a strong team member and one of the higher performing employees. Their reward is being given the opportunity of managing a new effort. During that effort, the organization cannot afford to have this superior performer NOT working on what they do best — the  technical work of the project.

The trouble occurs when the project is large or complex. In this case, balancing both the management aspect (PM) and performing key SME work can be overwhelming and tough to balance, often resulting in neither being done well. Few people can be actively involved in their technical focus, or SME activity, when needed and then be able to step back and see the big picture from an unbiased management perspective.

This is true both from a time as well as a viewpoint perspective. Most people allow their SME time to overtake management time until there is a crisis, at which time they go into reactionary or fire-fighting mode to deal with the issue (often later than they should) and survive. From the viewpoint perspective, it is difficult for someone who has been deeply engrossed in one aspect of the project, such as their area of technical expertise, to step back and address issues and concerns from all areas objectively. Mere mortals cannot always do this. Yes, we have all been asked to do this and some have done it fairly well, but the larger and more complex the project, the more difficult and unrealistic the expectation.

Add to this the fact that when PMs are assigned both roles, planning takes a back seat. When this happens, there often isn’t clear understanding or definition of scope, schedule, roles, expectations, constraints, etc., compounding the number and kinds of potential problems experienced later. Without an initial definition of those various aspects of the project, it is harder to get agreement on the possible fix to allow the team to move the project forward.

Projects may be completed in this structure, but at what cost? Are team members burned out? Were there more crises than necessary? What superhuman, or brute force, effort did it take to get the effort done? Was it worth it? These are valuable questions to ask, and even better if asked first when assigning roles.

This month, the articles appearing on Forward Momentum focus on a discussion regarding the use and abuse of best practices in project management. It’s fair to assume that there are a large number of opinions on this matter, as are the number of anecdotal examples that could be given. That said, here are two examples of abuse that immediately come to mind.

Abuse #1 – Best practice does not imply a “paint by numbers” methodology.

Project managers should not consider “best practices” as simply a series of rote activities applicable to every project regardless of subject, size and scope. They are not intended to promote a “paint by numbers” approach where the project manager has little substantive understanding of what is being undertaken and the associated risks. No, some better definitions can be found with a quick search on the Internet. Here are three separate, but similar explanations of the term.

First definition: “Best practices can be defined as the most efficient (least amount of effort) and effective (best results) way of accomplishing a task, based on repeatable procedures that have proven themselves over time for large numbers of people. A given best practice is only applicable to particular condition or circumstance and may have to be modified or adapted for similar circumstances. In addition, a “best” practice can evolve to become better as improvements are discovered.”

Second definition: “Methods and techniques that have consistently shown results superior than those achieved with other means, and which are used as benchmarks to strive for. There is, however, no practice that is best for everyone or in every situation, and no best practice remains best for very long as people keep on finding better ways of doing things.”

Third definition: “a practice which is most appropriate under the circumstances, esp. as considered acceptable or regulated in business; a technique or methodology that, through experience and research, has reliably led to a desired or optimum result.”

Notice that the common thread between all three definitions is the need for adaptation. In the realm of project management, one size definitely does not fit all. We occasionally, however, may encounter project managers who confuse the relatively mechanical exercises of schedule monitoring or meeting facilitation with robust project leadership. The Project Management Institute’s Project Management Body of Knowledge (PMBOK) takes almost 400 pages to describe five basic process groups and nine knowledge areas, all designed around the concept of “best practices”. A significant portion of the material discusses techniques for avoiding potential issues related to human interaction and perception. Anyone who’s taken the PMP exam knows that some of the questions can be rather ambiguous and subject to interpretation. There is simply no instruction manual for every situation, which implies that the project manager needs to have a fundamental understanding of the project at hand and may be required to drill down and become a subject matter expert in order to resolve particular issues. Project management is not an administrative role and the PMBOK is definitely not a cookbook. It is a set of best practice tools designed to help the project manager lead participants on a journey that hopefully will create something of value for the organization.

Abuse #2 – Best practice does not confuse the over-arching project leadership with task ownership.

You are the project manager, which means that you have a responsibility to lead and delegate. You are not a resource for taking on tasks that others prefer to bounce back in your direction. Following “best practices” requires clear communication of all responsibilities before the plan is executed. This is important since there may be a tendency for some personality types to define for themselves a very narrow scope of work if they perceive any ambiguity. It can lead to unintended finger pointing, confusion and in some cases, hostility.

Case in point: I was recently in an awkward meeting with a design engineer and the end-user. The engineer was responsible for figuring out the impact to the IT infrastructure in order to implement a new messaging system. It was obvious that he needed to do some more investigative work before a design could be drafted, so I asked him to contact the building engineer. He refused and then issued a rather smug proclamation that communication between team members was “the project manager’s responsibility.” It would have been better if I had aligned my expectations with the engineer before the meeting with the end-user, but I made an assumption that the engineer was capable of engaging others by picking up the phone. Apparently, I was wrong.

Make no mistake. Following best practices means that you should perform due diligence as a project manager in order to facilitate communication to stakeholders, both from within and outside of the project team. But it does not mean you are responsible for brokering interactions between team members. If someone on your project is not receptive to communicating and coordinating within the scope of their task assignments, then it may be wise to have a frank discussion in order to level-set expectations. If they still prefer to define their own boundaries, then it may be appropriate to find another resource. You will have enough to do in providing planning, leadership, tracking, decision-making and status. Don’t take on the work of others late in the game for fear of project failure. Negotiate expectations up front.

Project Managers are notorious for it. On top of business jargon we add our own unique language and terms. Writers on Star Trek call it technobabble, we can call ours PM-speak. We have our own language and acronyms, just as every organization has their favorite sayings and acronyms. Wouldn’t it be nice if we were all issued a universal translator or babble fish when we walk into an organization? But we aren’t, and we have to figure it out as we go along. We have to make an effort to be clear when we speak to others while also making sure that we understand those using lingo on us.

Why are they using that lingo? Does everyone understand the message the same way? Often, the answer is no, even when we are trying. But everyone does not always try, which makes it worse.

I am sure we can all think of a person who is notorious difficult to understand. Some people do this to demonstrate membership in a special club, like some inside joke or story. Some people do it to purposely remain vague and keep people guessing. They like the control and/or think it gives them flexibility. Some do it to show their knowledge without realizing that others aren’t impressed because they are too occupied in their minds trying to figure out what is being said. Others are vague and speak in jargon without realizing they are doing it and without realizing the impact of their strange language. Speaking in terms that not everyone understands clearly allows for different interpretations at best and confusion, frustration and rework at worst. This often leads to decreased morale and late deliverables.

How can we avoid falling into this trap? Here are some tricks I have used:

1. Cliches and acronyms: I have found that when teaching classes, I make more of an effort when I know I have an audience new to the topic or when the audience is made up of non-native English speakers. This helps me catch clichés and acronyms. I didn’t realize how often I used clichés until making this effort. At first, I would struggle to make my point without using a favored cliché. With practice, it gets better.
2. Local terminology: Make an effort to watch local or geographic terminology as well as proper names. To catch other technical or project management-specific terms, watch for glimpses of confusion or too-quick agreement from the other party. Also, think back to when you were just out of school and beginning your first professional job. How did it feel to listen to those around you discuss things that you did not fully understand? Make yourself aware of industry-specific or company-specific terms that you may be using. You have probably been using them for so long you don’t even think about it anymore. If your audience consists of people outside your organization or new to your organization, they will not be familiar with your organization’s culture, pet phrases, stories, history, and possibly organization chart. They may not know very simple things like division or document names. Something as simple as that can confuse people. When a term or name is thrown out that the other person is not familiar with, they will switch their focus from listening to you to internally trying to figure out what you meant. They will then fall further behind in comprehending the conversation, creating a spiral that may be difficult to break without some (or much) back-tracking.
3. Organize and rehearse: Carefully think through your message and how you will convey it before you speak. Mentally rehearse key or tricky discussion points ahead of time where necessary. It will make a difference.
4. Watch the body language: Most of the message received during communications is non-verbal, which includes your body language. When you are speaking to someone in person or using video conferencing, remember that body language will override your words if the two are not aligned. Don’t let the rolling of your eyes or sarcastic tone discourage the other party from speaking up if communications are not clear. Try to be empathetic and remain open-minded.

What techniques have you used to avoid misunderstandings? If we all share a tip, together we can get better.

I think you would whole-heartedly agree that Matrix Management is a well-established, well-recognized foundation of project management methodology.   Therefore, it must be in keeping with all the other basic truths of PM and just plain old good management– or is it?

If one of our goals is to KISS (Keep it Simple, Stupid!), does Matrix Management align with that goal?  It SOUNDS simple: all the people with similar skills regardless of their direct line of supervision are pooled and supervised by a person responsible to the project.  Simple.

So what gets complicated?  What about conflicting loyalties and priorities?  Those of us with both project and operations duties often hear that “Production is King” or “Operations is Priority Number One”.  But when a project deadline is looming, whose work takes precedence?  Two managers must now negotiate to answer that question.

Where are Matrix Management resources located, and how much independence and autonomy do they have?  As often encountered in truly virtual teams, not seeing someone face-to-face on a regular basis can have its complications.  Diligent oversight by both the direct supervisor and the project manager is imperative to execute and track work effectively.

So, what’s a KISS advocate to do?  First, take full advantage of the opportunity to foster the specialization that comes with matrix management and offer your staff the corresponding professional development it can provide.  Second, encourage the communication channels that are created as all the subject matter experts in one area are under your supervision.

And, Keep it Simple!

You’ve probably heard the acronym “KISS”, which stands for “keep it simple, stupid”.  I must admit, I was never a fan of any phrase that assumes the audience has diminished capacity.  And in this case, there is definitely nothing “stupid” about the benefits of keeping things simple, particularly when it applies to project management.

If you have spent any time studying project management courses or preparing for the Project Management Institute’s PMP exam, then you know that there is a good deal of complexity and abstract thought associated with generally accepted project management principles.  The number of concepts can be overwhelming.  They include a good understanding of organizational structures, project scope, time management, cost containment, quality metrics, human resource management, communication plans, risk mitigation and even procurement.  The number of tools and techniques associated with project initiation, control, monitoring and closure can number into the hundreds.  Some might even argue they number into the thousands.  Yet, as with all things, we soon learn to prioritize and select the tools and techniques which suit our project management style as well as the scope and duration of the efforts we undertake.

A case could be made that you could count on your fingers the essential components of a good project management plan.  In my world, these would include:

1. A statement of business requirements to be addressed.
2. Project charters, which include information identifying project sponsors, the project manager, a project ID and the anticipated duration of the effort.
3. A definitive statement of project goals and criteria for measuring project success.
4. Specific definitions regarding what is within scope and beyond the scope of the project.
5. Risk assessments, including an appropriate level of contingency planning.
6. A stakeholder list with subsets identifying active project participants, roles, specific responsibilities and contact information.
7. A definitive list of project deliverables.
8. The project budget.
9. The communication plan and meeting schedule.
10. Executive level status reports designed to summarize past expenditures, provide fiscal projections and identify issues requiring escalation.
11. Meeting minutes, action items and issues logs, which I consolidate into something called “project notes”.
12. Detailed project tasks, assignments and associated schedules.

Okay, I admit I don’t have 12 fingers, but I’m sure you get the idea.  Having small set of project definitions, controls and reporting mechanisms is one way to keep things relatively simple so that everyone has the opportunity to maintain the big picture during the life of the project.  Methodologies, forms and formal procedures can be beneficial until they reach a point of critical mass.  When that happens, they may actually impede progress, hinder communication and obfuscate status.  The confusion and associated slow response to the tragic oil spill in the Gulf comes to mind.  Please forgive my armchair quarterback analysis, but the situation might have been significantly better if some very basic questions had been answered before attempting to address the myriad of details.  Specifically,

• Who’s in charge?
• What are the immediate and long term objectives?
• What is the anticipated duration?
• How much money is available?
• Who is available to help?
• What is the communication plan?
• What contingencies will be executed on a specific date if “Plan A” is unsuccessful?

If you can get your head around those questions without referring to reams of documentation, then you have a much better chance for project success.

Less is sometimes more.

Many of us who manage large projects are flooded by e-mail and their associated attachments each day. These discrete items of information sit in our in-box silently demanding attention, yet often the subject lines do a poor job of drawing our attention to items which should be read first.  This is particularly true when e-mails have been forwarded multiple times.  Each contributor adds something new which may or may not be relevant to the topic at hand. This can slowly transform the original message, while leaving the subject line unchanged. To make matters worse, items arrive from a variety of sources in chronological order, which further serves to hide what is truly important. Some of us attempt to prioritize the information by simply reviewing each document, either chronologically or starting with the most recent e-mail and moving backwards. Often times, we try to commit the information to our memory.  But since it is difficult to retain more than four or five topics simultaneously, we resort to a more “stimulus driven” approach by acting on each document immediately after we’ve read it.  That action might be to:

• Make one or more phone calls to inform, clarify or initiated an action.
• Respond or forward the e-mail via e-mail for the same purpose.
• File the information in an e-mail folder.
• Disregard the e-mail and delete it.

The problem with the stimulus driven approach is that it ignores prioritization based upon our situational assessment of a large project.  Typically, these projects are comprised of sizable teams in a matrix business structure spanning large geographic areas, aka “virtual teams”. There can be much diversity of thought as well as physical distance between contributors.  With so many voices, we sometimes allow external forces to manipulate our work day.  We become subservient to the in-basket.

There is a better way.  You may want to consider summarizing each email by creating your own notes. In many cases, I find this approach much easier than trying to commit the information in memory or filing it in its original form. Here’s one method: 

Read the email or attachment in its entirety.

When you have a general understanding of what the sender is trying to convey, read it again, but this time simply scan for information that is important to you.  When you find it, use the Windows copy/paste function to drop it into your notes.

Once the information is in your notepad, you can then rearrange keywords and sentences in ways that are meaningful in the context of your assessment as the project manager. You can also juxtaposition the summary notes from one source with summaries from other topics to get a larger, more accurate picture of the situation or issue.

Admittedly, this method does require a little more upfront effort. The thought of writing summary notes may not be compatible with your work style, but for me, the work invested up front when a communication is received pays tremendous dividends downstream. Your workload will lighten dramatically, since summarizing will reduce the amount of time you will spend revisiting a topic.  You will be capturing information on your own terms.  That is a key concept. Writing summary notes will force you to critically think about each fact and assumption contained in an e-mail. It will also enable you to prioritize, and in some cases, correct the information.  By using this method, you may

• Increase your understanding of issues and events by connecting the dots.
• Help others by dramatically reducing the amount of time that would normally spend reviewing e-mail chains and interpreting meaning.

So you might want to give it a try. You may find that this method gives you more confidence, more time and less stress.  It may also help foster common understanding among virtual team members, regardless of background or geography.

Earlier, we began exploring Toyota’s current quality and performance problems and how Triage efforts could help them recover before it is too late. In this post, we continue that discussion. (Click here to read Part 1.)

Let us look at a few options they may want to consider. Firstly, let us look at their reaction to the current situation which appears to the public to be denial, delay, and no clear acceptance that there is a problem. While this perception remains, the company will flounder, sales will continue to drop off, and the reputation of being a low quality company will grow. So maybe their first action to stop the bleeding should be a public acceptance by management that there are problems, they now fully accept it, they apologize, and they are devoting extensive resources to solve current problems and prevent new ones. Then they could publicize that they are re-instituting the quality measures that made them an industry leader back in the day. They have already started to do some part of this (some may say grudgingly and without enthusiasm!) so maybe they should really punch this message home even more.

That might stop the decline in sales, but now we come to the cause of all their problems – the quality issues regarding uncontrolled acceleration. Another short/medium term measure might be to flood the car testing and evaluation companies with vehicles (already fitted with new mats and gas pedals) for them to test and report on – hopefully they will get reports from highly creditable agencies that no problems were found which will go some way to restoring credibility, or if problems are found they will be found by experts who can provide details which will assist in correction. Then for the longer term they need to thoroughly examine the quality measures they used to implement that made them an icon for quality in the past, compare those measures with today’s quality control, incorporate allowance for new technologies and manufacture, then implement measures and broadcast loudly what they are doing in the factories, to ensure only the highest possible quality products leave the factories. Communication is going to be vital to their recovery.

So as an example of how Triage might work for Toyota they could:

a) Stop the bleeding – be open and honest, communicate with the public and safety organizations that Toyota accept that there were problems and that management are fully focused on the issue

b) Improve short term sales by letting safety agencies and car reporting companies have cars to evaluate – hoping this will give a clean bill of health which can then be used in marketing, or if the worst happens, Toyota will have reports from experts identifying problems which can then be addressed

c) Longer term solutions of identifying the root causes of quality lapses and performing rigorous analysis to show how they can recover their reputation for quality.

High quality does not come cheap but is cheaper than the cost of not conforming to quality, and recovery of lost customers is always more expensive than gaining them in the first place. By performing some Triage, even if their analysis is not the same as mine, they can see how to stop the bleeding, look for a medium term solution to start building their credibility and sales, and a longer term root cause analysis of their quality problems, followed by an all out attack to resolve them.

Toyota must be aware of the feeding frenzy building up amongst lawyers of this and other countries, who see the opportunity for huge earnings via class action suits. This could well force itself up the triage list to prevent death of the patient!