The Berkun Blog

Management, design, and the making of good things.

Archive for the 'PM-Clinic' Category

This week in pm-clinic: the white knight

January 29th, 2007

After a few weeks on hiatus, the pm-clinic is back. With a vengeance. New tales of management challenges and great advice await.
This week in the pm-clinic discussion forum:

I was asked by to take over a troubled project. This group is managed by my boss’ peer so I am now dotted-line-reporting to him for this project. This
senior-level manager is not happy about being forced to use me. The project teams are strong but have been micro-managed by said manager who repeatedly
puts the cart before the horse - one of the major reasons the project is in trouble.

I, as the white knight,” am being asked to keep the listing ship from completely sinking. Expectations for getting it on track are high, while still meeting some of the originally set timelines.

How do I both manage this project and a sponsor who doesn’t want me as the PM?

-Signed, the white knight

This week in pm-clinic: Innovate or die

October 30th, 2006

This week in the pm-clinic discussion forum:

Is innovation for innovation’s sake a good idea? I think not, but my new VP has it in his head that our entire organization needs to be more innovative - despite his lack of clarity about what that means. So all of the team leads (including myself) are like a pack of wolves, pacing and racing around our projects.

New ideas are flying all over the place (reorgs, new technologies, new directions), but progress on existing projects has stalled, morale is volatile (rising and falling daily), and there is a shortage on meaningful decisions about why we’re changing things, or how those changes will be made.

How can I help my VP sort out what innovation means? (Or is this some kind of leadership game where he’s testing us by watching our responses)? Or more cynically, protect my team and existing projects from this chaos until it passes?

- Innovate or die

This week in pm-clinic: Haunted by ghost employees

October 23rd, 2006

This week in the pm-clinic discussion forum:

A handful of managers that have worked together for years are good friends. One of them, the one with the least competent reputation, left over a year ago, and is now being hired back into the company as a perennial contractor (product manager).

Every time my team has interacted with him, across various contracts and on different projects, we’ve had some kind of performance problem. However given his connections, despite feedback to the contrary, he keeps getting rehired (generally with different teams each time).

What can I do, as a manager myself, to exorcise this ghost employee from my world?

- Signed, Haunted by a ghost employee

This week in pm-clinic: Killing the zombie project

October 9th, 2006

This week in the pm-clinic discussion forum:

I’m a pm for a web development company - I have what we call a zombie: a project that lives on forever for no good reason. The client continually makes rounds of tiny changes, often to things where they can’t provide specific or actionable feedback so we can’t get it right the first time. The project scope (contract) of work, sadly, doesn’t have language that caps these things as they were unexpected. So, through either politics, influence, bands of garlic, or changing the process, how do you put a zombie
project to rest?

- Hunting project zombies

This week in pm-clinic: Being shown the door

October 2nd, 2006

This week in the pm-clinic discussion forum:

After two years as a general manager, building a team of 25 from scratch, my VP is showing me the door. More precisely, I’m being asked to find a role elsewhere in the company. Yes I’m devistated, but that’s not the point.

My challenge: how do I message my leaving why I’m leaving? Most of them came to the org because of me: I recruited them on the basis of my commitment to them and the project. I don’t want to be ugly and badmouth the VP, but I don’t want to lie either. How do I message this honestly, but create the least damage for the team and whoever has to replace me?

- Signed, trying to close the door (TCTD)

This week in pm-clinic: Keeping top talent

September 25th, 2006

This week in the pm-clinic discussion forum:

For about 16 months my big problem. in forming a new team, was finding top talent - but now that I’ve nailed that goal, I have an unexpectedly annoying problem: keeping top talent. The surprising downside to having rock star people is that they know they can easily find jobs elsewhere, and they demand more from me in terms of assignments and the challenge level of their projects than most of the people I’ve managed before.

I’m starting to think I’m overstaffed - my team has more talent than I really need for the kinds of projects we’re going to have over the next year.

Should I:

  • a)  Stop complaining. This is a good problem to have. I should do whatever it takes to hold on to as many talented people as possible, regardless of the circumstances.
  • b) Call the talent’s bluff and let them leave. I’ve over-hired, and if folks feel they can do better I should let them go, working towards a balanced pool of talent to match the more balanced work I have.
  • c) Fight for bigger projects based on the talent level I have.
  • d) ?

Signed, - Trying to keep top talent

This week in pm-clinic: thick vs. thin specs

September 18th, 2006

