Schedules

A schedule is a model for executing the project’s activities, including durations, dependencies, and other planning information. Schedule planning can use predictive or adaptive approaches.

PLANNING VARIABLES

Because each project is unique, the amount, timing, and frequency of planning varies. Variables that influence how project planning is conducted include, but are not limited to : 

▶ 

Development approach. 

The development approach can influence how, how much, and when planning is conducted. Examples include : 

▹ 

A specific phase for planning or organizing early in the life cycle. In these situations, much of the planning is performed up front. The initial plans are progressively elaborated with more detail throughout the project, but there is little change to the original scope.

 

▹ 

An approach with high level planning up front, followed by a design phase where prototyping is used. After the project team and stakeholders agree to the design,  the project team completes more detailed planning. 

▹ 

Adaptive approaches where the project team conducts iterations. Some planning occurs up front to establish release plans and further planning occurs at the beginning of each iteration.

▶ 

Project deliverables. 

Often the project deliverables necessitate planning in a specific way. Construction projects require significant up front planning to account for design, approvals, materials purchasing, logistics, and delivery. Product development or high technology projects may use continuous and adaptive planning to allow for evolution and changes based on stakeholder feedback and technological advances. 

▶ 

Organizational requirements. 

Organizational governance, policies, procedures, processes, and culture may require project managers to produce specific planning artifacts. 

▶

 Market conditions. 

Product development projects can take place in a highly competitive environment. In these situations, project teams can undertake a minimum amount of up front planning as the emphasis is on speed to market. The cost of delay that extensive planning entails exceeds the risk of potential rework. 

▶ 

Legal or regulatory restrictions. 

Regulatory agencies or statutes may require specific planning documents before granting an authorization to proceed or to secure approval to release the project deliverable into the market.

Delivery 

Planning begins with understanding the business case, stakeholder requirements, and the project and product scope. Product scope is the features and functions that characterize a product, service, or result. Project scope is the work performed to deliver a product, service, or result with the specified features and functions. 

Predictive planning approaches start with the high-level project deliverables up front and decompose them into more detail. This approach can employ a scope statement and/or a work breakdown structure (WBS) to decompose the scope into lower levels of detail. 

Projects that use iterative or incremental approaches can have high-level themes or epics that are decomposed into features, which are then further decomposed into user stories and other backlog items. Work that is unique, significant, risky, or novel can be prioritized to reduce the uncertainty associated with project scope at the start of the project before significant investment has taken place. Project teams plan routine work based on the concept of last responsible moment. This approach defers a decision to allow the project team to consider multiple options until the cost of further delay would exceed the benefit. It reduces waste by not expending time in developing plans for work that may change or may not be needed.

Estimating Planning entails developing estimates for work effort, duration, costs, people, and physical resources. Estimates are a quantitative assessment of the likely amount or outcome of a variable, such as project costs, resources, effort, or duration. As the project evolves, the estimates can change based on current information and circumstances. The project’s phase in the life cycle impacts four aspects associated with estimating : 

▶ 

Range. 

Estimates tend to have a broad range at the start of the project when there is not much information about the project and product scope, stakeholders, requirements, risks, and other information. Figure 2-14 shows a range of -25 to +75% at the start of exploring  a project opportunity. Projects that are well along in their life cycle may have an estimating range of -5 to +10%. 

▶ 

Accuracy. 

Accuracy refers to the correctness of an estimate. Accuracy is linked to range  in that the lower the accuracy, the larger the potential range of values. An estimate  at the start of the project will have less accuracy than one that is developed halfway through the project. 

▶ 

Precision. 

Precision is different from accuracy (see Figure). Precision refers to the degree of exactness associated with the estimate. For example, an estimate of 2 days is more precise than “sometime this week.” The precision of estimates should be compatible with the desired accuracy. 

▶ 

Confidence. 

Confidence increases with experience. Experience working on a previous, similar project can help with the level of confidence required. For new and evolving technology components, the confidence in estimates is expected to be low.

Estimate Range Decreases over Time

Low Accuracy, High Precision

151

Project Performance Domains

A project performance domain is a group of related activities that are critical for the effective delivery of project outcomes. Project performance domains are interactive, interrelated, and interdependent areas of focus that work in unison to achieve desired project outcomes. 

There are eight project performance domains : 

▶ Stakeholders, 

▶ Team, 

▶ Development Approach and Life Cycle, 

▶ Planning, 

▶ Project Work, 

▶ Delivery, 

▶ Measurement, and 

▶ Uncertainty.

Together the performance domains form a unified whole. In this way, the performance domains operate as an integrated system, with each performance domain being interdependent of the other performance domains to enable successful delivery of the project and its intended outcomes.

Performance domains run concurrently throughout the project, regardless of how value is delivered (frequently, periodically, or at the end of the project). For example, project leads spend time focused on stakeholders, the project team, the project life cycle, the project work, and so forth, from the outset of the project to its closure. These areas of focus are not addressed as siloed efforts because they overlap and interconnect. The ways in which the performance domains relate are different for each project, but they are present in every project.

The specific activities undertaken within each of the performance domains are determined by the context of the organization, the project, deliverables, the project team, stakeholders, and other factors. The performance domains are presented in the following sections without specific weighting or order.

STAKEHOLDER PERFORMANCE DOMAIN

The following definitions are relevant to the Stakeholder Performance Domain :

Stakeholder. 

An individual, group, or organization that may affect, be affected by, or perceive itself to be affected by a decision, activity, or outcome of a project, program, or portfolio. 

Stakeholder Analysis. 

A method of systematically gathering and analyzing quantitative and qualitative information to determine whose interests should be taken into account throughout the project. 

Projects are performed by people and for people. This performance domain entails working with stakeholders to maintain alignment and engaging with them to foster positive relationships  and satisfaction.

Stakeholders include individuals, groups, and organizations (see Figure). A project can have a small group of stakeholders or potentially millions of stakeholders. There may be different stakeholders in different phases of the project, and the influence, power, or interests of stakeholders may change as the project unfolds.

Examples of Project Stakeholders

Effective stakeholder identification, analysis, and engagement includes stakeholders who are internal and external to the organization, those who are supportive of the project, and those who may not be supportive or are neutral. While having relevant technical project management skills is an important aspect of successful projects, having the interpersonal and leadership skills to work effectively with stakeholders is just as important, if not more so.

STAKEHOLDER ENGAGEMENT

Stakeholder engagement includes implementing strategies and actions to promote productive involvement of stakeholders. Stakeholder engagement activities start before or when the project starts and continue throughout the project.

Navigating Effective Stakeholder Engagement

