Project Management optimize

How a theory of change affects practical project management


Today I got an email from an old friend. Well, an old colleague at least - he and I have a running feud lasting the better part of two decades. We've argued about these topics so much our disagreements fall into well oiled paths, and it's fun to just spend some time shooting barbs to each other.

The topic of our discontent is this. He believes in radical change, paradigm shift style, and quantum alterations in business productivity though technology and innovation. He puts his faith in the ability of human beings to radically change the way we think and react to events, to adopt new ideas, and to use new techniques to perform old tasks. In his defense he points to many periods of rapid change in our world, starting as early as the invention of the clay brick and "ending" as recently as the release of the iPhone.

I do not believe in radical change. In fact, I'm more in the "nothing much changes about people worth mentioning" camp. I include tools in this point of view - no matter how fast the tool changes, it takes decades for people to figure out how to really use it. "Fundamental" new technologies like computers and the Web (2.0 or otherwise) are not that different from bricks or electric dynamos in this respect. I realize this makes me something of a pariah in technology circles. In my defense, I point out that you can, pretty much word for word, map today's editorial pages to comments found on ostrikan from the early part of the 1000 BC.

So, what does this long standing argument have to do with project management? In a theoretical sense, everything. Project management is the discipline of controlling change. I don't believe that much other than surface change happens to the rituals with which human beings govern their lives so I don't see project management as being that integral to the world we live in. My friend thinks project management is the only way that a business can survive in this "new world".

In a practical sense, our differing views of change lead us to disagree on when a project actually ends. In his view a project executes, the change completes, and then you move on to the next challenge. In my view the project is just one of a series of events which might or might not lead to an eventual successful resolution of a business goal. Most often in IT the answer is we do not meet the business goal - instead we chase the immediate changes while leaving the rituals and methods of thought in place.

My colleague, who is still a professional consultant, experiences a world where projects end. I, who now work in a corporate environment, live in a world where projects have political and relationship ramifications starting years before they initiate and ending years after they formally complete.

Which of is, then, is right? Do projects ever end? Does anything really change or are we just rearranging the deck chairs while our businesses go about the process of reinforcing a caste system which we refuse to admit exists? Will Facebook and its ilk change the world or will they represent yet another failed internet revolution?

My amusement with tweaking my colleague's nose aside, I suspect it will be a bit of both. We cannot know what the real paradigm shift will be, nor can we recognize it before it appears. That's kind of the point - a true shift is so other that after it the thoughts of the previous existence no longer make sense at all. I realize that idea flies in the face of the entire industry of pundits, but there it is.

Now on to the real question, I guess. How do we apply the tension between these two points of view to create a better way to manage projects?

1 comments
Wayne M.
Wayne M.

Your friend is correctly expressing the PMI view of projects - the view that a project is a one-shot effort with a defined end point. I find this unfortunate, as I view most productive change as being incremental, i.e., the change requires a series of steps to accomplish. Additionally, the change feeds upon itself; one change opens up realms of related changes that could not be imagined prior to the initial change. My concern with the "projectization" of efforts and the marketing of project management is that we are taking a useful set of skills, isolating them, making making project management into its own goal. Rather than having a series of plannable, low risk, low cost, and low effort projects, we end up creating large, important projects that are inherently unplannable, high risk, high cost, and high effort. The bigger the project becomes, the more we expect from it, and the more pressure occurs to broaden the scope to justify the cost and schedule. Much of my more recent thought has been influenced by the agile development methodologies coming out of software development. Effort should be planned for very small time increments, two weeks to one month at a time. Long term direction can then be frequently reviewed and new directions set. By working on small increments, risk is reduced; an absolute failure only incurs 2-4 weeks of lost effort. We have the freedom to try something different and find out about it quickly; there is not the risk of investing 6, 12, 18 months into something that is not going to brign value. Radical change is best brought about incrementally. This entails a series of short-term projects and requires long-term oversight of the process.