This week in the pm-clinic discussion forum:

One ongoing debate in my world is thick vs. thin specs.  The thick camp believes that specs need to be detailed (thick) and that specifications should be comprehensive to the point that most issues are well covered and that the spec can answer most questions programmers and testers have. The thin camp believes no one reads big specs and at best a spec should cover points of contention and basic principles, leaving the rest for the programmer/tester/etc. to interpret or ask for clarification.

Where do people stand on the thin vs. thick spec issue? Do specs in your org typically go for more than 10 pages (thick)? or less (thin)?

- Signed, Thick vs. thin

This week in pm-clinic: The need for two faced managers

August 28th, 2006

This week in the pm-clinic discussion forum:

I manage a rapid prototyping team in for a major consumer software product. We partner with real dev teams from around the org, and explore out ideas they don’t have time for. The group is new and I’m under continual pressure from above to justify the group’s existence (a task of many middle managers) -  I’ve asked my team to think about ways to measure value, but I get the risks: people may game the measurements, or the measuring may kill the creative work - - but I’m asking anyway as I can use the ammunition.

So my challenge is how to satisfy the view of big management, which is measurement centric and the language of VPs, but also satisfy the needs for innovation, protecting the environment from passion killing rules and structure.

How can I be the bridge between these two views without being two-faced or deceptive about what’s going on? Or is this exactly what managers of innovative teams in more production centric organizations always have to do?

- Looking for the benevolent Janus

This week in pm-clinic: Dealing with the powerful but annoying

August 21st, 2006

This week in the pm-clinic discussion forum:

The manager for my team is one of the company founders. He’s smart, but oh man, is he annoying. He has a litany of habits that make my life, as a team leader, frustrating: from disrupting my authority in front of others, to changing his mind and then changing it back, to just being downright egotistical, snide and resistant to ideas from others. He is smart and does contribute, and listens about 1/3rd of the time, just enough to prevent the other founders from doing anything about him.

So I have to work with this man: he’s not going anywhere, and he has significant power over me, my team, and the company. So how can I protect myself and my team from his many less than delightful habits?

- Stuck in Annoyanceville

This week in pm-clinic: painless ways to cut features?

August 14th, 2006

This week in the pm-clinic discussion forum:

Our team has a monthly process called add/cuts, where all the head honchos get in a room, look at the feature lists, and decide what features to add and which to cut. These things are usually quite bloody, carnage heavy affairs - typically 80% cuts and 20% adds. It’s an ad-hoc meeting where we review goals, run the work item lists, and try to make things fit the schedule. Unfortunately it often falls into ritual feature killings, where each head honcho cuts things to prove to the others how hard core they are.

The result is that the meeting functions best to motivate people to finish work before these meetings (perhaps good), but also to skunk work, hiding work items, to avoid having them discussed in these meetings (which is bad).

I’m influential enough that I can propose a different way to run these feature level add/cut meetings. What should I propose?

This week in pm-clinic: Surviving the visionless manager

August 7th, 2006

This week in the pm-clinic discussion forum:

I lead a small team of 6 - we’re paired with 3 other small teams, all reporting into the same group manager.

Problem #1: the group manager doesn’t have a vision. He’s vague and tends towards disinterest in leadership matters.
Problem #2: All of us leads have visions, but they’re different.
Problem #3: Leaders and founders seem content to let us fight out our respective visions in code.

I’ve run up this hill before - it’s not fun. I want to find another way to deal with the situation and I’m hoping pmc can help.

- Surviving the visionless manager

This week in pm-clinic: Managing proof of concept

July 31st, 2006

This week in the pm-clinic discussion forum:

I’m a project leader in a research organization - as in a hard core blue sky R&D future thinking lab. We loosely organize around projects but our goals are the inverse of typical software: it’s the IP and the concepts we invent that people pay us for, not feature sets or code quality. Our releases to clients are vehicles for our concepts and research, but nothing more.

What I’m looking for are ways to apply project management skills to blue-sky, big think, projects. Can we improve the quality of our process and scheduling, or get more mileage out of the concepts we invent, but with a minimum impact on our ability to experiment, change directions, and go after big powerful ideas? What do things like specs, exit criteria and status meetings mean for a 100% proof of concept project?

- Flying in the blue sky


You're reading scottberkun.com, home of tasty essays. All rights reserved unless noted. You can subscribe here (RSS ).
If you're not sure how to feel now that you're at the footer, joy is free and recommended.