Defining and sharing a clear vision at the start of the project can enable good relationships and alignment throughout the project. Establishing a clear vision that key stakeholders agree on can entail some challenging negotiations, especially with stakeholders who are not necessarily in favor of the project or its intended outcomes. As shown in Figure there are several steps to engage stakeholders effectively.

Identify 

High level stakeholder identification may be carried out prior to forming the project team. Detailed stakeholder identification progressively elaborates the initial work and is a continuous activity throughout the project. Some stakeholders are easy to identify, such as the customer, sponsor, project team, end users, and so forth, but others can be difficult to identify when they are not directly connected to the project.

Understand and Analyze Once stakeholders are identified, the project manager and the project team should seek to understand stakeholders’ feelings, emotions, beliefs, and values. These elements can lead to additional threats or opportunities for the project outcomes. They can also change quickly, and as such, understanding and analyzing stakeholders is an ongoing action. 

Related to understanding the project stakeholders is the need to analyze aspects of each stakeholder’s position on and perspective of the project. Analyzing stakeholders considers several stakeholder aspects, such as : 

▶ 

Power 

▶ 

Impact

▶ 

Attitude

▶ 

Beliefs

▶ 

Expectations

▶ 

Degree of influence

▶ 

Proximity to the project

▶ 

Interest in the project, and 

▶ 

Other aspects surrounding stakeholder interaction with the project

This information helps the project team consider interactions that may influence the motivations, actions, and behaviors of stakeholders. In addition to individual analysis, the project team should consider how stakeholders interact with each other, as they often form alliances that help or hinder the project’s objectives. For example, if the project team believes a key business manager is highly influential but has negative perceptions related to the project, they can explore how to detect the business manager’s perceptions and respond appropriately as the project unfolds. In all cases, the analysis work should be held in confidence by the project team since the information could be misinterpreted outside the context for the analysis.

Prioritize 

On many projects, there are too many stakeholders involved for the project team to engage directly or effectively with all of them. Based on its analysis, the project team can complete an initial prioritization of stakeholders. It is common to focus on stakeholders with the most power and interest as one way to prioritize engagement. As events unfold throughout the project, the project team may need to reprioritize based on new stakeholders or evolving changes

Engage 

Stakeholder engagement entails working collaboratively with stakeholders to introduce the project, elicit their requirements, manage expectations, resolve issues, negotiate, prioritize, problem solve, and make decisions. Engaging stakeholders requires the application of soft skills, such as active listening, interpersonal skills, and conflict management, as well as leadership skills such as establishing the vision and critical thinking.

Communication with stakeholders can take place via written or verbal means, and it can be formal or informal. Examples of each type of communication are shown in Table.

Types of Communication

Communication methods include push, pull, and interactive communication : 

▶ 

Push. 

Communication sent to stakeholders such as memos, emails, status reports, voice mail, and so forth. Push communication is used for one way communications with individual stakeholders or groups of stakeholders. Push communication inhibits the ability to immediately gauge reaction and assess understanding ; therefore, it should be used deliberately. 

▶ 

Pull. 

Information sought by the stakeholder, such as a project team member going to an intranet to find communication policies or templates, running internet searches, and using online repositories. Pulling information is used for indirect sensing of stakeholder concern

Engagement goes deeper than pushing or pulling communication. Engagement is interactive. It includes an exchange of information with one or more stakeholders such as conversations, phone calls, meetings, brainstorming, product demos, and the like. With all forms of communication, quick feedback loops provide useful information to : 

▶ 

Confirm the degree to which the stakeholder(s) heard the message. 

▶ 

Determine if stakeholders agree with the message. 

▶ 

Identify nuanced or other unintended messages the recipient detected. 

▶ 

Gain other helpful insights.

Monitor 

Throughout the project, stakeholders will change as new stakeholders are identified and others cease to be stakeholders. As the project progresses, the attitude or power of some stakeholders may change. In addition to identifying and analyzing new stakeholders, there is an opportunity to assess whether the current engagement strategy is effective or if it needs to be adjusted. Therefore, the amount and effectiveness of stakeholder engagement is monitored throughout the project. 

The degree of stakeholder satisfaction can often be determined by having a conversation with stakeholders to gauge their satisfaction with the project deliverables and the overall management of the project. Project and iteration reviews, product reviews, stage gates, and other methods are ways to obtain periodic feedback. For large groups of stakeholders, a survey can be used to assess the degree of satisfaction. Where necessary, the stakeholder engagement approach can be updated to achieve higher stakeholder satisfaction.

INTERACTIONS WITH OTHER PERFORMANCE DOMAINS

Stakeholders permeate all aspects of the project. They define and prioritize the requirements and scope for the project team. They participate in and shape the planning. They determine acceptance and quality criteria for the project deliverables and outcomes. Much of the project work is around engaging and communicating with stakeholders. Throughout the project or at its closure, they use the project deliverables and influence the realization of project outcomes.

Some stakeholders can assist in lowering the amount of uncertainty present on a project while others may cause an increase in uncertainty. Stakeholders such as customers, senior management, project management office leads, or program managers will focus on measures of performance for the project and its deliverables. These interactions are samples of how the Stakeholder Performance Domain integrates and interweaves with other performance domains, though they are not inclusive of all the ways stakeholder concerns interact throughout the performance domains.

CHECKING RESULTS 

Table identifies the outcomes on the left and ways of checking them on the right.

Checking Outcomes—Stakeholder Performance Domain

TEAM PERFORMANCE DOMAIN

This performance domain entails establishing the culture and environment that enables a collection of diverse individuals to evolve into a high performing project team. This includes recognizing the activities needed to foster project team development and encouraging leadership behaviors from all project team members.

The following definitions are relevant to the Team Performance Domain : 

Project Manager. 

The person assigned by the performing organization to lead the project team that is responsible for achieving the project objectives. 

Project Management Team. 

The members of the project team who are directly involved in project management activities. 

Project Team. 

A set of individuals performing the work of the project to achieve its objectives. 

PROJECT TEAM MANAGEMENT AND LEADERSHIP 

Project management entails applying knowledge, skills, tools, and techniques for management activities as well as leadership activities. Management activities focus on the means of meeting project objectives, such as having effective processes, planning, coordinating, measuring, and monitoring work, among others. Leadership activities focus on people. Leadership includes influencing, motivating, listening, enabling, and other activities having to do with the project team. Both are important in delivering the intended outcomes.

Centralized Management and Leadership 

While leadership activities should be practiced by all project team members, management activities may be centralized or distributed. In an environment where management activities are centralized, accountability (being answerable for an outcome), is usually assigned to one individual, such as the project manager or similar role. In these situations, a project charter or other authorizing document can provide approval for the project manager to form a project team to achieve the project outcomes.

