How to Kill a Project? Don’t Ask, Don’t Tell!

June 1, 2010 | Author: PM Hut | Filed under: Uncategorized

How to Kill a Project? Don’t Ask, Don’t Tell!
By Bernadette St. John

With Don’t Ask, Don’t Tell in the news these days, I was thinking about what would happen if we applied such a policy to projects. I can’t think of a better way to ensure defeat. Or, to focus on the corollary, I think good communication is the best way to achieve project success.

Nothing earth shattering here. PMBOK tells us a project manager should spend most of her time communicating. But are you digging deep enough? Let’s say we have a project to develop a software product for a business application. For simplicity’s sake, let’s assume the project team includes people developing the software and the people who will use it (the business). Let’s also assume the project is well underway and we are getting ready for a prototype review next week.

The project manager calls the development lead and asks if we’re on track for the prototype review. “Sure, no problem” says the lead, thinking … or at least no problem I can’t figure out prior to the review. The project manager calls the business lead and asks if his team is ready for the prototype review. “Sure, all set” says the lead, thinking… I have a dozen things I need to do for my real job before then, I’ll worry about the prototype next week. Next week comes and the prototype is a flop. Functionality doesn’t work, key players are missing, expectations are not met and the project manager is scratching her head.

Needless to say, the communication was inadequate. More effective communication with the development lead would have included:

  • A review of the planned functionality and the following questions:
    • Is there any functionality that is not ready now?
    • Why isn’t it ready? Technical issues, timing, etc.
    • How confident are you that it will be ready next week?
    • What is the contingency plan?
    • What functionality will not be ready next week?
  • Discussion of any unexpected issues that arose while preparing the prototype
  • Identification of key areas that development needs specific business input on
  • Etc.

More effective communication with the business lead would have included:

  • A review of the expected attendees and the following questions:
    • Have key participants confirmed their attendance?
    • If a key participant can’t attend, is there someone who can adequately represent them?
    • Will there be someone who can speak for the business on all areas identified by development as needing input?
  • A heads up on the status of expected functionality. If it is not all ready, a review of the contingency plan. The business lead may not be happy, but at least he will have the correct expectation going into the prototype review and can focus on what is there, not on what is missing.
  • Review of functionality prioritization so that the review session can be structured to ensure adequate attention is given to the most important items and to accommodate schedules if everyone does not need to participate in the full review.
  • Etc.

You get the picture. With everyone having so much to do, it is tempting to accept an “everything’s fine” response and hope for the best. But to really be sure, you need to ask deep questions, be open to bad news, keep all parties informed and constantly confirm expectations. Ask, Tell, Rinse and Repeat.

Bernadette St. John is the Director of Digital Media for Questex Media Group, a global business-to-business integrated media and information provider, headquartered in Newton, MA. Bernadette is responsible for the project management and operations functions of the Digital Media Group. Bernadette has 10+ years of project management and software development management experience and is a member of the Mass Bay chapter of the Project Management Institute. Bernadette maintains Bernadette’s blog, a professional blog where she writes about Project Management.

Share this article:
  • Facebook
  • LinkedIn
  • TwitThis

No comments yet.

feel free to leave a comment

Comment Guidelines: Basic XHTML is allowed (a href, strong, em, code). All line breaks and paragraphs are automatically generated. Off-topic or inappropriate comments will be edited or deleted. Email addresses will never be published. Keep it PG-13 people!

XHTML: You can use these tags: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>

All fields marked with " * " are required.

The Stevens Enterprise Project Management Master's Program

Project Management Categories