Software development, much like manufacturing is drastically
changing. In order to stay on top, project managers need to accept and adapt to change. This
chapter provides focus areas for PMs concerned about: risks, cost, complexity, business climate and
The traditional world of project management belongs to yesterday. There will continue to be applications for which the traditional linear models we grew up with are appropriate, but as our profession matures we have discovered a whole new set of applications for which traditional project management (TPM) models are totally inappropriate. The majority of contemporary projects do not meet the conditions needed for using TPM models. The primary reason is the difficulty in specifying complete requirements at the beginning of the project. That difficulty arises from constant change, unclear business objectives, actions of competitors, and other factors.
Not having a complete and defined set of requirements precludes generating a complete work breakdown structure (WBS), required by all TPM models. Most observers would agree that except for the simplest of projects, it is not possible to specify complete requirements at the start of a project. Even if you could, one could easily argue that the world doesn't stand still just because you are managing a project. Changes in business conditions, the competition, and technology all can and do render requirements incomplete or at least misguided. The contemporary business climate is one of unbridled change and speed. Requirements are never really established; they continue to change throughout the life of the project. Cyclical and recursive models are coming into vogue; yet, many organizations continue to try to fit square pegs into round holes. How foolish, and what a waste of time and money. The paradigm must shift, and any company that doesn't embrace that shift is sure to be lost in the rush. Alan Deutschman's axiom "change or die" was never truer than it is in today's project-management environment.
The Contemporary Project Landscape
Change is constant and unpredictable! That comes as no surprise to anyone. In fact, change itself is changing at an accelerating pace. That should come as no surprise to anyone either. Yesterday's practices belong to yesterday. Today is a new day with new challenges. All project managers, whether the most senior or simply the "wannabes," are challenged to think about how to effectively adapt their approaches to managing projects rather than routinely follow yesterday's recipe.
There is a great deal of uncertainty on the road to breakthrough performance. Success will not come unless accompanied by courage, creativity, and flexibility. If we simply rely on the routine application of an off-the-shelf methodology, failure is very likely. As you will see in the pages that follow, I am not afraid to step outside the box and perhaps take you outside of your comfort zone. I am going to stretch your thinking about how to deliver effective project management, and hence deliver expected business value.
Nowhere is there more need for change than in the approaches you take to managing the class of project whose solution is not clearly defined or whose goal is only vaguely defined. These projects occur often, and most often do not fit your current practices. Anecdotal data I have collected from my world travels suggest that at least 70 percent of all projects do not fit the traditional, linear project-management life cycle that we have grown up with.
A challenge has been issued to all of us. That challenge is to align our project management processes and techniques with the changing needs of the project, your business environment, and the markets you serve—or risk being dismissed as irrelevant. That means we must embrace change in our approaches and models, as well as develop models that embrace change. The goal of this book is to introduce a new approach to managing projects—one that rises to these challenges. I call this approach the Adaptive Project Framework (APF).
The initial version of APF was developed as part of two separate engagements with my clients. Neither of these was a software-development project. In one engagement, the client required development of a project-management life cycle (PMLC) that was fully integrated into a systems-development life cycle (SDLC). The other engagement was to design a kiosk application for a large supermarket chain. So, one project involved business process design, while the other involved new-product development. APF can be applied to both types. That sets APF apart from most of the Agile approaches, which are designed around software-development projects. I'll have more to say on both of these engagements as two of the four case studies used in this book.
Buried beneath the mysticism that surrounds the technology revolution, a problem has surfaced. Businesspersons have an insatiable appetite to have their wants met. Sounds good so far, and no one would deny them that right. Surely technology could come to their rescue and help them get what they wanted. However, I have learned that wants are often the clients' expression of what they think is a solution to some unstated or poorly defined problem they face. If we are lucky and their wants accurately reflect the solution to their problem, then the direction of the project is clear. But wants don't often align with needs. Therefore, if you focus on satisfying wants, you may be focusing your attention in the wrong place and courting possible failure. Behind those wants are the true needs, which are often not stated. The businessperson has not distinguished between wants and needs; in fact, the wants have gotten in the way of seeing the real needs. This is not a matter of prioritization. It is a lack of understanding of the problem. This situation has persisted from the beginning of the technology revolution to this day.
If you remember anything from this introduction, remember the message conveyed in Figure I.1:
that what the client wants is probably not what the client needs. If you blindly accept what
clients say they want and proceed with a project on that basis, both you and the clients may be in
for a rude awakening. You will have built something the clients cannot use. Often
Wants versus Needs
in the process of building the solution, the clients learn that what they need is not the same as what they say they wanted. Here we have the basis for rolling deadlines, scope creep, and an endless trail of changes, reworks, over-budget situations, and schedule slippages. TPM has to strain to keep up with the realities of projects such as these. A lot of time is wasted planning things that never happen. It's no wonder that more than 65 percent of projects fail. That has to stop.
We need two things. The first is a process for discovering the needs that underlie the wants. Continuously asking "why" questions can uncover needs. I use Root Cause Analysis almost exclusively to peel away the wants and get to the real needs. Second, we need an approach that is built around change—one that embraces learning and discovery throughout the project life cycle. The approach must recognize that change will occur regardless of our attempts to the contrary. Our approach must have built-in processes to accommodate the changes that result from the learning and discovery that will certainly take place during execution of the project.
This book introduces a model that was designed precisely to accommodate these requirements. APF is that model. The name APF was carefully chosen.
From its very beginning to its very end, APF is designed to continuously adapt to the changing situation of a project. A change in the understanding of the solution might prompt a change in the way the project is managed, or in the very approach being used. Learning and discovery in the early cycles may lead to a change in the approach taken. For example, starting with an APF approach, you quickly discover the complete solution from the first few cycles of the project plan. Should you continue to use APF? Maybe some other Agile Project Management (APM) model would now fit better, or you might consider switching to some form of TPM, say an incremental approach. The new characteristics of the project will be the basis for any change of approach.
Nothing in APF is fixed. Every part of it is variable, and it constantly adjusts to the characteristics of the project. The changes in APF are not taken from a predefined list of possible changes. The changes in approach are a creative response to the changing needs of the situation. Obviously, APF requires meaningful involvement of the client and the project team, acting in an open and trusting partnership. Anything short of that will invite failure. To be successful with APF, you have to think like a chef and not like a cook! The cook can only follow recipes, and if an ingredient is missing, may be at a loss as to how to continue. A chef, on the other hand, has the skills and experiences to adapt to the situation and create recipes that work within the constraints of available ingredients.
My girlfriend provides an excellent example of what I mean. She makes a cheesecake that is to die for. Late one Sunday evening, she asked whether I would like her to bake a cheesecake for us. That's a no-brainer for me, and so I said "you bet." A few minutes after she started, I heard some rummaging around in the cupboards, followed by a moan from the kitchen. There was no vanilla extract, and that was an essential ingredient of her recipe. It was too late to go to the market, so I suggested she put the batter in the fridge and we'd pick up the vanilla extract in the morning. A few minutes later, I could smell a cheesecake in the oven. Maybe she had found the vanilla extract? No she hadn't. Instead, she found a container of vanilla frosting, and vanilla extract was one of its main ingredients. She figured out how much vanilla frosting would equal the vanilla extract called for in the cheesecake recipe and used that instead. The cheesecake was awesome! So what does this have to do with project management? My point is that if all you can do is blindly follow someone else's recipe for managing a project, you won't have a chance. But if you can create a recipe adapted to the conditions of the moment, you will have planted the seeds of success.
Projects are unique, and are never repeated under the same set of circumstances. So why isn't our approach to managing them unique as well? I'm not advocating a wholesale change in management approach, but rather a thought-out approach—one that takes into account and deals with the vagaries of the project. There are project, organizational, and environmental characteristics to account for in choosing the best-fit project management approach. Among the characteristics I have encountered, the following arise frequently, and their impacts must be considered in your final decision as to the best-fit approach:
- Market Stability
- Business Value
- Technology Used
- Business Climate
- Client Involvement
- Goal and Solution Clarity
- Number of Departments Affected
- Organizational Environment
- Team Skills and Competencies
- Completeness of Requirements
- Project Manager and Team Member Availability
Any combination of these project characteristics can cause a change in how the project is approached. For example, if a project approach requires heavy client involvement and you know from experience with this client that that won't happen on this project, then you wouldn't choose that approach. That may mean you have to compromise and choose a less-than ideal approach to work around lack of meaningful client involvement. (Chaos Report 20072 lists, for the very first time, lack of meaningful client involvement as the number-one reason why projects fail.) Alternatively, you might build in a workshop on client involvement, and based on the results of the workshop make your decision on which project-management approach to use.
As another example, suppose your organizational environment is characterized by frequent reorganization and realignment of roles and responsibilities. In such an environment, sponsorship and priorities of active projects will change. Your best-fit project management approach should be one in which deliverables are introduced in increments or short intervals rather than all-at-once at the end of a long project. Such a strategy will reduce the risk of wasted resources and loss of business value due to early termination of the project. I'll return to this discussion in Chapter 9: APF Frequently Asked Questions.
APF has several variations. I compare it to following a recipe versus creating a recipe. TPM follows recipes. APF follows a framework. The TPM project manager needs to know how to follow a step-by-step task list with little thought of why. The TPM project manager is, in a certain sense, captive to the accompanying project-management approach. APF, on the other hand, creates recipes. APF project managers need to understand the situation they face and adapt their toolkits to fit the situation. APF allows for that adaptation as the project situation changes. The APF project manager is in charge of the approach rather than the approach being in charge of the project manager, as is the case with TPM projects.
In order to place APF in the proper context, I like to envision the various project-management approaches as being mapped into a very simple project landscape. That is the topic of the next section. The project-management environment is an ever-changing one. It is defined by no fewer than seven interdependent variables. They are:
- The characteristics of the environment in which the project will be executed
- The characteristics of the project itself
- The business process life cycle
- The project management life cycle
- The profile of the project team
- The profile of the client team
- The hardware/software technology to support the whole endeavor
While this may seem overwhelming, it isn't. I'll explore the complexities of this multi-dimensional environment with you and show you how to obtain and sustain an effective project-management presence in this changing environment.
For years now, management gurus have preached that an effective organization is one where there is a balance among staff, process, and technology. Staff is smart. Of that there is no doubt. How many times have you heard an executive say, "Just put five of our smart people together in a room and they will solve any problem you can throw at them"? That may be true, but I don't think anyone would bet the future of the enterprise on the continuing heroic efforts of an anointed few. Technology is racing ahead faster than any organization can absorb, so that can't be the obstacle. Process is the only thing left, and it is to the business process that we turn our attention in this book. But it isn't just your normal everyday business process that interests us. We are going to look at a process that is really a process to define a process, rather than a staid and fixed approach—or recipe as I like to call it. Following the recipe analogy a bit further, I want to teach you how to create the recipe rather than just blindly follow some predefined recipe.
Balance between Staff, Process, and Technology
Several researchers have observed that successful organizations exhibit a balance among staff, process, and technology. As far as I know, no one has been able to build an assessment tool to measure the extent to which that balance exists. Several years ago, I undertook a project to develop an assessment instrument that measures the project-management balance in an organization with respect to the priority (and attention) it gives to staff, process, and technology. The assessment instrument is used to establish the current state and desired end state, and to suggest strategies for evolving from the current state to the desired end state. The underlying model that I developed is shown in Figure I.2.
The triangle represents the three dimensions that determine project management balance: staff,
process, technology. For the purposes of this assessment tool, Staff refers to the project team.
Process refers to the project-management strategy that has been selected for the project. (The same
model applies to any business process.) Finally, Technology refers to the tools, templates,
hardware, and software that support the chosen project-management process.
The Balance among Staff, Process, and Technology in an organization
The triangle is divided into six non-overlapping zones. Each zone is named with a combination of the letters S (representing Staff), P (Process), and T (Technology). Their ordering in the sector name gives us the ordering of their distances from each vertex, with the closest vertex listed first. The closer to a vertex a data point lies, the more important is that vertex to the organization. So, the combination SPT would mean that Staff is most important, Process less important, and Technology of even lesser importance to the organization. The ordering in this example also means that Staff (the project team) drives the choice of Process (the PMLC model) and that Staff and Process drive the choice of Technology (supporting hardware and software to be used).
The scores for each of the three parameters are linearly constrained. For this model the sum of their scores is 200, but it could be any number. This means that there is a dependency among the three parameters, and that every data point is constrained to lie within the boundary of the triangle.
The assessment data is summarized along these three dimensions and represented in the form of a straight line with a square at one end (current state) and a diamond at the other (desired state). The distance of the end points of the line to the vertices of the triangle give us a comparative measure of the priority of the given dimension to the organization. The closer the end point is to the vertex, the higher is the priority of the variable associated with that vertex. In this example, the location of the square tells us that the organization currently places a high degree of importance on Technology, less on Process, and least on Staff.
In other words, the technology infrastructure has been dictated. That infrastructure determines the project-management process to be used, and the project team is chosen to be compatible with the established technology and process infrastructure. The location of the diamond tells us that the desired project-management culture is to have more-or-less equal importance placed on Process and Technology (Process has a bit higher priority than Technology), with the highest priority given to Staff. In other words, members of the project team are chosen first. They then determine the best project-management strategy to be used for the project they are to be assigned to, and finally they choose from among all available technologies those that best support their choice of project-management strategy. The SPT zone is the zone that should be preferred by most organizations, although not every organization will have the same desired end state. There will be variations depending on industry. For example, financial institutions will depend more heavily on Process and Technology, whereas the retailing industry might depend more heavily on Staff and Process.
The length of the line is directly proportional to the degree of organizational change that will be needed for the organization to reach its desired support environment. As part of my research, I expect to develop strategies to help the organization move from its current state to its desired state. If you are interested in more information about the SPT assessment tool, please contact me at firstname.lastname@example.org.
In this book, I take the position that the characteristics of a project are the entry point into this model, and those characteristics drive our choice as to the team skills and competencies needed; then the team will determine the project-management tools, templates, and processes that should be used; and finally, the team and the tools, templates, and processes chosen will determine the best-fit technology to support it all. Obviously, this is not a recipe book to be blindly followed. Rather, it is a framework that teaches you how to create a recipe. Figure I.3 tells my story clearly. In other words, one of my objectives is to help you think like a great project manager and become a great project manager.
This was first published in March 2010