Archive for July, 2009

What comes first: Good News or Bad News?

Published July 29, 2009 Darrell Stiffler Leave a Comment

How many times have we heard the expression “Do you want the good news or the bad news first?” It seems to be a common expression in both casual and professional conversation when reporting on previous events or gathering information of a subject. I feel like this phrase is not appropriate to use when presenting in a professional environment. Really, for that matter, it’s probably not a good idea in casual conversation either.

As a child, I was taught to present the bad news first – as was the generally accepted practice where I grew up (in the Midwest). To not present the bad news first would be like hiding something and not being forthright.  It was perceived as being dishonest not to state negative aspects first.

As I have traversed through the business world and observed successful people and not-so-successful people, I have come to the conclusion that forthright people should be admired. Being forthright is indeed a worthy goal. The world would be better off if this goal was widely pursued. However, the sequencing of delivering a report that I was taught growing up should be modified.  I would agree that not telling the negative aspects of a report would be deceiving and should never be practiced. However, with the question of which should be presented first, good news or bad news, I contend that, without doubt, the good news should be presented first.  Not only should the good news be presented first, but it should be punctuated with supporting artifacts, metrics, and testimonials. I don’t propose that success should be exaggerated, but it should be presented in the best possible light as long as the integrity of the information can be maintained.

People like to hear good news; however, it doesn’t seem to have the impact of bad news. When people hear bad news they seem to get stuck and are not receptive to the good news that follows. I’ve found managers, in particular, will get stuck trying to solve the problem presented in the negative news and will pay little attention to the positive news presented later. This is because managers typically are problem solvers, especially senior managers. They probably got to the position of senior manager because they could solve problems.

I have heard the old cliché, “Good news travels fast.” It seems to ring truer to me that, “Good news travels fast, but bad news travels faster.”  Chances are, if something negative happens on your project, the “word” has traveled up the grapevine and management has already heard the rumor. By presenting the well-documented good news first, it will lessen the impact of the bad news when presented.

Presenting good news before bad news also reinforces another time-tested cliché, “Always put your best foot forward.” Enjoy the good news as long as you can.

Now the good news is that this is the end of the article, the bad news is that there is still a lot of writing to go.

How do you prefer to give/receive news? Good or bad news first?

From Darrell Stiffler

Strategies for Making Meetings Shorter

Published July 28, 2009 Brian Egan 2 Comments

How can we encourage meetings to be as short as possible while still getting everything done?
What everyone wants is a meeting in which everyone arrives on time and remains focused on the agenda items – but how do we get that? Here are a few tactics you might try:

Remove All the Chairs
Some innovative companies have removed all the chairs from their meeting rooms. This way, when you arrive for your meeting, you can’t settle in for a long stay. Meetings become shorter (to last as long as people can stand), and are probably more focused on important items because of the obvious time limitations.

This is not a bad technique. It’s simple, equitable (in that everyone is treated the same), and easy to put into place. But can all meetings be limited to the length of time that people can stand? What happens if you have a sore back?

I have not heard how effective this technique is at making meetings shorter while maximizing productivity, but it seems like a good idea. Certainly the message from management about the duration of meetings is clear.

Schedule a Room for Specific Time Frames
Another technique that is commonly used, either by design or by accident, is to put time restrictions on access to meeting rooms. If you know you are going to be booted out at a scheduled time, chances are you will remain focused.

Unfortunately, this technique does not prevent someone from reserving the rooms for a generous amount of time (that they may or may not need) or a senior manager commandeering a room indefinitely for “something important.”

Also, if meeting rooms are going to be managed as a scarce resource, then a coordinator should be required to police their use.
Continue reading ‘Strategies for Making Meetings Shorter’

A Project Management Glossary of Terms

Published July 21, 2009 Brian Egan Leave a Comment

I have come across a website gem. It is written by an academic, Max Wideman, who works in the field of management science, and it’s packed with project management wisdom.
Of particular interest is the “PM Glossary,” which is in its fifth version. This glossary offers a huge amount of information, all properly indexed and cross referenced, on the definitions of terms and words used in project management. It is really amazing. You have to wonder what motivated the guy to write it.

Every project manager should have this glossary in their list of favorites. You can buy copies, of course, but you don’t  need to if you are willing to work online.

After stumbling across the site, I found myself just looking up terms to see what the definition would be. The writing is clear, the format intuitive and there are plenty of links to related information.

