Project Management Essays

Know the End Before You Start

2012-01-24T14:35:00.000-08:00

Most of us have heard the saying "Keep your eyes on the prize." That's sage advice for project managers.

When starting a project we are all anxious to get to work and produce results. However, taking time at the beginning of a project to think about the end will pay dividends over the life of the project.

Scope management. Ambiguity about the project outcome leaves a broad range of interpretation about how to get there. This can result in a great deal of unnecessary work.
Performance management. As a project manager, you want your team to gel and become synergistic. A clear focus on a common goal brings people together around a higher purpose, and both morale and productivity increase dramatically.
Risk management. Anything that could alter the direct path to the finish line is waste, and potentially a risk. With a clear understanding of what the finish line looks like, your project team and other stakeholders are more apt to identify and address waste and risks.
Innovation. Good project staff tend to be innovators. They think creatively. A clear sense of the desired outcome can focus their creativity on ways to get the job done faster, easier, cheaper, or with greater assurance of the needed quality. Lacking this focus, their creative thinking can be a liability, requiring you to corral them rather than empower them.

The challenge for most project managers is to understand the desired outcome when the project sponsor doesn't really even understand it. I remember one situation where a high-powered project sponsor introduced his project manager by saying, "this is the guy that will keep changing his aim as I keep moving the target." The stakeholders laughed and waited for the punchline that didn't come. They all sensed that this project was off to a rocky start.

An effective project manager will help the project sponsor refine his or her thinking so the outcome becomes clear. A simple rule-of-thumb is that if you can't define what "done" means, you have more work to do. Take time to gain this clarity at the start. It will lead to a much healthier project and more enduring relationship with your sponsor.

The Most Important Lesson

2012-01-08T14:31:00.000-08:00

"Expect of people only what they will give".

To expect more is foolish. They will not give it. And you put the project at risk trying to get it.

You're right to want high performance. That's not the problem. The project has been formed for the very reason that results are needed that regular business-as-usual performance won't deliver. The problem comes when the required performance goes beyond what a team member is likely to give, regardless of how you ask for it. Albert Einstein has been quoted as saying:

“The definition of insanity
is doing the same thing over and over again
and expecting different results”.

To expect a different result simply by asking for the same thing over and over again shifts the problem from the underperformer to you.

A football coach puts even the best players on the bench if they see a pattern develop which could cost them the advantage. The player may be on the bench for a single play or the rest of the game. But the coach does not sacrifice the game because of a deeply held conviction that the player is supposed to be performing better. If they did, they would lose their job.

Humans are complex beings. We all have circumstances that impact our performance. We are not always comfortable discussing them with others. We may not even be comfortable admitting them to ourselves. Regardless, it is your job as Project Manager to discern these patterns and provide relief to the underperformer while the momentum of the project is still intact.

Each situation is different. It is your job to decide what "relief" is appropriate in each circumstance. Can you simply offload a small amount of work to bring the player's performance back up? Do you need to shift the player to some other role in the project to better align with their skillset? Do they need a short dose of immersion training? Do they need more supervision, measuring their work and adjusting their focus more frequently? Do they need to be removed from the project and returned to their business unit? You must decide, and act. You are doing them no favors keeping them in the same role, allowing the consequence of their underperformance to compound and hurt their team, or even the project.

Be alert to performance patterns and provide relief to the underperformer while the project is still on track. It will be best for the project, and better for them.

Preventing Scope Inflation

2012-01-01T08:20:00.000-08:00

Scope inflation is what happens when work grows beyond the minimum required to get the job done. It results in cost and schedule overruns, quality compromises, and disengaged project staff. It follows a common pattern, and so it can be predicted. More importantly, since it can be predicted, it can be prevented. Here's how it works.

At the start of a project, conflicting biases are not evident, but they exist. The customer, who you represent as a project manager, is eager to get the changes this project promises to deliver. They know if they don't get them now, the window of opportunity may be gone. The solution-provider, often a vendor you've contracted with, is eager to get the project done, on time and within budget. They know if they miss the schedule or go over budget, their reputation will suffer in the marketplace. They also know they could lose money on the deal, which would not help their career advancement within their company. The customer has an innate scope-maximizing bias, and the vendor has a scope-minimizing bias. To complicate matters, the scope as defined in most RFPs and contracts allows for a broad range of legitimate interpretation. So you can see how conflict is wired into the project from the start.

A good vendor will point out the potential for scope inflation early in a project, when the customer wants more than is being delivered. The inexperienced project manager, will advocate whatever the customer wants without weighing what the vendor is saying, and so will challenge the vendor to do what is being asked by the customer. The vendor will generally agree to your wishes, to avoid tensions with you or your customer so early in the project, even though they could argue that their lesser interpretation of scope is reasonable.

In getting the vendor to agree with the more expansive definition of scope, you have just committed your project team and the customer to more work downstream. They will have more quality assurance to complete, more documentation to write, more change to manage, more policies to write or change, more procedures to write or change, more compliance or integrity testing, and more training to deliver to all affected customer staff. The impacts can be well beyond what the customer bargained for, and can be more than they can absorb within the budgeted resources and agreed schedule.

Many times I've been asked to recover a troubled project. I've often found a deep chasm between the customer and vendor that originated from a project manager persuading the vendor to do something they shouldn't have, simply because the customer was within their contractual rights asking for it. It's like if you got your doctor to agree you should go on a junk food diet because that's what you want now, just to have to go back to them later for a much deeper problem.

A customer bias is good, but should not cause you to blindly advocate anything they wish, if the downstream consequences will hurt them. The better answer is for you to anticipate downstream consequences and present them in simple terms to the customer. If the customer makes an informed decision to proceed as requested, you update the project plan to reflect increased effort in affected tasks, and any impacts on budget and schedule. You affirm the change with the Sponsor, and proceed according to plan.

Adopting this objective approach to project management will cause the project to move along the most efficient schedule possible. It also keeps the project resources and schedule in balance with scope.

Leadership Traits in Project Management

2011-12-07T08:26:00.000-08:00

Project management has its own brand of leadership. Here are some traits I've observed in successful project managers:

Vision - The project manager believes in the future the sponsor sees.
Evangelism - The project manager infects others with the vision.
Urgency - The clock is always ticking for the project manager, who knows results must be delivered soon, or risk the sponsorship of key supporters.
Team - There's a deep need for people to work together, affirming and challenging each other.
Synergy - The project manager strives to find the chemistry in teams, knowing how it enriches the atmosphere when found.
Offense - The project manager understands that it's much more productive to lead people to do what's right than prevent them from doing wrong.
Curiosity - The project manager is a curious breed, always wanting to know what can go better.
Apprehensive - The project manager does not like sweeping generalizations or surprises, and seeks truth in statements about such things as schedule, cost, quality, or risk.
Predictability - Within an environment full of ambiguity, the project manager needs to see results, and anticipates what's needed to achieve them.
Resilient - The project manager is situationally aware and quick to work through roadblocks.
Insightful - Whether from experience or intuition, the project manager has inspiring new ways of looking at things.
Appreciation - Projects are formed to get results that would not likely come from the business-as-usual environment. The project manager understands this, and doesn't take staff accomplishments for granted.

What have you noticed in project managers you admire? Do you share those traits? Are these qualities unique to successful project managers, or do they really exemplify effective leadership in any leveraged situation?

The Power of a TLA

2011-11-06T12:14:00.000-08:00

Two choices. Talk their language, or baffle them with yours.

Your investment in education is seldom the concern of a customer. It's how you talk that matters. Think about it. Hearing from a doctor that you have papillomavirus gets your attention. Your immediate reaction isn't "Gee, I wonder where this Doctor went to school," or "I wonder how many hours a night she had to study." You're thinking "Is pampa-whatever-it-is life-threatening? Is it communicable? How did I get it? Will my children get it? Actually, what is it? Oh... it's a wart?" The patient moved right past the question of credibility with that single foreign term. The Doctor is in the lead and the patient is instantly transformed into a follower.

Much is the same with project management. We not only have our own language, but we have reduced much of it to TLAs. So if our patients - who we refer to as stakeholders - want to hear our opinion in terms they can understand, we have the increased credibility that comes from a two-step translation. First we patiently unbundle the acronym into the full three-word phrase, and search for a look of understanding. Knowing full well that the three-word phrase will mean little more than the original TLA, we translate the phrase with obvious compassion for the person that doesn't understand it. And they become our followers.

Some project managers make up their own TLAs, but I think that's self-centered. The PMBoK has plenty of TLAs to go around. Here are a few that are proven crowd pleasers:

TLA - Three Letter Acronym
WBS - Work Breakdown Structure
PDM - Precedence Diagram Method
AoN - Activity-on-Node
EVM - Earned Value Method
CPM - Critical Path Method
EMV - Estimate Monetary value
RAM - Responsibility Assignment Matrix
RACI - Responsible Accountable Consult Inform format (whoops, that's a FLA)
CPI - Cost Performance Index
SPI - Schedule Performance Index
CCB - Change Control Board

After you unbundle the TLA, you can follow with any translation of the phrase you want. Remember, it not the translation that matters. It's the fact that you had to give it in the first place that makes you the leader and them the follower.

One last tip. You might want get a full-length mirror so you can practice the deliberate calm you'll want to exhibit for your followers. Body language is very important when baffling.

First, Clarify the Problem

2011-10-15T21:55:00.000-07:00

You can't solve a problem you don't understand. If you're struggling with a problem, you probably don't understand it well enough to solve it.

Many project managers are biased for results, to a fault. They will try hasty solutions with their customers or staff, and rationalize the process as "sending up trial balloons". I've found that people are generally good for one trial balloon; willing to discuss the reason it won't work. But after one, they begin to wonder why they're doing your work for you.

If a problem has become particularly onerous, it has probably grown to include a number of component issues. Rather than attempting to solve a tangle of problems as if it were just one, take time to untangle them, separating the problem into its smaller components. Experienced project managers understand this axiom:

As you clarify a problem you are solving it.

Once you have the ingredients of a problem, you can more easily grasp the problem and the strategy for solving it starts to emerge. Breaking a problem down makes it easier to prioritize needed actions, and to affix responsibility for needed actions.

Many times, this process of talking about the problem before you talk about the solution reveals simple mis-understandings that can be cleared up with no further action. Other times, further research or discussion is needed to frame the problem in more actionable terms. That's alright, because researching a problem equips you with much of the knowledge that will be required to solve it.

Take time to understand the problem. Doing so will lead you to a useful solution.

Win Their Hearts, Win Their Actions

2011-06-29T14:46:00.000-07:00

To cause people to change, you must have more than a good idea. You must have their desire to act on it.

In project management, we learn to discern and rationalize needed actions. We study the environment, consider alternatives, consequences, cost, political resistance, and other factors, to ensure our recommendations are sound. And we are accustomed to having our recommendations accepted, even though they may be controversial. Why then, if they've accepted our recommendation, is there so little action? The reason is simple:

We've won their minds, but not their hearts.

We're asking them to do something different in the future than they've done in the past. The past is what they know. It's what has given them their style and their confidence. It usually takes more than being right to persuade people to leave a past that's served them well, for a future loaded with uncertainty. To ensure action follows our recommendations, we must take the extra step and win their hearts.

Win their hearts, win their action.

Talk candidly with key stakeholders and influencers. Ask the simple but uncomfortable questions after you know what's needed.

"Do you like this recommendation?"
"What will keep you from implementing this recommendation?"
"What will keep others from taking recommended action?"
"How can this recommendation be better? ...more practical?"

You will certainly learn the answers to these questions over time. Better to learn the answers early, when you're shaping your recommendations, than later when your impractical recommendations fail.

Take the extra step. Empathize. It will make your insights more relevant, and bias people in favor of needed action.

Why Good Managers Fail

2011-06-14T04:07:00.000-07:00

Organizations often lose their best managers because they are given a project to manage. Once I was brought in to a project that was chewing up the organization's best managers so fast that they coined the phrase "bonepile" to describe where they threw all the failed managers.

Project management is a specialty. The skills required to manage a project draw only partially from day-to-day management experience. The mechanisms used to become effective operational managers can even get in the way when managing projects. Here are a few differences:

Timeframe - Operations managers have a continuous timeframe point-of-view, whereas project managers have a periodic or constrained timeframe point-of-view.
Communication - Operations managers tend to follow the organizational hierarchy in their communications paths, whereas the project manager crosses organizational boundaries in more of a matrix manner.
Orientation - Operations managers have a process orientation, whereas project managers have a product orientation.
Authority - Operations managers benefit from the line authority they have, whereas project managers must earn referent authority; that which is gained through credibility.
Attrition Impact - The impact of attrition is generally lower to operations managers than to project managers, since project managers are working against the clock with specialized staff resources.
Predisposition - Operations managers tend to favor environmental stability or status quo whereas project managers deliberately change status quo.

Projects seldom provide extra budget for apprentice project manager positions, so that a pool of qualified project managers could be grown for the future. Yet on-the-job training is certainly the best way to gain essential skills. So what do you do? The answer is twofold: First, gain specialized academic knowledge before you take on a project. Many local educational insitutions now provide project management courses. The Project Managent Institute (PMI) is increasingly recognized as a credible source of education too. Second, get a mentor. There's no substitute for experience. And if you don't have it, your project will struggle or even fail. Experienced project managers are available on an as-needed hourly basis to mentor you through unfamiliar situations. Referrals are available through Project Management Institute or the Institute of Management Consultants (IMCUSA). A good one will easily pay for him/herself in the costs that can be avoided with solid project management.

So, don't give up. Get experience. The rewards of successful project management are abundant, and the relationships you grow tend to be deep and lasting.

Those Darn Users!

2011-05-22T08:20:00.000-07:00

If it wasn't for those users, I could get so much done!!

Have you thought how productive you could be if the users would just get out of the way? They can be such a distraction!

Here are a few tips for getting rid of the distractions:

Greet them with a cheery "I'm glad you're here!" They'll immediately be uncomfortable.
Give them work. Tell them you need a flowchart of all their processes.
Conduct an impromptu work session with them. Ask them to draw their business model on the whiteboard.
Talk to them in a foreign language. Project management language usually suffices.
Have a tips jar on your desk, labeled "for a good cause," and ask them how much they could donate. Having a legitimate good cause seems to make it even more awkward.
Have a pact with co-workers to jump up from their chair as soon as the distraction arrives, and come to you with a great sense of anticipation. It puts the distraction on the spot to be insightful, which wasn't part of the deal.

Pretty soon you will have fewer distractions in your day. Once you've gotten rid of distractions, the only thing left is expectations. But they come from a different office, and that's a story for another time.

The Unsung Hero

2011-04-29T22:44:00.000-07:00

What would a project be without a good Scapegoat?

The real value of a scapegoat is to accept blame. It's a specialty, and I claim there's a huge market for this service.

Think about it. If you had a choice to sidestep the wrath of a fire-breathing stakeholder for a mistake you made, wouldn't you take it? Without missing a beat, and based on established role, the Scapegoat steps in and with undisguised embarrassment admits fault. You wink knowingly at the scapegoat, who is well-versed in the correct body language throughout the lashing. Head slightly lowered, only occasional eye-contact, rapidly shuffling through a few papers as if to wonder where it all went wrong. After the fire-breather is out of fuel, the Scapegoat appears to discover the cause of the problem. That puts people at ease, knowing that at least they have somebody that can trace the problem to its root cause and therefore fix it. Lucky for them! The stakeholders couldn't have figured it out. They are too removed from the situation. They all breathe a sigh of relief. And you go back to whatever you were doing before the meeting, and make whatever adjustments you think appropriate, inspired and energized.

The role of Scapegoat has been in place for decades, just known by different names: Total Quality Manager or TQM, Business Process Reengineer or BPR, Subject Matter Expert or SME, Database Modeler, MS Project czar, or the more inclusive title of Contractor. They all mean the same thing at the end of the day: Scapegoat. It's just that in the past they've had to do actual work enroute to getting blamed. But that doesn't make sense because they're all tired out when blame hits, and don't respond well to it. Better to have them avoid any work so they're fresh and ready when blame hits.

On the advice of an interested client, I think I will start a new venture and call it "Scapegoat Consulting Group" which of course will be known simply as SCG, just as with IBM, 3M, and UPS. The tag line will be:

We don't do any work.
We just take the blame.

So, distinguish yourself! Hire your own Scapegoat early. Have them around when most of the problems originate. They will be much more credible when fault has to be assigned. And your peers will be green with envy.

If you need somebody to blame, give us a call. Our doors are open for business. Just don't expect us to do any work.

Inoculation for the Meetings Plague

2011-02-25T14:23:00.000-08:00

Meetings are like a plague. Once they get hold, they're really difficult to eradicate. The maxim "An ounce of prevention is worth a pound of cure" applies to the meetings plague. Here's a simple 4-step approach to inoculate yourself from contracting the plague.

Start with the assumption that no meetings are needed, and delete them all.
If somebody persuades you that one really is needed, give in. But assume that nobody need attend so don't invite anybody. At this step you can just stay in your office and get other work done, because nobody else will be there.
If somebody persuades you that somebody really needs to attend, give in. But invite only one person. At this step, schedule the meeting for only 5 minutes. That forces them to make the point and be done with it. You should also have the meeting in their office, because it's much less awkward to get up and leave their office ofter 5 minutes than kick them out of your office that quickly.
If somebody persuades you that the meeting really needs to be recurring, give in. But stick with the 5-minute rule. Allow a different location only if it's a hallway, and only if they agree to bring treats.

In all cases, require an agenda be created, but don't let them send it out. Agendas are a nuisance and double the meeting time just to read it.

That's it. You're welcome.

Project Management 101 (Speech)

2011-02-05T15:55:00.000-08:00

Most of us need to learn by our own mistakes, rather than heed the wisdom of others. Here then is the prescription for learning, so you can make the 12 most common mistakes faster and get to the wisdom sooner.

Project Management 101 provides a light-hearted look at ourselves as project managers and helps us sort it all out.

Barry Otterholt, CMC, PMP has been meddling in project management for 25 years. His experience spans the public, private, and not-for-profit sectors. He teaches project management at Northwest University and does a bit of therapeutic writing on the subject which can be viewed at www.stoufferco.blogspot.com.

If you would like Mr. Otterholt to speak at your event or host a panel discussion, please contact him at SpeakingInquiry@StoufferCo.com.

The Unsung Hero (Speech)

2011-02-05T15:49:00.000-08:00

What would a project be without a good Scapegoat? The real value of a scapegoat is to accept blame. It's a specialty, and I claim there's a huge market for this service.

The role of Scapegoat has been in place for decades, just known by different names: Total Quality Manager or TQM, Business Process Reengineer or BPR, Subject Matter Expert or SME, Database Modeler, MS Project czar, or the more inclusive title of Contractor. They all mean the same thing at the end of the day: Scapegoat. It's just that in the past they've had to do actual work enroute to getting blamed. But that doesn't make sense because they're all tired out when blame hits, and don't respond well to it. Better to have them avoid any work so they're fresh and ready when blame hits.

The Unsung Hero provides a light-hearted look at ourselves as project managers and helps us sort it all out.

If you would like Mr. Otterholt to speak at your event or host a panel discussion, please contact him at SpeakingInquiry@StoufferCo.com.

The Project Mindset (Speech)

2011-02-05T15:45:00.000-08:00

We've always known we were different, but not really sure how. Our sponsors call on us when there's a challenge, but not necessarily because we know their business. Our functional peers look at us and ask why we like this work with all the stress surrounding it, and our answer seldom sways them. Our family asks us to explain our work, and our answer doesn't remove the glazed look in their eyes. And when we look in the mirror, we're not really sure ourselves what makes us gravitate to projects. It's just a mindset, and we can't shake it.

The Project Mindset provides a light-hearted look at ourselves as project managers and helps us sort it all out.

Barry Otterholt, CMC, PMP has been meddling in project management for 25 years. His experience spans the public, private, and not-for-profit sectors. He teaches project management at Northwest University and does a bit of therapeutic writing on the subject which can be viewed at www.stoufferco.blogspot.com.

If you would like Mr. Otterholt to speak at your event or host a panel discussion, please contact him at SpeakingInquiry@StoufferCo.com.

Through the Eyes of Your Sponsor (Speech)

2011-02-02T22:02:00.000-08:00

You have one minute and one page. More than that has to be earned.

Sure, your meeting is scheduled for more time and you've been given no "one-page" rule, but what you do with the first minute and on the first page will determine whether you have the sponsor's interest beyond that or not.

Through the Eyes of Your Sponsor provides an insider's look into the job above you, and reveals 10 things you can do to get the most out of your Sponsor.

If you would like Mr. Otterholt to speak at your event or host a panel discussion, please contact him at SpeakingInquiry@StoufferCo.com.

My miserable life

2011-01-28T16:18:00.000-08:00

Yes, I'm a project manager. I don't know how it happened. It's like I woke up one morning and discovered I had far more responsibility than I had bargained for and much less authority than I needed, and no place to hide.

My staff are nervous because we've never done this before. I guess that's the nature of projects though, isn't it?

My boss is nervous because she just wants it done and I keep asking her questions she doesn't know how to answer. I guess that's the nature of projects too, isn't it?

And I learned a new word. Stakeholders. These are people that are "positively or negatively impacted by the project or its result." Really! Is there anybody that doesn't fit into this category of people that can expect things from me?

I'm starting to remember now. Somebody higher up the food chain had an idea and needed somebody to work on it. Not knowing better (and when everybody else apparently knew better), I stepped up. I'm pretty good with people and we tend to get things done. Boy what I would pay for a rewind switch right now!

I really had no idea what the predator envisioned. Am I supposed to call her a sponsor? That's like calling a butcher a cow advocate. Anyways, I was just flattered that she had enough confidence to bet on me at the time.

As the months have passed, we keep getting closer and closer to a target that keeps moving and moving. It's becoming really hard to see how all these changes are part of the original vision, but she keeps telling me to stay flexible. And so I do. When I point out how much this is all costing, she acts like I'm slapping her with news of an impending plague and artfully dodges the issue. I'm noticing recently that there are more higher-ups perched on her branch when I'm giving my status reports. They don't act nearly as ok with everything as she does. They're becoming as impatient as I've become, except they're becoming impatient with me!!

So here I am. Losing sleep over something I thought I could do because somebody else thought I could do it, not sure where I'm headed because nobody else can tell me, and getting attention I don't want because everybody else sees it.

Is this what project management is all about? Is this the way it works? It's sure a good thing I wake up and realize it's just a recurring nightmare! Can you imagine if this was real? Hmmm....

The insanity of it all!

2011-01-28T16:00:00.000-08:00

You're a project manager, right? You rationalize what you do as normal, right? No offense to the mentally challenged (I hold that we are all mentally challenged, in some way), but consider the definition of crazy and then go look at yourself in the mirror:

Full of cracks or flaws - When is the last time you had a project that wasn't full of cracks or flaws? Isn't that were it starts? Aren't cracks in the plan the root cause of most project failures? Or are your projects the exception? Come on now. Nobody's looking over your shoulder here.
Mad, insane - How many times have you preached something over and over again, even become upset about it, just to get the same results? Einstein is quoted as saying the definition of insanity is doing the same thing over and over again and expecting different results. I'm sure he wasn't referring to you.
Infatuated - Oh, the possibilities!! Each project is so alluring at the start, when you don't see all the monsters hiding behind the bushes. And as reality emerges, you remain steadfast in the belief that this project - your project - will turn heads. It will be your signature achievement. To keep you honest, answer this question truthfully: Which to you spend more time with, your project or your spouse and/or life-partner? Nah, you're not infatuated with your project.
Erratic - We prefer to call them course corrections, right? Do you make course corrections all the time? I'm sure you don't really have to, even if you do.
Obsessed, passionately preoccupied - So, which are you... ambivalent and unsuccessful? or obsessed and passionately preoccupied and successful? I know, this one hurts!
Unusual, being out of the ordinary - Isn't this the very definition of a project?

Crazy? How 'bout them Seahawks! ...what were we talking about?

Objective or Goals?

2011-01-10T00:25:00.000-08:00

The terms objectives and goals seem to be interchangeable in many management discussions. The two terms are very different, and both are essential and fully compatible in results-oriented project management.

Objectives drive the long term outcomes of the project. They reflect the overarching vision and expectations of the project sponsor and key stakeholders. Work streams are formed around objectives, as reflected in the horizontal bars in typical Gantt charts. Interim deliverables provide a way to control the project, but seldom yield value to the customer, who must wait to gain value until all work has been completed and the very last deliverable has been accepted.

A project objective may be something like "Make our line of business more profitable by cutting costs by 20% and increase revenues by 45% within two years."

Goals drive the short term outcomes of the project. They reflect the installments of value en route to reaching the overarching vision and stakeholder expectations. These installments of value - often referred to as showcase results - stand on their own. They are real results, delivering real benefits to real people. They would stand even if the project was subsequently canceled.

A goal may be something like: "Cut costs by 5% and increase profits by 15% within six months in the Southwest region." Upon reaching that goal, the lessons learned could be applied and the rollout of the benefits to the broader national store base would be smoother.

If the Gantt chart had a mechanism for showing goals, you would see them a vertical bar with a very short duration, overlapping the horizontal bars.

Objectives and goals should all be measurable. Neither should be ambiguous. Having goals allows you to think in terms of something more within your reach. You don't get overwhelmed as with the higher level objectives. You can say "Let's all rally around [you put in your goal here] and I bet we could get it done."

Objectives are the compass heading for the overarching vision. Goals entice the day-day performance. Both are important. Goals make more sense.

Credit to Harvard University for good discussing of this in the Harvard Business Review on Managing Projects.

Do You Speak "Project"? (v3)

2010-09-12T13:36:00.000-07:00

Project management is a specialty, and it has its own language. Resistance is futile.

Body of Knowledge - Each project should have one of these. Large bodies tend to be more credible because knowledge isn't thin.
Risks - What hasn't happened yet; pretty much everything in the future
Processes - a nifty alternative to delivering results
Finish-Start - the relationship between solution-provider and customer. When the solution-provider thinks they're done, the customer impressed on them how not done they are.
Planned Value (PV) - the thing dreams are made of
Earned Value (EV) - when reality gets in the way of dreams
Actual Cost (AC) - the truth that only comes out when the piggy bank is empty
Milestone - unlike kidney stones, these don't hurt when you pass them
Known unknown - proof that standards-makers sometimes run out of things to define
Free float - much better than expensive float
Crashing - an odd choice of terms for deliberately speeding up the pace
Change Request - found in projects that have dressing rooms. These are a sign of a well-endowed project
Customer - the people that preserve the custom of customizing, and insist they will accept the risk of doing so until they encounter the risk of doing so
Resource Breakdown Structure - a medical term pertaining to losing ones judgment in a structured manner. The structure part makes it more rational to turn irrational.

If any of this makes sense to you, you're in way too deep. Take a break. Those around you will understand.

Is PMBOK Overkill?

2010-09-10T16:19:00.000-07:00

The simple answer is yes, most of the time. But that's only because it's not applied right.

This question most often reflects lack of understanding about the PMBOK. PMBOK means a guide to the Project Management Body of Knowledge. The actual body of knowledge exists in all of us pratitioners. The PMBOK distills some of the more widely acknowledged best practices into a single reference point.

The PMBOK is not a methodology and doesn't claim to be a "how to" management script. In the early pages, the authors state that the PMBOK "...does not mean the knowledge described should always be applied uniformly to all projects." It's a framework, full of tools and techniques that can be applied with more or less rigor to situations that arise throughout a project. They use the term "tailoring" to encourage you to fit the bounty of PMBOK tools and techniques to your particular circumstances.

So how can PMBOK possibly be overkill? Obviously it can't, unless you don't tailor it to your needs.

Here are some of the benefits I've found in using the PMBOK:

It provides a common language so project managers from different projects or geographies can have productive conversations, and so newly formed teams can quickly become productive
It provides both art (being resilient to human situations) and science (following set protocols) to your project.
It provides a number of best practices that can be applied to common and uncommon situations
It provides techniques to frame a problem, to make it solvable.
It imposes a preventive bias, to avoid problems rather than react to them in a fire-fighting mode

The more I get to know PMBOK the more I benefit from it. What I initially thought was just a dry reference book suitable only to the most abstract projects, I now realize is chocked full of useful material that pertains even to the smallest project ...if you take the time to understand it and tailor it to your unique needs.

If you struggle getting your mind around the PMBOK, I'd suggest one of the many companion books that puts the PMBOK in more human and situational terms. Rita Mulcahy's materials are among my favorites. Heldman and Verzuh are among my favorite authors on the subject.

Give PMBOK a chance. Don't expect it to be your brains. View it as a project management tool belt. Pull out the right tool for the right situation.

Authority Without Authority

2010-08-25T19:59:00.000-07:00

Authority can be a fragile thing. You pay a dear price to obtain it, it can break if handled wrong, and it wears out quickly if used too often. Why not use it sparingly and make it last longer? In fact, why not leave it untouched entirely and in it's original condition forever? It might even increase in value over time.

Authority is typically invoked when you cannot persuade people to follow based purely on the merits of your opinion. This means that authority is often an indicator of dissent. And with dissent you are getting concession, not agreement.

Each person brings a certain number of concessions to a relationship. They're not aware of it of course, and the number of concessions vary from person to person, according to their tolerance for things they don't like. Each time you exert your authority over them, you use up some of your concession credits. If you exert your authority too often, your concession balance will be used up and your relationship will no longer be worth having.

If you ignore the symptoms of dissent, tensions will mount and relationships will start forming around differing opinions rather than shared purpose. This is when people start questioning their relationship with you and their wisdom of following your lead, regardless of your authority.

"All authority belongs to the people" - Thomas Jefferson

As an engaged project manager, you understand that your success lies in your ability to build a shared sense of purpose around the objectives of the project. You invest political and emotional capital in the people that are instrumental in reaching those objectives. You do whatever is possible to channel efforts, tear down barriers, and promote good ideas. This builds open relationships, where you can engage in candid conversations with your staff about expectations, strategies, and barriers to success.

There is a sense of family around the effective project manager, with plenty of critical comment and frustration, but also with obvious mutual trust and respect, and a desire to deliver. The staff have given the project manager implicit authority to lead them.

The best authority is that which your followers grant. With this authority, you can keep your original authority tucked neatly away, seldom having to use it, and watch it's value increase over time.

The Wisdom of the WBS

2010-04-07T09:15:00.000-07:00

The Work Breakdown Structure is a tool most of us have heard of but few of us use. That should change.

At the start of a project, when the WBS should be created, we are all anxious to deliver some showcase results to reassure our sponsors and stakeholders they picked the right people for the job. Time is of the essence and we're biased for delivery. There's a sense that too much planning is just stating what we already know, adding bureaucracy, and delaying delivery.

Too often however, when we gain the burden of hindsight, we recognize that stronger leadership in the early stages would have prevented many of the problems that are consuming us now. One of the least imposing and most revealing planning tools we have available in the early stages of a project is the WBS.

The WBS lines up the deliverables, and breaks down the work into manageable packages. It's conceptually simple, and can be facilitated with very little training.

Amongst several benefits, these are a few that stand out in my experience:

It aligns our understanding of expectations with those who are doing the expecting
It causes us to think about what's needed before we tackle it
It's preventive, preferring to avoiding risks rather than react to them when they happen
It biases the project for results, by tying all work to deliverables
It fosters healthy working relationships between customers and solution-providers

If we have a hard time creating the WBS, it's very likely because we don't know what people expect of us, or how we're going to get it done. Why then, would we willingly proceed on a path of certain trouble? A respected colleague once put it this way:

Planning will happen

...whether at the onset of the project, or in response to troubles throughout the project

Take time to plan. Use the WBS. It will save time and a whole lot of grief.

The Most Important Thing in a Troubled Project

2010-04-06T10:42:00.000-07:00

If you had the right answers the project wouldn't be in trouble, right? Maybe. But that's not the heart of the problem. The real problem is not having the right questions.

"A prudent question is one-half of wisdom." -Francis Bacon

One of the hallmarks of an effective project manager is curiosity. An effective project manager has an insatiable appetite for truth, and is always in search of it. If they only wanted answers, they would be pacified with sweeping generalizations, such as:

I feel confident we are on schedule
I'm 80% done
Sure we're a little behind schedule, but doing it right will save us time in the next phase
My project management tool shows we're in good shape

A high-performance team generally welcomes critical thinking about what they're doing and how it impacts the overarching project objectives. However, they are in the thick of things. They can easily lose objectivity or lose sight of the bigger picture. The project manager is in a unique position to challenge them on the quality and priority of their work. To be sure, the project manager must earn the right to engage staff at this level of candor.

I often think of Bruce Tuckman's model of team development, where teams go through evolutionary phases of forming, storming, norming and performing. Some teams never make it out of the earlier stages, which are marked with differences of opinion and defensiveness. However the effective project manager evangelizes the higher vision of the project and passionately moves the team to the performing stage. They become highly synergistic, with a shared sense of purpose. In this phase, they trust their project manager, are fulfilled by their accomplishments, and acknowledge their accomplishments are in part due to the critical thinking of those around them.

Asking the right questions will reveal issues before they become problems. And they will reveal opportunities for improvement that may have been missed otherwise.

A trusted colleague once advised me to ask the question "Why?" three times for anything that matters. She suggested that only after the third "Why?" would truth be revealed. I don't know if this can be classified as a universal truth, but in general I've found she was right and have enjoyed the results this simple tip has brought.

So, if you're not getting the right answers, ask the right questions. Probe. Seek truth.

Why Projects Are Late

2010-02-17T04:05:00.000-08:00

There are as many reasons for projects being late as there are dimensions to the human personality, since the reasons ultimately stem from human perception and the decisions that come from it. That said, I’ve found that there is indeed a single thematic cause for schedule slippage in most projects:

a focus on what’s been done,
rather than on what’s left to do.

A common sentiment I hear among project managers is: “We have good people. They’ll get the job done.” This is an early sign that the project manager does not understand his or her own role in the group. The project manager must be the trail-blazer; always looking where they’re going, ensuring the path is clear, judiciously eliminating or circumventing obstructions, ensuring adequate support provisions, and making sure the capabilities of each person are factored in to decisions about how to proceed around the next turn. It is the project manager’s responsibility to lead the way and inform the team about what’s in front of them. But instead, most project managers focus on what’s behind them; how far the team has come, how hard people have worked, and how well they’re working together. This is akin to driving a car with only a rear-view mirror to look through. It will surely cost the team unfortunate consequences.

The best managers I’ve met have an almost insatiable appetite for knowing what’s left and keeping everybody’s focus on it. They balance what needs to be done with what can get done, and make sure stakeholder expectations are aligned. They also tend to measure things, so the surprises are few and of lesser impact. Their status reports generally include updated projections about best-case and worst-case completion dates, and engage sponsors in discussions about what can be done to get the best-case.

One project manager summed it up nicely:

“Keep your eyes on the prize.”

Win The Opinion Leader

2010-02-15T02:05:00.000-08:00

Opinion Leaders are the ones that influence co-workers. They rally people, or divide them. They're found among the staff, not along lines of management. Their skeptical view of management is what makes staff listen to them. If you can win them over, staff will follow. Indeed, they may become your most steadfast supporters, and explain things to staff in ways that you or your leads cannot.

The lesser experienced project manager can easily alienate the opinion leaders. And it's understandable why. Often times, project managers are picked because they've proven themselves good business managers. Business managers have a longer relationship with staff and generally get the action they ask for with little debate. Project managers, on the other hand, are working with staff for the first time in many cases, and don't have the track record from which to expect unquestioned action. Further, project managers ask for actions that often break from traditional forms of communication, cross boundaries of authority, require frequent adjustments in priority, and generally can feel unfocused and misguided to staff.

At first it is a relief when you find most staff are willing to go with the flow, with little need for justification. Later however, you realize the resistant staff were the critical thinkers you really needed to ensure that the project's solutions are solid and will stand the test of time.

Early in the project you should discern which few of the project staff are likely to be resistant, and if brought on board, would bring others along. Take extra one-on-one time with these people. Keep an open mind in the discussions. If you are open to their criticisms, they will relax and gain a more balanced view of the project and your efforts. They will try to understand. Also, if you can strike a healthy discussion, they very likely will offer insights that will help you connect more effectively with project staff, and even improve the technical solution. To be clear, you are not seeking compliance from these individuals, you're seeking understanding and alignment. Their critical nature is often the very asset that keeps the project from making costly mistakes. Allow them to be critical, but provide a channel of two-way open communications to share thoughts and creative thinking. If these individuals are not directly reporting to you, create the same culture of exchange with your directs. In doing so, you are grooming them to be more effective project managers too.

Occasionally, skeptics enjoy the attention they get from their contrarian behavior more than the self-improvement and opportunity they get from higher level collaboration. These individuals are probably better served in a job outside of the project.

So it pays to take extra time with resistant staff, particularly early in a project as sentiments are being shaped, and explain the background and logic for your approach, in hopes that they will understand it, even improve on it, and in doing so influence others to follow.

What Matters Most

2010-02-03T15:50:00.000-08:00

After three or four projects, you learn that there are a few things that must go right for most any project to succeed. These are generally referred to as the Critical Success Factors, or CSFs. Here are a few:

Ensure strong sponsorship – Someone with money and authority to spend it must want the project. This sponsor must evangelize the value of the project throughout its life. He or she must also be willing to work through trouble spots and make tough choices when an issue goes beyond the project manager’s ability to control it.
Ensure proper funding - Funding should be sufficient. Seem obvious? Most project managers take whatever is provided and assume it will work, just to find themselves in hot water when the inevitable truth arrives.
Pick the right team - Typically this is the area where we see the most conspicuous signs of a troubled project. Too often staff are assigned to projects simply because they are available, rather than being the best person for the job. This usually results in disruptive changes to personnel in the middle of the project. Required skills must come to the project sooner or later to get the job done. Sooner is better.
Do planning - Planning should be on ongoing evaluation and adjustment process, not mere preparation of a deliverable. Adjustments in staff, schedule, and expectations should occur routinely as project circumstances change. This way Sponsors can have a clear understanding of when the project will be done and what it will cost.
Know the end before you begin – Much waste occurs in projects because people are not sufficiently focused on the outcome. You should define “Done” before you start, so everybody understands what the job is and all work can be directed at getting it done. The military refers to this as "exit criteria"; when these things have been done, we go away.
Prepare for change – Projects seek a level of change that can’t be attained via normal processes. The organization must be prepared for the change before it hits, so life can continue only slightly shaken.

Attending to these CSFs will have the project on a good footing from the start.

Is Loyalty a Virtue?

2010-01-11T23:12:00.000-08:00

The simple answer is yes. Loyalty allows staff to presume support from the project manager, even through trying times. And trying times are typical of projects, where people are routinely expected to push themselves beyond their comfort zone. Loyalty allows the project manager to presume stability and resourcefulness from staff, even through these same trying times when a project stretches the skills and emotions of the staff.

In one extreme, lack of loyalty causes staff to be very cautious for fear of being made a scapegoat. With this culture, staff don't take needed initiative to solve problems. And they don't raise legitimate issues, opting to wait for them to become problems that can be tied to somebody else.

In the other extreme, unquestioned loyalty causes staff to take inappropriate risks that cause a backlash later in the project when the cost of cure is high. In this environment staff can be heard rationalizing their actions by stating that the project manager, to whom they have such loyalty, requires it. Even when true, this degree of blind loyalty brands the individual as a "Yes Man", and discredits him or her in the workplace.

I remember a story set in the Boardroom of Toyota, where the Board Members were gathered together to discuss an idea presented by the Chairman. As the story goes, the Chairman presented his idea and asked for opposing views. Hearing none, the Chairman adjourned the meeting without a vote. Surprised, one Board Member asked why there would be no vote, to which the Chairman replied "No one has a perfect idea, and this is too important to wait for the market to tell me what was wrong with it". Toyota has proven to be a good company, and regardless of the accuracy of the story, the moral is clear:

Loyalty is a virtue until it quells needed debate.

Loyalty occurs over time, by surviving critical tests together. It is not gained merely from authority. The ability to talk candidly and share different points of view are key ingredients of loyalty.

Certified vs Competent

2009-12-30T14:30:00.000-08:00

Can you gain a professional certification and still be incompetent? Certainly.

Certification does not equal competence.

The professional certification simply acknowledges that you have a threshold of experience that has been verified, and that you've learned the PMI processes and knowledge areas sufficiently to pass a test. There's nothing preventing you from straying from your experience and accepting jobs for which you are unqualified.

The PMP designation evidences a differentiating commitment to the profession, and in my experience PMPs take a higher level of responsibility for their projects than their non-certified counterparts. However, there is nothing in the PMP credential that says you know how to manage a cross-cultural project, a LEAN manufacturing project, a strategic planning project, a revenue maximization project or a cost minimization project. Nothing that says you know how to manage geographically diverse projects, cross-organizational projects, or sector-specific projects. Nothing to say you won't apply too much formality in a simple project or too little formality in a complex project.

Project management also as its own language, with lots of terms not generally heard in the business-as-usual setting. PMPs might know this language from experience, or it might be learned for the first time when studying for the certification exam. In either case, this language can easily lull a prospective sponsor into believing you have much broader experience than you actually have, and offer you an opportunity that you should not accept.

The question of competence is only answered in terms of the specific needs of each unique project. If you simply asked for an accountant, you could get a cost accountant, governmental accountant, tax accountant, or any of many other areas of experience. The same is true of the PMP. Each PMP has certain experience that distinguished him or her from the pack, and is sufficient to have earned the professional credential. But any of us can demonstrate our incompetence if matched to the wrong project.

Qualify the opportunity before accepting it. Make sure you understand the unique requirements, and verify that you can provide the unique skills when needed.

Leadership 101

2009-12-30T12:43:00.000-08:00

The first thing you learn is to surround yourself with smart people. But why would smart people want to surround you?

Not sure? Just go with these sure-fire answers until you figure out your own.

We have a great opportunity to make a difference.
You have experience I just can't get elsewhere; I really need you.
The boss has given me the authority to run this project, and I'm not afraid to use it to get what we need.
This project will require innovation.
I'll give you latitude to do it the way you think best.
I won't let the good stuff be contracted out; we'll keep that work for ourselves.
I have an advanced degree.
I'm in the middle of writing a book.
I'm an entrepreneur.
Did I mention I have an advanced degree?

They key is to say these things with such conviction that people don't question your assertions. It helps to walk with a swagger too.

When the smart people get tired of following you, you can always look for wise people. The only difference is they will require substance behind your assertions before getting in line.

Project Management 101

2009-11-20T14:41:00.001-08:00

Most of us need to learn by our own mistakes, rather than heed the wisdom of others. Here then is the prescription for learning, so you can make the mistakes faster and get to the wisdom sooner.

Start work. What needs to be done will be discovered if we just get going.
Find the right people. Find people that can get excited about something and get along with others. They'll gain the experience when they need it.
Make sure you have a plan. People want to see that you have a plan. Find someone that knows how to make one and always have it on your shelf.
Make sure you have budget. Let the decision makers feel the pain if they don't give you the funding you need.
Do good status reporting. Make sure your status reports have nice charts, and make sure you email them out on time.
Maintain good morale. Do things as a team that make people like each other. Have after-work BBQs, weekend parties in the park, tell jokes. It's good to remember the names of your staff too. That makes them feel good.
Make sure you have a contractor. Otherwise you'll have nobody to pin the blame on.
Measure performance. Require people to answer how they're doing in terms of percent done.
Have an open-door policy. Always keep your door open when you're not with somebody.
Make sure you have a Plan B. In case something goes wrong, you need a fallback plan. The same guy that developed the main plan could probably do this one too. Hide it though, or people will ask about it.
Attend meetings. That's where you really learn what other people are doing, and it makes them feel like you're part of the team.
Be looking for your next project. You'll need it earlier than you think.

Do You Speak "Project"? (v1)

2009-11-19T14:03:00.000-08:00

Project management is a specialty, and it has its own language. Resistance is futile.

Scope - It's what has to be done. Always too general for some and too specific for others. Never right.
Resources - Funding and people authorized for the project. Never enough and always in the wrong denominations.
Schedule - How much time you have to get it all done. Never enough.
Project Manager - You. The person responsible for everything, and in control of nothing.
Sponsor - The one that wanted it in the first place. The one that shudders when you walk in because you always bring a problem, and give them way too many details.
Customer - The group that want things their way.
Vendor - The other group that wants things their way.
Users - People addicted to the old way.
Escalation - A process that defies gravity, and moves problems uphill.
Documentation - The last task in a project, or later.
Flowcharts - Cubicle art.
Team - Your best friends. The group that, when asked who caused a problem, forms a circle and each person points to the left.
Work Group - An oxymoron.
Oxymorons - People that take more than their share of oxygen from a project.
Project Plan - A deliverable assigned to the most annoying person on the project, who doesn't recognize his or her work is done after the project has started and is going according to plan.
Almost Done - Where you are after Day 1 of the project. What you say when the "80% done" answer quits working.
RFI - Request for Information. A request for a customized marketing document.
RFP - Request for Proposal. A request to take a monkey off a customer's back.
RFQ - Request for Qualifications. A request for a customized marketing document. A good source of boilerplate information for the RFP.
RFQQ - Adds a price quote to the RFQ. Generally from a vendor that has too little information from a customer that has too little understanding. Binding.
RFK - An important reminder that even the best project managers can find themselves in a bay of pigs.
Proposal - A document of sweeping generalizations.
Testing - What development is called after the development schedule has passed.
Testing - What the end-users do when the testing schedule has passed. Sometimes called Post-implementation Support.
Process Reengineering - Todays processes, turned sideways.
KPIs - Key Performance Indicators. Objective measures of failure, most often advocated by opponents. Never tracked.
CSFs - Critical Success Factors. An early view of the blunders you will certainly make. Always tracked, but never called CSFs.

If this sounds familiar, you are an experienced project manager, undoubtedly overworked, underpaid and not appreciated. Get a dog.

Foundational Skills

2009-10-25T13:11:00.000-07:00

Though each project requires some unique skills, most projects share the need for a common set of foundational skills.

Leadership - You need to visualize the end goal in a way that attracts good people who join in the desire for your vision and want to contribute.
Interpersonal - Though you're not in a popularity contest, people will do more for you if they like and respect you than if they don't.
Communication - The goal is alignment which can only come with understanding. You must opt for the most effective communications methods, which are not always the easiest or most efficient.
Situational Assessment - You need to grasp the context and significance of a situation and trigger any of a variety of corrective actions that might be needed.
Problem solving - You must deal with the root cause of a problem, not just the symptom.
Quantitative methods - Manage by the numbers, not by anecdotal evidence. Require proof that the project is on schedule, on budget, and of needed quality.
Sampling - You need a "trust but verify" philosophy, which means you have to sample performance so you can give direction where performance is less than expected. Sampling means measuring units over time. It also means sampling quality as the project emerges.
A bias for prevention - Time spent on success is more inspiring and cost-efficient than time spent on problems. Implement practices that prevent problems.

If you master these skills, other important skills will necessarily follow.

New Rules for Troubled Projects

2009-10-13T10:17:00.000-07:00

To recover a troubled project you must have experience to "see it how it is" and the courage to "call it like you see it". If you possess these qualities, the troubled project environment may be for you.

In a troubled project, sponsors and other stakeholders have become very frustrated at the lack of results, the mounting tensions, and the looming political embarrassment of being substantially over budget and over schedule. It's the perfect setting for a select few project managers that have the experience and courage to distinguish themselves from the pack.

"Of all the things I've done, the most vital is coordinating the talents of those who work for us and pointing them toward a certain goal."

- Walt Disney

As a recovery expert, you must coordinate the talents of those who work around you and point them toward that goal. To get the needed focus, you must understand the goal, quickly assess the situation, and negotiate a different set of rules by which you will manage the project. Among these rules:

Changing leadership - Even good leaders can get tired of the battle. Where you detect leadership that is unable or unwilling to take the needed actions, you need the authority to change them. That includes sponsors and other stakeholders that would be an obstacle to success.
Changing staff - You will need solid technical thinking from people that can work together. The most insightful people are often found in the shadows of a project, often deferring to the "vocal minority". You need the authority to empower them.
Changing location - An obstacle to success is the inability for team members to talk to one-another when the need arises. If people are not located in the same area, they will bury an issue because it's too inconvenient to address it, or actually get up out of their chair and go find the person which takes away much of their productive time. Better to co-locate the team in a troubled situation, so they can merely walk around the partition and ask a question.
Changing communications modes - People on troubled projects overuse to email because it's much easier and efficient, and because it's easier to have an email barrier between you and other disgruntle team members and stakeholders. You must restrict the use of email where conversations are needed to bring context and collaboration to a situation.
Changing utilization - You will find that unnecessary participation in meetings consumes as much as 35% of the team member's time. By removing them from the meetings, or even eliminating the meeting all-together, you will effectively be giving them back two days each week to get important work done.
Changing priorities - You will find a cobweb of conflicting or misaligned individual priorities. You must replace individual priorities with higher level project priorities. You must review alignment of team actions with project priorities often enough that all team members will know they risk being exposed if they don't align.
Changing oversight - In most troubled projects, you will find a lack of management information, and an excess of operational information. You must obtain reliable information about staff performance and project status on a regular basis. This will require changes to work habits, but the payback in making informed decisions is well worth the trouble.

Recovering troubled projects are not for the faint-of-heart. But if you want to gain distinguishing experience rapidly, find your way in to a troubled project.

What To Report

2009-06-26T23:16:00.000-07:00

Make them curious. The Wall Street Journal gives one or two sentences on the front cover about a story that can be found in more detail inside the newspaper. Give your audience the one or two sentence summary, that will pique their curiosity.
Don't presume they know their job. They are busy. They are likely in a position to know high level but not details. Their focus is on the business-as-usual environment and issues relating to it. Yours is a project, which by definition is being conducted outside of their business-as-usual environment.
Make it simple. Don't require them to search for the point you're making or the question you're asking. Sponsors and other stakeholders love when you give them a grasp of the situation in really easy terms.
Use numbers and pictures. Well-chosen numbers are powerful. Graphical depictions make it easy.
If you don't have facts, use logic. Often times data isn't available. That doesn't mean the problem doesn't exist. Where data is lacking, use the "if... then..." logic to shed light on a situation. A useful sequence for logic-based reporting is: 1) this could happen, 2) the likelihood of it happening is [small, moderate, big], and 3) the consequences if it does happen are [small, moderate, big]. It is then easy to persuade people to agree that two "bigs" are worrisome, whereas two "smalls" are not.
Don't wait until the problem is so ripe, it's obvious. You will usually sense a problem before it becomes obvious. The tendency is to wait until it's obvious to report it. But by then the consequences are worse and the cure can be costly. Don't wait for facts if your instincts are strong. Sometimes a Sponsor or other Stakeholder will know what you're sensing and provide useful context, so you can go about solving it sooner.
Always offer a solution. It's why you were selected. They can always opt for another course of action, but give them something to respond to. A blank page is usually not a good starting point when you need to discuss remedies. Odd as it sounds, I've found that things are better even when I offer weak ideas than no ideas at all. It gives them an "I don't like that, but what about this?" way to start.
Call out actions required of them. Too often, needed actions are lost in the noise of the report. Restate, in list form at the end of the report, actions that are needed, by whom, and when. Where I sense the need for an extra nudge, I also gently remind them of the consequences of inaction.
Always say Yes, but include the cost of the Yes. A sponsor or other stakeholder doesn't want a "no" or an "I can't" from you. With that response, you are pushing the project back to them, and they are certainly at a disadvantage compared to you. Instead, inform them of what it would take to deliver something they ask for. If you can't be precise, then offer a range of possible costs. But always offer them a "yes" and let them judge the merits of the investment, and decide whether or not to make it. It's their right.
Two choices; a specific date or a range of dates. A specific date is seldom made, so must be offered with low confidence. However you can offer a range of dates within which the outcome is very likely. So you can offer that with high confidence.

