Tag Archives: Communication

The Good News is YOU have BAD News

It is going to happen. You will have to deliver bad news. Not all of your projects are going to run perfectly. When they don’t you want to do a good job delivering bad news. How you deliver the news can make all of the difference in the world in terms of what happens next, how you are perceived as a leader and the strength of your professional relationships.

Consider the following scenario and then take the short quiz on how you will react. You have just learned that a key customer is putting all future project work with your company on hold. This customer contributed 25% of your organizations earnings for the next six months. This news is very upsetting to you and it will be upsetting to your management as well.

1. What is the first thing you do:

A. Text your manager that you have bad news and that you need to talk ASAP.

B. Take the afternoon off and get a massage or meditate to calm yourself down.

C. Take some time to process this information yourself and then schedule time with your manager for a discussion.

D. Do nothing and wait for a few days, perhaps the customer will decide to continue with future purchases as planned.

2. As you prepare to deliver the news you decide to present three other very good ideas for projects with other customers, all of which have the potential to bring in new business within the next few months. This is an example of:

A. You overstepping your boundaries as you are not in charge of proposing project ideas.

B. You bringing solutions while communicating bad news.

C. You trying to deflect the bad news with other potentially good news.

D. You tying to protect your job and earn your next promotion.

3. Before you begin to discuss the bad news about the customer and the now on hold projects, you decide you want to say something positive so you say to your manager:

A. “You can really tell that you have been working out.”

B.”Good news, we can cut back on overtime.”

C. “Soon we will not have to deal with one of our most demanding customers.”

D. Nothing, you do not have an appropriate positive comment to make.

4. The truth is that although the news about the customer is upsetting, you are about to give notice, so you are not that concerned. Despite this you say to your manager

A. “I can see where this is very upsetting for you.”

B. “I don’t know about you, but this is devastating to me.”

C. “Maybe this is the wake up call we needed.”

D. “I will leave you alone to start coming up with solutions.”

5. You happen to see your manager walking to the cafeteria. You decide to:

A. Tell her the bad news as you walk with her to the cafeteria.

B. Advise her that you have scheduled some time with her that afternoon.

C. Approach her at the crowded sandwich station and tell her the news.

D. Follow her to her table in the cafeteria and tell her while she eats.

Looking forward to reading your thoughts. Be sure to read next week when we discuss the answers and take a closer look at how to present bad news at work. In the meantime if you would like to learn more and earn a PDU check out ‘How to Deliver Difficult News’ over on eLearning4PMs.com, there is an audio version: http://elearning4pms.com/how-to-deliver-difficult-news-audio-program/ and a video version: http://elearning4pms.com/how-to-deliver-difficult-news/

How to Handle a Project Management Crisis

Please welcome guest blogger Helen Sabell who shares with us some very helpful tips on how to handle a project management crisis:

When a project hits a roadblock the entire team can go into crisis mode. Alarm bells will ring, coworkers will panic and the stakeholders will turn to you, the project manager. Being able to handle sensitive situations with a time-conscious, solution-based approach is the key to success in this role.

A project manager will use a variety of approaches during periods of high-pressure to ensure that the team remains motivated and engaged, ultimately driving the project forward. Check out these 5 tips for successfully handling your next project management crisis.

Notice The Early Signs

Even challenges that appear to have come out of the blue can have warning signs and taking notice of these will make or break the project deadline. Staying aware of rumours, following statistics closely and identifying even minor stakeholder concerns are sure-fast ways to keep on top of a problem. Turning your back on an issue, no matter how small it begins, will only leave it to grow bigger while you aren’t looking.

Communicate With Your Team

It is important for a project manager to lead by example during a crisis and communicate clearly with the entire team. Open communication actively drives away any confusion and doubt, keeping workers updated with changes as they happen. Even established professionals can panic and become negative under mounting pressure – it is up to the project manager to enforce a positive and focused outlook at all times to help manage stress.

Update With The Bad

While nobody ever likes to hear more bad news during a time of crisis, being realistic with your team will help to ensure that the expectations are clear. It is important for a project manager to be unafraid of delivering issues to stakeholders and highlighting when a problem is urgent. It goes without saying that they will appreciate being kept in the loop and working alongside a professional team that is honest and trustworthy.

Be Solution-Focused

Focusing on understanding the cause of the problem will bring you much closer to finding a solution than passing blame, which could bring the project to a standstill. Facilitating negative communication will have no gain for you or your co-workers. A leading project manager will need to work tirelessly to ensure their teams stay positive and enthusiastic in searching for a solution.

