« Reporting And Meetings in Project Management
Scope Verification - Project Closure »

Decreasing Project Completion Time

November 10, 2009 | Author: PM Hut | Filed under: Miscellaneous

Decreasing Project Completion Time
By Johanna Rothman

Many organizations have a minimum project duration. They can’t complete a project in less than some number of weeks or months. They take some time to start up a project and some (usually longer) time to finish the product. Typically, long startup times are a problem of decision-making, lifecycle choice, and requirements definition. In this article I’ll address start up problems.

  1. If it seems as if your projects never get started, you may have a problem with long decision-making. Make sure your decision-making includes all of these steps:
    • Defining the desired outcome, such as ranking the projects in order
    • Establishing the boundaries around the decision, such as chartering analysis of the projects and including who will make the final decision
    • Identifying the options, so that the group can make a decision
    • Selecting from among options, including identifying the decision criteria
    • Implementing the decision

    Senior management teams may have trouble determining the strategic outcome they desire. I’ve worked with some management teams who had trouble defining the boundaries around their decisions. Some management teams have trouble identifying the options. More teams have trouble selecting from among the options and may try to partially fund all the projects, thinking that some progress on all projects is better than funding some projects and not funding others.

    The most frequent problem I’ve seen in management teams is the inability to decide among projects. If your organization has trouble with this, I recommend you use the pairwise comparison technique: Looking at these two projects, which project do you want more than the other? Compare all the projects to each other, and you’ll end with a ranking of all the projects.

  2. If your management team is able to rank and select which projects to work on when, check on your lifecycle choice. Different lifecycles allow you to start or end more quickly, based on how well they help you manage technical and schedule risk:

    • Serial lifecycles (such as waterfall) don’t manage either technical risk or schedule risk well. They are easier to schedule. Serial lifecycle projects tend to take more time than other projects.
    • Cyclical lifecycles (such as spiral) manage technical risk well. Cyclical lifecycles have a built-in schedule risk. If the project team does not define what done means for the project, it’s possible to have cycle after cycle after cycle (and on) with no product to show.
    • Chunking lifecycles (such as staged delivery) manage schedule risk well. If you’re attempting a project in which you have no idea if the technology is feasible, you may find that you’ve used all the project time without a product to show for the investment.
    • Agile lifecycles (such as Scrum or XP) manage both technical risk and schedule risk well. They require people who are able to make the transition to agile techniques.

    Selecting an inappropriate lifecycle for your project and project team will slow down your project.

  3. If you’re able to decide which projects to start when, and you’ve chosen an appropriate lifecycle, make sure your requirements definition isn’t bogging down your project. Most projects can’t fully define their requirements up front — the users need to see little pieces of functionality before they know what they want. If you’re on a project that’s attempting to define many of the requirements at the beginning, consider changing how you think about requirements. Instead of saying, “We need to know how much we have to do,” consider asking, “How little do we need to know before we can plunge in and start the project?” The move from how-much to how-little thinking helps you think about the project in these ways: how to help the project deliver value quickly, that the schedule is important and doing it wrong the first time to do it again will slow down the project, and that we can deliver faster if we have less to deliver.

Your project doesn’t have to have a long startup time. But it does take thinking about what to do, how to do it, and how little you can do.

The original article can be found at: http://www.jrothman.com/pragmaticmanager/decreasing-project-completion-time-part-1.html

Johanna Rothman consults, speaks, and writes on managing high-technology product development. Johanna is the author of Manage It!’Your Guide to Modern Pragmatic Project Management’. She is the coauthor of the pragmatic Behind Closed Doors, Secrets of Great Management, and author of the highly acclaimed Hiring the Best Knowledge Workers, Techies & Nerds: The Secrets and Science of Hiring Technical People. And, Johanna is a host and session leader at the Amplifying Your Effectiveness (AYE) conference (http://www.ayeconference.com). You can see Johanna’s other writings at http://www.jrothman.com.

Share this article:
  • Digg
  • del.icio.us
  • Facebook
  • Google
  • blogmarks
  • LinkedIn
  • Reddit
  • StumbleUpon
  • TwitThis
  • Yahoo! Buzz

Related Articles

This entry was posted on Tuesday, November 10th, 2009 and is filed under Miscellaneous. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.

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.

Project Management Categories