Voices on Project Management

> Back to Voices Home

June 2010 Archives

PMBOK® Guide for the Trenches, Part 6: Quality

| | Comments (3) | TrackBacks (0)
We hear a lot about how quality can make a project management world full of butterflies and rainbows. But I have a bone to pick with quality.

C.F. Martin has making guitars since 1833. The company's quality is legendary -- and so is its price.

It was Martin that developed the Dreadnought body style, so called because its size was increased dramatically to boost volume and bass response. The resulting models, the D-18 and D-28, became the standard by which all other acoustic guitars are measured.

Sir Paul McCartney played a D-28 at his recent White House performance. Elvis Presley started off with a D-18 and moved up to the D-28 as soon as he could afford to. And from the time I started playing acoustic guitar, I wanted one.

I finally scraped together enough for a D-28, and my obsession started before I even left the store.

The custom cases are so precisely made that you can't leave the strap on the guitar. So, I bought a quick-disconnect device for it.

Then, my salesman informed me that Martin's lifetime guarantee doesn't cover cracks for guitars because of low humidity. In my home state of New Mexico, that's a problem. So, I bought an advanced humidifier and after-market insurance.

And, of course, I needed new strings. (One does not put medium-grade strings on a D-28.)

The beginning of my enslavement to this highest of high-quality musical instruments had begun.

The first time I used it in public, I was aware of a certain sense of dread. I realized that I was walking around with US$2,300 worth of fragile wood strapped to my torso. Microphone booms, chairs and other instruments loomed dangerously close by. My proximity bubble -- that area around your person where you're not comfortable with others -- had just grown significantly.

In past writings I've been a tad harsh on the quality fanatics, primarily because they can (and often do) place project managers in a position of being vulnerable to cost and schedule variances should high standards prove elusive. Those project managers should take heart: The ultimate consumers of your projects are held hostage to these same high standards, as I have come to realize.

I tried playing my other guitars, but it's too late. I have been spoiled. I have also reached the conclusion that quality has a distinct downside.

Clearing Your Team's Blind Spots

| | Comments (9) | TrackBacks (0)
Consider a team in which all members are performing at the optimal level.

You would see them engaging internal and external staff members only when necessary. They would deliver on requirements without having to consult you every step of the way, allowing you to be the chief who oversees a big project from a higher level rather than micromanages.

When team members aren't performing at their optimal level they are often constrained by blind spots. These are the internal roadblocks specific to each team member that we often label as communication issues, team dynamics, management style, and cultural and organizational biases.

Having a blind spot means not being able to see the complete picture. When we can't see the complete picture, we make up what is hidden by using context such as our knowledge, experience, goals and motivation.

Blind spots limit us because we lack the runway length required to let our ideas take off; we impose constraints that prevent us from understanding the goal, coming up with solutions and choosing the one that works best.

To expand your runway requires a well-integrated framework of communication and teamwork based on two main principles: clearing those blind spots by empowering the team to help each other and owning your enterprise.

In part two, I will expand on the power of ownership and how to tie these principles together.

Can you think of the blind spots that you were faced with in any of your previous or current projects? What was your way of dealing with them, and what was the impact on the results you produced?

How Much Proofreading Is Too Much?

| | Comments (8) | TrackBacks (0)
In March I introduced you to Sebastian, a highly competent, upwardly mobile executive who happens to be your boss. A very detailed person, Sebastian works from 6 a.m. to 10 p.m.

That post sparked quite a discussion and prompted some ideas for building a relationship with him. Now it's time to put these skills to use!

This time around, we're focusing on Sebastian's habit of proofreading. While it's a fact some people can see mistakes in documents that others just miss, his copious corrections are starting to cause issues.

Sebastian can and does act strategically. But his habit of correcting everything is causing the project managers and project management office staff in his division to spend an excessive amount of time focusing on the documents' presentation (style, font, grammar, spelling) to the detriment of the more important issues of content and strategy.

How do you advise him that his ability to see and correct minor errors might be counterproductive? And what is an acceptable standard for internal project documentation?  

