Home | Login | Recent Changes | Search | All Pages | Help

WhatWouldYouTeachNewProjectManagers

I'm building a syllabus to teach project management to students at the graduate level who have probably never managed a project before. Here's what I'm planning to teach:

• chartering a project (determining enough about the project to get going)
• how to generate a work breakdown structure and keep it updated
• how to monitor project progress
• how to have a conversation about the schedule with management and project staff so the project manager can avoid ScheduleGames
• how to iterate on planning the project
• how to know when a project is complete

Project managers of agile projects perform this work differently than project managers of traditionally-planned projects, and I was going to explain that during the class.

Am I missing something? (I'm sure I am :-) Please add what you think new project managers need to know. -- JohannaRothman 2004.01.21

• what the other people on the project do (or at least to ask them)
• that if you do not allow time for estimates, status meetings, team discussion, etc., etc. your schedule will be way less than your reality

Sherry.Heinze 2004.01.21

How to make it easy for people to tell you the state, even when it's not how you'd like it to be.

How to hear "bad news" early.

How to hear bad news so that you can take action.

esther.derby 01/21/04

I would teach them this URL.<g>

http://www.dorsethouse.com/books/rpm.html

And this one:

-- JimBullock, 2004.01.23

I recommend some basic NLP theory and practice, Myers-Briggs, and the Tao Te Ching.

IraWeinstein 2004.01.27

Johanna- There is so much to write and so little time today. I'll write what I can.

On MBTI-- As a project manager and planner I find the J/P difference quite profound. Strong Js may need counsel to avoid HastyClosure, while strong Ps may need help recognizing task completion. An understanding of the four temperaments serves me when forming teams and understanding why team-mates aren?t ?getting along?.

Teaching is a relationship between instructor and student. The personality and the style of the teacher will inevitably leak-out in the course of instruction. I am a strong ENFP; the models I prefer to build and work with are models of people and their interactions, not WBS and Gantt charts. At the end of the day, both are essential. NLP is one collection of models I find useful. Some of the model elements I use from NLP are:

• modalities ? preferences related to how an individual stores and accesses information: e.g. visual, auditory, kinesthetic preferences. Example: Continuing to search for the right words to explain a task to a team member when she really needs to see the detailed picture can be a waste of time.
• motivation strategies -- what motivates an individual to take action: e.g. fear of an imagined consequence vs opportunity for gain. Recognizing this basic difference can help you understand why some tasks are getting completed and some aren?t.
• convincer strategies-- how does an individual know something is true: e.g. has to hear from a friend three times, has to have seen the thing work once, has to be aligned with the viewpoint of a credible authority (aka sorting by affiliation). Could explain why upper management is not convinced when you know your arguments are sane.

NLP also has techniques for making change. For example, Reframing is a technique for shifting the interpretation of an event in order to change the experience of it. Think of it as a personal attitude adjuster. Sometimes as a project manager I have to change my own interpretation of an event before I can muster up the energy to honestly lead others.

I use the NLP I have learned to improve the quality of my communication with team-members. One catch-phrase of NLP that often bubbles up for me is: ?The meaning of your communication is the effect that you get?.

There-- we have nicked the surface of NLP. There is a lot of ground to cover: models, concepts, techniques, history, relationship to Satir's approach, ethics, dire warnings and limitations.

I am out of time. I can write more later.

IraWeinstein 2004.1.28

You have an interesting problem with scope creep. The problem is, of course, that "everything is connected to everything else." So what to leave in, and what to leave out? This becomes a problem when the categories are: "What I can teach you here, and now." and "Everything else which you can ignore." The solution I've used lately has two parts. First is a disclaimer that what I'm providing won't necessarily work by itself. Then I introduce a third category: "Stuff you should probably know about, not covered here." For the "stuff you should probably know about . . . " I try to introduce one small, stimulating example within the main line content I'm delivering. I tag each example with what it's an example of, and point to the bibliography.

I think Myers-Briggs, NLP, and similar would be in this third, "stuff you should know about" category for a project management course. So would perhaps theory of constraints, some statistics, basic accounting, risk management (which has some statistics again) and probably a few other things. Personally, I tend to think everything requires skill with general systems (specifically feedback systems) but that's another digression. Any of these topics named could be necessary for the success of a given project, or supplementary, or merely interesting.

As an example of teaching some kind of PM stuff I'd be inclined to point out - PERT chart in hand - that all these effort estimates and completion dates are guesses. Then I'd ask:

"OK, so how do we figure out our actual completion date for the whole pile?"

All of the naive approaches, of course, fall down, which introduces the topic in the third, "stuff you ought to know about" category. Like this:

"OK, so dealing with guesses about measurements is called statistics, and <this solution here that someone said> is actually an example - it's a statistical technique. For our purposes, there are three observations.

• These estimates are guesses. So we had better know what we're going to do when things don't come out exactly the way we thought.
• If we really have to get more precise about some number, like the end-date we're going to get, there's a whole field that deals with this.
• We can't know that things aren't working out as we'd thought without getting stuff shipped from each task, small tasks, clear deliverables and expectations, etc. etc. etc.

So, all of the techniques I've been advocating for handling projects are in part tools to deal with the fact that our plans are guesses. And BTW, stuff happens outside the project, so what we don't know when we're doing planning isn't the only source of variability."

I also think it's real important - and I've finally learned to do this some of the time - to qualify the solution you are offering. "37 sure-fire project management techniques guaranteed to allow your dysfunctional self to make your dysfunctional team deliver in your dysfunctional organization" is a bad offer, I think. "Controlling projects to perfect predictability, without that icky people-stuff or any the least clue about the practices involved" is another.

Personally, I tend to offer lately:

• Exposure to some techniques that have worked pretty well in a domain. Examples are: General Systems for investigating Software Engineering or The three r's of Software Testing.
• Some perspective in a domain applying those techniques, and the opportunity to add to that perspective.
• Pointers to go further with the techniques described, and for investigating the related topics.
• Some entry points into the community of practitioners associated with whatever I'm offering. So: "Find the unit-testing people here . . . "

That's a pretty good checklist, actually. I'm going to keep that.

-- JimBullock, 2004.02.05 (Edits, cleanup.)

Re: NLP

NLP - Neuro Linguistic Programming - has the work of Virginia Satir as one of its early anticedents. So you, Johanna, have been exposed to some of the basic NLP observations and models through exposure to Satir stuff. For example, NLP "modalities" are Satir "sensory modes" more or less.

The biggest observation for doing projects from both Satir's work and NLP, is some variation on "People are not Computers." People engage in the world as these bundles of processes. They're complex inside. So you aren't necessarily going to get back what you expect from any given human, even with something as simple as saying: "Good morning." Any given human includes yourself. Your project skills, plans, and tools had better allow for that.

FWIW, I've been investigating NLP pretty intensively for about 2 years now via the extensive written canon and some other ways. It isn't an easy field to get a handle on in part because of the personalities, factions, local definitions, extremely varied domains of practice and so on. Kind of like "Software Engineering."

-- JimBullock, 2004.01.30 (Edits, 2004.02.05)

I would also add that finding out who the real players that affect the project is of first importance. In many ways the offical organization charts used by the customer and the project have little meaning to the final result or how the project has to be managed on a day to day basis.

CharlesAdams 2004.01.30

Too many people who have the title of PM seem to me to be project administrators.

Their primary role is keeper of lists and publisher of plans. Despite their PMI certification, they follow. And they manage nothing.

I would spend a large amount of time in simulations about how a PM detects the project owners who want an administrator rather than manager. And what to do about it.

The fundamental quality to teach is congruence. That's something that isn't taught in courses that put almost complete emphasis on analysis, especially around building a pretty project plan using MS Project.

I know a PM is in trouble when they are more interested in learning about MS Project than learning about the fundamental dynamics of working with other people.

Managers get their work done through other people rather than through MS Project.

SteveSmith 2004.01.31

SherryHeinze 2004.01.31

Too many people who have the title of PM seem to me to be project administrators.

Excellent point along with the rest of the contribution. One indicator of project administrator-ness is to create that title, or that bundle of tasks then have a conversation about that. I've done it, as an instance of the "can you give me an intern" ploy. "Can you give me an intern to keep the schedule up to date, manage the issues list and so on . . . " Flushes that right out.

-- JimBullock, 2004.01.31 (And nobody's ever successfully made me no more than a project administrator.)

I've learned that the "thank you" that goes with the "no" matters, especially when there's some kind of positional authority involved. It gently changes the conversation into a different conversation. Like this:

• "We've decided to assign the XYZ team to you. Congratulations."
• "No."

This can sound like bucking someone's authority. The conversation that follows easily ends up being about who gets to tell who what to do. This is better:

• "We've decided to assign the XYZ team to you. Congratulations."
• "No, thank you." or the Miss Manners variation: "Thank you, but no."

This makes the conversation sound more like what it is. You are being offered a new, bigger job. You don't have to take that job. You can decline the offer. Simply adding the "thank you" moves the transaction in the conversation from command / response, to offer / accept, without having to deconstruct the words, or negotiate "what is going on here." This puts defining the transaction as an order back where it belongs - on the person giving the order.

• "We've decided to assign the XYZ team to you. Congratulations." (An offer, not an order.)
• "Thank you, but no." (Declining that offer.)
• "What do you mean?" (This may be genuine, or may be a ploy to let you hook yourself.)
• "I just can't take on the XYZ team right now." (A reason is not required. Stick to simply declining. Don't explain. Don't generalize. The point is to leave defining what's going on here to the person who started the conversation.)
• <intermediate moves>
• "You don't get it, this isn't a request." (OK. Now you know.)

Of course in the better case moving the conversation into requesting and accepting the request leads to an agreed next step that's OK for everybody. Even if that isn't possible, it's good to know where you stand.

- JimBullock 2004.02.04

One possible improvement on the "no thank you" is to start with the congruence wheel (self-other-context) and complete the wheel by coming back to yourself--which is the final part. So, for example,

• "We've decided to assign the XYZ team to you. Congratulations."
  
  
  • "Wow, I'm truly honored that you place such trust in me. [self, then other] Unfortunately, I feel it wouldn't be good for the project if I took on that responsibility [context], so I'm going to have to decline. But thanks again for offering it to me."

- JerryWeinberg 2004.02.04

Out of sequence idea here. Sorry for the jolt.

One thing I'd be sure to teach new project managers is the set of schedule games being developed in the other thread. I'd be inclinded to make a sort of Devil's dictionary, with snappy memorable names.

-- JimBullock, 2002.02.05

I would teach new project managers not to take things personally, and how to encourage others not to take things personally. I'll try to be more specific later.

---Michael B.

Michael, when isn't it personal??? -- Johanna

Hmmmm. biggest problem I see is when a project begins with a good system and a good PM. However, good PM's get promoted at some point (always critical, Murphy's Law), and another person with different style is dropped into the project with no overlap with previous PM. Deadly!

John benton

Here's the WhatJohannaWouldTeachNewProjectManagers for those of you who are curious. I'd love comments. JohannaRothman 2004.03.09