PMI Authorized PMP Exam Prep: Lesson 2 Start the Project

The goal of this artifact is to provide a quick overview of lesson 2 of PMI Authorized PMP Exam Prep, known as ‘Start the Project’. The purpose of this document is to provide opportunity to the course participants and enable learning on the go. The idea is to provide content that reinforces all the topics covered in the class on Saturday as part of the PMP course at Education Edge. 

‘Start the Project’ describes some of the tasks that will be performed in the early stages of a project. There are 4 core topics in this lesson as listed below:

Topic A: Identify and Engage Stakeholders

Topic B: Form the Team

Topic C: Build Shared Understanding

Topic D: Determine Project Approach

Topic A- Identify and Engage Stakeholders

It is important to identify and engage stakeholders when you start the project. Identification of stakeholders should be done as early as possible in the project lifecycle. It is critical to identify our stakeholders and document them in a stakeholder register. Identification should be followed by analysis of stakeholder. It is important to keep in mind that stakeholders can be identified anywhere in the lifecycle of the project.

Stakeholders may take on a variety of roles and responsibilities on a project. Can include members of the project team, customers, end users, business or project partners, and others. May or may not be actively involved in project work. Could affect or be affected by a decision, an activity or an outcome of a project.

For smaller projects, you can be very thorough in your identification and assessment of stakeholders and in developing an effective communications strategy with your stakeholders. 

For larger projects, or those with a challenging stakeholder environment, you should also try to be as thorough as possible, focusing on key stakeholders and groups. In those cases, the power/influence/impact grids and salience model tools will be more helpful to you.

Stakeholder Identification

  • Identify internal and external stakeholders of a project as  early as possible — typically during project charter development
  • As the project continues, keep looking for stakeholders in change logs, issue logs and other project documents.
  • Remember that anyone who is affected by the project or whose role or work affects the project can be a stakeholder!
  • Do this thoroughly now, because it can be problematic and costly to correct stakeholder assumptions or requirements at the end of the project.
Stakeholder Analysis

Stakeholder Analysis is a crucial factor when you start the project. Once you have a list of stakeholders to start with in the register, use these tools and techniques to further “identify” and assess them. 

Following methods can be use to assess and analyze the stakeholders:

  • Data gathering can include any means of finding out more about your stakeholders.
    • Ask the team if they’ve worked with them before; set up a meeting to begin building a relationship and ask lots of questions.
  • Data analysis is about taking the data and positioning it to make decisions. 
    • This is quantitative AND qualitative.
    • You need to know what each stakeholder needs and wants from the project, and how they perceive the project. You need to understand their interest; their rights (legal and moral); ownership; knowledge; and contribution. That is stakeholder analysis
    • To perform document analysis, you’ll review the business case and organizational documents that set up the project to understand who the key players are.  
  • Data representation is about showing how the stakeholder’s power, interest or influence intersect. Visualizing the data helps you make informed decisions.
    • Two-dimensional grids are useful for small projects or for projects with simple relationships between stakeholders and the project, or within the stakeholder community itself.
    • The 3D grid combines all three elements
    • A salience model is useful for large, complex communities of stakeholders or where there are complex networks of relationships within the community. It is also useful in determining the relative importance of the identified stakeholders. 

Directions of influence (influence matrix) classifies stakeholders according to their influence on the work of the project or the project team itself.


A project document including the identification, assessment, and classification of project stakeholders.

Stakeholder Engagement Plan

The stakeholder engagement plan and the communications management plan are interlinked artifacts.

The stakeholder engagement plan provides the details about the people with whom the project needs to maintain communications, and the communications management plan provides the details about which and how communication types, methods and artifacts are to be used to connect with stakeholders.  

Using the information in the stakeholder register and doing some further analysis, you create the stakeholder engagement plan and the communications management plan.

Communication Requirement Analysis
  • You need to ask stakeholders directly about their communication requirements. 
  • Doing so leads to a clear articulation of the stakeholder’s communication needs. 
  • Discuss and agree on frequency, method, technology, and subjects for communication.
  • Just as stakeholders and risks are continually analyzed during the project, so are the communication requirements. 
  • Capturing and analyzing the requirements enables you to make the right choice of how you’ll communicate with various groups or categories of stakeholders, including the kind of technology that will work best.