On the same site are various articles and other project management-related stuff. My favorite part is the glossary, but I am definitely going to go back and have a second look.

From Brian Egan

Editor’s note: This is not a sponsored post, and Mr. Wideman’s site is not affiliated with Global Knowledge.

Scope Management Does Not Mean Scope Stoppage

Published July 15, 2009 Vicki Wrona 1 Comment

This is Part 1 of a 2-part post.

I would like to address what seems to be a common misunderstanding regarding the term “scope creep.”

I read a recent question posted by a LinkedIn colleague titled “Why do so many project managers think scope management means scope oppression?” I like the question this post raises. I agree with the premise of her post, which is that we need to anticipate and expect change, and while it is our job as PMs to have a recommendation regarding the requested scope change, it is management who ultimately decides if the time and cost impact is worth taking to make the requested change to scope.

However, I disagree with one point made. This may be an issue of semantics, but I want to make sure we are all on the same page. The author says that “scope control has been described (incorrectly) by some PMs as ‘eliminate scope creep’.” Given the agreement from the responses she received, this seems to be a commonly misunderstood concept.

The misunderstanding relates to a different understanding of  scope creep. I had learned, and continue to teach in my classes, that scope creep results from adding unapproved changes. According to Wikipedia, scope creep “refers to uncontrolled changes in a project’s scope.” Controlled changes are fine. But we do want to stop uncontrolled changes.

I agree with her that, unfortunately, when we talk about scope management with stakeholders, they (and too many PMs) only picture the negative and not the positive aspect of this. They see their future requests being denied rather than PMs better managing the scope so the project can be delivered successfully. Nobody likes to be forced to define everything up front, because they often don’t know exactly what they want and do not want to limit their ability to change their mind in the future.

We have to take on a more healthy approach, letting stakeholders know that changes will be allowed if they make sense given our objectives and constraints. I don’t want to stop *all* changes. That is unhealthy. But I do want to eliminate changes that shouldn’t be made, or in other words, scope creep. Our job is to manage changes so they are for the good of the project.

Project success is defined as delivering a project on time, on budget, and within scope. This includes the original plan PLUS approved changes. We are not locked-in to all of the original estimates.

There is no expectation (on my projects) that change won’t happen, because as we all know that is not reality. The idea is to manage it for the good of the project – accepting some changes (where they make sense) and denying others that are deemed to be out of scope. I work with my teams to phrase scope management in a positive way, and I make it clear up front that I know changes will occur and it is our responsibility to help control them so we can deliver to the real constraints, which are normally budget and time.

I will continue this thought in my next post.

From Vicki Wrona

Process Review

Published July 13, 2009 David Egan 1 Comment

I was recently in a position to review the processes in a large institutional setting, and I found most of them to be too rigid. By this, I mean that a specific process was only initiated if a certain error or client issue was seen or observed. I also found that there were a few instances where what seemed like an obvious data collection option was completely skipped. For example, they had numbers for all the processes but not for one seemingly obvious case. When I asked about this data analysis, the answer was a well-rehearsed, ‘We usually do not record that data.’

It seems that we get comfortable in our daily business processes and do not always consider something obvious that other eyes might see.

I am going to suggest that you go find some outside eyes and have them do an evaluation of your current process steps for the various processes that you normally do in a day: print documents, collect data, use supplies, replenish supplies…whatever you do.

One thing I recommended is the simple idea of date stamping your work so that if someone else has to take your place or relieve you, they do not have to go find the data. It might save a few supplies, and every reduction in waste is worth striving for in our society and current economic environment.

Step back and  review the processes for how you do certain things. See if they still make sense, especially for really old processes and any relatively new ones.

From David Egan

Meetings: Encouraging Punctuality

Published July 10, 2009 Brian Egan Leave a Comment

Everyone is busy. There are lots of meetings and always too much to do. The questions is how can we encourage people to take meetings seriously and arrive on time so that the meeting has a chance of ending on time? What are some of the positive steps we can take to encourage punctuality?

Firm Commitment

“This meeting will end one hour after everyone is present. Please be on time so that we can finish on time.” Nothing works better than saying what’s in it for them. Explain how being punctual will benefit everyone.

If you make this commitment, be sure to live up to it. End the meeting when you are scheduled to end. Do not run over for any reason.

Treats