Distributed Management and Leadership 

Sometimes project management activities are shared among a project management team, and project team members are responsible for completing the work. There are also situations where a project team may self organize to complete a project. Rather than having a designated project manager, someone within the project team may serve as facilitator to enable communication, collaboration, and engagement. This role may shift among project team members.

Servant leadership is a style of leadership that focuses on understanding and addressing the needs and development of project team members in order to enable the highest possible project team performance. Servant leaders place emphasis on developing project team members to their highest potential by focusing on addressing questions, such as : 

▶ 

Are project team members growing as individuals? 

▶ 

Are project team members becoming healthier, wiser, freer, and more autonomous? 

▶ 

Are project team members more likely to become servant leaders?

Servant leaders allow project teams to self-organize when possible and increase levels of autonomy by passing appropriate decision-making opportunities to project team members. Servant leadership behaviors include : 

▶ 

Obstacle removal. 

Since it is the project team who generates the majority of business value, a critical role for the servant leader is to maximize delivery by removing impediments to their progress. This includes solving problems and removing obstacles that may be hampering the project team’s work. By solving or easing these impediments, the project team can deliver value to the business faster. 

▶ 

Diversion shield. 

Servant leaders protect the project team from internal and external diversions that redirect the project team from the current objectives. Time fragmentation reduces productivity, so shielding the project team from noncritical, external demands helps the project team stay focused. 

▶ 

Encouragement and development opportunities. 

The servant leader also provides tools and encouragement to keep the project team satisfied and productive. Learning what motivates project team members as individuals and finding ways to reward them for good work helps keep project team members satisfied.

Common Aspects of Team Development

Regardless of how the management activities are structured, there are common aspects  of project team development that are relevant for most project teams. These include : 

▶ 

Vision and objectives. 

It is essential that everyone is aware of the project vision and objectives. The vision and objectives are communicated throughout the project. This includes referencing the intended outcomes when the project team is engaged in making decisions and solving problems. 

▶ 

Roles and responsibilities. 

It is important to make sure project team members understand and fulfill their roles and responsibilities. This can include identifying gaps in knowledge and skills as well as strategies to address those gaps through training, mentoring, or coaching.

▶ 

Project team operations. 

Facilitating project team communication, problem solving, and the process of coming to consensus may include working with the project team to develop a project team charter and a set of operating guidelines or project team norms. 

▶ 

Guidance. 

Guidance can be directed to the overall project team to keep everyone headed in the right direction. Individual project team members may also provide guidance on  a particular task or deliverable. 

▶ 

Growth. 

Identifying areas where the project team is performing well and pointing out areas where the project team can improve helps the project team to grow. Working collaboratively, the project team can identify goals for its improvement and take steps to meet those goals. This also applies to each individual on the project team. Individuals may want to grow their skills and experience in certain areas, and the project manager can assist with that.

There are several models that describe the stages of project team growth included in Section 4.

When project teams form across different organizations based on a contract, strategic partnership, or other business relationship, specific roles that perform various functions may be more formalized and less flexible depending on the contract or other terms. Such arrangements often require more up-front work to establish a “one team” mindset, ensure project team members understand how everyone contributes to the project, and establish other enablers that integrate skills, capabilities, and processes.

PROJECT TEAM CULTURE 

Each project team develops its own team culture. The project team’s culture may be established deliberately by developing project team norms, or informally through the behaviors and actions of its project team members. The project team culture operates within the organization’s culture but reflects the project team’s individual ways of working and interacting.

Human beings have a set of biases, some of them unconscious and some of them conscious.  For example, one person may feel that unless a schedule is displayed using a software-generated Gantt chart, that it is not a true or valid schedule. Another person may have a contrasting bias that detailed planning any further out than 30 days is a waste of time. Being open and transparent about biases up front establishes a culture of openness and trust that can enable consensus and collaboration. 

The project manager is key in establishing and maintaining a safe, respectful, nonjudgmental environment that allows the project team to communicate openly. One way to accomplish this is by modeling desired behaviors, such as : 

▶ 

Transparency. 

Being transparent in how one thinks, makes choices, and processes information helps others identify and share their own processes. This can extend to being transparent about biases as well. 

▶ 

Integrity. 

Integrity is comprised of ethical behavior and honesty. Individuals demonstrate honesty by surfacing risks, communicating their assumptions and basis of estimates, delivering bad news early, ensuring status reports provide an accurate depiction of the project’s status, and in many other ways. Ethical behavior can include surfacing potential defects or negative effects in product design, disclosing potential conflicts of interest, ensuring fairness, and making decisions based on environmental, stakeholder, and financial impacts.

▶ 

Respect. 

Demonstrating respect for each person, how the person thinks, the person’s skills, and the perspective and expertise the person brings to the project team sets the stage for all project team members to adopt this behavior. 

▶ 

Positive discourse. 

Throughout the project, diverse opinions, different ways of approaching situations, and misunderstandings will occur. These are a normal part of conducting projects. They present an opportunity to have a dialogue rather than a debate. A dialogue entails working with others to resolve divergent opinions. The goal is to arrive at a resolution that all parties can embrace. A debate, on the other hand, is a win-lose scenario where people are more interested in winning personally than they are in being open to alternative solutions to a problem. 

▶ 

Support. 

Projects can be challenging from the perspectives of technical challenges, environmental influences, and interpersonal interactions. Supporting project team members through problem solving and removing impediments builds a supportive culture and leads to a trusting and collaborative environment. Support can also be demonstrated by providing encouragement, showing empathy, and engaging in active listening. 

▶ 

Courage. 

Recommending a new approach to a problem or a way of working can be intimidating. Likewise, it can be challenging to disagree with a subject matter expert or someone with greater authority. However, demonstrating the courage that it takes to make a suggestion, disagree, or try something new enables a culture of experimentation and communicates to others that it is safe to be courageous and try new approaches. 

▶ 

Celebrating success. 

Focusing on project goals, challenges, and issues often sidelines the fact that individual project team members and the project team as a whole are steadily progressing toward those goals. Because work takes priority, project team members may defer recognizing demonstrations of innovation, adaptation, service to others, and learning. However, recognizing such contributions in real time can keep the project team and individuals motivated.

HIGH-PERFORMING PROJECT TEAMS 

One goal of effective leadership is to create a high-performing project team. There are a number of factors that contribute to high-performing project teams. The list below is not comprehensive, but  it identifies some of the factors associated with high-performing project teams. 

▶ 

Open communication. 

