I don’t know about anyone else but I always suffer a bad case of “after release blues” It’s a combination of let down, exhaustion, and the release of a huge amount of energy in a very short time. Usually the feeling manifests as a certain amount of snappish behavior on my part,though sometimes I also have to deal with depression and a gnawing sense that something doesn’t feel quite right.

I’ve noticed, though, that if I let myself wallow for any length of time, the project I’m managing tends to fall apart. Follow through matters as much in project management as it does in golf or in boxing. Just stopping right after release might feel good, but it doesn’t necessarily lead to a successful project.

Why does stopping at release lead to disaster? After all, we’ve created the unique product our project existed to deploy. We got sponsor sign off and all is right in the regimented world of our artifacts. That’s all true. But the project’s success depends not on our artificial measurements but rather on how much change it creates in the environment. For change to occur someone, usually the executive sponsors and the project manager, have to continually push though the last few barriers to adoption. Those barriers inevitably show up after the project’s “completion” date.

The above is, naturally enough, nothing more than the platitudes you could pick up watching a golf video. How does it apply practically to either development or infrastructure? What does it mean in terms of support or operations? What the heck am I talking about?

Let me give some practical examples of how project follow-through makes a world of difference.

  1. On a software development project I try to save out 5% of my developers time for modifications to the administrative tools post launch. Let’s face it; we cannot develop a good administrative tool before the support team has a chance to really dig in and run the software for a while. If we can produce a new, improved management tool for our colleagues in the first few weeks of the operational period, we save a lot of trouble down the line.

  2. On any project I assume at least a week of my own time will go into post deployment operations and support meetings. At those meetings I will learn that, no matter how hard we tried, we didn’t provide all of the documentation needed. This means that I’ll use at least another week of business analyst or technical writing time hammering out the appropriate documents.

  3. It never hurts to call a random selection of the people you met during the project and see how things turned out for them. In fact, doing so lets you learn a lot about what is really happening out in the field. For a development project, this can give you enough insight to start in on a patch immediately. For an infrastructure project, it can point out system dependencies you never even knew existed.

These are just some things I try in the field. I’m sure there are other ways to keep moving and bring follow through into our projects.