One last tip: There are two times a Sponsor or other Stakeholder will cancel meetings; when the project is going really well, and when it's not. It's up to you to keep them informed. If you keep the information to yourself, you're accepting responsibility for consequences. Don't stop reporting just because stakeholders stop requiring it.

The Project Mindset

2009-04-09T23:59:00.000-07:00

Inexperienced project managers typically exude optimism. In contrast, experienced project managers are often viewed as skeptics. I've found that a solid project manager is both an optimist and a skeptic.

The experienced project manager has an insatiable appetite for knowing what's left to be done, at all times, irrespective of how well or poorly the project has performed in the past. This leads to a "show me" management style, requiring evidence from staff that their work is on track. They have a very different mindset from managers of day-to-day operations, who assume things are going well unless they get some indication to the contrary. Rather, they assume things aren't going well, unless they get some indication to the contrary. They require evidence from the project that the remaining work is being reduced at a the same pace as the remaining schedule.

The experienced project manager also has earned the right to be an optimist. They have been through difficult situations, and witnessed what resourcful humans can do when motivated. They often have deeper conviction about staff abilities than the staff do themselves. At times they might even come off as evangelical; talking persistently about the vision and being unflagging in the team's ability to deliver it. Though they are respectful to authority, they tend to be more impressed with aptitude. Consequently, they often invest in people that were previously undiscovered in the organization, and get a tremendoulsy motivated and productive team.

