Policies and Procedures – Page 72 – IS Survivor Publishing

Please release me

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.

Don’t supersize. Chunkanize.

Bare Bones Project Management: What you can’t not do has been shipping for a month now, and the response has been gratifying.

I wrote Bare Bones because, in my experience at least, the secret to success in project management isn’t the use of arcane, complex techniques. Like most areas of business, successful project management comes from getting the basics right. And of all the basics, the most important is to avoid long projects with big teams, because as projects get bigger, the likelihood they’ll succeed shrinks … logarithmically.

So when you can’t get the job done in six months with a core team of seven or fewer members, break the effort into chunks that fit inside these boundaries (“chunkanization,” as one client calls it). Doing so makes things simpler. But not simple — nothing ever does that. One reason:

Projects, the collections of projects called initiatives, and collections of initiatives called programs, are about business change. Most often (at least when it’s done well), an initial project creates a “functional design” — a view that paints an integrated picture for new business processes and practices, employee roles, and information technology. What follows depends on your choice of methodology, but eventually, later projects design, build and implement detailed process flows, employee position descriptions and training programs, and information technology.

Project teams focus on producing their assigned deliverables — on time, within budget, and conforming to the written specifications. The big picture is Someone Else’s Problem, so the likely result is a collection of deliverables that don’t fit together without quite a bit of sanding and hammering.

Managing multi-project initiatives and multi-initiative programs so they avoid this mess means handling at least three different types of interdependency. They are:

Conceptual: Behind any change is a set of core ideas. If everyone involved understands them, they’ll be less likely to create deliverables that meet all specifications but don’t help achieve the intended result. In other words, they’ll be less likely to say, with puzzled expressions, “Oh, you wanted wings on that airplane? Wings weren’t in the specs.”Nor is understanding the core ideas enough. For a program to succeed, you need everyone who works on it to be committed to them. Which is to say, completion can’t be enough. The participants have to personally want the program to succeed — a very different matter.
Design: Project teams make dozens of small decisions throughout the duration of the effort. For single projects there’s no issue. For multi-project initiatives or programs, different project teams will almost certainly make decisions about the same design issues.Dealing with these design interdependencies — so that these decisions are recognized when they happen and dealt with so the important ones are only decided once — is the single most difficult challenge a program manager has. It requires creating suitable administrative and governance structures. Even more important is instilling a mindset that encourages every participant in the program to help recognize these decisions when they come up, and to escalate them when they do.It’s a challenge because for each project, Just Doing It is the easier, expedient course of action. Every time a project team escalates a design issue instead, it causes delay.
Schedule: Some projects use the results of earlier ones. Since the project staff will have been reserved for each follow-on project, if a predecessor project is delayed, even for just a week or two, people sit idle. Yes, it’s basic. It’s also a difficult challenge, especially in companies where executives aren’t willing to have staff sit idle (your company, for example).Other scheduling interdependencies are more subtle. For example: Imagine three different development projects are due to complete within a month of each other. That means contention for testing environments — and your supply of these is far from unlimited.

In spite of the complexities associated with managing interdependencies, chunkanization still beats chartering huge monolithic projects. Beyond the most obvious benefits — that each project will, at worst, finish, and that benefits happen sooner — is another that’s just as important:

Every project results in unexpected insights. In a large, monolithic project, these result in scope creep, redesign, and re-work. In a chunkanized program they are additional inputs to later projects that haven’t yet been scoped, let alone launched.

So unless you can see five years into the future with perfect clarity, a bunch of chunks will beat a big block every time.