Podcast: Download

Subscribe: Apple Podcasts | Android

A wise person I work with made this profound statement today.

You can release on time and still fail

There’s a notion out there that project managers only care about making the schedule.  While it’s easy to get fixated on it, the more I work on product releases the less I find myself caring about “the schedule.”

This doesn’t mean it’s not important to meet the dates we’ve committed to. If a release is off track, I’m more interested in constructing a realistic schedule everyone has confidence meeting versus whipping everyone into a frenzy to meet a date simply because it’s published on a schedule.

Sometimes I find that the project team loses sight of who the schedule is for. When things are going well on one of my product teams, an anonymous colleague likes to say “This should make John Poelstra happy!” or “Look we’re meeting Poelstra’s schedule.”  And yet, while this person enjoys pulling my chain it really misses the point to call the schedule mine.

The schedule isn’t mine simply because I’m the project manager.  No, the schedule belongs to the entire release team. It’s the release team’s schedule, not the project manager’s.

If you have to re-evaluate or make adjustments to the schedule, make sure it makes sense to the entire team. Have you factored in all of the important aspects of the release?

  • Quality at sufficient levels
  • Features complete enough to meet goals of the release
  • Documentation complete enough to meet objectives
  • Marketing is able to promote its

What do you think of my ideas here?  If you object, I’d love to hear from you.

Related Episodes

Credits

All songs licensed under Creative Commons

Transcript

This transcript was created automatically and may contain small errors.

Today I want to talk about a funny notion that I’ve seen. I’ve seen it for a while, but I saw it pretty clearly on a project. And it was also framed very well today by a colleague who said, you can release on time and still fail. And I could not agree more. So there’s kind of this idea in project management that your success or failure as a project manager is judged based on whether you ship on time or not.

So you have a schedule, you set a schedule when you’re planning the project or the release, and if you release according to that schedule, you’re a hero, and if you don’t, you’re a failure. And as a project manager, it’s easy to get fixated on the project schedule. Although I’m finding, this was just kind of a realization, I think the longer that I spend in Project Manager, the less fixated I am on the schedule and the more fixated I am on the overall project and where it’s going and not so much whether it’s going to meet the original schedule that we published. And I think where this recently came out was someone was discussing some issues that we had related to a product release that was coming up, and they resolved them, and they said, well, this should make John Poelstra happy. And then another time, look, we’re meeting Poelstra’s schedule, as if the schedule for the product release is mine and is this special thing that I only care about.

And so I, you know, teasingly said, no, it’s Well, and I was serious. It’s our schedule. This is the release team schedule. This is not, this is not the project manager’s schedule. This is the release’s schedule.

This is the project schedule, the project team schedule. And so we all have a vested interest in it, meeting it, and everything to do with it. It’s not just like this secret hobby, not a secret hobby. This isn’t just a special hobby that John Poelstra as a project manager has. I still think it’s important to meet the dates that teams have committed to, that they thought were achievable when planning the project, but I think it’s more important to take a holistic view to say, okay, we have this project.

It needed to meet these certain requirements. In other words, in the case of a software release, it needed to have these particular features needed to be in the release. They needed to be complete enough to meet the goals of the release, understanding with software that software is never finished. A lot of times you are releasing with good enough for this release, we’ll make it a little bit better next time, or a lot better next time. Also, in terms of a holistic approach to the release, are the quality levels sufficient?

Is the documentation complete enough to meet the objectives for, say, the customer, or clearly explaining a product?

Released recently where there had been a real scramble to meet the release schedule. The code and everything was done. And yet when a really deep evaluation was done of the documentation to install this fairly complicated product, like a real thorough review of that was done, the release was, was held back because of— deficiencies in the documentation. On the other hand, I’ve seen other products, like I’m thinking OpenShift, a cloud product, where it’s an online product. Would documentation halt the delay of that release?

Probably not. That’s going back a few years. I don’t do OpenShift anymore, but just to set a context there. The schedule only makes sense, and the schedule only really matters, in my opinion, when you’re factoring all those other things that come into play. So, while it’s satisfying to meet a schedule that you have published, and, you know, these are the dates, and this is what we’re going to do, while it can be very satisfying to meet the original goals that were originally set out, if— the underlying objectives aren’t met, then yes, you could, as the project manager, whip everyone into a frenzy to meet a particular date because it was the originally scheduled date.

But I’ve also seen a lot of collateral damage from doing that. So just something to keep in mind. Release schedules, they belong to everyone. They should be negotiable. Not all the time, but if, if the underlying state of the release is getting to a point where it can’t fit into the existing schedule, just blindly holding onto the existing schedule is not usually a very good idea.

Now I realize there’s exceptions to this. Maybe you have contractual obligations. I’ve seen product releases that had huge financial implications, you know, and so yeah, those releases went out on a very specific date, you know, to meet those contractual obligations or for revenue recognition, whatever. Every release is different, but all these factors need to be taken into account when considering the project schedule and how it should be used, how it should be treated. And whether it should be adjusted.

And don’t get me wrong, just like the next person, I want to release on schedule. But as I mentioned at the beginning, over time, perhaps as I’ve matured, I see that there’s often a bigger picture than just meeting the schedule. So I’d love to know what you think of my ideas here, particularly if you object, I think, or have a different view on what I’ve shared here. Let me know, REDACTED, and perhaps I’ll share your thoughts in a future episode.