An environment that fosters open and safe communication allows for productive meetings, problem solving, brainstorming, and so forth. It is also the cornerstone for other factors, such as shared understanding, trust, and collaboration. 

▶ 

Shared understanding. 

The purpose for the project and the benefits it will provide are held in common. 

▶ 

Shared ownership. 

The more ownership of the outcomes that project team members  feel, the better they are likely to perform. 

▶ 

Trust. 

A project team in which its members trust each other is willing to go the extra distance to deliver success. People are less likely to do the extra work it may take to succeed if they  do not trust their project team members, project manager, or the organization. 

▶ 

Collaboration. 

Project teams that collaborate and work with each other rather than work in silos or compete tend to generate more diverse ideas and end up with better outcomes. 

▶ 

Adaptability. 

Project teams that are able to adapt the way they work to the environment and the situation are more effective. 

▶ 

Resilience. 

When issues or failures occur, high-performing project teams recover quickly. 

▶ 

Empowerment. 

Project team members who feel empowered to make decisions about the way they work perform better than those who are micromanaged. 

▶ 

Recognition. 

Project teams who are recognized for the work they put in and the performance they achieve are more likely to continue to perform well. Even the simple  act of showing appreciation reinforces positive team behavior.

LEADERSHIP SKILLS 

Leadership skills are useful for all project team members whether the project team is operating in an environment with a centralized authority or a shared leadership environment. The following sections describe some of the traits and activities associated with leadership.

Establishing and Maintaining Vision 

Every project has a purpose. Understanding that purpose is critical for people to commit their time and energy in the right direction toward achieving the project purpose. The project vision summarizes the project’s purpose clearly and succinctly. It describes a realistic, attractive view of the future project outcomes. 

In addition to briefly describing the desired future state, the vision is a powerful motivational tool. It is a way to create passion and meaning for a project’s envisioned goal. A common vision helps keep people pulling in the same direction. When immersed in the details of everyday work, a clear understanding of the end goal can help guide local decisions toward the desired project outcome. 

A vision developed collaboratively between project team members and key stakeholders should answer these questions : 

▶ 

What is the project purpose ? 

▶ 

What defines successful project work ? 

▶ 

How will the future be better when the project outcomes are delivered ? 

▶ 

How will the project team know that it is drifting from the vision? A good vision is clear, concise, and actionable. It does the following : 

▶ 

Summarizes the project with a powerful phrase or short description, 

▶ 

Describes the best achievable outcome, 

▶ 

Creates a common, cohesive picture in project team members’ minds, and 

▶ 

Inspires passion for the outcome.

Critical Thinking 

Throughout the various project performance domains, there is a need to recognize bias, identify the root cause of problems, and consider challenging issues, such as ambiguity, complexity, and so forth. Critical thinking helps to accomplish these activities. Critical thinking includes disciplined, rational, logical, evidence-based thinking. It requires an open mind and the ability to analyze objectively. Critical thinking, especially when applied to discovery, can include conceptual imagination, insight, and intuition. It can also include reflective thinking and metacognition (thinking about thinking and being aware of one’s awareness). Project team members apply critical thinking to : 

▶ 

Research and gather unbiased, well-balanced information; 

▶ 

Recognize, analyze, and resolve problems; 

▶ 

Identify bias, unstated assumptions, and values; 

▶ 

Discern the use of language and the influence on oneself and others; 

▶ 

Analyze data and evidence to evaluate arguments and perspectives; 

▶ 

Observe events to identify patterns and relationships; 

▶ 

Apply inductive, deductive, and abductive reasoning appropriately; and 

▶ 

Identify and articulate false premises, false analogy, emotional appeals, and other faulty logic.

Motivation Motivating project team members has two aspects: the first is understanding what motivates project team members to perform, and the second is working with project team members in such  a way that they remain committed to the project and its outcomes. 

Motivation to perform can be intrinsic or extrinsic. Intrinsic motivation comes from inside the individual or is associated with the work. It is associated with finding pleasure in the work itself rather than focusing on rewards. Extrinsic motivation is performing work because of an external reward such as a bonus. Much of the work done on projects is aligned with intrinsic motivation.

Examples of intrinsic motivation factors include :

▶ Achievement, 

▶ Challenge, 

▶ Belief in the work, 

▶ Making a difference, 

▶ Self-direction and autonomy, 

▶ Responsibility, 

▶ Personal growth, 

▶ Relatedness, and 

▶ Being part of a project team.

People are not motivated by just one thing; however, most people have a dominant motivator. To effectively motivate project team members, it is helpful to know each member’s dominant motivator. For example, a project team member who is motivated by challenge will respond well to stretch goals and problems to solve. A project team member who is motivated by relatedness will respond to being part of a dynamic working group. Project team members who thrive on autonomy will perform better if they can establish their own ways of working and even their own work hours and cadence. Therefore, tailoring motivation methods based on individual preferences helps to elicit the best individual and project team performance.

Interpersonal Skills 

Interpersonal skills that are used frequently in projects include emotional intelligence, decision making, and conflict resolution among others. 

▶ 

Emotional intelligence. 

Emotional intelligence is the ability to recognize our own emotions and those of others. This information is used to guide thinking and behavior. Recognition of personal feelings, empathy for the feelings of others, and the ability to act appropriately are the cornerstones for effective communication, collaboration, and leadership.

Since projects are undertaken by people and for people, emotional intelligence the ability to understand one’s self and effectively sustain working relationships with others is critical in project team environments. 

There are multiple models for defining and explaining emotional intelligence. They converge on four key areas :

▹ 

Self awareness. 

Self awareness is the ability to conduct a realistic self-assessment. It includes understanding our own emotions, goals, motivations, strengths, and weaknesses. 

▹ 

Self management. 

Self management, also known as self-regulation, is the ability to control and redirect disruptive feelings and impulses. It is the ability to think before acting, suspending snap judgments and impulsive decisions. 

▹ 

Social awareness. 

Social awareness is about empathy and understanding and considering other people’s feelings. This includes the ability to read nonverbal cues and body language. 

▹ 

Social skill. 

Social skill is the culmination of the other dimensions of emotional intelligence. It is concerned with managing groups of people, such as project teams, building social networks, finding common ground with various stakeholders, and building rapport.

Self awareness and self management are required to remain calm and productive during difficult project circumstances. Social awareness and social skills allow for better bonds with project team members and project stakeholders. Emotional intelligence is a basis of all forms of leadership.

Figure  shows the key points for each of the four aspects of emotional intelligence and how they relate. The aspects having to do with oneself are on the top, and the social aspects are on the bottom. Awareness is on the left side, and management and skill are on the right side.

