The Project Management Institute (PMI) has many different Special Interest Groups (SIGs) in order to meet the needs of its 250,000 members. The latest issue of the PMI Consulting SIG Newsletter asked the question:

What should be the curriculum if we had a Consulting Project Manager 101 Class?

Here are my thoughts:

1. The book “Flawless Consulting” by Peter Block should be a primary text. It’s not only a practical book on how to become a consultant, but also an inspiring treatise on the importance of integrity and honesty. Block’s main point is that we have to bring our entire, authentic self to our consulting. I found this to be invaluable advice when I was starting out.
2. I’d like to see a module on “How Teaching PM makes you a better PM Consultant.” I’ve become an adjunct faculty member at a local graduate school and have been amazed at how well teaching and consulting go together. I’m able to bring real world examples to the classroom, and I have all the language and techniques of PM at the top of my brain because I’ve just been teaching those concepts to students.
3. How about a section on “You and Your PMI Chapter”? My local Chapter is a great resource for two reasons. First, the Chapter is helping to educate our local business community about the value of project management. Second, I get to network and brainstorm with local colleagues, which helps me to stay energized and excited.
4. Legal Issues: we all need to be kept up to date on how to develop a good contract, what kind of insurance to maintain, and how to avoid incurring liability.

What else do should be part of the curriculum?

Here’s an interesting discussion from Tech Republic about the value of team building exercises.

http://blogs.techrepublic.com.com/career/?p=119

Several self-described nerds wrote in to say that they find the team building exercises that have been designed by extroverts to be truly horrific for introverts. One contributer, who calls herself Server Queen, said

I find that kind of thing very stressful, as I do almost any forced socialization. Any true introvert will find forced socialization draining. That’s the definition of an introvert; a true extrovert finds solitude draining and recharges from doing things in groups.

I’m an introvert at heart but I have forced myself to learn how do to things in extroverted ways because I find it easier to make a living using that mode of expression.

I think that team building exericises can be valuable but only if we as designers put a lot of thought into their development. The hoky “let’s all throw the koosh ball” games are perceived as a waste of time by all but the most extroverted of participants.

I love Thiagi’s games and have used several of them to good effect. But from now on, I’m going to put more thought into whether these games are safe for introverts.

There is an excellent collection of meeting tips available in the latest
BNET feature. Check it out for creative ideas, helpful hints for teleconferences, and what to do when your meeting goes bad.

When I ask my project management students to develop their first work breakdown structure, there are inevitably a few meetings listed as deliverables.

I feel strongly that a meeting itself should never be considered a deliverable. Meetings are held in order to achieve an objective. Therefore, we can list the desired outcome of the meeting as a deliverable, but not the meeting itself.

This is part of a larger problem, which is that meetings take on a life of their own. The worst offender is the “weekly status meeting,” held in dysfunctional organizations around the world. Team members come together having received no agenda and then a rambling discourse follows while they talk about what they’ve done in the recent past. With no direction and no documented goal, the meeting becomes an almost complete waste of time. It’s OK to have a regularly scheduled meeting time, but someone must own that meeting and give it a publicized purpose.

Some resources to help you to plan and hold great meetings can be found on my Amazon store page.

The WBS is a mythic document in Project Management. Every text reminds us that the WBS is the foundation of the project plan. But what the heck is it? Perhaps appropriately, I’ve found a lot of mythology on this topic. So let’s talk about what it is and how to build it.

I should begin by saying that experts differ. I belong to the school of “Effective Work Breakdown Structures” as outlined by Gregory Haugen in his book of the same name. Thus, we are believers in the deliverable-oriented work breakdown structure.

Simply put, the WBS is an outline of all the major deliverables that will be produced as part of your project. The key is that we are talking about the nouns, the (mostly) tangible objects that will be created through project work. Those items about which we can say, “once we have all of these things, the project is complete.”

Most people have trouble with this concept at first. We have often been trained to think in terms of the activities, that is, the verbs, rather than the deliverables or nouns.