Prevention Is Better Than Cure

The only thing better than a quick, effective solution is for there to be no problem to solve in the first place. Eliminating any chance of a crisis before it can occur requires excellent communication, in-depth research and a fine attention to detail. Of course, there will always be situations that cannot be foreseen and in such cases, a project manager should use the challenge as a chance to excel and ensure the same issue does not happen again.

Author Bio

Helen Sabell works for the College for Adult Learning, she is passionate about adult learning and the education of project management. She has designed, developed and authored many workplace leadership and training programs, both in Australia and overseas.

Why Do They Ignore My Email?

If you are asking yourself this question, I’m here to help.

You Are Frustrated

You have been sending your team email for a long time.? Some people on the team are good at responding and others…well let’s just say they don’t seem to be as “on top of it”.

by Mzelle Biscotte via Flickr

You were talking about a specific topic in a meeting, and half the room didn’t know what you were talking about.? “Didn’t you get my email?” you chided in frustration.? What’s wrong here?

How Can I Make Them Read My Email?

You can’t.

And you’re going about this the wrong way.? The problem is you, not them.

Email can be great for certain types of communication, but in my opinion it is an overused means of communicating, especially when so many of us have the option to walk over or get on the phone and talk to someone directly.? It can be a great method of communicating when the needs are asynchronous and when people are disconnected geographically, but in general it gets overused in my experience.

I have been guilty myself of not fitting the communication channel to the situation.

Email is Easy

For some people, sitting down in front of a computer and typing an email is much easier than walking across the hall to chat with a co-worker.? This can be especially true when the topic is charged, or if you are in conflict with the person on the other end.? Ironically, these are the times when it’s most important to not rely on email, because the power of direct communication is often the best way to resolve issues of any kind.

Pareto’s Email

It’s likely that 80% of email in organizations is ineffective and would be better served via a face-to-face or phone conversation.? The categories of email that may pass as prudent include sending meeting agendas and minutes, sending files, and when you are on totally separate schedules from those with which you want to communicate.? It could be argued that there are better means of collaboration and communication even in these cases too.

The Missing Feedback Loop

One of the biggest problems I see with email is a missing feedback loop.? If you are chatting with someone you can make sure they understood you, and that you understood them.? Tones of voice and body language play a role and more information is communicated.

With email, a vast chunk of it goes out and the author assumes everyone who was on the list 1) read it, 2) understood fully, and 3) cares about what you had to say.? It’s the “silence is golden” philosophy which, in my opinion, is a bad philosophy.

What do you think?

Making status meetings fun is possible – yes, I promise!

add fun to meeting room

add fun to the meeting room

This post was originally posted in Go Ahead, Manage.

Regular status meetings are boring: everyone goes around the table and rehashes what they did in the last week or month. No one really cares. If the project dates are slipping, the team wants the meeting to be over with so they can get back to doing something useful.

But status meetings can be fun!

Yes, I know, it’s a strange concept. But I’ve seen it happen. I was doing documentation on a software development team. The team was implementing agile development practices, and they were planning to do a release every month. This meant a big meeting with marketing, sales, the whole development team.

It was important for the project lead to include the whole company in that project. She felt that it would bring the two worlds of development and marketing/sales together, that it would help people understand the other side.

Since everyone had things to do in the project, I suggested that we make something visual, like a board, to monitor out progress. The rest of the team thought I was crazy, they humored me. So I built this huge board and pasted a giant photograph on it. It was about the size of 6 letter-sized pages. Then I cut out squares of colorful cardboard and pinned them over the picture, so I was the only one who knew what was behind the cardboard.

Each one of those pieces of cardboard corresponded to a task in the project. It could be a feature, or finishing documentation, and even the first sale was there. So developers, marketers and sales reps all had at least a square or two to “unpin” from the board. The first month, when we did the first “unpinning,” people thought it was really lame and corny.

But something happened.

People kept their pieces of cardboard and pinned them on the walls of their cubicles. Those pieces of yellow and purple cardboard became trophies.

On the second monthly meeting, people were clapping those who got to “unpin” and there was a feeling of pride in the room. The board was displayed at the entrance of the R&D department. It gave a very visual impression of how far along the project was.

And so people came to like those status meetings.

Making status meetings fun means changing how it’s done

Status meetings should not be just about reporting what happened. They should be about accomplishment. They should be there to reward the people who did good, and motivate those who are having difficulties.