Components of Emotional Intelligence

Some models for emotional intelligence include a fifth area for motivation. Motivation in this context is about understanding what drives and inspires people. 

▶ 

Decision making. 

Project managers and project teams make many decisions daily. Some decisions may be fairly inconsequential to the project outcome, such as where to go for a team lunch, and others will be very impactful, such as what development approach to use, which tool to use, or what vendor to select.

Decisions can be made unilaterally. This has the advantage of being fast but is prone to error when compared to engaging the wisdom of a diverse set of people. Unilateral decision making can also demotivate people who are impacted by the decision since they may feel their views and concerns were not considered.

Group-based decision making has the benefit of tapping into the broad knowledge base of a group. Engaging people in the decision making process also increases buy-in to the outcome, even if the option selected may not have been everyone’s first choice. Generally, inclusion increases commitment to the decision. The downside of group decision making is the time required and interruption to teamwork that can occur when taking people away from their work to be consulted in a decision.

Project team decision making often follows a diverge/converge pattern. This means stakeholders are first engaged to generate a broad set of solution alternatives or approaches. This is often done individually to avoid the effect of senior or charismatic stakeholders unduly influencing other stakeholders. Then, after a broad spectrum of decision alternatives have been generated, the project team converges on a preferred solution.

The goal is to make decisions quickly while engaging the diverse knowledge of a group in  an inclusive and respectful manner. Some decisions may be made in a different direction than some people prefer, but everyone has an opportunity to explain their position. In the end, the deciding authority, whether an individual or a group, makes a decision based on the presented analysis and with consideration for stakeholder expectations.

Careful selection of which decisions should go for group discussion and voting limits the interruptions and task switching experienced by the project team. Many approaches such as Roman voting, wideband Delphi estimating, and fist of five voting use the diverge/ converge pattern. They aim to engage individual input while voting at the same moment, which minimizes groupthink.

For those decisions that are beyond the authority of the project team to decide, the project team can investigate alternatives, consider impacts of each alternative, and escalate the decision to someone with the proper authority. This process aligns with the philosophy of “don’t bring me problems, bring me solutions,” while remaining aligned with organizational governance regarding decision making authority.

▶ 

Conflict management. 

Conflict happens on all projects. Projects operate in dynamic environments and face many mutually exclusive constraints including budget, scope, schedule, and quality, which can lead to conflicts. It is not uncommon to want to avoid conflict, but not all conflict is negative. How conflict is handled can either lead to more conflict or to better decision making and stronger solutions. 

Addressing conflict before it escalates beyond useful debate leads to better outcomes.  The following approaches can help : 

▹ 

Keep communications open and respectful. Because conflict can cause anxiety, it is important to keep a safe environment to explore the source of the conflict. Without a safe environment, people will stop communicating. Make sure words, tone of voice,  and body language remain nonthreatening.

▹ 

Focus on the issues, not the people. Conflict is based on people perceiving situations differently. It should not be personal. The focus is on resolving the situation,  not casting blame. 

▹ 

Focus on the present and future, not the past. Stay focused on the current situation,  not past situations. If something similar happened previously, bringing up the past will not resolve the current situation. In fact, it can serve to intensify the current situation even more. 

▹ 

Search for alternatives together. Damage incurred from conflict can be repaired by looking for resolutions and alternatives together. It can also create more constructive relationships. This moves the conflict into more of a problem solving space where people can work together to generate creative alternatives. 

There are several models for addressing and resolving conflict. Some of them are discussed  in Section 4.

TAILORING LEADERSHIP STYLES 

As with all aspects of projects, leadership styles are also tailored to meet the needs of the project, the environment, and the stakeholders. Some of the variables that influence tailoring of leadership styles include : 

▶ 

Experience with the type of project. Organizations and project teams with experience on a specific type of project may be more self managing and require less leadership. When a project is new to an organization, the tendency is to provide more oversight and to use  a more directive leadership style. 

▶ 

Maturity of the project team members. Project team members who are mature in the technical field may need less oversight and direction than project team members who are new to the organization, the team, or the technical specialty. 

▶ 

Organizational governance structures. Projects operate within a larger organizational system. There may be the expectation that the organizational leadership style of top management is recognized and reflected in the team’s leadership. The organizational structure influences the degree to which authority and accountability are centralized  or distributed. 

▶ 

Distributed project teams. A global project workforce is more common today than in the past. In spite of the best efforts to connect people virtually, it can be challenging to create the same level of collaboration and relatedness that is achieved when working face to face. To minimize the pitfalls of distributed project teams, technology can be used to increase and improve communication. Examples include : 

▹ 

Ensure there are collaboration sites for working together. 

▹ 

Have a project team site to keep all relevant project and project team  information available. 

▹ 

Use audio and video capabilities for meetings. 

▹ 

Use technology to maintain ongoing contact, such as messaging and texting. 

▹ 

Build in time to get to know remote project team members. 

▹ 

Have at least one face to face meeting to establish relationships.

INTERACTIONS WITH OTHER PERFORMANCE DOMAINS 

The Team Performance Domain emphasizes the skills used by project managers and project team members throughout the project. These skills are woven into all other aspects of the project. Project team members are called on to demonstrate leadership qualities and skills throughout the project. Communicating the project vision and benefits to stakeholders while planning and throughout the life cycle is one example. Another example is employing critical thinking, problem solving, and decision making while engaging in project work. Accountability for outcomes is demonstrated throughout the Planning and Measurement Performance Domains.

CHECKING RESULTS 

Table identifies the outcomes from effective application of the Team Performance Domain on the left and ways of checking them on the right.

Table Checking Outcomes Team Performance Domain

DEVELOPMENT APPROACH AND LIFE CYCLE PERFORMANCE DOMAIN

Figure Development Approach and Life Cycle Performance Domain

This performance domain entails establishing the development approach, delivery cadence, and project life cycle needed to optimize project outcomes.

The following definitions are relevant to the Development Approach and Life Cycle Performance Domain : 

Deliverable. 

Any unique and verifiable product, result, or capability to perform a service that is required to be produced to complete a process, phase, or project. 

Development Approach. 

A method used to create and evolve the product, service, or result during the project life cycle, such as a predictive, iterative, incremental, adaptive, or hybrid method. 

Cadence. 

A rhythm of activities conducted throughout the project. 

Project Phase. 

A collection of logically related project activities that culminates in the completion of one or more deliverables. 

Project Life Cycle. 

The series of phases that a project passes through from its start to  its completion. 

DEVELOPMENT, CADENCE, AND LIFE CYCLE RELATIONSHIP 

