The 5 Habits Of Highly Dysfunctional Companies

The concept of management by projects is a non-starter. The average company is not a project-driven company, and likely never will be. So why is this an idea that continues to be so prevalent? What problems — real or perceived — do its proponents hope to address? And if the project-driven organization cannot exist, what business model will surface that will reasonably address these problems? This series takes an in depth look at these questions, and offers insightful and reasoned answers.

As I previously discussed, project management as practiced in organizations today is heading for a shake-up. Projects are successful today in most instances despite the company, not because of it. But management by projects is not the answer.

Project management will not supplant the existing structures and processes. These frameworks need to evolve, however, if companies are ever to realize their project management goals consistently and reliably. Organizational structures need to recognize project management, but they won't be replaced by it.

As a means of beginning the discussion of what projects will look like once organizations fully embrace the need for consistent and effective project management, let's explore some of the key barriers that exist today:

• The budget year. Possibly the single biggest barrier to how company's think about projects today has got to be the arbitrary division of our money into 12 month periods. How many times have we heard that the deadline for the project is December 31, because that's when the money runs out? How many more times are we going to hear it before companies wake up and realize that projects don't have to be managed in 12 month stints? When will the bean counters clue in that just because it makes their jobs easier, that doesn't mean it's in the best interests of the company?
• Planning for the budget year. If the budget year is the biggest constraint, how we plan for it is a very large number two with a bullet. Most projects get conceived well in advance of actually being planned and initiated. Fair game; this isn't going to change, because the amount of work we have will always exceed the resources we have to do it. It's what keeps us employed. The first time projects get estimated, however, is during the budget planning cycle, which for most companies represents a time when we haven't got a clue what the project is going to do, let alone how much it will cost or how long it will take. Yet once the initial estimate is established, it becomes an immovable constraint, never to be revised or forgotten. We need to change our approach to the budget cycle so that we understand the project first, or we allow fluidity in the estimates until we actually know what we're trying to do. Or both.
• Managing each project to it's overall numbers. In know, I know. On the face of it, this one makes no sense. But think about it. As a company, we invest millions in projects every year. Some projects are over budget, and some are under. We kick the project managers who are over, and praise those who are under and next year we do it again. The reality is, projects are uncertain. Some will come in over their targets. Some will be under. Get a grip. If we spend $10 million every year on 30-odd projects, then manage to the $10 million. If one project needs more, take it from the project that has some to spare. But don't kick the project manager that went over. You still want them to perform on the next one, don't you?
• Creating a business case for everything that moves. Don't get me wrong. Business cases are a good thing. As with all good things, however, they are best when taken in moderation. Not all projects should require a business case; some aren't big enough to warrant it and some are too obvious to warrant it. And some projects have no direct benefits, but they're essential to other ones that do. Don't make infrastructure project justify the benefits when it's the strategic projects that use the infrastructure that will deliver the goods. Don't make the first strategic project justify all the benefits of the infrastructure, and give the others that follow a free ride.
• Not being sure of what we want the project to really do. It is true that the single greatest reason for project failure is not fully and completely defining the project requirements. It is equally true that many project customers haven't really got a hot clue what they actually want. Projects are born for all sorts of reasons. Some we start, some we inherit, and some were invented in a conference room years ago, where no one's had the grace to put them out of their misery. If you don't know what you want, cannot define the conditions that will determine whether you have it, or how you are going to evaluate whether the having is a good thing, don't let the project start. And if you do, again, don't take it out on the project manager you force to carry the ball in a game you can't define.

There are many more reasons that projects and operationally-driven organizations currently do not play well together. This is just a start. But resolving these few issues would go a long way to dealing with how projects and companies can co-exist more effectively.