If no one wants to go to the meeting, what’s the point of having the meeting?

Successful Projects: It’s Not Rocket Science

Project Management is not rocket science

Project Management is not rocket science

There is no worse person to be than the project manager at the end of a failed project. As an IT project manager, I have experienced that feeling and I can tell you it’s not nice. IT projects are particularly difficult to manage. In fact there really aren’t any IT projects, just projects that have elements of IT in them.

The trouble with these projects is that often you are doing something that hasn’t been done before, is unproven or cutting edge. Customers expect a good result not excuses, even though these projects are frequently a journey into the unknown. If we take the construction industry, building a new bridge for instance, we have been building bridges for hundreds of years and know how to do it. We understand how things are going to happen, in what order and the expected result. This is rarely the case with IT projects.

Avoiding the common pitfalls of IT project management is not rocket science, it is simply a case of taking some sensible measures. Identified here are five killer mistakes of project management:

Who Owns the Project?

The Mistake:

The nature of projects is change and change often encounters resistance. People don’t like change so they need to know it is necessary and what benefits it will bring. In order for a project to deliver change it needs the backing of senior management. Without it the project will proceed very slowly. The sponsor (senior management) is the person that drives the change forward and the project is the mechanism for change. A project without support from senior management will struggle.

The Solution:

Make sure you have the top down backing from senior management. There must be direct communication from the sponsor to the stakeholders. The message must be, “we are serious, this thing is going to happen so you are either with us or you are not” and beware those that are not.

Be careful as project manager to make sure the sponsor does not take the project over and become the de-facto project manager.

Getting Users Involved

The Mistake:

Lack of user input and involvement is the recipe for a bad project. This can either be because of the “we know what you want” mentality from the IT department or lack of interest from the customer. Either way it must be avoided.

The Solution:

The IT department must take time to understand the customers requirements before proposing any technical solution. Often IT is blinded by the latest, newest thing available and try to shoehorn the requirements into it. On the other hand, customers must devote the time and effort necessary to ensure a successful project by interacting with the IT department and making sure all requirements have been fully defined. Ensure you have spoken to all stakeholders to gathered their requirements and that they continue to work with you for the duration of the project.

Stopping Scope Creep

The Mistake:

Scope creep is the cause of more project failures than anything else. Not knowing exactly what a project is aiming to deliver or setting off in a fit of enthusiasm but little else, is a recipe for failure.

The Solution:

Ensure that the business case, requirements and scope are clearly defined and documented. Make sure the stakeholders understand them and sign them off. Stick rigidly to the scope and if changes are required then put them through a change management process where they are documented, justified and then agreed.

Managing Expectations

The Mistake:

Often there is an expectation that IT is like a magic wand you wave and suddenly a miracle occurs. During a technology project expectations can inflate to a ridiculous degree. It is the role of the project manager to manage expectations to a sensible level.

The Solution:

One way to avoid this is to break a project into smaller pieces or phases. I equate this to a sausage machine, where you feed in the raw material at one end and out it comes as small, perfectly formed, packages or sausages at the other end. The same can happen with IT projects where you take small packages of requirements and push them through the machine, producing several deliverables over the life of a project. This way you manage expectations by making frequent deliveries to demonstrate what the technology can really deliver. This approach ensures the project delivers to the customers expectations by giving them early visibility of what you are building.

Understanding the Lingo

The Mistake:

Have you ever stood next to a group of IT professionals and wondered what on earth they were talking about. It is like a whole new language and to non-IT people it often is. The pitfall comes when the customer and IT think they are talking the same language when in fact they are not. This leads to a problem when the IT department delivers what they understood the customer wanted and it turns out to be something different.

The Solution:

Communication problems are the hardest to resolve as often it is only looking back that the problem is identified. Regular communication and a close working relationship with the customer will help. What you really need is a person with a foot in both camps. Someone who understands the business and the IT equally well. If you can identify this person make sure you keep hold of them, they are hugely valuable. If you are unable to find this person, the next best option is to have two people, one from the business and one from IT. By working closely together and sharing information they can minimise any communication problems.


In 1995 The Standish Group surveyed IT executive managers for their opinions about why projects succeed. The three major reasons given that a project will succeed are user involvement, executive management support, and a clear statement of requirements. Concentrating on these three aspects alone will give your project a good chance of success.

Don’t become the victim of a failed project, put measures in place that will ensure your success. After all it’s not rocket science!

Read more about IT Project Management

The Curse of Knowledge in Project Management