Communication Methods

Interactive communication is a method which enables both sender and receiver to interact in real or near-real time.

The Push method entails telling and being direct and forthcoming with information. It is also at the timing of the sender. 

The Pull method, on the other hand, puts the responsibility of learning information on the recipient and is based on the time they must review it.

You should consider the following challenges and considerations when determining the method and frequency of communications for the stakeholder engagement plan and the communications management plan.

  • Urgency of need for information: How quickly to send? Where to provide?
  • Availability and reliability of technology: Does everyone have access?
  • Ease of use
  • Project environment — e.g., language and formality
  • Sensitivity and confidentiality of information
  • Social media policies
  • Data protection laws/regulations
  • Accessibility requirements

Communication Model

  • Sender-receiver model
  • Encode/decode

Communication model includes technical as well as personal data. Not only should the encoding and decoding of the message be taken into consideration, but also the potential noise that can inhibit the ability to correctly interpret the message.

“Soft” skills such as interpersonal communication and emotional intelligence are essential in healthy communication models.

  • Emotional factors
  • Cultural differences
  • Noise (subjective)

Topic B: Form the Team

Whether we are working on Predictive or Adaptive projects, it is important to form a collaborative team. This process starts as early as possible in the project lifecycle. This topic is a key topic and in the PMP exam you may be tested on the following principles:

  1. Empower team members and stakeholders and organize around team strengths
  2. Ensure knowledge transfer for project continuity
  3. Discuss project responsibilities within team 
  4. Outline expectations for working environment
  5. Engage and support virtual teams
    1. Examine virtual team member needs (e.g., environment, geography, culture, global, etc.)
    2. Investigate alternatives (e.g., communication tools, colocation) for virtual team member engagement 

In adaptive life cycles that use agile development approaches, two key concepts about team formation are understood together: self-organizing teams and servant leadership. 

In some agile teams, every team member leads; in other teams, someone assumes the role of team lead. 

We’ll discuss this next, but let’s look at the two key concepts of team formation that come from agile but can be applied to teams in any project environment.

From the Agile Practice Guide:

(Emphasis on the item in bold, as it applies to team formation.)

  • In agile, the team manages its work process and its work product. That self-management and self-organization applies to everyone serving and supporting the organization and project. 
  • Servant leaders work to fulfill the needs of the teams, projects and organization. 
  • Servant leaders may work with facilities for a team space, work with management to enable the team to focus on one project at a time or work with the product owner to develop stories with the team. Some servant leaders work with auditors to refine the processes needed in regulatory environments, and some servant leaders work with the finance department to transition the organization to incremental budgeting. 
  • The servant leader focuses on paving the way for the team to do its best work. 
  • The servant leader influences projects and encourages the organization to think differently

In a hybrid project, the project manager takes on the responsibility of centralizing coordination and being accountable for completing work while self-organizing project teams do portions of the work.

This solution ensures both accountability, which is important to stakeholders and the organization, and the flexibility that teams need to do their best work.

Roles on the project team can include:

  • Project management staff members who perform activities such as budgeting, scheduling, reporting and control, risk management and project communications. This role may be supported by a PMO.
  • Project staff members  who perform the work to create the project deliverables.
  • Supporting experts who perform work to develop the project management plan. These roles can include legal, logistics, engineering, testing and so on.

Business partner members that support the business partnership.

Project Resource Requirements

If your project follows a predictive life cycle, these are a few of the major considerations you should think about when building a team.

  • Will the team have enough of the relevant skill sets to perform the work and produce the desired results?
  • Try to avoid single points of failure – i.e., only one resource has a needed skill to perform a particular type of work.
  • Make use of what are called generalizing specialists, who have a core competency but also general skills in other areas that can be leveraged as needed by the team to support its objectives.

