Risk averseOrganizations use project management to achieve results. Information technology companies, large government programs, and the construction industry all use project management extensively. However, many other types of organizations—police departments, nonprofits, event planners—also are finding tremendous benefits in employing project management practices. They do so in order to increase efficiency and quality in delivering services, increase customer satisfaction, and improve team performance, making it more agile and responsive. One of the greatest benefits of project management, although this may not have been your experience to date, is that it allows everyone to speak the same language and operate on the same playing field. Thus, familiarity with terminology and its shared understanding are critical for project organization members.
Every discipline has its own vocabulary. Doctors and nurses, judges and lawyers, pilots and air traffic controllers each need a common vocabulary, and project management is no exception. Customer, project, and advisory teams all have to share the understanding of key terms.
Part of the process of successfully deploying project management in your organization is to standardize the terminology. That way, when a team member talks about risks, scope, issues, requirements, and other project manager concerns, everyone else knows what he or she is referring to.
This book is for functional managers like you who are becoming involved in projects within their organizations, so this section identifies the key terms you need to understand and elaborates on their context to help you apply the terms in your new role as the customer in the provider/customer relationship.
I promised myself when I began writing this book that I would not recite the same jargon or restate the same basic concepts found in hundreds of other project management books. But there is one definition that everyone needs; it comes from one of the project management bibles, A Guide to the Project Management Body of Knowledge (PMBOK® Guide). It is the definition of a project: “A project is a temporary undertaking to create a unique product, capability or result, having a defined start and end point and specific objectives, that when accomplished signify completion.”1
Let’s dig a bit deeper into this definition. Projects can create something tangible, namely, a product such as a software application, a marketing campaign, or maybe a patio in the backyard. Projects can create a result, such as an office move. That result would consist of having all office employees set up in a new location with the functioning lights, heat, air conditioning, security systems, computers, and office equipment needed to do their jobs. Projects can create a capability, such as the ability to track the location of freight in transit or to detect hazardous materials before people enter a building.
Projects have important characteristics that differentiate them from normal operations. Projects do not go on forever (although some may feel like they do); they are only in existence for a defined amount of time. You have probably witnessed projects taking on a life of their own with no clear end. Lacking clarity on how to know when you are done causes several challenges for you. Big projects can continue for so long that they appear to become a permanent part of the organization. Team members begin to focus more on a constant stream of activities than on clear milestones and deliverables. Urgency wanes and cynicism builds the longer the initiative goes on without the kind of visible results that make customers and team members feel confident. Projects do not sustain an organization; operations sustain the organization. Projects introduce change to make the operation more sustainable.
Projects consist of a set of interrelated activities across a distinct set of resources. Some organizations struggle tremendously with understanding what constitutes a project. There are organizations that use dollar amounts to categorize initiatives as formal projects, which then require the initiatives to fall under project governance procedures. This process is flawed; it incents people to work around the governance if they don’t like it. So they break the project into smaller components, which they pass off as change requests or maintenance activities.
Other organizations treat simple tasks as projects. I had a client who wanted me to train their documentation specialists in project management. The work these people did consisted of tasks, not projects. They updated various training and user manuals to keep pace with new system upgrades that were being implemented. By the time they planned the project, which was really just a task, they could have completed it. It was nonsense.
Projects require the coordination of these interrelated activities across resources. Mary Jo’s task output is an input to Susan’s task. Susan’s task output is going to be used by Bob, Joe, and Sam. They will use Susan’s output and someone else’s task output and create a new output. Each of these tasks needs to be done just once because it is unique and has not been done before. Each task must be completed in a defined time frame and with a budget. This type of work rises to the level of project.
Another key aspect of a project is its uniqueness. When we view a project as ordinary, we have preconceived expectations. The templates and processes used on ordinary projects often break down. However, when your reputation is on the line to deliver an important change to your organization, the project becomes more than ordinary. The success you have as functional manager in the provider/customer relationship hinges on treating your project as unique. With a unique project, your mental focus sharpens, your critical thinking increases, and your attention to detail heightens.
Projects require continuous planning and evaluation between the customer and the provider to address how the work will be completed. Project professionals refer to this as progressive elaboration. Progressive elaboration centers on the 30- to 60-day detailed plan that continually gets updated and refined as the work we do teaches us about how the coming work should be executed. This learning process must be done jointly within the provider/customer relationship to make it as useful as possible. Your provider, in planning, executing, and controlling work, learns by experiencing how the work is performed and compares it to how he or she expected it to be performed. Likewise, as the customer, you evaluate the use and applicability of the outputs of the project work and compare them to what you really need to achieve your organization’s objectives.
Many newcomers to project management have varying definitions and impressions of the field. Some immediately think “bureaucracy,” or maybe “herding cats.” Others think of technical jargon such as “critical path,” “milestones,” or my favorite, “earned value.” Some immediately ask for new software to be installed on their computer, so they have yet another application to play with.
Naturally, project management has an official definition by the Project Management Institute: the application of knowledge, skills, tools and techniques to project activities to meet the project requirements.2 To clarify the work, however, I like to define project management with these three components:3
1. Managing the competing demands of scope, time, budget, quality, and risk.
2. Managing differing and competing stakeholder expectations.
3. Meeting both defined customer requirements (needs) and undefined customer requirements (expectations).
The first statement might be familiar to you; it is rooted in the triple constraint (cost, schedule, and scope/quality), which has been officially transformed to include “manage.” A project manager must manage quality, risk, and human resources in the face of organizational influences and both external and environmental factors. Usually, one or two constraints are firm. For example, the project may have to be completed by a certain date, while flexibility remains in time frame and scope.
The second statement is a hard dose of reality. Stakeholders will have differing and competing interests and expectations that must be managed. If project managers are viewed as mere coordinators with limited authority or credibility, much of this stakeholder management will rest on your shoulders as the functional manager.
The last statement in the project management definition is my favorite. Project management requires you to meet the customer’s documented requirements as well as their undocumented requirements. But the expectations for projects can grow like a wildfire burning out of control. Customers and users rarely understand the written requirements, or even read them. Their expectations have developed over time about how they want things to be in their perfect world. Signing off on requirements may move the project along, but until customer expectations are aligned with scope documents, progress shown on Gantt charts is a false reality. Progress will begin to slow, if not come to an abrupt halt, when the customer’s lofty expectations encounter the hard facts of real, tangible, inspectable project deliverables. Furthermore, stakeholder expectations can vary wildly within a project organization. You must uncover them and rein them in or suffer the consequences of dissatisfied customers, one of whom might be you!
A project requires resources that must be organized into a temporary organizational structure, preferably project teams, customer teams, and advisory teams. A stakeholder is any person or organization who is actively involved in the project, for instance a project manager, and anyone who can be positively or negatively impacted by the project. The key word is “can.” If the project is successful, those impacted positively should be obvious. If the project fails or underperforms, who will be affected? Understanding these impacts and the personalities, power, influence, and control of these stakeholders is critical to the success of your project. You can help your provider document the stakeholders who are involved and can be positively or negatively impacted.
“Stakeholder analysis” refers to the action of analyzing the attitudes of stakeholders toward the project. It is done during the preparation phase of a project and should continue on a regular basis to track how stakeholders’ attitudes change over time. “Stakeholder dynamics” involves the identification of the key stakeholder groups and their major issues and trends that may impact success.
If your project manager isn’t conducting a stakeholder analysis in his or her first week on the project, you are not being well served. Many project managers will shortchange this step, especially if they have worked in the organization for years and know everyone, see them in the cafeteria, and chat with them in elevators. Why bother creating another meaningless document of stakeholders involved in the project when they are the same ones involved in all of the other projects? There is a reason, a valid one: unintended outcomes. These outcomes are not the ones intended by a purposeful action—they are surprises. They can be positive: a sunken battleship in shallow waters can become an artificial coral reef that is valuable to scientists and divers. They also can be negative: the covert funding of rebels and resistance groups, like the Afghan Mujahideen, has contributed to the rise of Al-Qaeda.4 The ability to anticipate a project’s unintended consequences increases significantly with a thorough stakeholder analysis.
A project has different types of stakeholders, and grouping them by type can help you with analysis. Direct stakeholders are directly involved in the project and/or directly involved in the anticipated benefits. Direct stakeholders can be primary stakeholders: the sponsor or executive(s) funding the projects, yourself, and your project manager. The primary group may include other key people who have a lot to gain or lose from the project. Direct stakeholders can also be secondary stakeholders, sometimes known as intermediaries. These are persons or organizations that are not directly involved in the project but are affected by it. These people are likely to be suppliers to or customers of the core business process that the project will impact. Secondary stakeholders often are recipients of those unintended outcomes.
The second major stakeholder group consists of indirect stakeholders. Indirect stakeholders may be people in human resources, finance, or regulatory groups who are required to ensure that your organization stays in compliance with internal organizational policy and procedures and with state and federal regulations. They do not directly benefit from the outputs of your project. They are likely to have more to lose than to gain and can be a good starting point for identifying possible unintended outcomes.
The most important stakeholder is usually the sponsor, defined as the individual or group within the organization performing the project who provides financial resources. The sponsor also should champion the project, communicate the vision, set reward systems, make critical decisions, and help attain buy-in from other key stakeholders.
Another important stakeholder is the customer(s) or user of the product, service, or result you are creating. As a functional manager acting in the provider/customer relationship, you have to manage not only your own expectations but also the expectations of those closely involved in consuming project deliverables that lead to project benefits.
Identifying all stakeholders is essential for the purpose of clarifying their expectations and success criteria and turning these into measurable goals. It will also help you get a feel for the true extent of the project. The project environment is comparable to a playing field for baseball, soccer, or football. Once you actually step on the field, it is usually much larger than it appeared. The energy required to chase down a foul ball is much greater than you anticipated sitting in the stands with your hot dog and beer. And the playing field increases dramatically when you have assumed the role of the internal leader of your project. You must begin to work both sidelines.
Another important term is deliverable, or a tangible, verifiable work product. The customer can assign requirements or features to deliverables; those requirements can be validated or tested. Deliverables can have a quality measure. Your project team must create something that is tangible and verifiable along the way to project success. These deliverables become the primary management control tool for the customer team and project team.
The term deliverable goes hand in hand with the phrase acceptance criteria. When creating a project deliverable, be sure to understand it before expending effort on it. Who is its intended audience? Who will consume it? What decisions will result from it? How does the audience wish to experience it? Finally, what are the acceptance criteria? When you don’t think with the end in mind, project effort is wasted, and rework is required to make the deliverable conform to customer expectations.
All projects involve risk, or uncertainty about the future. Risks are possible events that may increase or decrease the chances of achieving your project success. The project team’s success traditionally is defined as getting your project done on time, within your budget, and creating output: the design features, specifications, and quality attributes that were planned and expected. But your success should be the recognition of the benefits, not simply acceptance of the project’s output.
You can identify these risk events using the proper facilitation techniques, but quantifying them is much more difficult. Gaining a clear perception of your stakeholders’ different perceptions of risk is important and useful. There are four general types of risk attitudes:5
Risk averse
Risk tolerant
Risk neutral
Risk seeking
Like general attitudes, these risk attitudes are not fixed and can be managed. Someone with a risk-averse attitude is uncomfortable with uncertainty and has a low tolerance for ambiguity. These people seek security and resolution when facing risk. They will find established procedures comforting and will make every attempt to minimize threats. A primary stakeholder with a risk-averse attitude is likely to take aggressive risk response actions to avoid or minimize risks.
People with a risk-tolerant attitude take uncertainty in stride, seeing it as a normal part of everyday life. They do not show heightened awareness or concern for risk opportunities or adverse risk events, nor do they take a proactive approach to managing risks. A primary stakeholder with a risk-tolerant attitude views risk as normal and possibly entrepreneurial in nature.
Someone with a risk-neutral attitude seeks plans and tactics that have high payoff and uses creativity to address unknowns. A primary stakeholder with this attitude is likely to use a mature approach to managing risk and will focus on long-term goals.
Finally, a person with a risk-seeking attitude enjoys challenges and seeks plans and tactics that have high payoff. This leader is adaptable and not afraid to take action. He or she may be seeking the thrill of a challenge, but may underestimate risk’s probabilities and impacts. A primary stakeholder with this risk attitude often has a casual acceptance of risks and may pursue opportunities aggressively, sometimes at the peril of the team.
There is no wrong risk attitude; however, a risk attitude should match the type of project and its objectives. Most projects and programs are better off with leaders who do not have extreme risk attitudes.
As a provider, I need a functional manager who is willing to talk about risks. Duane, a functional manager and rising star, was assigned to be the business leader of a strategic initiative. Duane embraced the role, partnering with his project managers and external providers. As one of his providers, however, I noticed that Duane did not like talking about risk. He treated it as an insult if we brought risks to the attention of his management; he felt it implied that he wasn’t doing his job.
This mentality is much more common than I first imagined. Project managers and their methodologies and templates force risks to be documented, but that is usually where it stops. Meaningful discussion about risk with stakeholders is much harder to achieve when the insecurity of functional managers and business leaders is getting in the way.
All projects require a level of decision making. Executives must make fundamental decisions about the organizational change upon which they are embarking, but then they turn over the execution decisions to you. Conflicts are a normal part of any change process, but keeping the conflict healthy takes effort and skill. The provider/customer partnership must facilitate decision making by educating stakeholders and recommending courses of action.
Project management is both an art and a science. The art involves dealing with the people on the project, the stakeholders, and how they interact and contribute to the project. Your project is likely to assemble a diverse set of individuals who may have never worked together before and may never again when the project is over. These resources are matrixed in from various organizations to assist you in accomplishing the project’s goals. It is not uncommon for resources to be located in distant offices or foreign countries; in fact, a team may never meet a key team member in person. Diversity is a huge asset for a project, but it must be managed by the provider/customer partnership. Remember that all of these people create their own perspectives of you, your partnership, and your project.
Good decisions are made when a culture of inclusion, rather than exclusion, exists between the provider/customer team and key stakeholders. If the provider/customer relationship itself is not working, it chokes off knowledge and insight from within the project that are needed for effective decision making.
The science of project management can be intimidating, but using common business sense can remove the mystery.
All projects have a life cycle of needs and requirements. Organizational needs first emerge from a change that generates these needs.6 This change leads to recognition of stakeholders’ needs. This recognition requires a conscious effort to ensure that the project team, customers, and any vendors share a thorough understanding of the organization’s needs.
Finally, the needs are articulated in an in-depth manner that provides the basis for requirements and project scope. To make matters more challenging, customers typically have a sense of their needs, but may not completely understand them or their implications, as these needs are often dynamic and evolutionary. Therefore, the provider/customer partnership must be responsible for pinpointing the real need and proactively managing stakeholders’ expectations.
No industry definition exists of a standard project life cycle; cycles are unique to specific organizations, the project environment, and organizational best practices. How project phases are distinguished in your current organization is likely different from any previous organization for which you worked. The project phases have common characteristics, however. They are generally sequential: first we plan, then we design and build, test, train, and finally implement. Planning, design/build, testing, training, and implementation may be five distinct phases of the project. Another organization may call them discovery, requirements, design, construction, and deployment. These phases can overlap or be discrete; for instance, design may or may not start before the requirements phase is complete. Outputs or deliverables from one phase are reviewed and validated for use in the next phase. The risk and stakeholder influence is greatest during early phases, which means your provider/customer partnership must be working well early on in the project. Resources and their related costs normally peak during middle phases of the project and then trail off. How effectively and efficiently these resources are applied is directly related to how well the start-up phases are executed.
Every project should execute a set of common processes, which are applicable to all projects. But you have a strong voice in determining how they are applied to your particular project. Managing projects is not a cookie-cutting operation. As a functional manager, grasping this concept is essential. You should use the common processes associated with all projects but also use common sense in adapting, customizing, and applying them correctly to your specific situation. Unfortunately, many project managers and project offices still have not grasped this concept. I give an overview of these processes below. Your project manager should lead the action on each process, but as the customer, your understanding and involvement in all phases is absolutely vital.
The common processes are:
Initiation
Planning
Executing
Monitoring and controlling
Closing
Initiation. Your project should go through some level of formal initiation: management determines that this effort is worth an investment of resources with a goal of achieving a return benefit. Typically, this is more than just a hallway conversation. It should include analysis of why this project has value, analysis that involves the most important stakeholders, including the project manager and key customer(s). This process identifies and initiates the provider/customer relationship and delegates a level of authority to this partnership to start working on the project.
Closing. Every project must include closing processes. “Wait,” you are probably thinking, “what happened to planning, executing, and monitoring and control?” A secret to successful projects is that you should be thinking about closure as soon as you begin initiation. A key question for you is: How do we know when we are done? When teaching project management classes, I chuckle when I find the closing processes and materials at the end of the lesson plan. It is always the shortest component of the class. I wonder if this is because so few projects actually make it to closure or if everyone is just so exhausted by that point in the project that we simply move on.
Closure starts on day one of the project. Thinking about what it means to be successful has to be a constant activity throughout the project and every process.
Planning. Planning is the common process with the greatest variability and it must be adapted to be applied correctly to your specific situation. The PMBOK® Guide defines 20 discrete planning processes. Which ones you apply to your project and to what level of detail is something that should be discussed early in your provider/customer relationship. This book does not review all 20 planning processes, but it does discuss the critical ones in detail. If you want to know all 20 (which I do not believe is necessary for a functional manager), you can buy the PMBOK® Guide or, better yet, ask your project manager. Anyone certified as a Project Management Professional (PMP) will know the 20 processes. Work with your partner and craft the proper planning processes that meet the needs of your project.
If you find yourself struggling to get your arms around a large project, your stakeholders are probably even more confused and see your project as a vast mess of various activities and issues. This is not good a thing. I remember sitting in a conference room with key project members soon after their project was given the green light. The room was filled with various attempts to define “What we do next.” One senior manager said, “Let’s get our issues on the white board.” He took a marker and began to solicit issues from others in the room. Will the existing network infrastructure support the system? Who is responsible for selecting the vendor? This person is busy on another project until May. Does this business unit understand that they will need to reduce staff? Twenty or thirty issues later, this random mix of concerns that were all relevant overwhelmed the mood of the room with anxiety. Then the senior manager said, “OK, does everyone know what to do? Let’s meet in two days and see where we stand.” This level of planning is not sufficient for significant change. Good planning processes relieve stakeholders’ anxiety rather than adding to it. When planning, you want to organize and approach the work in a methodical manner that actually gives stakeholders the sense, “Yes, we can do this.”
Executing. Directing and managing the execution of the project is doing what you said you would do in your plan. Without execution, nothing would get done! The common mistake is to jump into executing the project too quickly, particularly when you are relying on outside vendors. Now, I am all for getting the project started promptly and creating quick wins to establish momentum. But when vendors play a vital role in your project, the tendency is to select a vendor too soon, before sufficient internal planning has been done. Vendors find it in their own best interest to eliminate their competition, get the business, and then exert their influence to achieve their own goals, which are not necessarily the same as yours.
Selecting a vendor is not an initiation or planning process; it is an execution process that must be preceded by understanding what work you wish to give to outside vendors. This determination is made as you plan out the deliverables and requirements you need in your project to satisfy your organization’s need. Then the project team documents what exactly they want the vendor to do. Only then should proposals, capabilities, and pricing be reviewed for you to decide which vendors will best serve the project. All project execution activities should be a result of some planning effort, documented or undocumented.
Monitoring and Controlling. The common processes of monitoring and controlling require you to understand another important term: baseline. Baselines are developed during planning but used in monitoring the project execution. A baseline provides a definitive measure of what you expect to deliver, when, and for how much. If you don’t have a baseline, you are not really capable of effective control.
Baselines are intuitive. For example, if you expect to spend $2,000 on a vacation, you have requirements and expectations associated with this initiative. Your vacation will be at a warm, sunny beach resort with activities for you and your children. You expect to spend $1,000 for transportation, $600 for food, and $400 for entertainment. The duration of your vacation is seven days. You have consciously baselined the scope, cost, and schedule for your vacation. If you are like me, you are not going to wait until you get back home to start monitoring the features, costs, and duration of your vacation. Four days into the trip, you realize you have gotten carried away and spent much more money on meals and entertainment than you expected. You know you should have nearly half of the meal and entertainment budget left to spend, but when you add up the receipts, you find that you already spent $850 on these items. In your mind, you are tracking your baseline expenditure of costs to your actual costs. You need to decide whether to slow down a bit, eat in or settle for fast food for a few days, or overrun your budget. You make judgments as to the benefits of these modifications to your vacation plan. How will your kids react, and what about that key stakeholder, your spouse? I hope you don’t track daily expenditures to the penny on your vacation, but many of us do have to be responsible in our leisure expenditures. What actions are you going to take to achieve the benefits you want? You apply these same principles to the quality of the services, the risks of certain activities, and so on. It is inherent in our nature to monitor and control our life events.
Your project is likely to have primary and secondary stakeholders that extend far beyond your vacation scenario’s immediate family members. As a primary stakeholder in the customer role of the provider/customer partnership, you are expected to be a responsible steward of your organization’s consumption of resources. The complexity of features, benefits, costs, quality, time, and risks is much greater, requiring that your baselines be very clear if you wish to monitor the actual results of project execution and compare them against a given point in the project. For some reason, organizations struggle with monitoring and controlling projects, and the statistics on project failure prove it. Maybe this is because project teams are a part of the larger organization and feel less collective accountability, or maybe they just do not have the necessary information about their baselines or actual performance to make the comparison.
Monitoring and controlling is nothing more than comparing what you expected to happen, as defined in your plan, to what is really happening, your actuals. The comparison of baselines to actuals creates variances. Variances are a part of life, but in corporate cultures, variances are viewed as indicators that somebody must be doing something wrong. I see project managers updating project plans with actual dates that mirror the planned dates even though the project is running behind schedule. This skewed approach is doomed to fail. The baselines created do not hold the projected timeline stable while actual work commences. The only recognized set of dates is the plan itself. As work progresses, updates are made to those dates, masking any variances until the end date or critical published milestones start to slip. By then it is too late.
The goal of monitoring and controlling is to understand your variances early enough to take the proper corrective action to bring the actual work back in line with the baselines. As functional manager, you must demand that your project manager accurately capture the actual work performance information for your scope, cost, and schedule, and compare it against a baseline of scope, cost, and schedule on a continuous basis. Have the project manager explain how he or she intends to do this, and then ask for it regularly.
Common project processes are different than project phases. Phases are unique to the project environment, discipline of work, and the organization. These core common processes—initiation, planning, executing, monitoring and controlling, and closure—are just that, core components to all projects.
Each of the common processes for all projects has subject matter that drives underlying aspects of the process. To plan a project, you must have information or subject matter about the project’s scope. Thus, scope is specific subject matter associated with all projects. Projects are temporary and have a time element associated with them: the time required to complete the project. Time is another subject matter related to all projects, as is cost. Each of these subject matters is related to every other one. We need to understand the project scope to understand the time and cost of the project. If scope increases, cost and/or time are likely to increase. If the sponsor imposes an aggressive deadline, that will impact scope, how much you can get done, and likely the cost.
In my first book, I made a proclamation that projects don’t fail, people fail. Projects are executed by people, human beings like you and me. These people are resources and resources are common to all projects. The management of resources is a subject matter common to all projects. How well these resources are managed impacts other subject matters. If they are poorly managed, the time to complete the project may slip. If we have untrained or inexperienced project resources, the scope may increase or quality of the deliverables may suffer.
Quality is another common subject matter, the quality associated with deliverables or product of the project and the quality of the management of project work. Deliverable or product quality infers fitness of the tangible output to be used by the customer. This should objectively be measured, but customer expectations and how they match up to their experiences of the product ultimately determine quality. Quality applied to the work of the project infers continuous improvement of how the project is planned, executed, and controlled. Has the team captured the right information in the scope? If not, you have a quality issue. What is the team doing to improve the definition of scope?
Communication is another subject matter common to all projects. How well does communication flow to stakeholders on the project, or are they in the dark, making decisions with outdated or missing information? That becomes a quality issue. Quality has relationship to other subject matters: if quality is poor, a deliverable may need to be reworked, increasing cost and delaying the schedule. Consider this: if all projects require resources, these resources must communicate on the project’s interrelated activities. If communication is poor, conflicts may erupt among stakeholders, impacting how human resources are managed. A strong case can be made that effective communication may be the most critical subject matter on projects. Complaints about poor communication within and across temporary matrix project organizations are nothing new. The flow of information can be connected to the quality of human resources management on your project. The effectiveness of communication impacts all aspects of the project. Statements such as, “I didn’t know the customer wanted a report as well” or “I thought we decided to push the deadline a week” are examples of poor communication affecting other subject matters.
Tired yet? I am. Your primary stakeholders are pushing you to get this project done, so let’s move on. Remember that these primary stakeholders, namely, your sponsor(s), have decided to commit real money, in the form of resources and possibly equipment, software, and services to complete this project. Why? They expect to receive benefits from this initiative. But these benefits are not in the bank. They have to be earned through good project management and decision making. A level of uncertainty always exists about achieving the stated objectives of a project because a project seeks change, something a team hasn’t done before. Uncertainty is a part of every project. This uncertainty manifests in events—risks—that can occur and may derail the plans. Risk is another common subject matter and, of course, it is related to other subject matters—cost, schedule, and quality, to name a few.
Not every project has equipment, materials, or large purchases associated with it, but many do. The purchase of materials is directly related to the scope of the project. The human resources available to work on the project may require purchase of services. Procurement is another common subject matter on projects. Procuring services and materials involves risk, such as having less control, or not knowing whether a vendor’s quality of workmanship is better than that of your internal resources. You can begin to see the obvious relationships between procurement and other subject matters.
We have discovered eight subject matters associated with all projects:
Scope
Time
Cost
Human resource management
Communication
Risk
Procurement
All these subject matters have various relationships and influences over each other. These subject matters (commonly referred to as “knowledge areas” for project professionals) need to be applied properly to our common processes of initiating, planning, executing, monitoring and controlling, and closure. This is the bread and butter of project management methodology. The recognition and comprehension of the interaction of the core common processes and their inherent subject matter(s) is common to all projects. This is referred to as integration. If we are looking to demystify project management, we need to understand these basic relationships. In summary, projects have five core processes and nine subject matters (including integration). Figure 5-1 illustrates the five core processes and the subject matter(s) associated with each process.
Figure 5-1 Five Core Processes
Putting It All Together. Let’s first understand the relationships between the common processes. Initiation will always be influenced by your organization’s type of business, culture, procedures, and support systems. The typical output is the project charter, which formally sanctions the project, explains the reasons why the change is needed, and identifies some key personnel. The result is the delegation of authority from senior management to the project team to begin committing the organization’s resources to the project. The key subject matter involved in this process is communication. Communicating the vision of the project and identifying, then analyzing, stakeholders is a critical part of successful initiation.
The output of initiation should be tangible documents such as a project charter and stakeholder analysis. A charter does not have to be complicated; I have seen brief, one-page charters that are signed by sponsors and presented in kick-off meetings. (See sidebar showing a sample charter of a business analysis training project.) To some extent, planning can be going on while initiation is being finalized. How much planning is done and the cost that goes into planning are subject to the constraints of the initiation process.
Like the charter, a stakeholder analysis does not have to be complicated. The key is looking both wide and deep when identifying stakeholders and then evaluating how much control they have over decisions and resources and how much level of concern they have over the project outcome. Figure 5-2 is a sample stakeholder analysis template. Once information is collected on the stakeholders, they can be plotted in a matrix to identify the most critical.
Figure 5-2 Sample Stakeholder Analysis
These outputs become inputs into the planning process. Planning is a process common to all projects … even yours! Planning can be the most complex of the processes, and every subject matter should be addressed at some level. The obvious ones are scope, cost, and time, but planning for quality deliverables and quality project management processes is also important.
Plan how the stakeholders you just identified and analyzed will receive project information. Plan for the potential uncertainty—risk—and how you will deal with it. Significant purchases of material and services are subjects on which you and your project manager must provide critical thinking and thought leadership very early on in the project. The 20 discreet planning processes in the PMBOK® Guide have an exponential number of relationships. In Chapter 2, I distilled the 20 processes into eight that are relevant for the functional manager. Your provider should be able to provide guidance on the complexities and nuances of the details espoused in the PMBOK® Guide. In your role they are not necessary; your partner supplies this expertise.
The outputs of planning will be inputs for doing the actual work: executing and keeping it on track, and monitoring and controlling. Do not wait for all the planning to be done before starting the work of the project. Plan some work, do some work, and control and monitor the work. Here is a simple example: Defining the scope of the project will reveal the resources needed to complete it. Getting those resources assigned to your project (acquiring resources) is executing the work of the project. Identifying the deliverables to be completed by the project team and accepted by the customer team is planning. Reviewing proposed deliverables with your primary stakeholders is executing the work of the project; namely, communicating or distributing information and managing their expectations.
The typical mistake is starting work that really should not be started yet, such as writing software code before clear project objectives are determined or knocking down walls before permits have been secured. Any project work that commences should have baseline documentation of the scope, cost, and time required to complete it. Baseline documentation comes from your planning processes so that it can be compared to the actual work results (deliverables) that have been produced by your executing processes. All of these become inputs to monitoring and controlling. Figure 5-3 depicts the basic interactions between planning, executing, and monitoring and controlling processes.
The deliverables completed in executing processes are inputs to monitoring and controlling. Within monitoring and controlling, quality standards are applied. If deliverables meet scope and quality standards, they are accepted by your customer as a part of monitoring and controlling and the project or phase of project is closed.
Just as you did with your vacation, when monitoring and controlling a project, you begin to compare planned results with actual results, determine the variances, and decide on possible courses of action to bring actual results in line with planned results. You should control not just cost and schedule, but scope, cost, time, risk, quality, communications, and procurements. Each subject matter will have a proposed action that becomes an input to the change control process—part of your monitoring and controlling process. Decisions are made as to which changes to the project plan should be accepted. These decisions become inputs back into your common executing and planning processes.
Figure 5-3 Controlling Process Interactions
These feedback loops between monitoring and controlling, planning, and executing will continue during your project. Ideally, this happens through a combination of subjective observation and evaluating hard project data.
Here are some key points for review:
Planning, executing, and monitoring and controlling all work hand in hand, often subtly. It is important to recognize these different processes and manage them accordingly.
Planning outputs are always inputs to both the executing and the monitoring and controlling processes.
The main outputs of monitoring and controlling processes are decisions on how to respond to your variances and resulting actions. These decisions and actions are inputs back into planning and executing.
Determining whether deliverables have the needed features and functionality and deciding whether to accept them are part of the monitoring and controlling process.
Determining whether deliverables meet the desired quality standard is also a monitoring and controlling process. However, it is different from verifying features and functionality, which are related to project scope. For practical purposes, the customer team will treat these evaluations as one and the same, but you must understand whether you are dealing with a scope issue or a quality issue when determining corrective courses of action.
Many confusing terms and phrases are rooted in the various methodologies adopted by organizations. These include project management methodologies and system or software development methodologies. Often, the methodologies clash in the actual project playing field but having a basic understanding of the various methodologies you may encounter can help alleviate confusion.
A methodology is a set of guidelines or principles that can be tailored and applied to a specific situation. In a project environment, these guidelines might be a list of things to do. A methodology could also be a specific approach or a set of templates, forms, and even checklists used over the project life cycle. A formal project methodology should lead the work of all team members throughout the life cycle of a project. A project management methodology is not a silver bullet or quick fix, but a cookbook approach for project success.7
The methodology with which many project managers are familiar is the PMBOK® Guide from the Project Management Institute (PMI). This methodology is very process driven. The common complaint is that it can be bureaucratic when not applied properly by practitioners or project offices.
Another common methodology used is PRINCE2 (PRojects IN Controlled Environments), a process-based method for effective project management. PRINCE2 is a de facto standard used extensively by the UK government and is widely recognized and used in the private sector, both in the UK and internationally. PRINCE2 focuses on business justification, a defined organization structure for the project management team. It emphasizes dividing the project into manageable and controllable stages and has the flexibility to be applied at a level appropriate to the project.8
Other project management methodologies exist, some proprietary and others non-proprietary. For any organization, the goal is to have a repeatable process that delivers successful projects.
Methodologies also apply to program management and portfolio management. A program is a group of related projects managed in a coordinated way to obtain benefits and control.9 In contrast to projects, programs have larger scope and more significant benefits. A portfolio of projects is simply collection of your organization’s project investments; however, it groups projects and programs together to facilitate the achievement of specific strategic business objectives.
Governance. Project methodologies should be under the ownership of a project office. A project office is an organizational body with various responsibilities related to the centralized and coordinated management of projects. The project office, also referred to as the project management office or PMO, should provide your organization with these services:
Maintain the processes and methodologies pertaining to the management of projects, including templates, forms, and checklists incorporating lessons learned from previous projects for use in future projects.
Develop project managers’ career paths and provide training and hard and soft skill development.
Facilitate the responsible estimating and budgeting of projects, including developing plans and schedules and providing status updates.
Facilitate the monitoring and control of projects by implementing standard processes to execute change control on projects.
Establish and maintain project-related software tools, and maintain project management software standards.
Provide expert assistance in the form of mentoring and coaching for the staff involved.
Other possible project office functions include managing shared resources, monitoring compliance with project standards, coordinating communication across projects, and developing project policies and other shared documentation.10
Software development has its own methodologies. As a functional manager in the provider/customer relationship, you don’t need expertise in each one, but knowing the basics is helpful, as is the ability to recognize when a methodology is not serving you well.
Our first methodology is the classic waterfall model. Even though it has weaknesses, large organizations such as financial institutions, health care organizations, and governments still use this methodology. These organizations typically have a mix of older, legacy, high-volume transaction processing applications and new technologies to make data more accessible and manageable. They require these applications to work in tandem, seamlessly, 24 hours a day, 7 days a week, sharing data, updating databases, presenting information over the Internet or at points of customer transactions.
The major weakness of the waterfall model is that, after project requirements are gathered in the first phase, managing changes to the project as requirements change or more information becomes available to the project team is cumbersome. Requirements must be completed and approved before functional designs and technical designs are completed. Then coding commences based on requirements and design, and when it is complete, testing begins. The life cycle can be long and can frustrate customers. But if requirements are well known and the software is mission critical and complex, this methodology does work.
In response to the weaknesses of the cumbersome waterfall model, new models were developed that add some form of iteration to the software development process. In the spiral system design life cycle (SDLC) model, the development team starts with a small set of requirements, rather than waiting for the entire project’s requirements, and goes through each development phase for that set of requirements. The advantage of the spiral model over the waterfall model is that the iterative approach allows development to begin even when all the system requirements are not known or understood by the development team.
The top-down SDLC model was popularized by IBM in the 1970s and its concepts are used in other SDLC models. In a pure top-down model, high-level requirements are documented and programs are built to meet these requirements. Then the next level is designed and built. A good way to picture the top-down model is to think of a menu-driven application. A major problem with the top-down model is that real system functionality is not added and cannot be tested until late in the development process. If problems are not detected early in the project, they can be costly to remedy later.
In the bottom-up SDLC model, the lowest level of functionality is designed and programmed first, and finally all the pieces are integrated together into the finished application. This means that, generally, the most basic components are developed and tested first. The idea is that any project show-stoppers will surface early in the project. The bottom-up model also encourages the development and use of reusable software components, those that can be used multiple times across many software development projects. The disadvantage of the bottom-up model is that an extreme amount of coordination is required to be sure that the individual software components work together correctly in the finished system. Few systems are developed purely from the bottom-up model.
With the demand for faster software development, and because of many well-documented project failures, rapid application development (RAD) was introduced as a better way to add functionality to an application. The main new feature of RAD not found in older SDLC models is the use of prototypes. After a quick requirements-gathering phase, a prototype application is built and presented to the application users. Feedback from the user provides a loop to improve or add functionality to the application. Early RAD models did not involve the use of real data in the prototype, but new RAD implementations do use real data. The advantage of rapid prototyping models is that time-to-market is greatly reduced. Rapid prototyping skips many of the steps in traditional SDLC models in favor of fast and low-cost software development. The idea is that application software is disposable. If a new version of the software is needed, it is developed from scratch using the newest RAD techniques and tools. The big disadvantage of the rapid prototyping model is that the process can be too fast, and, therefore, proper testing may be compromised.11
New software development methodologies continue to appear: the chaos model, the Agile programming model, and many others. Agile has become a popular method of developing software. The various forms of Agile include Scrum and Extreme Programming, to name a few. The Agile Manifesto values:12
Individuals and interactions over processes and tools.
Working software over comprehensive documentation.
Customer collaboration over contract negotiation.
Responding to change over following a plan.
People practicing Agile should be treating your satisfaction as their highest priority with early and continuous delivery of valuable software. They welcome changing requirements, even late in the project and they desire to work closely with business people on a daily basis throughout the project. They believe requirements and designs emerge from self-organizing teams.
One downside of Agile is its use of some terms that can keep the customer from understanding what is really going on unless the entire project organization is educated on Agile and its vocabulary. “We are starting our second sprint!” “Hello, I am your Scrum master.” “In our daily standup, we decided to simplify the requirements.” Simple questions can get odd answers. You may ask how long it will take to finish a particular functionality only to hear, “We are time boxing it.”
Without adoption of the methodology by the business, these terms end up isolating the project team, which works against their principle of valuing individual interaction over process. Another principle of true-blooded adherents to the Agile Manifesto that should concern you is that the primary measure of progress is “working software.” This should get your attention. As a customer, of course you want software that works, but you need software that supports the business change you desire to achieve your benefits. Having software engineers who are only concerned about working software and not with the ultimate desired benefits should concern you.
Regardless of the software development methodology used, the common project management processes of initiating, planning, monitoring and controlling, and closure and the respective subject matters of scope, time, cost, risk, etc. always apply. Don’t let anyone tell you otherwise.
1. Project Management Institute, A Guide to the Project Management Body of Knowledge (PMBOK® Guide), 4th ed. (Newtown Square, Pa.: Author, 2008), 5.
2. Project Management Institute, PMBOK® Guide, 443.
3. J. Davidson Frame, Managing Projects in Organizations: How to Make the Best Use of Time, Techniques, and People (San Francisco: Jossey-Bass, 1995), 119.
4. Mary Anne Weaver, “Blowback,” The Atlantic Monthly, May 1996, 24–36; http://www.theatlantic.com/past/docs/issues/96may/blow back.htm.
5. David Hillson, Effective Opportunity Management for Projects—Exploiting Positive Risk (New York: Marcel Dekker, 2004), 46–47.
6. Frame, Managing Project in Organizations, 111–113.
7. R. Max Widerman, Review of Project Management Methodologies by Jason Charvat. http://www.maxwideman.com/papers/pm-methodologies/pm_methodologies.pdf (accessed May 26, 2011).
8. ILX Group, “What is PRINCE2?” http://www.prince2.com/what-is-prince2.asp (accessed May 26, 2011).
9. Project Management Institute, PMBOK® Guide, 8–9.
10. PM Solutions, “What are the Functions and Roles of the PMO?” http://www.pmsolutions.com/insights/pmo-resource-center/what-are-the-functions-and-roles-of-the-pmo/ (accessed May 26, 2011).
11. James E. Purcell, “Comparison of Software Development Lifecycle Methodologies.” http://www.giac.org/cissp-papers/217.pdf (accessed May 26, 2011).
12. Kent Beck, Mike Beedle, Arie van Bennekum, Alistair Cockburn, Ward Cunningham, Martin Fowler, James Grenning, et al., “Manifesto for Agile Software Development.” http://agilemanifesto.org/ (accessed May 26, 2011).