All Posts in Organizational Design

|In: Organizational Design|Last Updated:

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.

Comments

|In: Leadership|Last Updated:

It’s summer — the season when sunlight falling across a sandy beach will warm you through and through, driving the last vestiges of winter’s cold from your chilled and battered muscles. Ahhhh.

Put a convex lens between you and the sun, though, and OUCH!

The difference between diffused warmth and ignition is focus.

Swing a hammer at a piece of wood and you’ll get a dent in the wood. Swing the same hammer at a nail positioned over the wood and you’ll get a hole in the wood, filled with a nail. The difference between a dent and penetration is focus, too — the nail focuses the hammer’s energy onto a much smaller area.

Want your IT organization to have more impact? The secret is no secret — it’s the ability to focus your organization’s energies.

The only problem is, the entire company’s political ecology operates to blur your focus.

It happens like this: A dozen or so different executives and managers submit project requests … important requests … for IT. IT has enough staff to support only three of them at any one time. That, however, would result in winners and losers, so you reach a compromise with the executive committee. Instead of choosing three projects to work on, staffing them fully, and getting each done in the six months a fully staffed project would take, you instead launch all twelve. With twelve projects in play you assign your staff among them so that everyone works on four projects at once.

Being reasonable, you recognize that each project will take four times as long as it would with dedicated teams working on them. But that’s okay, because while nobody is getting exactly what they want, everyone is getting enough.

Except that it isn’t okay. It’s a disaster. First of all, no project should ever have a timeline longer than six months. Beyond that there’s no sense of urgency — two years and forever are mathematically equal, according to the calculus of project management.

Second of all, it isn’t the case that a developer, divided among four projects, will get the same amount of total work done as one who is dedicated to a single project. It takes time for people to switch their attention from one to another — real, significant time, which translates to perhaps 10% or more additional overhead.

And finally, even if neither of these effects were true, it’s still bad business. Compare the business benefit to be had in the two cases. With dedicated project teams, every six months another three projects would finish, delivering their business benefit. One fourth of the total benefit would arrive after six months, another fourth after a year, and so on. With divided effort, the company experiences no benefit at all until two full years has elapsed. If all projects deliver the same annual benefit … call it a Benefit Unit (BU) … then after two years the company with dedicated project teams will receive nine BUs. The one with divided effort will receive none.

Nine to nothing — that’s a winning score. The mathematics behind it isn’t even complicated. In most companies it’s also unachievable, due to a recently-discovered psychological effect known as “envy.”

Okay, I lied about it being recently discovered.

Envy works like this: Imagine I offered you five thousand dollars, just for reading Keep the Joint Running every week. I imagine you’d be happy to have it.

Now imagine that after a few months you found out that I’m giving your colleague in the next cubicle ten thousand dollars for reading it. Would you still be happy about the five grand you’re getting? If so, you’d be unusual. Most people would be unhappy at the unfairness of it instead. They’d be envious.

So it is with IT governance. Give the members of the executive committee a similar choice — everyone gets the same small benefit, or everyone gets more benefit, but it’s distributed unequally — and most will prefer the former.

Most CIOs think of IT governance as a process — an organized series of steps, that operates on evidence and logic in an almost algorithmic fashion to establish IT’s priorities.

It sure would be nice if that was the case. It can be the case. But only if, as a prerequisite, the executive “team” is really a team — aligned to a common purpose instead of each one focusing on personal perquisites.

It does happen. It just doesn’t happen very often.

Comments