When the project is over, staff overwhelmingly favor their time with the experienced project manager. They reflect that it was a time of personal growth, advocacy, and accomplishment.

About These Essays

2009-01-14T22:00:00.000-08:00

"The most successful project managers have perfected the skill

of being comfortable being uncomfortable."

-- anonymous

Every project presents a new set of circumstances, requiring you to work outside of your comfort zone. And projects are always challenging, as evidenced by the very fact that a project was formed.

The root cause of most struggling projects can be traced to under-qualified project managers who are reluctant to seek help. Too often these under-qualified project managers end an otherwise rewarding management career with a failure, simply because they (or their supporters) didn't understand the specialized skills required to manage a project.

These essays offer some perspective on common issues in project management, in hopes of helping project managers navigate the challenges. I hope you enjoy them.

All the best...
Barry

Inspire Your Team

2008-10-28T22:23:00.000-07:00

There are lots of variables in a project, but none so important as the human sentiment. Remarkable accomplishments are seen from inspired people, and remarkable teams are seen from an inspired leader.

So what can you do to inspire your team? Here are a few tips:

Know them uniquely - Go 1-on-1 with them and learn what matters to them.
Find their gift - Observe what they do well, and not well. Help them understand their natural gifts, and channel your opportunities to align with their strengths.
Promote them - More than just giving them a raise or a new title, call attention to them. Let people around you know what they're good at and give them your endorsement.
Take risks - As you see strengths, give opportunities that may stretch them. Let them know you won't abandon them if they fail, but track their progress so they won't.
Coach them - Provide on-the-job training. As you assign them stretch-opportunities, be aware of their challenges and coach them through situations.
Listen - The best advice often comes from the most unsuspecting people. Seek thought-leadership, and listen when you receive it.
Acknowledge - Let people know when they've delivered a gem of an idea or solution. They may not perceive it on their own.
Push back - Require that one or more potential solutions are presented with problems. Remind people that they often have greater context for a problem than you. Affirm them.

