The longest journey might begin with but a single step. It will have a lot more of them than a short journey, though, and your feet will feel a lot more sore when you’ve finished it.

Robert Otwell made this point well, explaining:

I have worked on two multi-year projects (federal government customers — no surprise there), and on both the lack of completion wore people down. People want to take pride in their work and feel that they are accomplishing useful and even important things. If a project completes in two, four, or six months, the project team takes pride and celebrates launching a product. When a project grinds on month after month you are almost embarrassed to answer when someone asks what you’re working on.

It’s a wonderful point. I’ve often pointed out that long projects create no sense of urgency. This is the flip side of the same coin: Short projects aren’t merely more urgent, they’re more satisfying for everyone involved.

Once more with feeling: Projects are, first and foremost, human activities. Before the plan, before the methodology, before all the tips and techniques comes leading the project so the men and women who do the heavy lifting are as positively motivated as possible.

Speaking of excellent points, Veronica Sanford made this one:

People don’t want projects to finish because they believe that once the project is closed they will never hear from IT again. Thus, to get what they want, the Lines of Business keep that project umbilical cord alive and well, adding requirements and being dissatisfied with the results of the project.

Not only do they believe it, they’re often right to believe it. The way IT governance is practiced in many companies pretty much guarantees it, in fact. It’s a shame, because it isn’t a particularly difficult problem to avoid. What’s necessary is a practice that’s well understood by commercial software vendors; less so by internal IT groups: Release management.

Release management is halfway between working on projects and working on small enhancements. Organize application support into application teams (or if you’ve implemented some sort of enterprise suite, into teams focused on major modules). Each team forms its own steering committee composed of key stakeholders who agree what new features will go into each release. Depending on the nature of the beast, IT implements new releases either monthly, quarterly, or when the team is in the mood.

Monthly or quarterly generally works better.

A couple of items to consider if you’re new to release management:

• If business stakeholders aren’t accustomed to periodic releases, you’ll face some resistance at first as you transition from enhancement-by-enhancement governance. The selling points, though, are compelling. One that stands out is amortizing the time and cost of testing across all enhancements instead of having to laboriously test each one.

• You’ll almost certainly have to institute a bypass process to handle emergencies and “emergencies” (if you don’t know the difference, you haven’t worked in IT very long). It will be up to the steering committees to keep use of the bypass process in check.

• At times you’ll find yourself launching large projects that affect the same applications or modules you manage through release cycles. This can get tricky. The best solution I know of is to just let it happen … but make sure the application team vets the project team’s design and coding, and that the project makes use of the application team’s standard integration and regression test cases.

• Release management without version control software is sufficiently close to impossible as makes no difference.One other point: If your organization is among those that have instituted a Business Analyst function as a communications liaison between developers and end-users, embed your Business Analysts in the application support teams.

Or, better, get with the KJR Manifesto (Rule #5): Elevate the role of your Business Analysts so they serve as business process designers, and have developers work directly with business users in designing and implementing the incremental improvements that go into each release.

Among the benefits, two stand out. First, taking the Business Analysts out of the enhancement loop actually improves the accuracy of design, because business users get to explain what they want directly to the people who will make it happen.

And second, helping redesign the business is a more rewarding role than translating from English into English.