Although the project plan is almost synonymous with project management, its also overused and abused in a number of ways. In this blog, we address some points to keep in mind when building and implementing an effective plan.
So, I just concluded with a very long argument with some other project managers. Maybe argument isn't the best term for it. We hold differing opinions about the functions of management and leadership, of action and intention, in the modern business world. Their views are probably a good deal more practical than mine, or at least better suited to long term survival in the corporate machine.
However, there is one thing I will not budge on. I continue to feel great distaste for the way we use project plans. Even the name is wrong; the things we put together in project are no more plans than this blog. They certainly don't accurately portray the elaborate interaction between people and ideas which actually make projects come off. Nor do they in any way measure the tremendous efforts undertaken in the leadership discipline, where we try to get people to buy in so they will work for us at all.
The first thing to realize is the project plan is a tool for communication not for control. Writing something down doesn't make it true. It's a way to communicate, in a standard form, what we think might happen. When we miss dates or things take longer than we expect, the dates have to change. Yes, that will impact other projects. At some point, someone will realize that negotiating those impacts is actually part of our job as project managers, not something to get all worked up about.
The second thing to realize is that no task on a project plan actually happens as detailed. You may hit your critical path; odds are against your WBS actually running like you think it will, and I'll eat my hat if anyone ever completed all of the tasks on an IT project plan of over 4 months duration. We simply cannot plan creative work the way we do effort driven or dependency drive activities. If we try to make reality conform to the plan for our measurement's sake, we will eventually go completely insane.
The third thing to realize is that leadership means more than management when the chips are down. People can find a way to support themselves and their families. IT people, as a rule, respect intelligence not authority or fear. If you want people to act, to spend their time and energy for you, they have to come to believe in what you want them to do. It has to be their idea, in large part, and express their views of the world. Otherwise you get what I see on a lot of project teams – late nights right at the end and a lot of rolled eyes and angry muttering.
One not so funny thought about that last point. The way we measure project managers, it's impossible to sort out the good leaders from those who wrap themselves in the process and its artifacts. One skill makes it so you can effectively deliver projects. The other drives your projects, sooner rather than later, into the ground time and time again. Which, though, do we reward?