If you invest in your people, they will invest in you.

Do You Speak "Project"? (v2)

2008-10-15T17:27:00.000-07:00

Project management is a specialty, and it has its own language. Resistance is futile.

Work breakdown structure - Shows how work will break down, before it does. No remedy shown.
JAD Session - Where everybody has a voice, and they're all overlapping.
Scope - A medicinal beverage, most commonly used to wash the odd taste out of our mouth following a JAD session.
Mini-spec - An analyst's abbreviated interpretation of a user expectation. It should be flicked from the requirements quickly, before anybody notices it.
Gantt - Shows exactly what happens when, using a series of bars. After a few bars, you start to feel guilty about what happened when. You wisely keep it to yourself.
Dependency - The discovery that you've become married when you weren't looking, to somebody that doesn't even know the music you like, resulting in tasks for which you were unaware, but are now being kicked out for not completing.
Critical path - the shortest route to the door in case of an emergency, like when a stakeholder shows up.
Stakeholder - The one left holding the goods when all the cooks have left the kitchen.
Team Lead - a term originally referring to the plow-horse in front. Actually, still.
Broken links - The relationships you had before you joined the project.
Change agent - The person that disrupts your business, with the promise of a better life. Referred to as "parole officer" in some circles.
Org chart - Formalized pecking order, showing who the peckees answer to.
Low hanging fruit - Food for the hungry, that spoils on the limb because nobody looked up.
Standard terms and conditions - The name of a nifty little game, originally created by lawyers, where nobody wins but the lawyers. You can upgrade from the Standard to the Premium edition of Terms and Conditions if you'd like to win, though few can afford the cost of winning.
TLAs - Anything worth saying can be reduced to a three-letter acronym. The accomplished project manager can string TLAs together to make an encrypted phrase that only other project managers can understand. Of course CIA is a TLA, so they know project management and you should watch what you say around them.
Methodology - Start here, end there. No thinking required. Of mice and men, this is for the mice.
Slack time - When you could have a smoke.
Referential integrity - When people refer to your integrity, even when the database is all messed up.
Exit Criteria - Conditions that prove you're done. Most often created when you think you're done and need to prove it.

