Contents:
- This month's Feature Article: Decreasing Project Completion Time
- Announcements
- On the Bookshelf
- Want to hear more from Johanna?
- Want to read more of Johanna's writing?
=-=-=-=-=-
Feature Article: Decreasing Project Completion Time
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, and I'll address long completion times in next month's Pragmatic Manager.
- 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.
- 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.
- 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.
=-=-=-=-
*Announcements:
I wrote a handbook about corrective action with Denise Robitaille called “Corrective Action for the Software Industry: A Pragmatic Approach to Effective Problem Solving.” It's for people who want to do corrective action without a lot of overhead – whether or not you have a formal quality management system. See https://www.jrothman.com/books.html .
=-=-=-=-
- On the Bookshelf:
“Five Core Metrics: The Intelligence Behind Successful Software Management” by Lawrence Putnam and Ware Myers, ISBN 0-932633-55-2. Putnam and Myers help the software manager understand why time, effort, size, reliability, and productivity are interrelated. They present the core metrics clearly and explain how to use them. If you don't believe me when I claim there's a minimum start-up time for a project, here's their take on on a minimum project time: “In the software trenches, for example, the minimum development time is a fact of life. No matter how many stakeholders dance around the creative fire, each project has a development time than can be no shorter than this minimum. That schedule is determined by the application size and type and the organization's existing level of productivity.” They also explain why you're more likely to finish shorter projects on time. If you want to understand how productive your organization is, read this book.
=-=-=-=-=-
- Want to hear more from Johanna?
If you want to catch me at a public event, see if you can make this:
Mar 10, 2004, “Are You Hiring Yesterday's Testers?” at the Software Quality Group of New England, Burlington, MA
My calendar page, https://www.jrothman.com/calendar.html always has the most recent information.
=-=-=-=-=-=-=-
- Want to read more from Johanna?
Here are my publications since the last Pragmatic Manager:
Two Candidates. One Position, Better Software, February 2004
Investing in Architectural Infrastructure: A Business Conversation, Cutter IT Journal, January 2004
When Enough is Not Enough, Stickyminds.com, January 2004
Don't forget to check out my blogs: Managing Product Development, and Hiring Technical People.
I keep a list of my latest writings on https://www.jrothman.com/papers-chron.html, and point to the articles from there.