Post your comments and ideas, and we'll review and consolidate the answers in a few weeks.

PMBOK® Guide for the Trenches, Part 5: Communication

| | Comments (2) | TrackBacks (0)
Frankly, I have no idea why or how the perfectly working lingo of the old cost/schedule control system criterion (C/SCSC, also known as "the C-Spec") has been superseded by the more recent, trendy jargon, but I am pretty sure project management, as a discipline, would be greatly enhanced if only we could go back to the way it was.
 
When the C/SCSC came out in the United States in the late 1960s to early 1970s, the Department of Defense insisted that organizations with whom they did business had a fairly advanced project management information capability. Because this insistence was attached to large amounts of business, companies took notice and quickly put into place the codified project management practices called for in C-Spec.

Coming as it was from the United States Department of Defense, you just knew there would be plenty of acronyms.

The time-phased budgets were known as the budgeted cost of work scheduled, which quickly became BCWS and shortened again to just "S."

Similarly, earned value was the budgeted cost of work performed, abbreviated to BCWP and then "P."

Actual costs, being the actual cost of work performed, then ACWP, had the same last initial as earned value, so it became just "A."

Three of the most important concepts in project management information theory had been reduced to single letters. It could even be argued that this entered the realm of code: a code that only the true believers of project management knew by heart.

But there was no earthly reason to know what the project managers  were talking about if you were a newly minted MBA or an accountant.

Their faces would likely assume aspects not unlike those of archeologists trying to understand hieroglyphics pre-Rosetta Stone.

Project managers could discuss their cost and schedule performance openly, even the ugly parts, without fear that the non-believers of project management had a clue what was being asserted.

Indeed, the folks in accounting took the opposite tack. Their communications lost their original precise definitions and are now mainstream. The "bottom line," originally the last line of information on a profit and loss statement, entered the business lexicon and eventually became synonymous with the final outcome of a process or event.

But you know you're in the company of project managers if you overhear a discussion on the merits of the CPI and SPI at the cume level (the reporting of the schedule performance index and the cost performance index at the cumulative, or life-cycle-to-date, level). The Defense Acquisition University actually publishes a "Gold Card," which is, in essence, our secret decoder ring, defining most of the commonly used project management acronyms and formulae.

At least we have the "Gold Card." What do y'all think?

The Courage to Acknowledge

| | Comments (4) | TrackBacks (0)
Last June, I blogged about a presentation on acknowledgment that I gave to 800 project managers at a conference in Helsinki, Finland. Afterward, Agoston Nagy, a participant, shared with me a conversation he had with a senior project executive of an Indian power company.

Mr. Nagy's colleague asked the senior project executive what the most important competence of a project manager is.

"He answered: 'A project manager must have the courage to acknowledge when somebody does a good job,'" Mr. Nagy recalls.

We must consider that this executive was responsible for 16 simultaneous power plant construction projects and many other projects in his company. The team took in accolades: One project won an international award for excellence in 2005, two others were finalists in the same competition in 2006 and another project won in 2008.

I really appreciate how Mr. Nagy's example illustrated the need for courage when acknowledging a co-worker.

Why courage? Isn't it a simple thing to let someone know how much you appreciate them, how their being part of your team makes you certain you will complete the project successfully?

No, it isn't. Acknowledging others in a heartfelt and truthful way makes us feel at least somewhat vulnerable. We are not certain that they will accept the acknowledgment in the right way: What if they think we are trying to manipulate them? What if they think we are not being sincere?

That's why we need to be courageous and take the risk -- at all times. It is worth it, no matter how vulnerable it makes us feel!

About This Blog

Voices on Project Management offers insights, tips, advice and personal stories from project managers in different regions and industries. The goal is to get you thinking, and spark a discussion. So, if you read something that you agree with — or even disagree with — leave a comment.

All posts represent the opinions of the bloggers.

Follow PMvoices on Twitter

About Bloggers

Keep checking back because the voices for this blog will continue to grow and change to represent a variety of regions, industries and opinions.

Read blogger profiles

Voices Poll