Challenges to Effective Project Management
,As discussed earlier in this introduction the contemporary project environment presents the project manager and the client with a number of challenges to managing such projects effectively. The use of the best-fit PMLC model will rise to these challenges and adapt as necessary.
Flexibility and Adaptability
Traditional Project Management (TPM) practices were defined and matured in the world of the engineer and construction professional where the team expected (and got, or so it thought) a clear statement from clients as to what they wanted, when they wanted it, and how much they were willing to pay for it. All of this was delivered to the project manager wrapped in a neat package. The “i”s were all dotted, and the “t”s were all crossed. All the correct forms were filed, and all the boxes were filled with the information requested. Everyone was satisfied that the request was well documented and that the deliverables were sure to be delivered as requested. The project team clearly understood the solution they would be expected to provide, and they could clearly plan for its delivery. That describes the naive world of the embryonic project manager until the 1950s. By the mid-1950s the computer was well on its way to becoming a viable commercial resource, but it was still the province of the engineer. Project management continued as it had under the management of the engineers.
The first sign that change was in the wind for the project manager arose in the early 1960s. The use of computers to run businesses was now a reality, and we began to see position titles like programmer, programmer/analyst, systems analyst, and primitive types of database architects emerging. These professionals were really engineers in disguise, and somehow, they were expected to interact with the business and management professionals (who were totally mystified by the computer and the mystics that could communicate with it) to design and implement business applications systems to replace manual processes. This change represented a total metamorphosis of the business world and the project world, and we would never look back.
In the face of this transformation into an information society, TPM wasn't showing any signs of change. To the engineers, every IT project management problem looked like a nail, and they had the hammer. In other words, they had one solution, and it was supposed to fit every problem. One of the major problems that TPM faced, and still faces, is the difference between wants and needs. If you remember anything from this introduction, remember that what the client wants is probably not what the client needs. If the project manager blindly accepts what the clients say they want and proceeds with the project on that basis, the project manager is in for a rude awakening. Often in the process of building the solution, the client learns that what they need is not the same as what they requested. Here you have the basis for rolling deadlines, scope creep, and an endless trail of changes and reworks. It's no wonder that 70-plus percent of projects fail. That cycle has to stop. You need an approach that is built around change — one that embraces learning and discovery throughout the project life cycle. It must have built-in processes to accommodate the changes that result from this learning and discovery.
I have talked with numerous project managers over the past several years about the problem of a lack of clarity and what they do about it. Most would say that they deliver according to the original requirements and then iterate to improve the solution one or more times before they satisfy the client's current requirements. I asked them, “If you know you are going to iterate, why don't you use an approach that has that feature built in?” Until recently with the emergence of Agile Project Management approaches the silence in response to that question has been deafening. All of the agile and extreme approaches to project management emerging in practice are built on the assumption that there will be changing requirements as the client gains better focus on what they actually need. Sometimes those needs can be very different than their original wants.
Obviously, this is no longer your father's project management. The Internet and an ever-changing array of new and dazzling technologies have made a permanent mark on the business landscape. Technology has put most businesses in a state of confusion. How should a company proceed to utilize the Internet and extract the greatest business value? Businesses are asking even the more basic questions — “What business are we in?” “How do we reach and service our customers?” “What do our customers expect?” The dot.com era began quickly with a great deal of hyperbole and faded just as quickly. A lot of companies came into existence on the shoulders of highly speculative venture capital in the 1990s and went belly up by the end of the century. Only a few remain, and even their existence is tenuous. The current buzzwords e-commerce, e-business, and knowledge management have replaced B2B and B2C, and businesses seem to be settling down. But we are still a long way from recovery.
The question on the table is this: “What impact should this have on your approach to project management?” The major impact should be that project management approaches must align with the business of the enterprise. Project management needs to find its seat at the organization's strategy table. Project managers must first align to the needs of the organization rather than their own home department. That is today's critical success factor. The appearance of the business analyst has added new challenges, as discussed in the next section.
Deep Understanding of the Business and Its Systems
The best project managers understand the business context in which project deliverables must be defined, produced, and function. This means not only an understanding of the internal systems and their interaction but also the external systems environment of suppliers and customers in whose environments the deliverables must function. The systems analyst and business analyst are key components in that understanding. There is a good argument that can be offered for the morphing of the project manager and the business analyst into one professional having the requisite skills and competencies of both. That discussion is out of scope for this book but it is a discussion that needs to take place. For a series of articles that I wrote on this morphing of the project manager and the business analyst, a series that others have since commented on, see the Business Analyst Times.
Take Charge of the Project and Its Management
I like simplicity, and I believe my definition of the project landscape using only two variables — goal and solution — with two values each — clear and not clear — is simple yet all inclusive of all projects. The result is four categories of projects.
- When the goal and solution are clear, it generates the Traditional Project Management (TPM) category.
- When the goal is clear but the solution is not, it generates the Agile Project Management (APM) category.
- When neither the goal nor the solution is clear, it generates the Extreme Project Management (xPM) category.
- And finally when the goal is not clear but the solution is, it generates the Emertxe Project Management (MPx) category (though this may seem nonsensical, it is not — more on this one later).
Every project that has ever existed or will exist falls into one and only one of these four categories. Each category gives rise to a PMLC, and each PMLC has at least one specific project management approach in it. This four-category classification gives rise to five PMLC models. It is these models — their recognition and use — that is the subject of this book.
Project Management Is Organized Common Sense
The PMBOK definition of project management is crisp, clean, and clearly stated. It has provided a solid foundation on which to define the process groups and processes that underlie all project management. But I think there is another definition that transcends the PMBOK definition and is far more comprehensive of what project management entails. I offer that definition as nothing more than organized common sense. Projects are unique, and each one is different than all others that have preceded it. That uniqueness requires a unique approach that continually adapts as new characteristics of the project emerge. These characteristics can and do emerge anywhere along the project life cycle. Being ready for them and adjusting as needed means that we must be always attentive to doing what makes the most sense given the circumstances. Hence, project management is nothing more than organized common sense.
We are not in Kansas anymore! The discipline of project management has morphed to a new state, and as this book is being written, that state is not yet a steady one. It may never be. What does all of this mean to the struggling project manager?
To me the answer is obvious. You must open your minds to the basic principles on which project management is based so as to accommodate change and avoid wasted dollars and wasted time. For as long as I can remember, I and my colleagues have been preaching that one size does not fit all. The characteristics of the project suggest what subset of the traditional approach should be used on the project. This concept has to be extended to also encompass choosing the best-fit PMLC model based on the characteristics of the project at hand. For the interested reader you can learn more about this mindset in my book Effective Software Project Management (Wiley, 2006). In that book I define a discipline that fully integrates PMLCs and systems development life cycles (SDLCs) into a strategy that I have called a Software Development Project Methodology (SDPM). The result is an approach that aligns with the needs of the client, the enterprise, and the project.