Managing Product Development

I’m editing a chapter in my hiring book, and the original sentence reads:

…managers amplify the work of other people …

The editors have suggested that amplify is the wrong word, and suggested “facilitate.” I’m still thinking about this. Managers do facilitate the work of other people. They also make their staff more effective. They provide leverage to their staff. They remove obstacles. To me, facilitate is too small a word for all these things. But I’m stuck and have no other words right now. If any of you have a better word, please tell me. Thanks.

We were on vacation last week in Breckenridge, CO. I enjoyed it, although it did take me a few days to acclimate to the 9600 feet altitude. Returning on I-70 East, we saw some great road signs:

Truckers don’t be fooled - 4 miles steep grade

Truckers you are not done yet - 1. 5 miles to go

These road signs are different enough from other signs that drivers and passengers pay (even more) attention to them. The message that even though the road looks like it’s flattening out a bit, it’s not — that the drive is still risky.

Project managers choose a different action when they know it’s close to the end of the project. Instead of slowing down as truckers (and the rest of the drivers) should, PMs know it’s time to maintain the pace of the project. If you let people off the project before the project is complete, it will take longer and cost more to complete the project.

I was a program manager for a 100+person project a number of years ago. Four weeks before the end of the project, the company laid off one-third of the project staff. It took the project another nine months to complete. Now, it’s possible we wouldn’t have made the original date, but as far as I could tell at the time, we were on target, possibly as much as a week early.

Project managers, focus your project team on the ultimate date, not a penultimate date. Maintain a reasonable project momentum, you don’t risk crossing the desert watching your success being snatched away.

Just in case you hadn’t heard enough from me about inch-pebbles, here’s an article I wrote for Computerworld.com.

I’ve been at this now for a year, and here’s my mini-retrospective on my blogging:

• What did I do well that I don’t want to forget? I learned that even a small entry that helps me to think more is useful. I don’t have to wait until I have completely well-formed thoughts. Pointing you to other authors is useful too.
• What did I learn? Some of my entries are useful for turning into longer articles. Your feedback helps me learn where I should write more (because I’m too vague or because I have a lot of energy around the topic). I also learned that Frank Patrick and Hal Macomber are great reviewers. I already knew that Dale, Esther, Keith, and Laurent were great reviewers.
• What should I do differently the next time? Make fewer mistakes For example, I completely failed to understand the impact of spam and phishing on email and productivity. Consider taking off more on other authors.
• What still puzzles me? I suspect I could use the blog even more for trying out things in my writing, and I’m not sure how to do that yet.
• What do I need to discuss in greater detail? Should I convert from an RSS to ATOM feed? The conversion is easy; I can’t tell if it benefits you, my readers.

In case you’re wondering where these questions came from, they’re from Norm Kerth’s book on retrospectives. When I facilitate project retrospectives, I use these questions to focus the conversation. I’m becoming the princess of focused conversations (Esther is the Queen), so when I debrief simulations or activities in workshops, I use the focused conversation technique. To me, a year of blogging felt more like a project than a small, focused, well-contained activity.

I’m on vacation, so I’ll be blogging very little this week. In my last Pragmatic Manager email newsletter, I wrote about killing canceled projects. Here’s the summary:

1. Explain why you’re canceling the project.
2. Give people time to clean up their work before starting on their new work.
3. Cancel all meetings associated with this project.
4. Assign someone to handle the inevitable questions about the canceled project, preferably someone high up in management.
5. Perform a project retrospective and see what people learned from this project.
6. Start people on their new project as soon as they’ve cleaned up their work.

I spoke at a joint meeting of the RI PMI and ASQ last night. My presentation was “Predicting Project Completion.” I offered a simulation for people to try: predicting the time it would take and then sorting two decks of cards. We learned a lot and had fun.

At the end of the meeting, one of the attendees came up to me and said, “Marketing thinks we have a short market window, and they want a ton of stuff in the product. What can we do?” I suggested he consider one of these lifecycles: agile or design-to-schedule or staged delivery. I don’t know anything about the product, nor do I know about the capabilities of the people, so I can’t say which is right, but any of these will be better than what he’s doing now (a form of waterfall).

I was a little surprised by how few people knew about agile lifecycles (I gave the 2-minute intro in my talk), and by how few people knew about cost to fix a defect or fault feedback ratios. I suspect people working inside organizations are so stressed by the quantity of work that they haven’t paid attention to the popular literature about agile techniques or measurement possibilities.

Oh, one more thing. If you’re a bloglet reader, I can only hope that you see this (and the several previous) posting. Bloglet has decided there’s something wrong with my blogs again. I’ll keep fixing and eventually things will work…