There are several ways to create the WBS. If you’re finding that you are focused on those verbs, then do a sticky note exercise. Write one activity each on a bunch of stickies. Then find a nice blank wall and arrange those verbs so that you can see which deliverable should result from each set of activities. This is a bottom-up approach.

Another approach is to begin at the top. Think about the largest categories of deliverables. Usually these consist of things like:

Then decompose those major deliverables into one or two smaller categories. Thus, under Design, we may have both Database Design and Website Design. The goal is to keep the WBS fairly high level. I don’t like to see WBS documents which are longer than one or two pages (which is related to another topic: keep your projects small and manageable).

However, you do need to make sure that 100% of the project-related work is represented on the WBS. For example, say you forgot to list Documentation as a deliverable but you know that there will be documentation work that must be done. In that situation, the WBS would not be an accurate reflection of the work and all the future prject management documents would underestimate the resource needs of that part of the project.

By the way, this and the next few essays will be under the larger topic called “The Devil is in the Details,” one of my eight tips for project management success.

One final thought: meetings are not deliverables, but that’s a topic for a future essay.

When I introduce project management to my students, I always tell them that my goal in the course is not just to teach them how to do project management. My goal is to change their lives.

In part, this is because learning project management is about becoming empowered. No longer will you feel that you must sit quietly and do what you’re told. Instead, when you see bad decisions being made in your organization, you’ll feel compelled to ask questions. But you’ll be able to frame those questions in business-oriented language. Rather than simply complaining, you’re able to talk about the risk factors of a project and the implications of moving forward when the potential return on investment appears to be negative. By understanding project management, we gain the confidence needed to help our organizations learn, improve, and mature.

This is by way of introduction to Joel Spolsky’s excellent column on Customer Service
Joel is a change agent. He is willing to study his business environment and make decisions based on what he sees even when those decisions run counter to the current received wisdom about how to run a company.

For example, he understands that in order to run a successful software help desk, the staff must have the skills to both understand and communicate the customer’s problems. As he says,

It’s crucial that tech support have access to the development team. This means that you can’t outsource tech support: they have to be right there at the same street address as the developers, with a way to get things fixed. Many software companies still think that it’s “economical” to run tech support in Bangalore or the Philippines, or to outsource it to another company altogether. Yes, the cost of a single incident might be $10 instead of $50, but you’re going to have to pay $10 again and again.

When we handle a tech support incident with a well-qualified person here in New York, chances are that’s the last time we’re ever going to see that particular incident. So with one $50 incident we’ve eliminated an entire class of problems.

This resonates for me because we see the same class of issues in project management. Executives often choose to see the planning phase of the project as a waste of time and money. But in the same way that Joel’s $50 eliminates an entire class of problems, our investment in a project planning phase eliminates untold numbers of potential issues, with a savings in time and money that is many times the cost of planning.

After a bit of a detour, I’m back to Eight Tips for Project Success. Tip #1 was “Pick the Right Project.”

After a month of writing, I’m all the way up to Tip #2, “Involve Your Customers.” First and foremost, this means listening to them. Early on in the project, your team should spend time with customers and end users. Make sure the team understands the requirements from their point of view.

As you move from planning into project development, try to create prototypes of the end product. If the product is a web page, it’s simple to build a dummy page that looks like a user interface but which has no functionality. If you’re building a house, build a model first. If you’re writing a play, test some scenes with friends. The idea is to build a mockup of the product before the “point of no return” decisions have been made. Change is cheap during the prototype stage, but change is expensive once we’ve locked down functionality.

Why build a prototype? Because people are busy and because language is an imperfect communication tool. I can spend hours writing documents and talking about user interfaces but the odds are high that my audience is busy thinking about other things. However, when you sit them down in front of a prototype and say “this is what the product is going to look like,” then suddenly they can focus. Even if they tell you that they hate it, you’ve made progress because now you have information.

Another benefit of involving your customers is that they become invested in the success of the project. It’s easier to manage their expectations because they are close to the project. Finally, if your customers are truly involved, then you can be confident that you’re working on the right project. Don’t forget, if you build the wrong product quickly and effectively, it’s still wrong.