The type of project deliverable(s) determines how it can be developed. The type of deliverable(s) and the development approach influence the number and cadence for project deliveries. The deliverable approach and the desired delivery cadence determine the project life cycle and its phases.

DELIVERY CADENCE 

Delivery cadence refers to the timing and frequency of project deliverables. Projects can have  a single delivery, multiple deliveries, or periodic deliveries.

▶ 

Single delivery. 

Projects that have a single delivery deliver at the end of the project. For example, a process reengineering project may not have any deliveries until near the end of the project when the new process is rolled out. 

▶ 

Multiple deliveries. 

Some projects have multiple deliveries. A project may have multiple components that are delivered at different times throughout the project. A project to develop a new drug may have multiple deliveries, such as preclinical submissions, Phase 1 trial results, Phase 2 trial results, Phase 3 trial results, registration, and then launch. In this example, the deliveries are sequential. Some projects have deliveries that are developed separately rather than sequentially, such as a project to update building security. Deliveries may include physical barriers to entry, new badges, new key code pads, and so forth. Each of these is a separate delivery, but they do not need to come in a specific order. All of the deliveries are concluded before the project is considered to be completed. 

▶ 

Periodic deliveries. 

Periodic deliveries are like multiple deliveries, but they are on a fixed delivery schedule, such as monthly or bimonthly. A new software application may have internal deliveries every two weeks, and then periodically release the deliveries  into the market.

Another delivery option is called continuous delivery. Continuous delivery is the practice of delivering feature increments immediately to customers, often through the use of small batches of work and automation technology. Continuous delivery can be used for digital products. From the product management perspective, the emphasis is on delivering benefits and value throughout the product life cycle. Similar to a project, there are aspects that are development oriented. However, similar to a program, there can be many development cycles as well as maintenance activities. This type of undertaking works better with project teams that are stable and remain intact. Because the project teams are focused on one product, they can apply learning about the product, the stakeholders, and the market. This allows the team to respond to market trends and stay focused on value delivery. This practice is included in several approaches such as DevOps, #noprojects and Continuous Digital, for example. 

DEVELOPMENT APPROACHES

A development approach is the means used to create and evolve the product, service, or result during the project life cycle. There are different development approaches, and different industries may use different terms to refer to development approaches. Three commonly used approaches are predictive, hybrid, and adaptive. As shown in Figure 2-7, these approaches are often viewed as a spectrum, from the predictive approach on one end of the spectrum, to the adaptive on the other end.

▶ 

Predictive approach. 

A predictive approach is useful when the project and product requirements can be defined, collected, and analyzed at the start of the project. This may also be referred to as a waterfall approach. This approach may also be used when there is a significant investment involved and a high level of risk that may require frequent reviews, change control mechanisms, and replanning between development phases. The scope, schedule, cost, resource needs, and risks can be well defined in the early phases of the project life cycle, and they are relatively stable. This development approach allows the project team to reduce the level of uncertainty early in the project and do much of the planning up front. Predictive approaches may use proof of concept developments to explore options, but the majority of the project work follows the plans that were developed near the start of the project. Many times, projects that use this approach have templates from previous, similar projects.

A project to develop a new community center might use a predictive approach for the construction of the grounds and facilities. The scope, schedule, cost, and resources would be determined up front, and changes would likely be minimal. The construction process would follow the plans and blueprints.

▶ 

Hybrid approach. 

A hybrid development approach is a combination of adaptive and predictive approaches. This means that some elements from a predictive approach are used and some from an adaptive approach are used. This development approach is useful when there is uncertainty or risk around the requirements. Hybrid is also useful when deliverables can be modularized, or when there are deliverables that can be developed  by different project teams. A hybrid approach is more adaptive than a predictive approach, but less so than a purely adaptive approach. Hybrid approaches often use an iterative or incremental development approach. An iterative approach is useful for clarifying requirements and investigating various options.  An iterative approach may produce sufficient capability to be considered acceptable prior to the final iteration. An incremental approach is used to produce a deliverable throughout a series of iterations. Each iteration adds functionality within a predetermined time frame  (a timebox). The deliverable contains the capability to be considered as completed only after the final iteration. The differences and interactions between iterative and incremental development are shown in Figure 2-8. An example of a hybrid approach could be using an adaptive approach to develop a product that has significant uncertainty associated with the requirements. However, the deployment of the product can be done using a predictive approach. Another example is a project with two main deliverables where one deliverable is developed using an adaptive approach and the other using a predictive approach.

Iterative and Incremental Development

As part of the community center, a project to establish senior services could be developed and deployed iteratively. For example, the first iteration could be a Meals on Wheels program. This could be followed by a transportation service, then group outings and events, caregiver relief, adult day care, and so forth. Each service would be complete on its own and could be deployed when it was available. Each additional service would improve and increase the senior services for the community. A project to establish training for community action patrol volunteers could use an incremental approach. The training, comprised of basic training, logistics training, and patrol training, can be developed by different people. It can be developed at the same time in modules, or one module can be developed, feedback gathered, and then subsequent modules can be developed. However, the community action patrol training program will only be complete after all the modules are developed, integrated, and deployed.

▶ 

Adaptive approach. 

Adaptive approaches are useful when requirements are subject to a high level of uncertainty and volatility and are likely to change throughout the project. A clear vision is established at the start of the project, and the initial known requirements are refined, detailed, changed, or replaced in accordance with user feedback, the environment, or unexpected events. Adaptive approaches use iterative and incremental approaches. However, on the far side of the adaptive methods, the iterations tend to get shorter and the product is more likely to evolve based on stakeholder feedback. While agility is a wide mindset that is broader than a development framework, agile approaches can be considered adaptive. Some agile approaches entail iterations that are 1 to 2 weeks in duration with a demonstration of the accomplishments at the end of each iteration. The project team is very engaged with the planning for each iteration. The project team will determine the scope they can achieve based on a prioritized backlog, estimate the work involved, and work collaboratively throughout the iteration to develop the scope.

The community center will need a website so community members can access information from their home computer, phone, or tablet. The high level requirements, design, and page layouts can be defined up front. An initial set of information can be deployed on the website. User feedback, new services, and internal stakeholder needs would provide content for a backlog. The backlog information would be prioritized, and the web team would develop and deploy new content. As new requirements and new scope emerge, the estimates for the work would be developed, the work would be done, and once tested, it would be demonstrated for stakeholders. If approved, the work would be deployed to the website. 

CONSIDERATIONS FOR SELECTING A DEVELOPMENT APPROACH 

There are several factors that influence the selection of a development approach. They can be divided into categories of the product, service, or result; the project ; and the organization. The following subsections describe the variables associated with each category.

