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.