Made To Stick

Made To Stick

It delights me every time I discover a way that the world of knowledge available to human kind is applicable across disciplines.

Granted, the book Made to Stick which I am reading right now is intended to apply as a guideline without any particular discipline in mind, only communication and retention of ideas in general.

While driving to work one day, I realized how the ideas can and should apply to project status meetings. There are usually specific points that you want to highlight with those in the room, be they the sponsor, project team, customer, etc. You may want different ideas to stick with different groups of people, too. This book is all about how to craft and present ideas to make them stick.

Let’s say you have a particular risk on your project that is looking like it may be a big issue, and you are asking for your sponsor’s help in mitigating or preparing for it. If that is the biggest issue for your sponsor to help with, you want the risk and what they can do to help to stick with them, and make it a dominant thought when they leave the meeting. Whenever they think of your project, they should associate it with that risk they need to help with.

OK, so now you are holding a status meeting with your team. You want to review progress over the last period, talk about what is happening now and coming up, and make sure everyone is away of risks that could impact their work. This is an opportunity to recognize people for their accomplishments, and it would be very helpful if the idea that “this project manager appreciates our effort, and recognizes us for it” sticks with them. You also may want to pick out a few key milestones that everyone is working towards, and major risks they should look out for so you can be notified as early as possible if something comes up.

With every example you care to come up with, it is important how you craft and present the message. There are many techniques described in the book, relating to the content of the message itself, associations, and many other helpful principles.

Project Blame Management

John called up Miles after the conference call to commensurate on the hopelessness of the situation.? “So what did you think of all that?”

Miles was miffed too.? “I have no idea.? The director talks about our project as if he’s doing it, and it’s the greatest thing since sliced bread.”

“Tell me about it.”? John replied.? “But from what I can tell, the other group has no idea or direction for what they are doing.? I have no idea how what they are doing is supposed to work with the tool you and I are working on.”

Project Blame Management

Project Blame Management

“Me neither.? I know the tool you and I are building will be useful for everyone, but the restructuring on their end seems to not really be providing any value.? Did anyone calculate the ROI on that?? They have about 20 to 30 people taking up a ton of time.? What for?”

John sighed.? “Oh well, let’s just keep our noses to the grindstone and make sure our part is good.? Even if the whole thing fails, at least they won’t be able to point the finger at us.”

“Are you sure we shouldn’t let the director know about this?? Maybe he’s oblivious to the whole thing going on over there.”

“Na, besides, we already told Brian.? We’ll just get in trouble if we go above our manager’s head.? Brian knows what is going on, and he’ll have our back when this thing comes crashing down.? Our department is doing everything we can.”

Does this sort of scenario seem strangely familiar?? If not, excellent!? Too many project teams suffer from this sort of silo mentality, where incentives can run counter to the good of the project as a whole.? When communication amounts to telling them what they want to hear in meetings, then conversations like this occur later on, you know you have a troubled project.

Survey Project Teams for Feedback: Video Blog

This is my first video blog, it is a screen capture where I expand on a post I made earlier about using a monthly team barometer to gauge how things are going on your project, and get honest feedback.? I show you exactly how to sign up for an account at polldaddy.com and I set up a sample post with 3 targeted questions for your project team.? Let me know what you think about this format of post!

Catching People Doing Things Right

I had a stimulating discussion today with Travis, a friend and colleague about communication styles. It reminded me about the importance of catching people doing things right. Many managers and co-workers miss opportunities to congratulate or thank people who go above and beyond, but rarely miss an opportunity to criticize when mistakes are made.

Here are some guidelines I try to live by, and am very thankful to have been reminded of so I can re-focus:

  • Make a concerted effort to recognize when a colleague or employee went above and beyond to help you, or did an outstanding job on something
  • Evaluate the situation
    • Was it a good example of excellence?
    • Is it appropriate for you to give feedback? Would it be welcome?
    • Do you know enough about it to describe exactly why they went above and beyond?
    • Are you sincerely impressed with the example?
  • Give sincere feedback
    • Use the proper channel
      • Face to face is usually best
      • Sometimes an email to their manager may be appropriate
      • Other times just stopping by and expressing your sentiments is best
      • Public is usually best
    • Use the proper timing – immediate is usually best
  • Give credit where credit is due
    • Acknowledge the efforts of individuals where possible when discussing an effort or result. Make a point to let everyone know who did great work, by name.

