The Pragmatic Manager, Volume 2 #1
Contents:
- This month's Feature Article: Kill Canceled Projects
- On the Bookshelf
- Announcements
- Want to hear more from Johanna?
- Want to read more of Johanna's writing?
=-=-=-=-=-
Feature Article: Kill Canceled Projects
I've worked with several managers and developers who had a difficult time killing cancelled projects. One developer was so enamored of a project, that even after he was laid off from the company, he returned on his own time to complete the project! You might think he was a giving helpful person — and you'd be right. But his continued work on the project, even for “free,” cost the company time in support of his “free” work.
If your company has canceled a project, then work to stop the project. When I help managers cancel projects, we discuss how they will manage the cessation of work.
- First, explain to the people on the project why you're canceling the project and what happens to them. People want to know that you appreciate their efforts. And they want to know what work they'll be doing now.
- Give people time to clean up their work before starting on their new work. That means checking in the code that's checked out with comments that explain the state of the code, or noting on a design which alternatives were under discussion, or which tests were or were not completed. Cleaning up work is not the same as finishing up work, so I recommend this step take less than a day to perform.
- Cancel all meetings associated with this project. Once people clear their schedules of these project-related meetings, they'll see other time they have available for the new work.
- Assign someone to handle the inevitable questions about the canceled project, preferably someone high up in management. If a technical person has the project information, he or she might start working on it again. If a manager is assigned to be the point person, the manager is less likely to start working on the project.
- If you're canceling a project that's had some substantial work (sometimes as little as a few weeks or more), take the time to perform a project retrospective and see what people learned from this project.
- Start people on their new project as soon as they've cleaned up their work.
Canceling a project may not be fun for you. But if you cancel the project cleanly, you won't have to do it again — and you'll be helping the company move forward.
=-=-=-=-
- On the Bookshelf:
“Agile and Iterative Development: A Manager's Guide” by Craig Larman, ISBN0-13-111155-8. If you're not sure how to describe a variety of different lifecycles, Larman's book will help. The book is organized so you can look at any of the motivations, explanations, or lifecycles (both iterative and evolutionary) and have pointers to other areas in the book that discuss that issue. I especially like the Practice Tips section which explains what to do when trying to manage a non-waterfall project. Larman explains on page 249 what to do with multiteam or multisite iteration planning (sub-team iterations). Part of the Practice Tips section deals with requirements, and I particularly liked the Team Rotation Writing technique described on page 291.
“Critical Testing Processes: Plan, Prepare, Perform, Perfect” by Rex Black, ISBN 0-201-74868-1. Black uses a running example to help testers and test managers address the testing part of a project. Here's an excerpt from my Amazon review: “In particular, the planning chapters (using the running example project) make many of the planning and risk management issues obvious. This book will help you determine which activities make sense for you to perform, how to analyze quality risks, how to estimate the work, and how to speak the language of the business (return vs. cost). If you only read the first seven chapters, you'll be farther ahead in your thinking about testing and preparing your group to test than you ever were before.” There's more, but if you only read the planning chapters you'll still get tremendous value.
=-=-=-=-=-
- Announcements
The 5th annual AYE conference will be Nov 7-11, 2004 in Phoenix, Arizona. No talking heads here — sessions at AYE are and interactive and long enough to get beneath the surface. People who come to AYE, don't just attend, they participate and learn. We send conference updates by email. To sign up for our private, low volume mailing list, please go to http://www.ayeconference.com/moreinformation.html
I sent out a subscription confirmation message earlier this week to people who hadn't double-opted-in. Yes, it was from me. Yes, the URLs look funny. That's ok. I want to make sure you want to be subscribed.
=-=-=-=-=-
- Want to hear more from Johanna?
Here's my public speaking schedule for the next few weeks:
Feb 12, 2004, Predicting Project Completion, Joint meeting of RI PMI and ASQ, Providence, RI
Mar 10, 2004, Are You Hiring Yesterday's Testers?, Software Quality Group of New England
Feb 26, 2004, Teams without a Common Boss, SCPD, Waltham M
My calendar page, https://www.jrothman.com/calendar.html always has the most recent information, and pointers to the events.
=-=-=-=-=-=-=-
- Want to read more from Johanna?
I published a few articles in December and January: (I keep the list of my latest writings on https://www.jrothman.com/papers-chron.html, and point to the articles from there)
No More Second Class Testers!, Better Software, January 2004
Hey, it could happen! A contrarian's approach to predictions, Computerworld.com, December 2003
Successful Software Management: 14 Lessons Learned, Crosstalk, December 2003.
Don't forget to check out my blogs: Managing Product Development, and Hiring Technical People.