Reward punctual arrival. Have gourmet coffee available up to the time that the meeting is scheduled to begin. Let all participants know what special treats will be available and when. Scheduling a 15 minute break (with treats) before a meeting is a surprisingly effective way to get people to attend meetings on time – or even early. It also allows for social exchanges to be completed prior to the meeting, and it can improve the efficiency of the meeting that follows. The only trick is to prevent freeloaders from joining in.

Reciprocal Behavior

Treat others the way you would like to be treated. Attend other peoples’ meetings on time when they do the same for you. Do not keep your strategy a secret. Let your team members know whose meetings you feel obliged to attend on time, whose are less important to you, and why. Reward the behavior that you want to encourage.

Feedback

The most basic and consistently effective motivation appears to be positive feedback in the form of simply showing appreciation. Tell others who arrived on time that you appreciate them doing so. Thank them individually.

During my review of meeting management practices, the topic of feedback (positive and negative) came up time and again. In most organizations there is no feedback for meeting participants other than negative comments about bad behaviors. In those rare cases where meeting managers took the time to provide positive feedback, there was a markedly higher level of future cooperation. Saying “thank you” actually seems to work.

Conclusion

What is the message here? Should every meeting have a budget for gourmet coffee and biscuits? It would be nice, but it is probably not practical. The message is that a reward of some kind is necessary. The reward does not have to be food. It does not have to be money. But there does need to be some reward for arriving at meetings on time, or else people won’t. The most effective and least expensive form of reward appears to be positive feedback.

We all know how busy everyone is, how many others things they could be doing, the million good reasons they could have for being late. Thank them for being punctual. And then do the same for them – attend their meetings on time.

From Brian Egan

What is the Project Management Life Cycle

Published July 6, 2009 Darrell Stiffler 4 Comments

The term “Project Management Life Cycle” is not mentioned in either A Guide to the Project Management Body of Knowledge (PMBOK®) 2000 or the PMBOK Guide-3rd Edition. In the PMBOK Guide-4th Edition, the term is used only once. On page 3 it states, “The PMBOK Guide provides guidelines for managing individual projects. It defines project management and related concepts and describes the project management life cycle and the related process.” However, the PMBOK Guide does not define what the term “Project Management Life Cycle” means.

What is mentioned in all three PMBOKs referenced here is “Project Management Process Groups.”  The PMBOK 2000  mentions 5 Process Groups:

  • Initiating
  • Planning
  • Executing
  • Controlling
  • Closing.

Note it does not mention Monitoring. The PMBOK Guide-3rd Edition, on page 38, lists the Project Management Process Groups as:

  • Initiating
  • Planning
  • Executing
  • Monitoring
  • Controlling
  • Closing

The PMBOK Guide-4th Edition lists the same Process Groups (page 6).

So where did the term “Project Management Life Cycle” come from? I really don’t have a good answer for that. I have heard and read about the term for more than 10 years now, and I have always assumed it would fall into the category of “Best Practices.”  Best Practices seems to be a good term to use when you don’t have a good justification for a term.  :)

I did a Google search for “Project Management Life Cycle” and found a few entries I thought were interesting. There is a Project Management software company out of New Zealand that is big on the term. However, contrary to the PMBOK, the software company states that there are only 4 phases: Initiation, Planning, Execution and Closure. The State of New York has a different view of Project Management Life Cycle, which includes Origination, Initiation, Planning, Execution, and Closure.  This is consistent with the PMBOK Government extension.

Many Global Knowledge courses teach the Project Management Life Cycle.  The courses teach that the Project Management Life Cycle is the same as the Process Groups. In the PMP Exam Prep Boot Camp when it was based on 3rd Edition PMBOK, as well as other Project Management courses, they used the acronym IPECC. That seems to work pretty well for teaching the concept. Now that the PMP Exam Prep Boot Camp is based on the PMBOK Guide-4th Edition, they use a different acronym of IPECaC.  This is a new acronym to me, but I understand it has been around for a while. I kind of like IPECC, because I am accustomed to it.  I mean, if you want to get really accurate on the acronym why not name it IPEM/CaC? But that seems a little silly.

The Project Management Life Cycle is very important and should be taught. I think the Project Management Institute should be more specific and define exactly what it represents, eliminating the confusion in the industry. Trying to absorb all of the knowledge in the PMBOK is difficult enough without adding to the confusion.

From Darrell Stiffler

Subscribe in a reader

Subscribe by Email

Follow us on Twitter

Author Archives