Product, Service, or Result 

There are many variables associated with the nature of the product, service, or result that influence the development approach. The following list outlines some of the variables to consider when selecting the development approach.

▶ 

Degree of innovation. 

Deliverables where the scope and requirements are well understood, that the project team has worked with before, and that allow for planning up front are well suited to a predictive approach. Deliverables that have a high degree of innovation or where the project team does not have experience are better suited to a more adaptive approach. 

▶ 

Requirements certainty. 

When the requirements are well known and easy to define, a predictive approach fits well. When requirements are uncertain, volatile, or complex and are expected to evolve throughout the project, a more adaptive approach may be a better fit.

▶ 

Scope stability. 

If the scope of the deliverable is stable and not likely to change, a predictive approach is useful. If the scope is expected to have many changes, an approach that is closer to the adaptive side of the spectrum can be useful. 

▶ 

Ease of change. 

Related to the requirements certainty and the scope stability, if the nature of the deliverable makes it difficult to manage and incorporate changes, then a predictive approach is best. Deliverables that can adapt easily to change can use an approach that is more adaptive. 

▶ 

Delivery options. 

As described in Section 2.3.2 on Delivery Cadence, the nature of the deliverable and whether it can be delivered in components influences the development approach. Products, services, or results that can be developed and/or delivered in pieces are aligned with incremental, iterative, or adaptive approaches. Some large projects may be planned using a predictive approach, but there may be some pieces that can be developed and delivered incrementally. 

▶ 

Risk. 

Products that are inherently high risk require analysis before choosing the development approach. Some high risk products may require significant up-front planning and rigorous processes to reduce threats. Other products can reduce risk by building them modularly and adapting the design and development based on learning to take advantage of emerging opportunities or reduce the exposure to threats. 

▶

 Safety requirements. 

Products that have rigorous safety requirements often use a predictive approach as there is a need for significant up front planning to ensure that all the safety requirements are identified, planned for, created, integrated, and tested. 

▶ 

Regulations. 

Environments that have significant regulatory oversight may need to use a predictive approach due to the required process, documentation, and demonstration needs.

Project 

Project variables that influence the development approach are centered around stakeholders, schedule constraints, and funding availability. 

▶ 

Stakeholders. 

Projects that use adaptive methods require significant stakeholder involvement throughout the process. Certain stakeholders, such as the product owner,  play a substantial role in establishing and prioritizing work.

▶ 

Schedule constraints. 

If there is a need to deliver something early, even if it is not  a finished product, an iterative or adaptive approach is beneficial. 

▶ 

Funding availability. 

Projects that work in an environment of funding uncertainty can benefit from an adaptive or iterative approach. A minimum viable product can be released with less investment than an elaborate product. This allows for market testing or market capture with minimum investment. Further investments can be made based on the market response to the product or service.

Organization Organizational variables such as the structure, culture, capability, project team size, and location influence the development approach. 

▶ 

Organizational structure. 

An organizational structure that has many levels, a rigid reporting structure, and substantial bureaucracy frequently uses a predictive approach. Projects that use adaptive methods tend to have a flat structure and may operate with selforganizing project teams. 

▶ 

Culture. 

A predictive approach fits better in an organization with a culture of managing and directing, where the work is planned out and progress is measured against baselines. Adaptive approaches fit better within an organization that emphasizes project team selfmanagement. 

▶ 

Organizational capability. 

Transitioning from predictive development approaches to adaptive approaches and then to using agile methods is more than just stating that the organization will now be agile. It entails shifting the mindset starting at the executive level throughout the organization. Organizational policies, ways of working, reporting structure, and attitude should all be aligned in order to employ adaptive methods successfully. 

▶ 

Project team size and location. 

Adaptive approaches, especially agile methods, often work better with project teams of 7 ± 2. Adaptive approaches also favor project teams that are located in the same physical space. Large project teams and project teams that are mostly virtual may do better by using an approach that is closer to the predictive side of the spectrum. However, there are approaches that seek to scale up the adaptive approaches to work with large and dispersed project teams.

LIFE CYCLE AND PHASE DEFINITIONS 

The type and number of project phases in a project life cycle depend upon many variables, chief among them the delivery cadence and the development approach, as described previously. Examples of phases in a life cycle include : 

▶ 

Feasibility. 

This phase determines if the business case is valid and if the organization has the capability to deliver the intended outcome. 

▶ 

Design. 

Planning and analysis lead to the design of the project deliverable that will be developed. 

▶ 

Build. 

Construction of the deliverable with integrated quality assurance activities is conducted. 

▶ 

Test. 

Final quality review and inspection of deliverables are carried out before transition, go live, or acceptance by the customer. 

▶ 

Deploy. 

Project deliverables are put into use and transitional activities required for sustainment, benefits realization, and organizational change management are completed. 

▶ 

Close. 

The project is closed, project knowledge and artifacts are archived, project team members are released, and contracts are closed.

Project phases often have a phase gate review (also known as stage gate) to check that the desired outcomes or exit criteria for the phase have been achieved before proceeding to the next phase. Exit criteria may tie to acceptance criteria for deliverables, contractual obligations, meeting specific performance targets, or other tangible measures.

Figure shows a life cycle where one phase finishes before the next one begins. This type of life cycle would fit well with a predictive development approach since each phase is only performed once, and each phase focuses on a particular type of work. However, there are situations, such as adding scope, a change in requirements, or a change in the market that cause phases to be repeated.

Figure shows a life cycle with an incremental development approach. There are three iterations of plan, design, and build shown in this example. Each subsequent build would add functionality to the initial build.

Figure shows a life cycle using an adaptive development approach. At the end of each iteration (sometimes known as a sprint), the customer reviews a functional deliverable. At the review, the key stakeholders provide feedback, and the project team updates the project backlog of features and functions to prioritize for the next iteration.

This approach can be modified for use in continuous delivery situations, as described in  Section 2.3.2 on Delivery Cadence.

Several adaptive methodologies, including agile, use flow based scheduling, which does not use a life cycle or phases. One goal is to optimize the flow of deliveries based on resource capacity, materials, and other inputs. Another goal is to minimize time and resource waste and optimize the efficiency of processes and the throughput of deliverables. Projects that use these practices and methods usually adopt them from the Kanban scheduling system used in lean and just intime scheduling approaches. 

ALIGNING OF DELIVERY CADENCE, DEVELOPMENT APPROACH, AND LIFE CYCLE

The community center examples described in Section 2.3.3 will be revisited to demonstrate how the delivery cadence, development approach, and life cycle fit together. In this example, there are four products and services: the building, the community action patrol (CAP) training, the senior services, and the website. Table describes the delivery cadence and the development approach.