At first, when Hal posted State of the Art of Project Management — Underlying Theory is Obsolete I wasn’t sure what he meant by #9: “Project portfolio management is an excuse not to manage each project. Each project team must be set-up for success.” Now in PMO: Obsolete Before It Gets Off the Ground, I understand what he means. I agree.

A PMO can and should be responsible for project tactics (project-by-project and as a whole), not strategy, which is what project portfolio management is. Functional management, starting at the first level and up to the top, has the responsibility for determining which projects are started (and when), which are finished (and when), and which projects are canceled (and when). No one else can or should perform this function. Project initiation, completion, and canceling are strategic decisions, and no one outside of functional management has the information they need to perform that work. If you’re a development (or test or whatever) manager and you’re also a project manager, ok, you wear two hats, and you can help each hat out. But if you’re a project manager or you’re in the project office, you can’t possibly know enough about the organization’s strategy, and how it’s changed, and what that means for managing the project portfolio.

So here’s my take on what the project office (PMO) can and should do:

• Guide project managers through the decisions about how to organize the project.
• Help project managers select among practices that may be useful for their projects and help implement those practices as necessary.
• Help project managers understand the state of their project, and especially to recognize when the project is in trouble.
• Help project managers understand their risks, how to determine the risks, and how to evaluate the risks.
• Supply people who can facilitate retrospectives for completed or canceled projects.

A PMO should be internal consultants to the project managers and to senior management, and completely tactical in focus. Of course, they’re company employees and may well have opinions on the worth of any given project. But the strategic force of managing the project portfolio has to come from management, specifically senior management.

I just read Jim Coplien’s paper about teaching design called “Close the Window and Put it On the Desktop”. He references the “Rule of Least Surprise,” which is to do the “least surprising thing.” In design, it means the user shouldn’t be surprised or confused by what the program does. But what does it mean for projects?

Here are some thoughts-in-process for applying the Rule of Least Surprise for managing projects:

• The project manager helps the project team focus on the final deliverable, not interim deliverables, so the project team doesn’t fall into the “crossing the desert” mode, where it looks as if the project will never finish.
• The project manager helps the team set the goals and refine the project’s goals, so the project team knows what they have to do at all times. (”Does this task help us accomplish the goal?”)
• The project manager helps make the project state visible to all team members so they can see where they are with respect to the goal. (So the project team isn’t surprised by the work remaining.)
• The project manager makes the project state visible and understandable to the stakeholders, so they can see the project’s progress. (So the stakeholders aren’t surprised by the work remaining and the risks to accomplishing that work.)

I’m still thinking about this. But since I believe the project manager leads the design of the project, the rule of least surprise should apply to projects, as well as to products.

I’m writing an article about defining the rhythm or cadence of your project and how to increase that, if you want to finish the project faster. I’m a little stuck — at least, if rewriting the whole thing three times is stuck, that’s where I am :-), so here’s another observation about project rhythms.

If you watched the SuperBowl Sunday night, you had a chance to see two different teams play their own games to their own rhythms. The Panthers have a long-pass, long-run, elegant rhythm to their game. The Patriots have a short-pass, short-run, nibbling-up-the-field rhythm to their game. In this instance, the Patriots won (Yeah!), but each team played their own game. It would have been easy to fall into the trap of playing the other team’s game — something that would have played to that team’s strengths. A good defense is necessary to avoid being trapped into playing the other team’s game, so that you’re not in reactive mode. But both teams managed to play their own games, leading to a fabulous football game.

The same thing can happen on your projects. If you work your project according to your own project rhythm, you (the entire project team) can create a great project — at least, as good as you can make it. But, if you attempt to work to someone else’s rhythm, your project can’t succeed.

Any project can develop a rhythm and then maintain it. The project manager (and project staff) has to look for obstacles and risks and remove them (that’s the defense part). Easy to say, sometimes hard to do. But the biggest obstacle is to not be trapped into working someone else’s project. You’re working someone else’s project when they cut staff, change the delivery date, change the focus of the project, or some other major change, and then expect you to react — and react well. In my experience, once a project has started it’s almost impossible to change the project rhythm from a top-down mandate and succeed with the project. I have seen successes where people changed practices and were able to change the project rhythm.

It doesn’t matter what kind of a lifecycle you use, although any cyclical or chunking lifecycle makes it easier to see the rhythm of your project. As long as you help the people on your project see their rhythm, your project will make progress. And if you want to increase the pace of the project, look for things that you don’t even know are obstacles and remove them.