THE CONTEMPORARY PROJECT LANDSCAPE

by Dr. Robert K. Wysocki, Senior Consultant, Cutter Consortium

We weren't forced to follow the old ideas.

-- J. George Bednorz, IBM researcher and Nobel laureate

Traditional project management (TPM) practices were defined and matured in the world of the engineer and construction professional, where the team expected -- and got -- a clear statement from clients concerning what they wanted, when they wanted it, and how much they were willing to pay. All this information was wrapped in a neat package and delivered to the project manager. All the i's were dotted and t's were crossed. All the correct forms were filed, and all the boxes were filled with the relevant information. Everyone was satisfied that the request was well documented and that the deliverables were sure to be delivered. The project team clearly understood the solution it was expected to provide, and it could clearly plan for its delivery.

Until the mid-1950s, this was the prevailing environment in which a project manager operated. At that time, while the computer was well on its way to becoming a viable commercial resource, it was still the province of engineers and a few anointed gurus who spoke the arcane language of computers. Project management continued as it had under the management of the engineers. But by the 1960s, the winds of change arrived. Using computers to run businesses was now a reality, and positions such as programmer, programmer analyst, systems analyst, and early forms of the database architect developed. These professionals were really engineers in disguise but nonetheless were somehow expected to interact with the business and management professionals (who were totally baffled by the computer as well as by the mystics that had figured out how to communicate with it) to design and implement business systems to replace manual processes. This represented a total metamorphosis of both the business world and the project world, and members of the industry never looked back.

Buried beneath the mysticism of the computer was another problem: the inability of systems personnel to distinguish between customer wants and needs. If you glean anything from the following discussion, remember that what the client wants probably isn't what the client needs. If a project manager blindly accepts what clients say they want and proceeds with the project on that basis, he or she is in for a rude awakening. Because in the process of building the solution, the client often discovers that what it needs is not what it has requested. Here we have the basis for rolling deadlines, scope creep, and an endless trail of changes and rework. Traditional projects must strain to keep up with the realities of projects such as these, and it's no wonder that more than 70% of projects fail. This situation had to stop.

Part of the problem arose from the perception of the computer as a cure-all and a silver bullet. Many project managers believed, "All we have to do is push a button, and the rest is automatic. Conducting business will be simple." But unfortunately, wants got in the way of identifying real needs. Project managers needed an approach built around change -- one that embraced learning and discovery throughout the project lifecycle. They needed to build in processes to accommodate the changes that result from this learning and discovery.

In the face of all the changes that ushered in the information society, TPM remained stagnant, showing no signs of change. When the IT project manager had a hammer, every IT project management problem looked like a nail. Things seemed to be working -- or at least no one complained that they weren't. The reality was that the old ways were becoming less effective in delivering successful projects. New ways were needed to handle the increasing complexity and uncertainty. For several years now, I and other project management consultants have suggested that one size doesn't fit all. By this notion, we mean that the project manager should decide based on a project's particular characteristics which portions or variations of the traditional approach should be used. As a project went from high to low risk, from high to low cost, from mission- critical to routine maintenance, from groundbreaking to well- established technology, the project management approach went from the complete traditional methodology to subsets and variations of the traditional approach.

The question that goes to the heart of project management is, "What basic approach makes sense for this kind of project?" Once an approach is chosen, the subtleties of adapting it to the project can be addressed.

In sum, the traditional world of project management belongs to yesterday. Of course, there will continue to be applications for which TPM is appropriate, but for a whole new set of applications, TPM is totally inappropriate. The paradigm must shift, and any company that doesn't accommodate the shift is sure to be lost in the rush. "Change or die" was never a truer statement than it is today.

Why do we need yet another way of managing projects? Don't we have enough choices? The answer is that while we have plenty of choice, projects still fail at a high rate. I believe part of the reason for this failure rate is that we haven't yet completely defined at a practical and effective level how to manage the kinds of projects that we are required to manage in today's business environment.

-- Dr. Robert K. Wysocki, Senior Consultant, Cutter Consortium