In addition to the team members themselves, you will need to identify the other physical supports that the team members will require to be able to perform — equipment, access rights, etc.

  • Focus on enabling team members to think of themselves as “T-shaped.”
  • It’s no longer enough for most of us to be experts in one focused area. We need to develop competencies and expertise across a broad range of areas. So, consider the depth as well as breadth of team members’ knowledge.
  • From a strategic point of view, there are many benefits to T-shaped people on cross-functional teams, including value, versatility and flexibility.
Team Norms

Team norms are the agreed standards of conduct for all team members.

 Establish these norms together early in the project to set the stage for an appropriate range of behaviors and actions. Team norms are a shared set of mutually agreed rules. It’s a means of keeping a standard and accountability in case of problems.

Team Charter

A good team charter should include:

  • The team’s shared values
  • Guidelines for team communications and the use of tools
  • How the team makes decisions
  • How the team resolves conflicts when disagreements arise
  • How and when the team meets
  • Other team agreements (such as shared hours, improvement activities)

Ideally, the charter should be produced by the team, or at least with the team’s active participation. The team charter can and should be reviewed and updated as needed.

  • Ground rules enable the team to take ownership of its rules, set expectations for itself around how the team will operate together, and establish effective mechanisms to handle conflicts that will inevitably occur.
  • Key objectives include:
    • Facilitating effective team collaboration
    • Promoting visibility of work and progress
    • Enabling the team to self-organize and self-manage as much as practicable
  • A group of people with a shared goal who fulfill their roles with little or no time spent meeting face-to-face.
  • An organizational placement strategy in which the project team members are physically located close to one another to improve communication, working relationships, and productivity.

Topic C: Build Shared Understanding

This is the third topic of the second lesson “Start the Project” in the PMI authorized PMP exam prep. One of the first goals in starting a project is to ensure that all team members and stakeholders have a common understanding of the objectives of the project, as well as an understanding of any agreements, such as contracts or statements of work that initiated the project.  You must also enable the team to understand the importance of the project and the alignment to the organization’s strategic objectives. Again, the focus is on creating that collaborative team environment, but the stakes are highest in this period. As much as possible, you need to make sure everyone is aligned before work starts. If you get the team in a good place from the start, then keeping them motivated and inspired to do their best work will be easier in the weeks ahead! Teams that understand and believe in the vision would generally deliver successful outcomes. As project managers it is our responsibility to continue to communicate the vision and help build shared understanding of the project. Here are some of the principles tested on the PMP exam from this topic:
  1. Lead a team and set a clear vision and mission
  2. Negotiate project agreements
    • Build shared understanding by surveying all necessary parties to reach consensus 
  3. Define team ground rules and communicate organizational principles with team and external stakeholders. Establish an environment that fosters adherence to ground rules
How you go about building a shared understanding will, again, depend a great deal on the project context, the team, stakeholders and yourself. However, the general process looks like this:
  1. Share the agreements.
  2. Agree on or negotiate to reach an understanding on the agreements.
  3. Then uphold the agreements throughout the project.
To elaborate a bit more, take a look at the below ideas:
  • First, you should perform your due diligence towards learning what the project is about and ensure the project vision and project charter are clearly articulated. Be able to talk about the details and the spirit of the project. Remember this is the value of stewardship. You must share a holistic understanding of the project with the team and stakeholders. 
  • Next, you will ensure their “buy-in” to the project agreements — the project charter and vision statement.  
    • Why: Without this buy-in, especially from key stakeholders, you will find your job difficult. We will discuss how to manage resistant or detractor stakeholders during the course, but if you can avoid creating future conflict at this stage, you should. 
    • How: Whether a key stakeholder lacks enthusiasm or openly voices a clear objection, it must be dealt with. Negotiate to reach consensus about the project from your key stakeholders. 
    • With regards to the team, every team will make decisions regarding roles and responsibilities, priorities, assignments and deliverables in a different way, but establishing a way of working to suit them and to deliver the best value for the project is fundamental to success.
  • The last step calls on you to fulfill your role as a steward once again. You must ensure the project agreements are upheld by the stakeholders and the team for the duration of the project.