If you can relate to this, you might have a problem. Go take it out on your FTEs!

Caution: Phase-Shifting!

2008-09-30T23:16:00.000-07:00

Phase-shifting occurs in nearly every information technology project I've observed. Phase-shifting simply means that milestones are being made, but the related work hasn't actually been completed, thereby shifting it to a subsequent phase.

A classic example of phase-shifting is from a development phase into a testing phase. During the development phase, the project is highly motivated to hit published milestones. And if you can show that important milestones being met, sponsors and other stakeholders will leave you alone. Even better, you don't have to argue about work not being done with the Team Leads or Contractor Leads who are usually more qualified to win the argument.

Early in the project, the project manager's message is "get it done on time, and within budget". This leaves scope as the only variable the Team Leads and Contractors can manage. And so they manage scope, which means they compromise on scope in favor of reporting "on time, and within budget" to make you happy.

This false-positive reporting creates a bow-wave of work which builds and builds and eventually crests and crashes later in the project, when development deliverables have been accepted, fees paid, and the ability to finish the work is impaired. So the project remains in the testing phase much longer than was anticipated or budgeted.

What was previously being reported as on schedule now becomes so routinely reported as behind schedule that the sponsors become numbed and unresponsive to the problem. I remember one executive sponsor actually arguing, "Yea, but are we worse off than we were last report?" to which the independent quality assurance contractor replied "No, but if you were 20 feet under the surface of the water and unable to breathe at last report, should you really be pleased that you're still only 20 feet under now?". The sponsor was clearly tired of the problem and becoming unresponsive.