Delivery Cadence and Development Approach

Based on this information, a potential life cycle might be: Adaptive Incremental 

▶ 

Start Up. 

Entry criteria for this phase are that the business case has been approved and the project charter has been authorized. In this phase, the high level roadmap is developed, initial funding requirements are established, project team and resource requirements are defined, a milestone schedule is created, and planning for a procurement strategy is defined. These deliverables should be complete prior to exiting the start-up phase. Exit criteria will be reviewed at an origination phase gate review. 

▶ 

Plan. 

In this phase, the high level information for the building is decomposed into detailed plans. A detailed design document for the CAP training is completed. An analysis of the senior services offering is completed along with a gap analysis. The initial wireframe for the website is created. These deliverables should be complete prior to exiting the planning phase. Exit criteria will be reviewed at a planning phase gate review.

▶ 

Development. 

This phase will overlap with the test and deploy phases since the deliverables have different delivery cadences and different approaches. The website will have early deliveries to inform the public of the progress for the community center. Some senior services and the CAP training may begin prior to the opening of the community center. Each deliverable may have a separate review prior to entering the testing phase. 

▶ 

Test. 

This phase will overlap with the development and deploy phases. The type of test will depend on the deliverable. This phase includes inspections for the building, a beta delivery of the CAP courses, small scale trials for the senior services, and operating in a test environment for each release for the website. Each deliverable will go through the applicable testing prior to moving to the deploy phase. 

▶ 

Deploy. 

This phase will overlap with the development and test phases. The first deployment of the website may be somewhat early in the project. Activities in this phase will iterate as more deliverables become available. The final deployment for the project will be the opening of the community center. Ongoing updates to the website and the senior services will be part of operations once the community center is open. 

▶ 

Close. 

This phase takes place periodically as deliverables are completed. When the initial website has been deployed, project personnel (including contractors) will be released and retrospectives or lessons learned for each deliverable will be completed. When the entire project is done, information from the various phase gate reviews and an overall evaluation of project performance compared to baselines will be conducted. Prior to final closeout, the project charter and the business case will be reviewed to determine if the deliverables achieved the intended benefits and value.

Figure shows a possible life cycle for the community center project. The start-up and planning phases are sequential. The development, test, and deploy phases overlap because the different deliverables will be developed, tested, and deployed at different times, and some deliverables will have multiple deliveries. The development phase is shown in more detail to demonstrate different timing and delivery cadence. The test phase cadence would follow the development phase cadence. The deliveries are shown in the deploy phase.

What’s in a Name? Not all project practitioners differentiate between the development approach and the life cycle. Some practitioners will say a project follows an agile life cycle when they are actually talking about the development approach. Some practitioners refer to predictive approaches as waterfall. Adaptive development approaches may also be known as evolutionary approaches. Because project management is evolving, the language used continues to evolve. The best way to understand what a person is referring to is to determine how they are developing deliverables and ask them the names of the phases in the life cycle. This can help frame the project and understand how people are using terms. 

INTERACTIONS WITH OTHER PERFORMANCE DOMAINS 

The Development Approach and Life Cycle Performance Domain interacts with the Stakeholder, Planning, Uncertainty, Delivery, Project Work, and Team Performance Domains. The life cycle selected impacts the way in which planning is undertaken. Predictive life cycles undertake the bulk of the planning up front and then continue to replan by using rolling wave planning and progressive elaboration. Plans are also updated as threats and opportunities materialize. 

The development approach and delivery cadence is one way to reduce uncertainty on projects. A deliverable that has a lot of risk associated with meeting regulatory requirements may choose a predictive approach to build in extra testing, documentation, and robust processes and procedures. A deliverable that has a lot of risk associated with stakeholder acceptance may choose an iterative approach and release a minimum viable product to the market to get feedback before developing additional features and functions.

The Development Approach and Life Cycle Performance Domain has significant overlap with the Delivery Performance Domain when considering delivery cadence and development approach. The delivery cadence is one of the main drivers of delivering value in alignment with the business case and the benefits realization plans. Eliciting the product requirements and meeting the quality requirements as described in the Delivery Performance Domain have a significant influence on the development approach.

The Team Performance Domain and the Development Approach and Life Cycle Performance Domain interact when it comes to project team capabilities and project team leadership skills. The project team’s way of working and the project manager’s style vary significantly depending on the development approach. A predictive approach usually entails more emphasis on up front planning, measurement, and control. On the other end of the spectrum, an adaptive approach, especially when using agile methods, requires more of a servant leadership style and may have self managing project teams.

MEASURING OUTCOMES 

Table identifies the outcomes on the left and ways of checking them on the right. 

Checking Outcomes Development Approach and Life Cycle Performance Domain

PLANNING PERFORMANCE DOMAIN 

Planning organizes, elaborates, and coordinates project work throughout the project.

The following definitions are relevant to the Planning Performance Domain : 

Estimate. 

A quantitative assessment of the likely amount or outcome of a variable, such as project costs, resources, effort, or durations. 

Accuracy. 

Within the quality management system, accuracy is an assessment of correctness. 

Precision. 

Within the quality management system, precision is an assessment of exactness. 

Crashing. 

A method used to shorten the schedule duration for the least incremental cost  by adding resources. 

Fast Tracking. 

A schedule compression method in which activities or phases normally done  in sequence are performed in parallel for at least a portion of their duration. 

Budget. 

The approved estimate for the project or any work breakdown structure (WBS) component or any schedule activity. 

PLANNING OVERVIEW 

The purpose of planning is to proactively develop an approach to create the project deliverables. The project deliverables drive the outcomes the project was undertaken to achieve. High level planning may begin prior to project authorization. The project team progressively elaborates initial project documents, such as a vision statement, project charter, business case,  or similar documents to identify or define a coordinated path to achieve the desired outcomes.

It is becoming more common for initial planning to consider social and environmental impacts in addition to the financial impacts (sometimes referred to as the triple bottom line). This may take the form of a product life cycle assessment which evaluates the potential environmental impacts of a product, process, or system. The product life cycle assessment informs the design of products and processes. It considers the impacts of materials and processes with regards to sustainability, toxicity, and the environment. 

The amount of time spent planning, both up front and throughout the project, should be determined by the circumstances. It is inefficient to spend more time planning than is needed. Therefore, the information gained from planning should be sufficient to move forward in an appropriate manner but not more detailed than necessary. Project teams use planning artifacts to confirm stakeholder expectations and provide stakeholders with the information they need to make decisions, take action, and maintain alignment between the project and stakeholders.