My friend, Jack Perron, sent me this excerpt from a sweet book called The Willows and Beyond by William Horwood. The book is a sequel to Kenneth Grahame’s The Wind in the Willows. For best comic effect, take a moment to read these inspirational words on leadership out loud.

In this scene, Toad (who has been visited by his lazy son, Master Toad, and
who has decided that the kid needs to be forced to hike every day) comes
across a book by chance in his library…

The book was entitled “Hiking For Leaders With Novices: Do’s, Don’t’s, and
Definitely Not’s”, by Colonel J.R. Wheeler Senior, Member of the Alpine Club
and Hiking Advisor to the Royal Marines School of Music (Yachting Section).

Wheeler’s notion of leadership was clear and to the point:

The leader is leader, and must at all times be on his guard against
insubordination and the dangers of paying too much attention to the weak and
feeble in his group. These must be weeded out and made an example of.

Where native porters are concerned, the leader is advised to hire two or
three (on my Nangha-Dhal Experdition I took on an extra porter for every
four days of the journey, but conditions were extreme) so that they might be
disposed of en route to encourage the others not to slacken.

The good leader will always remain in front and not allow another to
take his place there, otherwise, like the African pack lion, he is done
for….

It will frequently happen, and a leader should certainly not be
disheartened by this, that the way will be lost. I make it a practice, and I
urge novice leaders to learn from my mistakes and follow this advice
vigorously, on no account to tell others in my party where I intend going.
This ensures that wherever one may arrive, one appears to have intended that
as one’s destination.

The true leader should not feel obliged to know or understand the use of
every piece of equipment or the practice of every technique, for he will
have employed those in his expedition who should be able and willing
advisors on such matters. However, the effective leader will need to
appreciate the importance of seeming to know what he is talking about and
looking as if he knows what he is doing. This inspires confidence in those
he leads, and keeps them at their tasks.

Therefore, a leader is strongly advised to try on the equipment till he
is used to wearing it, and to find some quiet place where, unobserved, he
can get the feel of it with a short solo hike or two. In this way, he will
ensure that he looks the part.

I attended an interesting session on Risk Management the other day, sponsored by our local Microsoft Project user’s group. The presenter was from Palisade and he demonstrated their @RISK product plug-in for MS Project.

::geek mode on::

@RISK allows you to use probabalistic modeling for any or every task in your schedule. This means that instead of saying that a task will take 5 days, you can use statistical language to describe the likely range of days. Once this has been done for a number of tasks, then the model of the entire schedule can be described using probability.

::geek mode off::

This concept is fundamental to successful project management. Because of the uncertainty inherant in projects, it is insane to try to predict exact task durations. We might as well pretend to be psychics wearing gypsy headscarves. However, we can hone our estimation skills to the point where we can make educated predictions.

The @RISK product is cool because it removes much of the emotion from the calculation of date ranges. However, it is important to note that the assignment of the probability distribution to each task is still a human activity. There’s no magic formula or supercomputer that can tell you exactly how likely a given outcome will be. And thus, garbage in/garbage out.

The take-home lesson is that when you’re planning a project, don’t get trapped into giving your management an exact date when the project will be complete. Provide a range of dates that accurately describes the amount of uncertainty. If it’s early in the project and much is still unknown, say “second half of the year” or “third quarter.” As you refine the project plan and remove some of the uncertainty, you can provide more granularity by stating the month when you expect to complete the project. The only time you can be certain of your completion date is the day you’re done.

Much more information is available in Steve McConnell’s Rapid Development and Software Estimation: Demystifying the Black Art.

Your team has a good project, one you believe in and which will help your organization to achieve its goals. The next step is to write a good vision statement. You may think that everyone understands where the project is going, but folks are probably more confused than you think.

Here’s Scott Berkun on the subject, from The Art of Project Management:

Because everything derives from the high-level vision, the team’s overall leader should invest more entergy in it than any other early planning material. The five most important characteristics [of a good vision] are:

• simplifying
• goal-driven
• consolidated
• inspirational
• memorable

I counsel my students to write short vision statements, no more than a sentence or two. The language should be vivid and exciting, quickly communicating that vision of the future state which gives their project meaning.