Establish a project vision statement

  • When a project begins, it is critical to have a clear vision of the desired objectives. 
  • This includes the creation of a vision statement.  
  • This should come from the product owner, sponsor or key stakeholders and continually be reinforced to the team throughout the project.
  • There are many ways that this vision statement can be expressed and understood.

Development of Project Charter and sharing the approved project charter is one of the great ways of building shared understanding.


A technique used to explain a desired solution or outcome. Stakeholders try to describe aspects of a solution in the same way a marketer might describe product features and benefits on a box.


A common Extreme Programming (XP) technique that describes a common vision of how a program works. 

Project Charter

Development of Project Charter and sharing the approved project charter is one of the great ways of building shared understanding.

Once stakeholders and team members have accepted and can begin to internalize the project vision and agreements, it’s time to ensure the project charter is finalized. 

  • If there is no formal project selection process in an organization, a project professional may draft the project charter and review it with the executive sponsor (and possibly key stakeholders) for approval and distribution. 

There is no single way to create a project charter, but it is imperative that a project has one. Project charter leads to establishing clear understanding of the project. The following is achieved via a project charter

  • The project charter authorizes the project and authorizes the project manager to apply resources to project activities. 
  • It enables and authorizes the project manager with power to apply resources to project work and activities.
  • It defines the business need and rationale for why the organization is undertaking the project.
  • Because it states a business need that is approved at the executive level, it verifies alignment with the strategic goals.
  • Finally, and very importantly, it keeps everyone on the team — as well as stakeholders — focused on a clear project vision.
  • Later, everyone can refer to it for a high-level vision of the project. 

Note: When a project is the result of a contract or statement of work (SOW), that document may serve as the charter.

Kick off Meeting

The kickoff meeting is an opportunity for the project sponsor to present the project to stakeholders and officially “kick it off” or initiate it.

Some organizations have more than one kickoff meeting — an internal one for the team and one that is organization-wide and/or includes all stakeholders, both internal and external. 

This all depends on your organization and the project context.

Topic D: Determine Project Approach

As you start the project, determining the appropriate project approach is extremely important. Now that you have a clearer idea of the purpose, objective, stakeholders and team resources required for the project, you and your team will be thinking about how you can best approach the work.

