Sunday, September 5, 2010

The 5 Habits Of Highly Dysfunctional Companies

The 5 Habits Of Highly Dysfunctional Companies

Posted by Guest in Project Management
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 it's 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.

Aug 30 2010

The Best Project Management Methodology

Posted by Marios Alexandrou in Project Management
I received an e-mail from a visitor to my site who described the following situation:
Hope you're fine. I was wondering if you could possibly help me. I'm a final year project management student currently undertaking a university research project as my final year assignment. I was shocked to see that so many methodologies actually exist as we have only been taught Prince2. My question is, what would be an ideal methodology for me to undertake in regards to a university project on children with asthma? My university has received funding from an organization called [company name removed] and we want to create an Expert Patient Program for young children with asthma. This will be done by conducting a number of workshops and drawing conclusions from the children's views. Any ideas?
Aug 27 2010

Projects and Investments

Posted by Guest in Project Management
In a previous post, we discussed the reality that while the practice of project management may continue to advance, overall project results will not significantly improve until better decisions are made through the full lifecycle of an idea. One of the most significant barriers to improvement, however, is the comprehension of what this lifecycle represents in terms of stages -- and where the responsibility for decisions resides in each stage.
Aug 24 2010

The Road To Organizational Change

Posted by Guest in Project Management
The road to organizational change is an odd one: both well traveled and unfamiliar at the same time. The intensity of resistance, the many bumps and potholes and the sense of isolation all too often lead one to surmise that the road is one seldom traveled. It is easy to assume that few have passed this way, and those that have had not too easy a time of it. Certainly no easier than ourselves as we face it today as if for the first time.
Aug 21 2010

Is Project Management a Fad?

Posted by Guest in Project Management
An emerging theme that I have encountered in conversations of late is the perception that project management is becoming the latest management fad. Interestingly, my reaction has ranged from "Is it?" to "Already?" to "Why did it take this long?" For someone who has been on the inside of promoting and developing project management as a corporate competency, it is easy to develop the impression that this is the way things have always been done. Objectively stepping back, however, project management as a formal discipline is a much newer concept for many organizations.
Aug 18 2010

Where Should The Responsibility For Project Management Really Lie?

Posted by Guest in Project Management
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 it's 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.
Aug 15 2010

Two Project Management Metaphors

Posted by Marios Alexandrou in Project Management
I recently got through the book, The Blind Men and the Elephant by David Schmaltz. The sub-heading of this book is "mastering project work". That, along with recommendations from others, prompted me to buy the book expecting to read about processes and techniques for managing projects. That's not quite what I got.
Aug 12 2010

10 Styles of Innovation

Posted by Marios Alexandrou in Project Management
In a recent issue of
Aug 09 2010

Portfolios and Project Management Organizations (PMOs)

Posted by Guest in Project Management
To do a project, or not to do a project. That is the question.
The rationale by which project decisions get made varies widely from organization to organization, and is for the vast majority of organizations largely a subjective process. While a few short years ago the linkage between projects and strategy was a much more tenuous one, it is now becoming much more widely recognized that projects are a key means of realizing organizational strategy. The choices we make in terms of the projects that are taken on have a significant influence in defining organizational strategy for the organization.
Aug 06 2010

10 Steps to a Successful Project

Posted by Marios Alexandrou in Project Management
The state of Maine spent $25 million on a web-based Medicaid claims system. In exchange for all that money, they got a $300 million backlog in unprocessed claims. Doesn't seem like a particularly good deal, does it? The details of this web services project were unique, but the problems were quite common. Projects fail all the time and there are often plenty of people to point fingers at.

No comments:

Post a Comment