Trust and verify is an excellent credo in an IT project. Measure frequently. Focus on what remains to be done, not what has been done. Ask precise questions, and don't settle for ambiguous answers. Require evidence of progress, not mere conjecture or sentiment. Search for truth. And be alert to phrases like "80% done" or "they can always work harder and smarter" or "we can make it up later". These are clear warning signs that a phase-shift is occurring.

Non-productive Team Members

2008-09-30T23:15:00.000-07:00

Judgments about individual performance are more frequent and less forgiving in projects than in business-as-usual operations. In project settings the expectations are high, the schedule is ambitious, the budget is tight, and other people's ability to perform is tied more directly to your own performance. One person falling behind can have a cascading effect on their team. Likewise, a team falling behind can have a cascading effect on other teams, easily resulting in schedule delays and cost overruns to the project and missed opportunities to the business.

Non-productive team members should be helped as soon as the pattern of non-productivity is revealed. The remedy starts with the team itself.

An effective team wants its members to succeed, and takes the initiative to find out why a team mate is struggling. The very fact that a team mate doesn't have authority over the non-productive member can be what opens the door to needed conversation. A team mate is likely to have the best context for a situation, and can bring fresh perspective. A team member who doesn't take the initiative because it's not their job is not performing as a team member. Taking responsibility for each others performance is at the heart of what differentiates a team from a work group.

After reasonable attempts have been made to help a non-productive teammate, and before the teammate's performance hurts the morale or work product of the team, the project manager should become involved.

The project manager should engage the non-performing team member with a collaborative tone, and presume the problem can be worked out. Open discussion of the barriers to needed performance will reveal whether the solution is within or outside of the team member's control. The project manager should probe for issues including their understanding of the task at hand, dependencies on other tasks, prioritization of work, management of time, accountability, or interpersonal conflict. The discussion may reveal broader issues within the team that should be corrected. Conversely it may lead to a recognition that the team member is not likely to deliver the needed performance, in which case the project manager must proceed with corrective action. And it doesn't have to be contentious.

A non-performer may have been assigned to the project, on the advice of a boss or other person of influence, just to find themselves in over their head. If this is the case, and the desire is still there, some extra coaching by a team lead or a specialist may be a good investment and result in an appreciative and loyal team member. Alternatively, there might be a less critical position that would allow the person to acquire the skills without putting the project at risk.

If after reasonable attempts have been made to discern the problem and no viable solution has been found, it may be time to consider a transfer back out of the project and into their prior position or another position in the business-as-usual environment.

Dealing with non-productive team members can be an awkward process for even the experienced project manager. Here are some tips to make it easier.

Be candid about where responsibility lies. If the root cause is outside of the person's control, admit it and seek to fix it. If it lies within the person's control, be clear about it and expect it to be fixed.
Be empathetic, but not apologetic. Show sincere regard for the person's performance and an honest desire to guide them to needed performance. But the performance of the team usually cannot be slowed while one person gains needed skills. And the project manager cannot make a personal project out of mentoring one person. Be comfortable explaining the boundaries of reasonableness, beyond which a different course of action must be taken.
Be resourceful. Unforeseen circumstances are typical of projects. And people are the vital ingredient in projects, particularly when trying to solve problems. Encourage the non-productive person to think about ways to solve the problem, while you are doing the same. They are in as good a position to know what would work as you.
Seek another opinion. If you're not able to bring the team member to the needed level of performance, consider the brief use of a third party. Human resources groups and external consultancies can be quite effective in helping people quickly see a path to performance.
Know when to cut bait. Not all problems can be solved within the tolerances of the project. If you've exhausted all reasonable avenues, cut bait. Decisive action on an unrecoverable team member will benefit the team member, whether he or she understands it or not. And it will very likely be encouraging to the remaining team members who are wanting to hit the higher level of performance needed by the project.

I've often thought that a psychology degree would have been nice to have in my past. So much of project management is about persuading people to perform at a level they're unaccustomed to, and to have them understand that it is indeed about working smarter, not necessarily harder.

I'm a Sponsor. Now What?

2008-09-30T23:11:00.000-07:00

Project sponsors don't manage projects. They just want things done. And they don't like details. They just want things done. And they don't really like bad news. They just want things done. They've authorized the money, the staff, and the schedule. Isn't that enough?

One of the critical success factors most often cited in project management articles is the need for a solid sponsor with sufficient budget authority. I agree. Without solid sponsorship, your job as project manager will be complicated beyond your control.

In most projects, the Sponsor is positioned on the outside of the project organization, and their role is not clearly defined. Further, inexperienced project managers feel any imposition on the Sponsor is a sign of weakness, so tend to leave them alone. This leaves them wondering what their responsibility is, or worse, enjoying their lack of responsibility. So, what is the Sponsor supposed to do?

First, a Sponsor must understand that they own the project and its outcome. It's necessarily that way. And it's common sense when you think about it. The Project Manager cannot approve extra money; cannot change an end-date; cannot authorize transfer of human resources from the business organization into the project; cannot cut scope, or add to it for that matter. Those decisions are all the prerogative of the Sponsor. But the Sponsor is typically involved in strategic matters and can't tend to the details of the project. That's why you are here. Moreover, many Sponsors have never sponsored a project before. They may be reluctant to ask a subordinate (you) for guidance. Including the Sponsor's responsibilities in the standard project documentation can help the Sponsor do his or her job. Here are some things you could include:

Advocate - The Sponsor should be the strongest advocate of the project and its outcome. They should be alert to opportunities to evangelize the expected benefits, and cultivate an enthusiastic following.
Manage by exception - The Sponsor is a "boundary manager", meaning they entrust the day-to-day activities to the project manager who manages to project objectives. However, an experienced Sponsor makes sure they are alert to issues which could push the boundaries of the project manager's authority or skill.
Manage by the numbers - The Sponsor must know how the project is doing, and the impact of issues on quality, schedule, and resources. This is provided by fresh objective data about remaining work, productivity of resources, and best and worst case schedule scenarios for project completion.
Isolate required decisions/actions - Needed actions of the Sponsor are too often hidden amongst other information in the status report. Isolate decisions or actions required of the Sponsor from the rest of the report, and be clear about when the decision or action is needed. Track this as you would any other needed action, and provide a tickler if the date is approaching with no apparent response. It's generally wise to include a short statement about the consequence of inaction, so they are not caught off-guard when competing priorities might cause them to forget this one.
Make timely decisions - If a decisions is required, ask for it. If the Sponsor cannot make it, find out why. Often, some due diligence is required to provide enough context to an issue so a decision can be made. If the Sponsor has insufficient information from which to make the decision, provide it. All decisions are not of equal importance. Make sure you convey the consequence if indecision, in specific terms.
Escalation - This relates to timely decisions, but deals specifically with interpersonal or contract conflicts, for which attempts at resolution within the project have failed. You must make clear the consequence of the issue, the facts surrounding the issue, and your recommendation. Mostly importantly, you must state the need for a timely decision or risk unwanted impact to the project.
Affirmation - Most project members will say they don't need strokes, but they do. When you are working hard, the occasional expression of appreciation is welcomed, even inspirational. And an inspired workforce is more productive than one that has fallen into routine.

Outlining these responsibilities will help the Sponsor, and create more open communication with you.

The Benefit Of Frameworks

2008-09-30T17:47:00.000-07:00

The hardest part of a problem is understanding it. Once you understand it, you are much more apt to solve it. But many problems are unfamiliar; you've not experienced them before. That's where frameworks become a useful aid. Frameworks have been created by other people that have encountered your problems and put some dimension to them, in order that they may be solved more easily in the future.

A framework can come in many forms; a checklist, a template, a flowchart, a financial model, a chart. The key is to find one that is a close fit with your specific situation; one that gives you a way to see the problem that makes it solvable.

One widely used framework is the ISO Open Systems Interconnection architecture (OSI) which organizes technology into a model that assists in the design of the IT organization and also in determining performance measures.

Another familiar framework is the nutrition pyramid, which organizes the primary food groups into an easily-understood picture, allowing people to eat healthier.

Frameworks are different than methodologies. Whereas methodologies provide a set of processes that serve as a road map through a wide range of situations, a framework is more of a blueprint for a specific situation.

Frameworks are available through a variety of sources. The easiest way to find one is simply to Google on a key term or phrase and see what comes up. You can then click on Images when the results are returned, since many frameworks are presented as a graphic or picture. Another way to find a fitting framework is to join an online group of similar interest, and ask them for one. LinkedIn.com groups are proving to be an increasingly popular source of professional groups and connections. Also most consultancies have their own frameworks to help them navigate a client situation and if hired, will share them with you.

So if you are struggling to get your arms around a problem, search for a framework that will help you see the problem in a solvable way. The more time you take to understand the problem, the less time it will take to solve it. And the better you understand the problem, the more insightful your opinions will be.

Gain A Sense Of Urgency

2008-09-29T15:00:00.000-07:00

One of the biggest differences between a project environment and normal business environment is the sense of urgency.

Schedules are always top-of-mind in the project environment. You have an end-date and a series of interim milestone dates, and they're all published in some form of a project plan that stakeholders see. The lesser experienced project manager will view these project milestones in terms of the time pressures they've handled as a line manager for years. But the time pressures are different in projects. The stakes are higher than in business operations. This is evidenced by the very fact that a project was formed to deliver an outcome that somebody with authority felt they wouldn't get through normal operations. In projects, goals are more aggressive, expected results are higher, and so productivity must be higher too, meaning more done in less time than would happen using normal management methods. This brings a sense of urgency beyond normal day-to-day business activities.

The experienced project manager is always looking for ways to accelerate the project, even when things are going well. They're always looking for ways to gain a week here and there to compensate for inevitable downstream delays. Some may view the experienced project manager as being pushy, while others will view them as resourceful. Either way, they earn the reputation of getting bigger things done quicker than most others would. They gain a favorable reputation with key officials and become "go to" people for tough assignments. Indeed, many well-healed project managers cannot return to line management roles because the pace is far too slow for them.

It is important to understand that project management is a specialized skill, not a rung on a career ladder. Both project managers and line managers play important roles in the course of business. They should not be in competition.

Here's one way to look at the difference:
A line manager is like a primary care physician. He or she is with you before and after the specialists are involved. They have a much broader span of responsibility for you. In contrast, project managers are specialists. They're brought in to address a specific need, apply specialized skills, usually for a short period of time, to obtain a specific outcome. A sense of urgency differentiates the specialist from the primary care physician.

Here's another way to look at the difference:
A project is like running a sprint. You run a shorter race, but you give it everything you've got, from start to finish. In contrast, business operations are like running a marathon. You pace yourself so you can go the distance. A sense of urgency differentiates the sprinter from the marathon runner.

If you're wanting to differentiate yourself as a project manager, you should gain an innate sense of urgency, and an insatiable appetite for ways to improve individual and team performance, and let everybody share in the spoils of the high performance organization that results.

Two Common Trouble Spots

2008-09-28T14:59:00.000-07:00

Conversions and Interfaces

If you want to quickly establish your project management prowess within a project, ask about conversions or interfaces. They are two areas that are thematically trouble-prone. And you can find some form of these tasks in nearly any type of project.

Conversions

In systems projects, it can mean conversion from one system to another. Or from one data format to another. Or of hardcopy files to a digital form.

In business projects, it can mean conversion from one set of procedures to another. Or from one organization to another. Or from one location to another.

A useful way to think about conversions: Anything in a project that needs to be one way one day and another way the next.

Interfaces

In systems projects, it can relate to information required by government agencies. Or exchanged between systems within your organization. Or involving manual steps in the middle of automated processes.

In business projects, it can relate to processes that involve governmental agencies. Or with external business partners. Or across lines of business.

A useful way to think about interfaces: Any entity outside of your own, to whom you owe or require information to meet your day to day commitments.

What to do

The best answer is to scope it early. That is to say, understand all things that will need to be converted and compile a complete inventory of what exactly needs to be done for each and by when. Get an estimate of quantity. Similarly with interfaces; compile a complete inventory of interfaces that will be affected - either eliminated, changed, or added - and important dates and dependencies.

Once you understand the size and nature of the challenge, you will be in a much better position to evaluate the skills needed and level of effort required to complete the tasks. From that, you can work back from important completion milestones to ensure work is started early enough and you can monitor progress much more effectively along the way. You will also learn of dependencies in getting the job done. Dependencies are a common trouble spot when you need a response from somebody over whom you have not control, as is characteristic of external entities.

These two areas are so often sources of problems that it's a good idea to stage this scoping analysis very early in the project and visit it from time to time to ensure it accurately reflects the work to be done, and challenges in getting it done.

Simplify the Job

2008-09-26T18:09:00.000-07:00

The Project Manager’s job is far more complicated than it needs to be. There are far fewer skilled project managers in the workplace than complex projects that require them. A common-sense solution then, is to simplify the job of the project manager. Here are some ways you can do that:

Limit your role – A common trap is for the project manager to accept responsibility for scope. The project manager does not typically have the authority to dismiss requirements, and so does not own scope. Scope is a function of the outcome that is expected by the Sponsor, and is inherently owned by the Sponsor. If Sponsor expectations are not aligned with the resources he or she authorizes, you cannot be expected to deliver the expected outcome. The project should be reviewed with your Sponsor on a regular basis to ensure scope and resources are in balance. Where imbalances exist, the Sponsor must authorize a decrease scope or increase resources. Following this rule, you will spend less time rationalizing impossible outcomes, and more time on creative ways to optimize the things you actually have control over.
90 day rule – Define tasks such that they can be completed within 90 days. This provides two benefits. It sets a milestone within grasp, which motivates people to achieve it. It also provides enough near-term understanding of the work to be done that the risk of run-away effort is minimized. Following this rule, you will spend much less of your time mediating opinions about tasks that have no clear definition and have more time to optimize efforts on well-defined tasks.
Zero-based meetings – Many recurring meetings continue on their own momentum, long after their usefulness has ended. It's not unusual for me to find over 30% time which can be handed back to staff merely by eliminating unnecessary meetings. That's like giving staff an extra day or two a week. Challenge the inventory of meetings from time to time. Let your zero-based meeting bias show. Start with the assumption that no meetings are required, anywhere, any time. Were the need for a meeting can actually be proven, assume nobody needs to attend. Obviously this is nonsensical, but you’d be surprised how much waste can be trimmed from the work day and how much more people enjoy the workplace when they get more work done.
Sync Sessions – Here is a meeting that seldom occurs, and can be the highest value series of meetings a project manager can have. Conduct weekly review meetings of 15 to 30 minutes with each of your directs, where they openly discuss their workload, share crative thinking about ways to approach their targets more efficiently, and synchronize their estimates according to the work which remains on the task. This ends up being a fair investment of your time, assuming you are in charge of 7 to 15 directs, but the payback is among the highest of anything you can spend time on. After all, the only true project variable is the human mind and how they see what needs to be done. Following this rule will provide more time to engage in creative and emotionally fulfilling dialog with your team and the result will improve the bottom line cost and schedule.

There are many other ways to simplify the job, but these are among the most effective I’ve found. They require some courage to implement, but the payback is quite worth the effort.