Determining the right project approach is essential for each project’s success. The approach, be it Predictive, Adaptive or Hybrid should be determined based on the nature of project, risk, uncertainty, complexity along with the culture. Focus on the following principles from exam standpoint:

  1. Assess project needs, complexity and magnitude 
  2. Recommend project execution strategy (e.g., contracting, financing) 
  3. Recommend a project methodology/approach (i.e., predictive, adaptive, hybrid

While the predictive life cycle has been effective in supporting good practices in plan-based project management standards for more than 50 years, project management is evolving more rapidly than ever before. The process-based orientation of the predictive development approach is prescriptive and cannot always support the amount and complexity of change inherent in today’s global business landscape. 

We require more and better ways to solve problems, create solutions and offer businesses and organizations a wider range of value options. 

Project teams are increasingly asked to focus more on intended outcomes rather than predefined deliverables, and that is why the approaches to project management have not only changed but diversified.

Tailor the approach
  • Use tailored project management approaches to support dynamic work environments.
  • Discover what kinds of value the organization wants and when it needs to be delivered.
  • Advantages:
    • Feature or capability assessment 
    • Improve organizational tolerance for change 
Popular Project Approaches

Experienced project professionals choose the best development approach for a project, depending on the resources, timelines, stakeholders, industry, the project work and many other factors. Each project and situation requires an assessment of what method, or way of working, will best apply. Let’s take a closer look at the three methods of, or approaches to, project management: Predictive, adaptive and hybrid.

  • Predictive (aka Plan-driven): This is the established and highly reliable approach to project management where, as much as possible, the project needs, requirements and constraints are understood at the beginning of the project, and plans are developed accordingly.
  • Those plans drive the project forward.
  • The more well planned, the more predictive and controlled the project is.
  • Change is always possible but is considered and controlled through a process that ensures the continued viability of the project.
  • Risk is approached and managed methodically.
  • Adaptive: This encompasses a range of iterative, incremental and agile approaches where the team works collaboratively with the customer to determine the project needs, quickly building outputs based on those assumptions, getting feedback, and continuing forward or adapting as much as needed.
  • The aim is to deliver value early by regularly confirming and incorporating input.
  • The team’s work, together with the customer’s input, drives the project forward.
  • Adaptive development acknowledges risk and change as part of innovation.

Hybrid: A third option is to incorporate components of both approaches and create a tailored development approach.

Product management is different from project management

  • It represents a key integration point. 
  • The product is part of the project requirements, either as an end item itself or a component item. 
  • Product management involves the integration of people, data, processes and business systems to create, maintain and develop a product or service throughout its life cycle. 
  • The product life cycle is a series of phases that represents the evolution of a product, from introduction through growth, maturity and to retirement. 
  • Product management may initiate programs or projects at any point in the product life cycle to create or enhance specific components, functions or capabilities.
Project Life Cycle
  • A project life cycle is a progression through a series of developmental stages. Visualize a project from start to completion. That is a complete life cycle. 
  • It’s how you organize doing the work of the project — the logical breakdown of what you need to do to create project deliverables. 
  • The project life cycle is based on the industry in which the project is being conducted, the organization’s preferences and the development approach, e.g., predictive, adaptive or hybrid.

Therefore, the development approach describes how the project work is conducted.

More About Predictive
  • Let’s take a closer look at the predictive life cycle. This graphic shows a single phase and an outline of the predictive development approach. 
  • The project management life cycle is applied to each phase when using a predictive approach — and often includes governance or oversight through reviews conducted at the end of each phase.
  • Just as the name suggests, predictive life cycles are very good when you have fixed requirements and fixed expectations of those requirements. There is a high element of control — and thus, predictability — in projects that follow a predictive life cycle.
More About Adaptive
  • There may be fewer and fewer cases of projects that can adopt purely predictive life cycles. 
  • That’s because we are living in an age of high complexity and change, where predicting outcomes is fraught with difficulty, and business needs and conditions, as well as internal and external enterprise environmental factors (EEFs) change rapidly and without notice.
  • Notice here that a project begins with an initial vision for the product, and this is developed iteratively or incrementally (the development approach) with the customer’s input until the customer is happy with it. 

The terms “iterative” and “incremental” are often confusing, therefore worth clarifying here. 

  • Iterative and incremental development approaches are similar.  
  • They are used in both adaptive and hybrid life cycles.
  • And they are what enables teams to release value to the customer before the end of the project!
Incremental approach:
  • Produces deliverables successively (in pieces or modules), adding functionality until the final deliverable contains the necessary and sufficient capability to be considered complete.
  • Provides finished deliverables that the customer may be able to use immediately.
Iterative approach
  • Focuses on an initial, simplified implementation and then progressively elaborates, adding to the feature set until the final deliverable is complete. 
  • Allows feedback for unfinished work to improve and modify that work.
Most popular Agile approach – Scrum
  • Scrum is an agile framework for developing and sustaining complex products, with specific roles, events and artifacts.
  • It is one of the most widely used agile frameworks, so worth discussing here.
  • Agile is an umbrella term that refers to a family of approaches that share common values and principles.

This is an overview of Scrum ceremonies that focus on product development. These four are recognized by the Scrum Alliance. We’ll look at some other notable agile planning meetings for the project and product on the next slide.

Sprint planning
  • Team collaborates with product owner to plan work for current sprint
  • Scrum master/senior scrum master facilitate
Daily scrum
  • Short daily meeting of team only
  • Team members describe work, ask for help, consider progress toward goal

Not a status meeting

Sprint review – can include Demo
  • Held at end of sprint
  • Team, product owner and stakeholders attend, or customers review progress and give feedback to adapt product
Sprint Retrospective
  • Team identifies improvements to performance and collaboration

Related Articles

Share your love

Leave a Reply

Your email address will not be published. Required fields are marked *