Sincerity is key. If you do this every day, or for mundane things, people will see right through your lack of sincerity. Only acknowledge people for going above and beyond when they actually and obviously went above and beyond.

How about this for an exercise? When you’re chatting with people at the water cooler or at lunch, instead of talking about how frustrated you are with John Doe, talk about how Jane Doe did an outstanding job on that presentation.

Critical Chain Benefits From Traditional PM

Today I was trying to think of ways to integrate some of the methods and benefits of Critical Chain project management into the traditional PM methodology most companies use. I wanted to pick out one element of CC that would potentially yield the most benefit without much, if any, additional overhead to the project manager. Perhaps this has been written of before, but I haven’t come across it. Most of the CC proponents I’ve come across have an all-or-nothing mentality, so they wouldn’t normally write about this kind of hybrid approach. Here’s what I came up with.

Parkinson’s Law

One of the deadliest risks for slipping on schedule is Parkinson’s Law, “Work expands to fill (and often exceed) the time allowed”. I don’t believe that people on the project are lying around doing nothing because they think they have so much time (like a student might). Instead, people may be doing extra analysis and working on some ideas that might yield truly useful features. Having worked as a developer in a project environment, I can say with honesty that my co-workers and I did this a lot. We were well-intentioned, and we did good work. However, I can also safely say that many of the things we worked on didn’t address a specific customer requirement. They were nice little experiments, and developers love experiments.

The difficulty in managing projects is related to finite resources, time, and budget. Effort which addresses stakeholder requirements directly yield the most value, in that they are fulfilling what you promised. Those deliverables should be addressed first and foremost. If you have time left over, then I’d say it might be OK to work on nice little experiments that may add value.

How can you ensure resources are working on the ‘meat’ before they spend time on desert? I don’t suggest micro-management. That is self-defeating, demoralizing to the staff, and time-consuming.

The Method

Instead, let’s inject a critical chain technique into how you manage this project. Estimates on tasks are usually inflated to allow for slack time in the eye of the estimator. Let’s take the CC method of removing slack and creating a buffer, and apply it to only the lower levels, either on individual tasks or series of tasks. Take the scheduled time and chop off the last 20% of it. (I wouldn’t bother with anything less than 40 hours in duration) This is now your deadline, and the time afterwards until the “official” deadline is the management buffer. Keep communication with the team open and honest, let them know what you are doing. Their goal now is to get the task done by the new due date. If they are done by then, they can spend some time doing “Google-ish” creative brainstorming and experimentation. If not, that’s when the project manager becomes more heavily involved than normal, helping to remove roadblocks and provide more resources. Of course, the PM should be doing this all along, but now is the time to redouble your efforts. It’s important to let the team know that if they go over this deadline, it’s not the end of the world. It shouldn’t even be a negative thing. It’s just an early alert system, and everyone should know ahead of time that there’s just as much chance of going over this deadline as their is hitting it on time or early. Keep the critical path in mind with your decisions, you may have to let a non-critical path task slide to address a critical one.

By managing the tasks this way, resources are compelled to knock out the things that lead to a specified deliverable first, and add the most value. It doesn’t require adjusting the official schedules, or introduce paperwork overhead. This is simply a management technique.

As a solo developer or on a team, I think it would be great to “eat our frogs first” and then either start the next task early, or have a few days to brainstorm about what we can do to add even more value. Working with a team for a short time with a blank canvas, you can pool the skills and do some great team building while generating some really creative stuff. You could also do additional testing and debugging, or start looking at the next task early and brainstorm about the best way to go about it. Or, a little of everything. Let the ones who like engineering do things to fix bugs, enhance the documentation, and make it scale better. Let the prototypers do their thing.


  • Understand CC buffer management and the benefits of it (links below)
  • Get your team on board by showing them the WIIFM (what’s in it for me?)
  • Keep the critical path tasks in mind for decision making
  • For tasks 40 hours or longer:
    • Create a CC deadline by chopping off the last 20% of time from a scheduled task
    • The last 20% is now a management buffer
    • Check status at the CC deadline
      • Not complete: Focus support efforts on the task
      • Complete: Start the next task early, or have a “Google day”!

For some background on Critical Chain and it’s benefits, here are some references for you. Specifically, you need to understand why you’re doing this well enough to get your team to believe in it too. This probably won’t work well with totalitarian rule.

The PM Podcast Episode #57
Focused Performance
The Critical Chain Yahoo Group
Critical Chain and the Design Process – MIT
CC whitepaper from Boeing
More case studies
Yet another case study