Management, especially good management, is hard to do. This blog is for people who want to think about how they manage people, projects, and risk.
© 2003-2010 Johanna Rothman | Email Johanna | RSS feed | Sign up for AYE newsletter | Workshops | Consulting | Podcasts | Johanna's site | Johanna's email newsletter
I have been delinquent for those of you who subscribe to my email newsletter. I have not published one since April. On the other hand, I just posted Park Projects You Can’t Staff, For Now. The next newsletter is scheduled for Thursday morning. In case you’re wondering, I post the most immediate past newsletter when I queue one up for sending. If you decide to subscribe, you can rest assured I will not bombard you with email!
I’ve been working with clients making the transition to Agile. They are accustomed to a product manager “owning” a product, and negotiating for people to work on their product. Of course, that means begging, borrowing, stealing people from other projects and lots of multitasking. It also means that specific people have very specific knowledge of products or pieces of products, and it’s way scary for these product managers to consider allowing other people to work on their products.
These clients have organized their technical folks into teams to work together on projects, one at a time. There’s just one problem. They have more product managers than teams. What do the product managers, who are now product owners, do?
If they ask the teams to work concurrently on two products as if they are two teams, the teams aren’t really one team. If they ask people to slide work into an iteration, the people are multitasking. These folks need the structure of a timebox, which is why they considered and rejected the notion of a kanban board. But, they can rank all the work for an iteration jointly, and then ask the team to work on the stories in rank order.
Notice that they are keeping the idea of work flowing through a team. The two product owners are working together to rank the work for the iteration according to the project portfolio. At least one client is considering shortening their iterations so they can keep the team working on just one product for an iteration. They aren’t there yet.
The product owners are learning how to write smaller stories. The teams are learning how to put more people on a story to finish it faster. The product owners will need to collaborate and the leadership teams will need to keep reevaluating the project portfolio so the product owners can collaborate and provide one ranked backlog for the teams.
Transitioning to agile is difficult. Agile does make the issues transparent. It doesn’t make them easy to solve. At least they can see the problems.
There are plenty of ways for these folks to fail. But they are committed to creating teams who can work together. They are committed to no more multitasking. We’ll see how it goes.
The December Harvard Business Review has an article, Is the Rookie Ready? (You have to subscribe and pay to read the whole thing.) The story is this: Kristen is the new project manager, reporting to Tim. The old PM left because Tim, who’d been her manager for 6 months didn’t know how to work with her. Tim hears from an old customer two weeks before Christmas, “Please help us and send a team down to install your software, the stuff we rejected a year ago because it was too expensive. Oh, and we need it by Jan 1.”
Tim agrees (Big Red Flag here). He asks Kristen to go install and make the standard software work (no customizations) and to take whomever she needs. Kristen doesn’t think this is a such a good idea, but Tim tells her it’s her job to make it happen. He tells her to tell the team ‘we’re going to do this.’
The question to the famous commentators is, “Is the Rookie Ready?”
Wrong question. Michael Schrage suggests hiring back the old PM. But, then he says “Kristen is in over her head.” NO. KRISTEN IS NOT IN OVER HER HEAD. TIM IS A TERRIBLE MANAGER. We can’t tell if Kristen is in over her head.
Sorry for yelling, but I just couldn’t take it. (You should have heard me while I was reading the article :-) Anyone would be in over his or her head, because the only way to solve this problem is to have someone intimate with the product install it. Even then, this is a 6-week project. Why would Tim agree to a 2-week install? Sure, the customer wants it. Customers want all kinds of things. They can’t always get what they want, when they want, for the price they want.
Tim is a terrible manager, because he keeps taking the best programmers and making them managers (part of the story I didn’t summarize). If they want to be managers, that’s fine. But it’s not clear Kristen wants to be a manager. And, he doesn’t even push back on the customer. And, Tim has allowed a standard product without a standard install. (Ok, it’s a big product. Maybe a standard, unattended install isn’t possible. Maybe it really does need 6 weeks to install. So, why isn’t there an install group that does this??)
Why would Tim agree to do a special install over the holidays without asking for more money? Why would Tim even think this is acceptable to do without asking the team who will do it? Because Tim isn’t the one giving up his vacation. The fact that he even thinks this is acceptable behavior just astonishes me.
It’s time to ask if this project is strategic to the company. (Where are all the other managers? Why is Tim getting this call? HBR, I can write a more realistic story than this.) Maybe this is not even a project to take on.
If they’d asked me to comment on this story, here’s what I would suggest:
Tim is creating management debt by making bad decisions. He’s not managing the project portfolio–what other projects are now crises? He’s not managing the people. He’s certainly not building a trusting relationship with his people. What the heck is he doing?
I’m so worked up about this because I worked for a jerk like this once. He committed all kinds of deliverables on behalf of my project to the customer. Half the time, he didn’t even tell me. He never once thought what was good for the organization or even the customer.
Managers like Tim kill an organization. They create management debt by not managing people correctly, by not managing the project portfolio correctly, and by not managing the customer correctly.
The question is not whether the rookie is ready. As Paul Muller, one of the experts who commented said, “Every manager has a first crisis, whether it’s three days or three years after assuming the role.”
The question is not “Is the rookie ready?” The question is why is Tim employed at the organization? Why has no one seen the messes he has made?
Daniel wrote a lovely post, Kill, commit, or transform your projects over on praglife.
Keeping projects around that are not staffed, multitasking on several projects (committing to none of them), and running away from reality doesn’t help anyone. The projects don’t finish faster–they finish, if at all, slower. The people don’t have a sense of accomplishment, they feel as if they have a never-ending mountain of work.
Sometimes, transforming a project is as simple as asking “How little can we do and still have a valuable product?” Too often, we fall into “how much” thinking, instead of how little. Sometimes, transforming a project is much bigger.
Whatever you do, don’t blindly commit to projects. I’m in the process of drafting a post about that and will link it here when it’s done.
I just posted the October Pragmatic Email newsletter, You Can’t Do All the Work. Now What? If you subscribed, you’d have already received today’s….
Have a great New Year’s everyone.
A new article is up, Using the Project Portfolio to Move to Incremental Project Funding. It’s up on PMBoulevard.com. (Free registration required). Enjoy!
I have an article up on PM Boulevard: Choosing the Strategically Important Work. Enjoy! (I think you need to register for this site too. Free.)
I recently wrote an article on how to say No, and a twitter follower wanted to know what to do when your manager can’t hear no.
First, understand why your manager can’t hear no.
Once you understand why a manager can’t hear no, you can choose how to act. For the first three reasons, your manager may not know about how to or is not willing to manage the project portfolio. In that case, you can manage your project portfolio.
Gather all your work into your project portfolio. Break your tasks into small chunks, so you can complete something in a morning or an afternoon. If you finish some task, can you get to a wait state on that project, waiting for others to get back to you?
If so, you can repeat, ranking and reranking as you proceed. It’s better to have a one-on-one with your manager and make sure you are working on the most important work. If your manager cannot help you rank, don’t worry. Show your manager that it’s possible to make a decision, make some progress, and then re-evaluate that decision based on more data.
If your manager doesn’t believe you, you may have a different problem. Is it a case of Queen of Denial, or is it something more basic, such as lack of trust? If it’s the schedule game, eventually your manager will encounter reality. If it’s lack of trust, that’s another whole problem and another blog post.
Most managers can’t hear no if they literally cannot imagine how to work themselves out from under the pile of work. Show them.
I have a column up on Stickyminds.com, No: Such a Difficult Word. Please leave comments there. Enjoy!
I have a column up at PM Boulevard (free registration required): Manage Your Project Portfolio and Stop Thrashing. Enjoy!
.
.
.
