Project Management in Practice

What is a project?
A project is a temporary endeavor, with a beginning and an end, and it creates a unique product, service, or result.
Projects are created to provide business value and to deliver benefits defined in a business case and the benefits management plan
(strategic management plan). Projects are designed to bring a positive change to the organization, usually to add or improve
products or services, and, in some cases, to satisfy legal or other regulatory requirements.

→ Project is a transformation of an idea into a tangible reality.

What is Portfolio Management?

A portfolio includes programs, individual projects, and other related operational work that are prioritized and implemented to achieve
a specific strategic business goal. Combining programs, projects, and operations into one or more portfolios helps optimize the use of
resources, enhances the benefits to the organization, and reduces risk.
A project is included in a portfolio based on potential return on investment, strategic benefits, alignment with corporate strategy, and
other factors critical to organizational success.

What is Program Management?

By grouping related projects into a program, an organization can coordinate the management of those projects. The program approach
focuses on the interdependencies between the projects and may help decrease risk, achieve economies of scale, and improve
management.
Projects are combined into programs to provide coordinated control, support, and guidance.

What is Project Management?

Project Management is the systematic process of managing work efficiently and effectively to deliver planned results. The art of
project management relates to how a project manager uses skills such as influencing, organizing, and strategizing, in addition to
other interpersonal and team skills.
Effective use of project management ensures that the organization is focused on the most important work and, because of
appropriately tailored planning efforts, the work is done correctly and in the most time and cost effective manner. Risks are identified
and planned for before they occur, communication is managed effectively, and quality is achieved. These efforts result in satisfied
stakeholders and achievement of business objectives.

What is the difference between a project, program, and portfolio?

A project is a temporary endeavor with a beginning and an end, a program is a group of related projects, and a portfolio is a group of
projects and programs related to a specific strategic organizational objective.

Project Life Cycle

Project management process is the application of tools and technics to transform the idea into a tangible solution.

A life cycle is a progression of phases through a series of developmental stages. The project life cycle describes the phases of work on a
project required to produce the deliverables.
For projects following a plan-driven life cycle, you may go through the overall project management process (initiating through closing)
once for the entire project, although portions of the process may be iterated or repeated throughout the project life cycle.

Starting point: idea, need, problem, opportunity.

In initiating, the project manager determines whether the business case and the benefits management plan can be achieved and
does some high-level planning to verify that it is likely the project can be completed within the given constraints of scope, schedule and
cost. Stakeholders are identified, and stakeholder analysis is performed to assess each stakeholder's potential involvement and
influence on the project.
The project is formally authorized in project initiating when the sponsor signs the project charter.
Project charter → we define the objectives (high level estimate for budget, quality etc.), business case (ROI, NVP, PBP, strategic value,
inventory, risk)

After the project charter has been approved, the project moves from initiating into detailed planning, where a project management
plan (including plans for how to plan, execute, monitor and control, and close the project) is developed. For this phase we have to
conduct researches on the market.

The project then moves into executing, where the team completes the work according to the processes and procedures detailed in the
project management plan.
The baselines:
• Stakeholder management → to whom we are sharing the solution
• Scope → what
• Scheduling → when and how we are going to reach the solution
• Budget → how much
• Resources → money and people, materials and equipment
• Quality → KPIs
• Risk management → defining the damage if something unexpected happens
• Communication
• Procurement
• Integration management

While the work is being done, the work results (or work performance data) are fed into monitoring and controlling, to make sure the
project is progressing according to the baselines established in the project management plan.
If variances from the plan require changes, the change requests are evaluated in the Perform Integrated Change Control process (part
of monitoring and controlling) to determine their impact on the project, identify the best options for dealing with them, and decide
whether they should be approved, rejected, or deferred.

Ultimately, when the work is done (or the project is terminated), the project moves into closing.

Final point: tangible solution, product, service

→ the strategy is connecting the initial and final point, next to that the legal framework
The market is after the final point, it is where there are clients (for B2B) and customers (for B2C). End users are the ones who spend for
the product/service. B2G in the market is the 60%.

The penalty is proportional to the amount of time and money lost if the product is not on the market

Which maybe the reason for entering project initiating, planning, executing, monitoring and closing?
Project Initiating
• Business need
• Project has so many problems that you reevaluate the business need
• Begin a new phase of the project
Project Planning:
• Project executing necessitates ongoing planning
• Project monitoring necessitates additional planning
• Project initiating is completed
Project Executing:
• Project planning is completed
• Integrated change control results in a changed project management plan
Project Control & Monitoring
• Need to monitor quality of deliverables
• Requested changes, including recommended corrective and preventive actions
• Work performance data
Project Closing
• Project is complete
• Project is delivered to the customer
• Project phase is completed

Integration Management
What is a project manager's primary role? To perform integration management, to pull all the pieces of a project together into a
cohesive whole.

Project charter
All projects should have charters, whether the project is an internal initiative or is being done for an external customer. The development
of a charter often starts with some form of agreement or understanding. When the work is being done for an outside organization, a
formal contract is involved.
Although we often think of the buyer creating a project charter, the organization providing services to the buyer should also create a
charter. This means that on a project where there is a buyer and a seller, both organizations would create project charters that have
different points of view. The buyer's reason for the project, as stated in their project charter, might be to achieve a particular product
scope while meeting project constraints. The seller's reason for working on the project, as stated in their project charter, might be to
increase revenue, enhance their reputation, or gain additional work from the buyer.
Regardless of whether you have a large or small project, developing the project charter requires the following actions:
• Identifying stakeholders,
• Meeting with key stakeholders to confirm high-level requirements project scope, risks, assumptions, and issues,
• Defining product scope,
• Defining project objectives, constraints, and success criteria,
• Documenting risks.

At various points during project execution, the project manager reviews the project charter. Which of the following best describes what a
project charter may be used for when the work is being completed?
One way to decide if a change should be approved is to determine whether the work falls within the project charter. If not, it should be
rejected, assigned to a more appropriate project, or addressed as a project of its own.

Project Management Plan

The project management plan integrates all the individual management plans into a cohesive whole, creating a centralized
document to describe what is involved in the project. The overall project management plan also includes the baselines for the project.
Together these baselines are called the performance measurement baseline.

Scope baseline → the project scope statement, work breakdown structure (WBS) and WBS dictionary.
Schedule baseline → the agreed-upon schedule, including the start and stop dates for each work package, and scheduled milestones.
Cost baselines → the time-phased cost budget (the spending plan indicating how much money is approved for the project and when
the funds are required and will be available).

The project management plan includes more than just a bar chart and the project manager's plan for completing the work. It includes all
the management plans for the project.
Change Management Plan
Controlling a project to the baselines is so important that the project manager needs to think in advance about where there might be
changes and what to do to limit the negative effects of changes.

Are you focused on change management on your projects? Regardless of whether you work on small or large projects, your role is not
just to facilitate changes. Instead, you need to plan the project in a way that minimizes the need for changes and prevents unnecessary
changes.

You also need to proactively look for needed changes, thereby solving problems before they have a major negative impact on the
project. Because making changes is much costier than including the work from the beginning, changes should not be undertaken lightly.

→ A change management plan describes how changes will be managed and controlled.

A change management plan may include:

• Change control procedures (how and who).
• The approval levels for authorizing changes.
• The creation of a change control board to approve changes, as well as the roles and responsibilities of those on the board.
• A plan outlining how changes will be managed and controlled.
• Information on reporting the outcome of change requests.

Change Requests
• Three main categories of change requests are corrective action, preventive action, and defect repair.
• Changes may involve additions to the project requested by the customer, changes to the plan that the team believes would make
their work more efficient, or even changes to the policies and procedures used on the project.

When a change request is made, the other impacts to the project should be evaluated first. The change could impact scope, cost,
quality, risk, resources, and/or customer satisfaction. Once these are evaluated, the change control board, if one exists, can approve or
deny the change.

Detail Process for Managing Change Requests

• Prevent the root cause of changes → The project manager should not just focus on managing changes; they should proactively
eliminate the need for changes.
• Identify the need for a change → The project manager should be actively looking for changes from relevant stakeholders because
discovering a change early will decrease the impact of the change.
• Evaluyate the impact of the change → If it is a scope change, how will it affect the rest of the scope of the project? If it is a
schedule change, how will it affect the rest of the schedule for the project?
• Create a change request → The process of making any change should follow the change management plan.
• Perform integrated change control → How will the change affect all the other project constraints?
− Assess the change. Does the change fall within the project charter? If not, it should not be a change to your project; it may be
an entirely different project. If the change is not beneficial to the project it should not be approved.
− Identify options. Actions to decrease threats or increase opportunities include compressing the schedule, changing how the
work is performed, adjusting quality or cutting scope so that the effect of the change will be minimized.
− The change is approved, rejected, or deferred. Those changes that affect baselines, charter, etc. would likely need to go to a
change control board and/or the sponsor.
− Update the status of the change. This helps everyone know the status of the change.
− Adjust the project management plan, project documents, and baselines as necessary.
• Manage stakeholders expectations → By communicating to stakeholders affected by the change.

Why do we use project?

• To be more effective and efficient
• Build trust with the stakeholders
• To be faster, better, stronger than our competitors in the market

Strategic project thinking

Aging: In the following years, the population about 60 or more is going to be the 21% of the world by 2050. This has an impact on the
market: we forecast what are the expectations to slightly change the services.
Acceleration urbanization: by 2050 the 72% are going to live in the cities (now it is around 40%).
Rise technology: in 2020 we have 6.58 devices per person, there is an exponential growth in the use of technology. We have to
interconnect with different devices to satisfy expectation.
Resources scarcity: to keep this standard of living we need 50% more of energy, 40% more of water.

Strategic project thinking

• Plan
• Build
• Test
• Review
• Deploy
→ it takes 18 months to realise the project, this is too much time because competitors have already produced something! In 2001 there
was the bubble of technology: Blackberry produced a disruption since they created a huge gap from the existing products.
In the new concept of agility (snail graph).

Agile Project Management

What is Agile Management?
• Approach to managing changes and complexity
• Approach to managing and working on Projects: innovative CX solutions
• Agile is a set of Values and Principles through Practices
→ Agile is a mindset defined by values, guided by principles, and manifested through many different practices. Agile practitioners select
practices based on their needs.

Manifesto for Agile

We are uncovering better ways of developing software by doing it and helping others do it.
Through this work we have come to value:
• Individuals and interaction over processes and tools
• Working software over comprehensive documentation
• Customer collaboration over contract negotiation
• Responding to change over following a plan

12 principles:
1. Our highest priority is to satisfy the customer through early and continuous delivery or valuable software.
2. Welcome changing requirements, even late in developments. Agile processes harness change for the customer’s competitive
advantage.
3. Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.
4. Business people and developers must work together daily throughout the project.
5. Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.
6. Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant
pace indefinitely.
7. Working software is the primary measure of progress.
8. The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.
9. Continuous attention to technical excellence and good design enhances agility.
10. Simplicity – the art of maximizing the amount of work not done – is essential.
11. The best architectures, requirements, and designs, emerge from self-organizing teams.
12. At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behaviour accordingly.
Agile vs. non-agile planning

Agile is:

Innovative opportunities through Agile Solutions: new twchnology, new competitor, new trend-product,service, new customer
behaviour, new paradigm.

What is Agile?

Introduction to Agile Project Management

Why Agile Project Management is a Key Success Factor?
• Effectiveness and efficiency
• What is being delivered is right, real value for the customer
• Mitigate/eliminate uncertainty
• Leadership, team&stakeholders engagement (expectations)
• Faster, better, stronger
• Build trust

New Organisational Paradigm

N.B.:
Plan driven approach: related to traditional techniques to develop a strategy
Agile approach: incremental iteration to implement the strategy

Pros and cons of traditional and agile approach

This can be a question in the exam: look for more information!!!

Traditional Planning (Plan driven approach)

Pros:
• Clear structure: The process is well-structured, with defined phases (initiation, planning, execution, monitoring, and closing),
making it easy to understand and follow.
• Comprehensive planning: The planning phase is extensive and completed before the project execution begins, which ensures all
aspects are considered upfront.
• Predictability: Due to detailed upfront planning, this approach offers clear milestones and predictable timelines.
• Defined deliverables: There is a clear understanding of the final product from the start, which helps in estimating time and cost
effectively. Once the scope is defined, there is less deviation, leading to stability in execution.
• Easier to predict budget
• Clear Roles and Responsibilities: Traditional planning establishes well-defined roles and a hierarchical structure, which can
streamline accountability.
→ We know exactly the process to follow. Depending on the sector it can happen we have to use this method (for example when
building aircraft we can not do experiments)
→ Scram method is the most famous traditional approach, everyone knows the exact position they cover and consequently authority
and responsibilities) → for flat organization

Cons:
• Big investments at the beginning, since there are not trials you spend everything at the very beginning.
• Inflexibility: Once the project moves past a phase, making changes can be difficult and costly. It is less adaptable to changing
requirements.
• Long Planning Cycles: The extensive planning can lead to delays in starting the execution phase, and any missteps in planning
could lead to significant issues during execution.
• Risk of Obsolescence: By the time the product is delivered, market or customer needs may have changed, leading to a solution
that no longer fits. Feedback typically comes at the end of the project, which can result in missed opportunities to make early
improvements.
• Risk of scope creep: Without iterative testing or frequent validation, the project can stray from its initial goals without realizing until
too late.
• Limited Collaboration: Tends to follow a top-down approach, which can restrict team engagement and real-time collaboration.

Agile Planning
Pros:
• Adaptability: Agile allows for iterative cycles (sprints or iterations) that accommodate changes in requirements or adjustments
based on feedback, making it ideal for dynamic environments.
• Continuous feedback: Each iteration delivers usable outcomes, allowing teams to gather feedback and improve incrementally
• Customer-Centric: Focuses on delivering value to the customer through early and continuous feedback, ensuring that the final
product meets their needs.
• Early value delivery: By delivering parts of the project in iterations, stakeholders start seeing value earlier in the process.
• Better risk management: Since the process involves continual reassessment and adjustments, risks are identified and mitigated
earlier.
• Enhanced collaboration: Agile encourages continuous stakeholder engagement throughout the project, ensuring alignment with
evolving need. It also helps in fostering creativity and collaboration among team members.
→ Less risky since you can work on prototypes, more creativity, more stimulating for employee (organic structure, non vertical, we can
take part of ROI and reinvest in the project → much more profitable since we recover after 2 iteration more or less
Cons:
• Unclear timeline and budget: Agile's iterative nature makes it harder to estimate the final completion time and total cost upfront.
• Requires Discipline: While flexible, Agile requires teams to maintain a strict discipline to ensure regular delivery and continuous
feedback. Poor communication or lack of cohesion can lead to chaos
• Scope can evolve endlessly: Without clear boundaries, the evolving nature of agile projects can result in scope creep if not
properly managed.
• Incomplete early deliverables: The early iterations may provide incomplete deliverables, which might not be useful to the end
customer until the final product is complete.
• Team Dependency: Success heavily depends on team collaboration and the skill level of the team members, making it challenging
for organizations with less experienced teams.
• Difficult to predict budget

In summary, non-agile approaches provide more certainty and structure at the outset, which can be beneficial for projects with well-
defined requirements. Agile approaches, on the other hand, provide more flexibility and better handling of changing requirements but
can introduce uncertainty regarding the final timelines and budget.

Strategic agility
Depending on the feedback of the market we can choose to add features or not, but at the same time there are new technologies,
competitors etc.: we decide if we can continue investing or not.
There is never a final point since the product can always be made better.

Start: vision → Minimum Viable Product (not at the full potential of the product but maybe just one feature but already in the market
earlier) → next iteration with an added feature or incremented value → new technology, competitor, trend-product-service customer
behavior, paradigm… → decision to stop or adapt to changes → next iteration …. → final solution that may be different from the initial
vision.

Project Stakeholders Management

Processes required to identify the people or organizations that could impact or be impacted by the project, to analyze their expectations,
and to develop appropriate management strategies for effectively engaging them in project decisions.

Project stakeholders are individuals, groups, or organizations who may affect or be affected by a decision, activity, or outcome of a
project. They are comprised of persons and organizations who are actively involved in the project, or whose interests may be positively
or negatively affected by the execution of the project. They may also exert influence over the project and its deliverables.

The project team identifies internal and external, positive and negative stakeholders, advising them in order to determine properly
the project requirements and to satisfy the expectations of all parties involved. The project manager should manage the
influences of these various stakeholders to ensure a successful outcome.

While communication, coordination and development of relationships are parts of stakeholder management, collectively they
contribute to the main objective of this process: stakeholder satisfaction.

An important part of a project manager’s responsibility is to manage stakeholder expectations, which can be difficult because
stakeholders often have very different or conflicting objectives.

Part of the project manager’s responsibility is to balance these interests and ensure that the project team interacts with stakeholders
in a professional and cooperative manner.

Stakeholder analysis generally follows the steps described below:

• Identify all of your project stakeholders
• Determine their requirements
• Determine their expectations
• Determine their interest
• Determine their level of influence
• Determine their level of authority (power)
• Plan to engage stakeholders.
• Plan how you will communicate with them.

A stakeholder’s belief about or mental picture of the future is an expectation. Expectations are important to recognize and address to
ensure stakeholder satisfaction with the project. The project manager must do additional work to uncover the expectations of
stakeholders.

The Stakeholder Register

The main output of the stakeholder analysis is the stakeholder register. This document contains information about identified
stakeholders that includes, but is not limited to:
• Identification information → Name, organizational position, location and contact details, and role on the project.
• Assessment information → Major requirements, expectations, potential for influencing project outcomes, and the phase of the
project life cycle where the stakeholder has the most influence or impact.
• Stakeholder classification → Internal/external, impact/influence/power/interest, or any other classification model chosen by the
project manager.

This is an example of a Stakeholder Classification grid:

Stakeholders Managers → processes required to identify the people or organizations that could impact
or be impacted by the project, to analyze their expectations, and to develop appropriate management
strategies for effectively engaging them in project decisions.
Everyone who can affect or be affected by the resources of the company, they can be internal or external
stakeholder.

These are multiple classification model used for stakeholders’ analysis, such as:

Power/interest grid → Grouping the stakeholders based on their level of authority (power) and their
level or concern (interest) regarding the project outcomes.

Stakeholder Matrix
There is a framework power-interest which helps to allocate the importance of the stakeholder for the company.
Once we have all the stakeholders we try to classify them in order to understand their needs, concerns and expectations and decide
where to invest more money.
• Yellow zone (top left) → engagement strategies

Power/influence grid → Grouping the stakeholders based on their level of authority (power) and their ability to positively or negatively
affect a project (influence).
Salience model → Describing types of stakeholders based on their power (ability to impose their will),
urgency (need for immediate attention), and legitimacy (their involvement is appropriate).

Stakeholder cube → Providing a model with multiple dimensions (power, interest, attitude), that improves
the depiction of the stakeholder community as a
multidimensional entity and assists with the development of
communication strategies.
• Power: influenial-insignificant
• Interest: backer-blocker
• Attitude in project: active-passive

The degree to which a particular stakeholder may be able to be positively or negatively affect a project is the level of influence. Each
stakeholder’s level of influence may be based on status within the organization, seniority or other factors. The level of influence of each
stakeholder should be identified and managed throughout the project.

KANO Model (stakeholders relationship – tailoring solutions)

The Kano Model is a framework for prioritizing and categorizing stakeholders, customers or users needs. It was
developed by Professor Noriaki Kano in the 1980s in Japan. The Model classify all the needs in 5 categories:
Basic Needs (Must -Be), Performance Needs (One Dimensional), Excitement Needs (Attractive),
Indifferent Needs, and Reverse Needs.

• Delighters (attractive) → yield high levels of customer support. These features deliver unexpected, novel,
or new high-value benefits to the customer.
• Satisfiers (desired/one-dimensional) → these features bring value to the customer. In this category, the
more the better.
• Dissatisfiers (must-be) → these are features that will cause a user to dislike the product/service if they are not there but will not
necessarily raise satisfaction if they are present.
• Indifferent → these features have no impact on customers in one way or another. Since customers are indifferent to them, we
should try to eliminate, minimize, or defer them.

Tool useful to identify and create a very customized solution for different types of stakeholders. We measure the measure of
satisfaction on the y-axis and the level of functionality on the x-axis (depending if we are or we are not using that product).
If the functionalities delivered are the basics (= must-be), then the level of satisfaction is neutral. We have to differentiate from the
competitors to get an higher level of satisfaction.
The desired functionalities are the one that, if provided, they give an increased satisfaction of the customer: there is a linear function,
linear proportion between satisfaction and level of functionality.
Attractive functionalities: the competitors are not delivering this functionality, therefore if I am not providing this it is not a reason of
decreased satisfaction but, if I am providing them then there is an increased level of satisfaction: there is an incremental increase of
satisfaction given an increase of the level of functionality.
Finally, there are indifferent functionalities, which can not increase / decrease the level of satisfaction because stakeholders are not
interested.

Example from insurance

In 2016 Axa evaluated its business portfolio, a threat from other companies came up. Investment in AI-CX, solution about blockchain,
partners-new customers, cyber insurance services, beyond insurance. Depending on the data collected, the price changes. 30.000 new
start-up in the world everyday (just 0.5% of them are successful = alive and profitable after 3 years).
Big data system built in 2016 → From the beginning a MVP with a basic price is offered, after 3 months the performance of start-ups are
evaluated with 600 different KPI. If the start-up is doing well, then there is an incremental offer.
Today the top service by Axa are data sold to start-ups which want to be successful in the business.

Managing and Monitoring Stakeholders Management

Stakeholder management and monitoring generally follows the steps described below:
• Manage stakeholder expectations and influence.
• Communicate with stakeholders.
• Monitor communications and stakeholder engagement.

Identify what items (related to stakeholder management) belong to each Project Management Process Group:
P1. Initiating:
• Identify stakeholders
• Determine stakeholders’ expectations, interest, influence and impact
• Develop stakeholder register
P2. Planning:
• Plan how will you communicate with stakeholders
• Plan to engage stakeholders
P3. Executing:
• Facilitate conflict resolution
• Facilitate stakeholder engagement and manage expectations
P4. Control & Monitoring:
• Monitor stakeholder engagement
• Inform stakeholders of all change request results

There are some tools to manage and monitor stakeholder engagement. One of them is the stakeholder engagement assessment matrix,
comparing between the current engagement levels of stakeholders and the desired engagement levels required for successful project
delivery. The engagement level of stakeholders can be classified as
follows:
• Unaware of the project and potential impacts.
• Aware of the project and potential impacts but resistant to any
changes that may occur as a result of the work or outcomes of
the project. These stakeholders will be unsupportive of the work
or outcomes of the project.
• Neutral: Aware of the project, but neither supportive nor
unsupportive.
• Aware of the project and potential impacts and supportive of the
work and its outcomes.
• Leading: Aware of the project and potential impacts and actively
engaged in ensuring that the project is a success.

A key to your success as a project manager is how you handle stakeholder relationships.

Think about how you involve stakeholders on your projects. Proper stakeholder management means you keep them informed, solicit
their input, and work to satisfy their needs and expectations. Without this effort, the project may fail.
Remember that it’s recommended to analyze and manage the needs and the level of influence of stakeholders throughout a project. If
all the stakeholders’ needs and requirements are taken into account before plans are finalized and project work is begun, fewer changes
will be needed later in the project, when they will be more costly. The earlier stakeholders are identified, the better for the project.

Scope Management Plan

Processes required to ensure that the project includes all the work required, and only the work required, to complete the project
successfully.
Scope management is the process of defining what work is required and then making sure all of that work, and only that work, is
completed.

Definition:
• You must plan how you will determine the scope, as well as how you will manage and control scope. This is part of your scope
management plan
• Scope must be clearly defined and formally approved before work starts.
• A work breakdown structure (WBS) is useful on all projects. Using this tool enables you to clarify identified scope as well as find
additional scope.
• You are responsible for getting acceptance of deliverables throughout the project.

Requirements:
• Requirements are elicited from all stakeholders, not just the person who assigned the project.
• Requirements must be evaluated against the business case, ranked, and prioritized to determine what is in and out of scope

Changes:
• A work breakdown structure (WBS) is useful on all projects. Using this tool enables you to clarify identified scope as well as find
additional scope.
• While the project is being completed, you must check to make sure you are doing all the work included in the project management
plan, and only that work.
• Any change to scope must be evaluated for its effect on time, cost, risk, quality, resources, and customer satisfaction.
• Changes to scope require an approved change request.
• Scope changes should not be approved if they relate to work that does not fit within the project charter.

What is the differences between product scope and project scope?

• Product Scope → Requirements that relate to the product, service, or result of the project. It can also be defined as the product
deliverables with their associated features and functions. It answers the question, "What end result is needed?".
• Project Scope → The work the project team will do to deliver the product of the project. It encompasses the product scope.
Project scope includes the planning, coordination, and management activities (such as meetings and reports) that ensure the
product scope is achieved. These efforts become part of the scope baseline and scope management plan, which are parts of the
project management plan. To determine whether the project scope has been successfully completed, the work accomplished is
measured against the scope baseline.

Plan Scope Management

The scope management plan essentially contains the parts which detail how scope will be planned, executed, and controlled. It
defines the following:
• How to achieve the scope
• What tools to use to plan how the project will accomplish the scope
• How to create the WBS
• How scope will be managed and controlled to the project management plan
• How to obtain acceptance of deliverables

Collect requirements
Requirements are what stakeholders need from a project or product. Requirements should relate to solving problems or achieving the
objectives outlined in a project charter. Requirements may include requests about how the work is planned and managed.

For example, a stakeholder could request that systems not be shut to accommodate a project during peak business hours.
Requirements may include the capabilities stakeholders would like to see in the product, such a software application that allows
multiple users to access it at the same time.

Requirements can also relate to the following:

• Quality
• Business processes
• Compliance
• Project management

Requirements Traceability Matrix

Have you ever worked on a project in which some requirements got lost in the details? In the process of determining requirements, one
requirement often leads to additional, more refined requirements and clarifications, especially on large projects. It can be difficult to
remember where a requirement came from and what its significance is to the project.

Losing focus on the reason for a requirement can result in a major strategic or project objective not being met. The requirements
traceability matrix helps link requirements to the objectives or other requirements to ensure the strategic goals are accomplished. The
matrix is used throughout the project in analyzing proposed changes to project or product scope.
Define scope
The Define Scope process is primarily concerned with what is and is not included in the project and its deliverables.

Remember that planning is iterative. When the requirements have been determined and the scope is defined, the project manager is
ready to determine the schedule and budget. If the resulting schedule and budget do not meet the sponsor's or management's
expectations for the project, the project manager needs to balance the requirements (scope) against budget and schedule constraints.

Through iterations of the project, options for meeting the scope, schedule, and cost objectives are developed. These options are
then presented to management for a decision.

The scope statement is a document that in effect says, "Here is the approved project and product or service scope for this project”. The
project scope statement may include the following:
• Product scope
• Project scope, including a description
• Deliverables of the project
• Acceptance criteria
• What is not part of the project
• Assumptions and constraints

The project scope statement is an output of the Define Scope process, which occurs during project planning.

Create Work Breakdown Structure

The WBS is a required element of project management. This organizational tool shows all of the scope on a project, broken down into
manageable deliverables and work packages.

Most commonly, the project name goes at the top of a WBS. The next level is typically the same as the development life cycle. The
subsequent levels break the project into deliverables, which are then broken down again into smaller component deliverables,
ultimately to create work packages.

Such decomposition continues until reaching the level appropriate to manage the project.

A WBS allows you to break down a seemingly overwhelming project into pieces you can plan, organize, manage, and control.

Note that on a WBS, work refers not to an activity, but to the work products or deliverables that result from an activity or group of
activities. A WBS is deliverable-oriented.

Every WBS is unique, and every project manager will approach creating a WBS in their own way. But there are a few guidelines that
every project manager should follow when creating a WBS:

Requirements can also relate to the following:

• Input → WBS should be created by the project manager using input from the team and other stakeholders.
• Levels → Each level of a WBS is a breakdown of the previous level.
• Project → An entire project should be included in the highest levels of a WBS. Eventually, some levels will be further broken down.
• Deliverables → A WBS includes only project deliverables that are required; deliverables not included in the WBS are not part of the
project.
A WBS is the foundation of a project. This means almost everything that occurs in planning
after the creation of a WBS is related to the WBS.
For example, project costs and schedules are estimated at the work package or activity level,
and not for the project as a whole. Also note that a WBS can help a project manager identify
more risks by examining a project at the work package level.

Work packages are assigned to individuals or parts of the performing organization, depending
on the size of the project.

The WBS can be used as a communications tool for all stakeholders to see what is included in
the project.

WBS Dictionary
Think about how a work package is identified in a WBS. It is usually described using only one or
two words. But assigning a deliverable with such a brief description to a team member allows for too much possible variation. In other
words, it allows for scope creep.

A WBS dictionary is the solution to this problem. This document provides a description of the work to be done for each WBS work
package, and it lists the acceptance criteria for each deliverable, which ensures the resulting work matches what is needed. Therefore,
a project manager can use a WBS dictionary to prevent scope creep before work even starts, rather than dealing with scope creep while
the work is being done.

Descriptions of the work packages are in the WBS dictionary. Activity lists may identify the work package they relate to, but they do not
contain detailed descriptions of the work packages. The project scope statement defines the project scope, but it does not describe the
work a team member is assigned.

3 mandatory documents:
• Scope statement → vision
• Work-breakdown structure (WBS) → big picture: we break down a more complex concept into smaller elements, which become
from this moment deliverables → if we break down again the deliverables, they become WP’s (work packages) → we can now
estimate time, resources and cost. We usually breakdown the packages until they can estimate how much resources and costs
they need for 80 h of work (the usual labour of two people for 4 weeks)
• WBS Dictionary: document for providing the details for building the WBS

The project scope statement, along with the WBS and WBS dictionary, comprise the scope baseline.

Validate Scope
The Validate Scope process involves frequent, planned meetings with the customer or sponsor to gain formal acceptance of
deliverables during project monitoring and controlling.

Validate Scope is done to help ensure the project is on track from the customer's point of view during the project, rather than just
hoping to get final acceptance in project closure.

It is better to find changes and issues during the project than at the end. The customer will either accept deliverables or make change
requests.

These are some tips to manage properly the ‘Validate Scope’ process:
• Work must be completed and checked before each meeting with the customer; therefore, you must have what are called verified
deliverables.
• It's helpful to have the approved scope with you when you meet with the customer, so you need the scope baseline from the
project management plan.
• You'll also need to share information about the requirements of the project and show the customer how those requirements have
been validated. This information can be found in the requirements traceability matrix.

The Validate Scope process occurs during project monitoring and controlling. It is done at the end of each project phase to get
approval for phase deliverables, as well as at other points to get approval for interim deliverables.

Process:
• Changes are requested
• Change requests are evaluated through integrated change control, and approved changes may lead to re-planning
• Complete deliverables
• Perform Control Quality inspection (verify deliverables)
• Meet with the customer (validate scope)
Traceability Matrix
We have n different requirements (still intangible), and then we have k deliverables. We are checking if everything done in the WBS is
respecting the expectation of the main stakeholders.

• An empty column: maybe we can not satisfy the requirements,

therefore we are not providing the solution and indeed we have to go
back to the WBS.
• An empty row: we are providing something which is not required by the
clients → we can transform that deliverable in something more
attractive or give it up
→ This might be an exam question.

We have to justify every strategic goal, understanding which outcome is contributing to.

When we have plenty of solutions, we do not decide to implement them all at once but we have to decide which ones to prioritize:
• Solutions depending on what is more important for the stakeholders
• The ones which meet more requirements
• The ones which give more value to customers
• Return On Investment
• Project Cost
• Net Present Value
• Payback period
• Strategic value
• Long term-partnerships

Control Scope
Control Scope involves measuring and assessing work performance data against the scope baseline and managing scope baseline
changes. At any point in a project, the project manager must be sure that the scope is being completed according to the project
management plan.

You, as project manager, need to be aware of the original requirements recorded in the requirements documentation and the
requirements traceability matrix. You, then, have to measure the completed work against the scope baseline and determine whether
the variances are significant enough to warrant changes. If necessary, you would submit a change request to assess the impact the
change would have on all aspects of the project. New work performance information may result, along with updates to the project
management plan and project documents.

Control Scope focuses on controlling the scope of the project and Perform Integrated Change Control focuses on determining the
impact of a change of scope on time, cost, quality, risk, resources, and customer satisfaction.

Schedule Management Plan

Processes required to manage timely completion of the project.

One of the key responsibilities of a project manager is ensuring that the needed end date for a project can be met and to create
options to make it happen, all before project executing starts. If you know the many options for compressing a project schedule and
understand that a project schedule must be realistic before project executing begins, this unit should not be difficult for you.
Schedule baselines: when, how, who.

Plan Schedule Management

What is Schedule Management?
The Plan Schedule Management process involves documenting how you will plan, manage, and control the project to the schedule
baseline, and how you will manage schedule variances. Many project managers just work on the project and hope the project meets the
deadline, but proper schedule management requires you to develop and follow a plan, measuring progress along the way.

So as part of planning, you need to determine in advance what the measures of performance will be, how and when you will capture
the data you need to evaluate schedule performance, how you will use the data to keep the project on track, and what you will do
when variances occur.
Plan Schedule Management answers questions such as: "Who will be involved, and what approach will we take to plan the schedule for
the project?" and "What processes and procedures will we use to create the schedule?"

The key outputs

The key output of this process is a schedule management plan. It is part of the project management plan, and it helps make the
estimating and schedule development process faster by specifying the following:
• Rules for estimation → Rules for how estimates should be stated; for example, should estimates be in hours, days, or weeks?
Should estimators identify both the effort (the amount of labor involved in completing an activity; for example, 12 hours) and
duration (the amount of work periods the effort will span; for example, 1.5 days) needed to complete an activity?
• Schedule baseline → A schedule baseline for measuring against as part of project monitoring and controlling.
• Variance → A threshold for acceptable variance.
• Measures → Performance measures that will be used on the project, to identify variances early.
• Variances management → A plan for how schedule variances will be managed.
• Changes → Identification of schedule change control procedures.
• Types of reports → Types of reports required on the project relating to schedule.
• Project reporting → Formats and frequency of project reporting.
• Length of releases → The length of releases and iterations (in an adaptive life cycle).

From Scope we HAVE: Scope Statement, WBS, WBS Dictionary, Traceability Matrix
What are the next steps? Define Activities, Sequence Activities, Estimate Activity Resources, Estimate Activity Durations, Develop
Schedule, Control Schedule.

Define Activities
This process involves taking the work packages created in the WBS and decomposing them into the activities that are required to
produce the work package deliverables and thus achieve the project objectives. The activities should be at a level small enough to
estimate, schedule, monitor, and control. These activities are then sequenced in the next process: sequence activities.

Defining activities is not always done as a separate process. Many project managers combine this effort with creating a WBS and
WBS dictionary; they decompose work packages into the activities required to produce them, rather than stopping at the work package
level.

Rolling Wave Planning

Have you ever worked on a project that seemed to have too many unknown components to adequately break down the work and
schedule it? It might simply be a project for which it is better to not plan the entire project to the smallest detail in advance, but instead
to plan to a higher level and then develop more detailed plans when the work is to be done. This practice is called "rolling wave
planning" and is a form of progressive elaboration.

Iterations of rolling wave planning during the project may result in additional activities being added, and in the further elaboration of
other activities. Therefore, rolling wave planning may create the need for updates to the project management plan, specifically the
schedule, scope, and/or cost baselines. These changes require integrated change control, beginning with a change request.

Milestones
Milestones are significant events within the project schedule. They are not work activities and have no duration. For example, a
completed design, customer-imposed due dates for interim deliverables, or a company-required checkpoint could be milestones. Initial
milestones are documented in the project charter. The project manager can also insert milestones as checkpoints to help control the
project. If a milestone in the schedule is reached and any of the planned work has not been completed, it indicates the project is not
progressing as planned.
Sequence Activities
The next process involves taking the activities and sequencing them in the order in which the work will be performed. The result is
a project schedule network diagram.
There are four types of logical relationships between activities:
• Finish to Start → An activity must finish before the successor can start. This is the most commonly used relationship.
• Start to Start → An activity must start before the successor can start.
• Finish to Finish → An activity must finish before the successor can finish.
• Start to Finish → An activity must start before the successor can finish. This dependency is rarely used.

Types of Dependencies
Mandatory dependency (hard logic) → A mandatory dependency is inherent in the nature of the work (for example, you must design
before you can build) or is required by a contract.
Discretionary dependency (soft logic) → This is the way an organization has chosen to have work performed. These dependencies are
important when analyzing how to compress the schedule to decrease the project duration (fast track the project).
External dependency → This dependency is based on the needs or desires of a party outside the project (for example, government or
suppliers).
Internal Dependency → This dependency is based on the needs of the project and may be something the project team can control.

Lead Time and Lag Time

Critical path → chain of linked tasks that directly affects the project finish date. If any task on the critical path is late, the whole project
is late.

• A lead may be used to indicate that an activity can start before its predecessor activity is completed. For example, web page design
might be able to start five days before the database design is finished (negative number).
• A lag is waiting time inserted between activities, such as needing to wait three days after pouring concrete before constructing the
frame for a house (positive number).

In other words: A lag is the amount of time whereby a successor activity will be delayed with respect to a predecessor activity. A lead is
the amount of time whereby a successor activity can be advanced with respect to a predecessor activity.

→ Total float and free float are the time an activity can be delayed without impacting the entire project or the next activity.

Project Schedule Network Diagram does:

• Help justify your time estimate for the project.
• Aid in effectively planning, organizing, and controlling the project.
• Show interdependencies of all activities, and thereby identify riskier activities.
• Show workflow so the team will know what activities need to happen in a specific sequence.
• Identify opportunities to compress the schedule in planning and throughout the life of the project.
• Show project progress.

Project Schedule Network Diagram does not:

• Determine team roles and responsibilities (it is part of project resource management).
• Perform risk identification, qualitative and quantitative risk analysis, and risk response planning (that’s part of project risks
management.).
• Assess what to purchase and create procurement documents. (that’s part of procurement management).

Estimate durations
When the activities have been defined and sequenced, the next step is to estimate how long each activity will take. To come up with
realistic time estimates, it’s recommended to have access to the following inputs:
• Activity list and attributes → The relevant inputs may include the time for required leads or lags between activities, which must be
factored into duration estimates.
• Assumption log → Assumptions or constraints that contribute to risk within the activities to be estimated can be found in the
assumption log.
• Lessons learned register → Information relevant to estimating the duration of schedule activities include lessons learned from
earlier in the current project or from past, similar projects performed by the organization.
• Resource breakdown structure → Represents categories of resources required for the project.
• Resource requirements → These requirements indicate the skill levels of resources required to perform specific project work.
• Project team assignments → Project team assignments should include the number and experience level of individuals who have
been committed to the project.
• Resource calendars → These calendars provide information on when key resources with specialized skills needed for project
activities will be available. If the resources are not available within the timeframe of your project, you may need to add extra time to
some activity estimates, allowing for less experienced resources to do the work.
• Risk register → The risk register may include identified threats and/or opportunities that should be reflected in the estimates.

What is wrong with padding? A pad is extra time or cost added to an estimate because the estimator does not have enough information.
In cases where the estimator has many unknowns and the information required to clarify the unknowns is unavailable, the potential
need for additional time or funds should be addressed with reserves through the risk management process. Through risk management,
the uncertainties are turned into identifiable opportunities and threats (risks). They should not remain hidden; instead, estimators need
to identify and openly address uncertainties with the project manager.

→ The role of the project manager in estimating is to provide that information, to prevent padding and to formulate a reserve in the risk
management plan.

Develop schedule
After network diagram and activity duration estimates are completed, it is time to put this information into the scheduling software. The
schedule includes of all the project data, such as the activities, duration estimates, dependencies, and leads and lags. Representations
of the schedule include bar charts and milestone charts. The approved project schedule is the baseline and is part of the project
management plan.

Critical Path Method

The critical path method involves determining the longest duration path through the network diagram, the earliest and latest an activity
can start, and the earliest and latest it can be completed. To use this method, you need to understand the following basic concepts:

Critical Path
Critical path is the longest duration path through a network diagram, and it determines the shortest time it could take to complete the
project.
Activities on the critical path have zero float. This must be addressed before the project begins, as the project manager is responsible to
ensure that the project schedule is realistic and achievable.

There is at least one critical path, the more we have the more risky is the project since we have less flexibility.

Critical activities → we can not have a delay on this activity, we have to start and finish exactly at the same moment: any delay will
impact the timing of the whole project.
Non-critical activities → we can have a slack or float: we can have a delay on this activity without affecting the total duration of the
whole project.

Float
Float or schedule flexibility is divided into:
• Total float: amount of time an activity can be delayed without delaying the project end date.
• Free float: amount of time an activity can be delayed without delaying the early start date of its successor activity.
• Project float: amount of time a project can be delayed without delaying the externally imposed project completion date required by
the customer or management.

Float is an asset on a project, as it provides schedule flexibility. If you know where you have float, you can use it to help organize and
manage the project.

In planning, the critical path generally has zero total float. During project executing, if an activity on the critical path is completed earlier
or later than planned, the critical path may then have positive or negative float. Negative float on the critical path requires corrective
action or changes to the project to bring it back in line with the plan.

It is the algorithm behind the calculation of the timing.

• Calculation from the left to the right: the earliest moment to start
activity 1 and the earliest moment to finish activity 1 (we choose the
highest).
• Calculation from the right to the left: the latest moment to finish
activity 1 and the latest moment to start activity 1 (we choose the
lowest).
• We can now allocate the activities in the diagram.

How to calculate
To calculate the numbers in the square we start from the top left (0+3= 3 = EF) → B=3+2= 5 → C=3+5=8 → D=5+1=6 → E=8+2=10 (we
choose the higher between the two EF connected with arrows to the square E) → F= 10+1=11 (we choose the higher EF between D and
E).
To go back: F=11-1=10 → E=10-2=8 → D=10-1=9 → B=8-2=6 (we choose the LF lowest between D and E) → C=8-5=3 → A=3-3=0.
Since in D we have a slack we can better allocate our resources moving resource D from D to C (where we do not have any slack time
since it is critical).

To have a better time management an Agile Organisation is paramount.

The structure of an Agile Organisation is not fixed but it constantly changes.
• Chapters (develops expertise and knowledge across squads): the chapter lead is responsible for one chapter and represents the
hierarchy for squad members.
• Tribe (collection of squads with interconnected missions): empowers tribe lead to establish priorities, allocate budgets and fro
interface with other tribes to ensure knowledge/insights are shared. Agile coach: choaches individuals and squads to create high-
performing teams.
• Squad (basis of new agile organisations):
- Includes no more than 9 people
- It is self-steering and autonomous
- Comprires representatives of different functions working in single location
- Has end-to-end responsibility for achieving client-related objective
- Can change functional composition as mission evolves
- It is dismantled as soon as mission is executed
• Product owner (squad member, no its leader): is responsible for coordinating squad activities, manages backlog, to-do-lists and
priority setting.

The Agile Project Team:

Benefits of knowing the critical path

When you know the critical path, you can use float as a way to focus your management of a project and to achieve better allocation of
resources. For example, if you have resources who are not very experienced but must be used for the project, you can assign them
(assuming they have the skill set) to work on the activity with the most float. This gives you some level of security; even if their activity
takes longer, the project is less likely to be delayed.

A resource becomes over-allocated when we assign MORE WORK than the resource can achieve within a particular time period.

Knowing the float also helps team members juggle their work on multiple projects. They, of course, need to get approval from the
project manager for any delays from the plan, but the amount of float tells them how much time flexibility they may have for each
activity they are working on.

A project manager is informed midway through project planning that she was given inaccurate data regarding new regulations affecting
the required end date of her project. She may need to make a few adjustments, but she thinks she can still manage the project to
complete it before the regulations take effect. She confirms this by analyzing the sequence of activities with the least amount of
scheduling flexibility. What technique is she using?
CPM → There are only two choices related to scheduling: critical path method and precedence diagramming. Precedence diagramming
is a diagramming technique that deals with the relationship between activities, not schedule flexibility. The project manager is analyzing
the critical path.

We, as project managers have a professional responsibility to push back, present options, and make sure the project is achievable by
properly planning the project and using schedule network analysis techniques such as schedule compression.
Also keep in mind that schedule compression is a way to utilize float by fast tracking activities that are on the critical path.

Fast tracking means adjusting the activities, so critical path activities that were originally planned to be completed in a series are re-
planned to be done in parallel. It can save time, but it also adds risk to the project. The objective of this technique is to manage the
schedule without changing the schedule baseline.

Another compression technique, called crashing, involves adding or adjusting resources in order to compress the schedule while
maintaining the original project scope. By definition, it always results in increased costs, and may increase risk. It trades time for
money.

Resource optimization
Resource optimization refers to finding ways to adjust the use of resources. There are two techniques that can achieve this outcome:

Resource Leveling
Resource Leveling is used to produce a resource-limited schedule. Leveling lengthens the schedule and increases cost to deal with a
limited number of resources, resource availability, and other resource constraints. A little-used function in project management
software, this technique allows you to level the peaks and valleys of the schedule from one month to another, resulting in a more stable
number of resources used on your project.

You might level the resources if your project used 5 resources one month, 15 the next, and 3 the next, or some other up-and-down
pattern that was not acceptable. Leveling could also be used if you did not have 15 resources available and preferred to lengthen the
project (which is a result of leveling) instead of hiring more resources.

Resource Smoothing
Resource Smoothing is a modified form of resource leveling, where resources are leveled only within the limits of the float of their
activities, so the completion dates of activities are not delayed.

Fast tracking affects both time and cost but may not help even out resource usage. Resource optimization is the only choice that will
definitely affect resources.

Control Schedule
The project (and the project manager) will be unsuccessful if the schedule baseline (the end date agreed to in planning and adjusted
for approved changes) is not met. So, monitoring and controlling efforts go beyond measuring; they also involve
taking corrective and preventive action over and over again during the life of the project to keep the project in line with the plan.

Without such work, all the efforts in planning to create a realistic schedule could be wasted.

7 steps:
1. Define deliverables / work packages
2. Sequences deliverables / work packages → finish to start means that when we finish an activity we have to move to the next
activity. We try to forecast what might happens analysing the legal framework. Start to start means we can work parralelly on two
activities. Finish to finish, we need to finish both at the same time. Start to finish is not used.
3. Allocate resources by estimating → two types of resources: work (money per unit of time → for people and equipment) and
material (money per unit) resources.
4. Estimate the duration of each work pachage (h, months, weeks depending on the complexity of the project) → direct cost
5. Optimize the schedule, at the beginning we have a draft → compression techniques: crashing (allocating more resources =
increase of resources, money but drastic decrease of time) or fast tracking (reallocating resources = same budget and slighlty
decrease of timing)

Appunti Software
Question in the exam: Dependcies, resources, duration and the cost are always at the lowest level of the ƒ! Even if we have more level we
calculate time, money and resources at the lowest level of the brench.
If the algorithm is giving me some kind of error maybe this is the problem!!!!
Trends are not linked.
Materials are selected only once and then they are comprehended for the whole project.

Cost Management
Processes involved in estimating, budgeting and controlling costs so that the project can be completed within the approved budget.

How would you prioritise the strategic projects? Return on Investment, Project Costs, Net Present Value, Project Risks, Strategic Value.

N.B.:
From scope management we have:
Scope baseline → scope, statement, WBS, WBS Dictionary

From time management we have:

Time baseline → schedule, resources, critical path and slacks

The Plan Cost Management process involves identifying how you are going to plan (including estimating and budgeting), manage,
monitor and control project costs, including the cost of resources.

This process answers the questions: "How will I go about planning cost for the project?" and "How will I effectively manage the
project to the cost baseline, control costs, and manage cost variances?"

A cost management plan may include the following:

• Estimates → Specifications for how estimates should be stated

• Accuracy and precision → The levels of accuracy and precision needed for estimates
• Formats → Reporting formats to be used
• Rules → Rules for measuring cost performance
• Guidance → Guidance regarding whether costs will include indirect costs (costs not directly attributable to any one project, such
as overhead costs) in addition to direct costs (those costs directly attributable to the project)
• Guidelines → Guidelines for the establishment of a cost baseline for measuring against as part of project monitoring and
controlling
• Procedures → Cost change control procedures
• Decisions → funding decisions
• Potential fluctuations → Guidelines for dealing with potential fluctuations in resource costs and exchange rates
• Roles and responsibilities → for various cost activities

What costs should you estimate?

To put it simply, you need to estimate the costs of all the efforts to complete the project. This
includes costs directly associated with the project, such as labor, equipment, materials, and
training for the project, as well as the following:
Cost characteristics
A cost can be either variable or fixed as well as direct or indirect:
• Variable costs → These costs change with the amount of production or the amount of work. Examples include the cost of material,
supplies, and wages.
• Fixed costs → These costs do not change as production changes. Examples include the cost of setup, rent, utilities, etc.
• Direct costs → These costs are directly attributable to the work on the project. Examples are team wages, team travel and
recognition expenses, and costs of material used on the project.
• Indirect costs → Indirect costs are overhead items or costs incurred for the benefit of more than one project. Examples include
taxes, fringe benefits, and general services.

Role of the Project Manager

STEP 1: Costs estimation

Tools and Techniques to estimate costs: Parametric estimation, Analogous estimation (Top-Down), Estimation Bottom-Up.

Costs can be estimated using techniques as top-down (analogous) estimating, or bottom-up estimating:

1. Top down (analogous) estimating

• Applicable to duration, cost, and resource estimating (and therefore for early stages of the process), analogous estimating uses
expert judgment and historical information to predict the future
• Management or the sponsor might use analogous estimating to create the overall project constraint/estimate given to the project
manager as the project is chartered.
• The project manager may use analogous estimating at the project level, using historical data from past, similar projects
→ Analogous estimating is used most frequently during project initiating and planning, not project executing. Parametric estimating
involves calculations based on historical records. Analogous estimating early in the project uses top-down estimating techniques.

→ Total budget distributed downstream to Work Packages (Top-down).

Advantages:
• Based on previous projects and expert opinions. Less costly to create and easy to make with little effort.
• Cost constraints created by management in project initiating give the project manager data to evaluate high-level project feasibility.
• Overall project costs will be capped for a project analogous estimate.

Disadvantages:
• Less accurate.
• Extremely difficult for projects with uncertainty or where there is no history of similar projects.
• Estimates are prepared with a limited amount of detailed information and understanding of the project or key deliverables.

2. Bottom-up estimating
Based on the WBS: estimated costs of individual activities and work packages (Activity Based Costing) and added upstream.
→ Applicable to define in more precise budget planning and execution phase.
• Involves creating detailed estimates for each part of an activity (if available) or work package (if activities are not defined).
• Doing this type of estimating well requires an accurate WBS.
• The estimates are then rolled up into control accounts and finally into an overall project estimate.

Advantages:
• Based on a detailed analysis of the project and the deliverables.
• Provides a basis for monitoring and controlling, performance measurement.
• More accurate.

Disadvantages:
• Requires time to break the project down into smaller pieces.
• Requires that the project be defined and well understood before estimating begins.
• Takes time and money to use this estimating technique.

STEP 2: Determine budget

The budget → In this part of cost management, the project manager calculates the total cost of the project to determine the amount
of funds the organization needs to have available for the project. The result of this calculation is the budget.

Cost baseline → The cost baseline is the portion of the budget the project manager will have control over. Meeting the cost baseline
will be a measure of project success, so the budget should be in a form the project manager can use while the work is being done to
control costs and, therefore, control the overall project.

Inputs → Many of the inputs to the Estimate Costs process are used here as well: the cost management plan, the scope baseline, the
project schedule, the risk register, and organizational process assets (existing policies on cost control and cost budgeting, for example).
You will also need information about when and for how long resources will be needed, and any agreements regarding the
purchase of services or products for the project.

In estimating the total cost of a project (determining the project's budget), a project manager must perform risk management
activities and include reserves in their estimates. The cost baseline includes contingency reserves; it represents the funds the
project manager has authority to manage and control. The cost budget is the cost baseline plus the management reserves.

STEP 3: Control Cost

Earned Value Management System (EVMS)
• Earned Value (EV): value of work performed expressed in terms of the approved
budget assigned to that work for an activity or WBS component.
• Planned Value (PV): Authorized budget assigned to the work to be accomplished for
an activity or WBS component
• Actual Cost (AC): total cost actually incurred and recorded in accomplishing work
performed for an activity or WBS component.

What do we NEED TO KNOW whether a project is on time and cost?

Schedule Variance: SV = EV – PV
Explains which part of the planned program is actually completed, or how fast we are
progressing on the originally planned:
• SV > 0 has been carried out more work than planned
• SV < 0 has been carried out less work than planned

Cost Variance: CV = EV – AC
• CV > 0 we spent less than performed
• CV < 0 we spent more than performed
Schedule Performance Index: SPI = EV/PV
• SPI > 1 has been carried out more work than planned
• SPI < 1 has been carried out less work than planned

Cost Performance Index: CPI = EV/AC

• power > 1 we spent less than performed
• CPI < 1 we spent more than performed

Others indicators that help us to see HOW is the project on time and cost
• Budget at completion (BAC): Final Planned Budget
• Estimate at Completion (EAC): EAC = BAC / CPI
→ Final Estimated cost working with the current CPI
• Variance at Completion (VAC): VAC = BAC – EAC
• To Complete Performance Index (TCPI): TCPI = (BAC-EV) / (BAC-AC)
→ Performance required from today to complete the planned budget

Control costs
The cost management plan includes your plan for how you will control the costs of the project, which may include items such as
meetings on cost, reports, measurements that will be made, and the frequency with which you will measure. The control part of the
management plan is customized to the needs of the project.

→ A cost baseline is an output of the Determine Budget process. When this process is complete, the cost baseline, including all funding
requirements, is established. As in the other processes we have discussed, the efforts involved in determining the budget may create
the need for updates to project documentation including cost estimates, the risk register, and the project schedule.

→ The costs of activities are included in the project cost estimate, and the contingency reserves (to cover identified risks) are added to
that to come up with the cost baseline. Thereafter the management reserves (to cover unknown, or unidentified, risks) are added to
come up with the cost budget. The management reserves make up the difference between the cost baseline and the cost budget.

Budget
Botton-up model starting from the sngular activities to the final budget
Direct cost is the sum of the cost of the deliverables (which are given by sum of the costs of their work package). We can estimate with
some tools and algorithm the know risk, we can cover that risk with the contingency reserve (around 10%).
Contingency reserve + direct cost = cost baseline Question in the exam
Management reserve is used to cover unknown risk → uncertainties and events we can not predict (around 5%).
We have also indirect cost, cost which allows the company to keep its structure (it is around 15%).
Profit margin is the last voice.

Document presenting budget to the client:

Deliverable 1 → description → we calculate the ratio budget/direct cost in percentage and then we apply that percentage to all the
deliverables/activities (if the direct cost of the package is 50 and the ratio is 90% given the budget 190 and direct cost 100, then the
value of 50 presented to the client becomes 95)
WPI 1 (we apply the same percentage)
WPI 2 (we apply the same percentage)
Deliverable 2
Deliverable 3
Total budget
+ Taxes

Risk Management
Uncertanties can create risks and opportunities.

The risk amangement plan is comprehensive of:

1. Identify risks → risk register (WBS, SWOT, PESTEL)
Risk breakdown structure is the total evaluation of the risks we might have (the risk owner is the person in charge to identify, track
and measure the level of the risk and to mitigate or avoid the risk)
2. Measure the level of risks:
Qualitative analysis → in the y-axis the probability of the risk, while in the x-axis the impact (money, time, etc.) of the risk. The
scale goes from low to medium to high to very high. Positioning the risks we can build a matrix → probability impact matrix
→ Likert is the first person in history investing scales of like and dislike
Quantitative analysis → Montecarlo simulation, Tornado diagram, Decision tree analysis. When we have the exact probability and
the exact impact we can measure the Expected Monetary Value (EMV) = P x I.
We identify the risk with the higher impact and probability and we can and, depending on the experties we:
• Mitigate
• Transfer
→ the contingency reserve is used to mitigate or transfer. We transform the risk in terms of money and we compare it with the 10%
of the contingency reserve. Usually the impact is lower than 10%.
In the region where probability and impact is low we just accept those risks. This acceptance is until the risk unexpectedly
happens and we workaround.
Under the green line there are non-important risks which are workaround (In the exam the answer is workaround in one question).
We have now to evaluate the dependancies between the risks (secondary risks).
Mitigation → addiotional budget and resources

Project Risk Management

What is risk management? Risk management is the process of identifying evaluating, and planning responses to events, both
positive and negative that might occur throughout the course of a project. Through risk management, you increase the probability and
impact of opportunities on the project (positive events), while decreasing the probability and impact of threats to the
project (negative events).

A project manager's work should not focus on dealing with problems; it should focus on preventing them. Performing risk
management helps prevent many problems on projects and helps make other problems less likely or less impactful.

Think about your own projects. How would it feel if you could say, "No problem; we anticipated this, and we have a plan in place that
will resolve it”, whenever a problem occurs? How good would you look to your boss and sponsor? How much time and money would
you save that would have otherwise been spent addressing the problem? How much less stress would you have in your life?

Effective risk management helps to increase the probability and/or impact of positive risks, or opportunities. And when you
eliminate threats and increase opportunities, project schedule and cost estimates can be decreased, reflecting the results of risk
management efforts. These are the benefits of risk management and the reasons risk management is a required part of proper
project management.

The everyday impact of risk management on projects and the project manager is an important concept that you need
understand. Through risk management, the project manager can stay in control of the project, rather than being controlled by it.

All the following are always inputs to the risk management process:
• Historical information
• Lesson learned
• Work breakdown structure

Project status reports can be an input to risk management. However, when completing risk management for the first time, you would not
have project status reports. Therefore, project status reports are not always an input to risk management.
Unceirtainty, threats and opportunities
Uncertainty is a lack of knowledge about an event that reduces confidence in conclusions drawn from the data. The work that
needs to be done, the cost, the time, the quality needs, the communications needs can be uncertain. The investigation of
uncertainties may help identify risks.

An uncertain event is something identified in advance that may or may not happen. If it does happen, it can have positive or
negative impacts on the project. Project managers often just focus on threats (what can go wrong and negatively impact the project).
Do not forget that there can also be positive impacts, called opportunities.

Risk factors
When assessing risk, it's necessary to determine the following:

• Probability → The probability that a risk event will occur (how likely).
• Possible outcomes → The range of possible outcomes (impact or amount at stake).
• Timing → Expected timing for it to occur in the project life cycle (when).
• Frequency → The anticipated frequency of risk events from that source (how often).

Plan Risk Management

The Plan Risk Management process answers the question of how much time should be spent on risk management based on the needs
of the project. This includes:
• The risk appetite of management and
• Other key stakeholders
The project manager, sponsor, team, customer, other stakeholders, and experts may be involved in the Plan Risk Management
process. They define how risk management will be structured and performed for the project.
Risk management efforts should be appropriate not only to the size and complexity of the project but also to the experience and skill
of the project team. Successful risk management cannot be done with just a standardized checklist of risks from past projects.
Although such a checklist can be helpful in creating a plan and identifying risks, the necessary risk management effort needs to be
performed on each project.

Step 1. Identify risks

Project managers should begin looking for risks as soon as a project is first discussed. In fact, an assessment of overall project risk
is included in the project charter. However, the major risk identification effort occurs during planning.

In this process, risks to the project are identified. This effort should involve all stakeholders. Each stakeholder has a different
perspective of the project and can provide thoughts on opportunities and threats.

Risk categories
A standard list of risk categories can help ensure areas of risk are not forgotten on your projects. A risk breakdown structure (RBS)
is an organizational chart that can help you identify and document risk categories.

Risk can be classified or categorized in many ways, including:

• External → Regulatory, environmental, or governmental issues; market shifts; problems with project sites.
• Internal → Changes to schedule or budget; scope changes; inexperienced team members; issues with people, staffing, materials,
and equipment.
• Technical → Changes in technology, technical processes, or interfaces.
• Commercial → Customer stability, terms and conditions within contracts, vendors.
• Unforeseeable → Only a small portion of risks (about 10 percent) are actually unforeseeable.

Risk causes
Research has shown over 300 potential categories of risk, including risks caused by:
• The customer
• Lack of project management effort
• Lack of knowledge of project management by the project manager and stakeholders
• The customer's customers
• Suppliers
• Resistance to change
• Cultural differences

Risk register
The Identify Risks process results in the creation of the risk register and the risk report. The risk register will contain the identified
risks and potential responses.

This is an example of a Risk Register:

Risk register components

• List of risks → Risks should be stated as clearly and specifically as possible using a cause-riskeffect format.
• Risk categories → Risk categories are made up of risk causes that fall into common groups. These groups can include risks such
as technical risks, internal risks, external risks, management risks, organizational risks or environmental risks.
• Potential risk responses → There will be times when a response is identified at the same time as a risk. These potential
responses should be added to the risk register as they are identified and analyzed later as part of risk response planning.
• Potential risk owners → The person in charge of managing a risk until is mitigated or eliminated.
• Root causes of risks → The root causes of risks provide valuable information for use in later efforts to plan risk responses and
reassess risk on the project, and as historical records to be used on future projects.

A risk owner may be involved in developing risk responses for their assigned risk. They are also responsible for monitoring the project for
triggers that indicate the risk is imminent and for managing implementation of the planned risk response.

Step 2. Perform qualitative risk analysis

As you begin this process, you should have a long list of risks documented in the risk register. But it would be too expensive, and it
would take too much time, to plan responses to all these risks. You need to analyze the risks, including their probability and potential
impact on the project, to determine which ones warrant a response. To perform a qualitative analysis, the following must be
determined:
• The probability of eack risk occurring → Using a standard scale: common subjective analysis scales include Low, Medium, High
or 1 to 5.
• The impact → The amount at stake or the positive or negative consequences of each risk occurring, using a standard scale, such
as Low, Medium, High or 1 to 5.
Probability and impact matrix
A probability and impact matrix is a data representation technique that can be used during this process. Because qualitative risk
analysis is based on subjective evaluation, the rating of any one risk can vary depending on the bias of the person doing the rating
and how risk averse they are. Therefore, organizations frequently have a standard rating system to promote a common understanding
of what each risk rating means.

This is an example of a probability and impact matrix:

A key for understanding the ratings on this matrix might be documented as shown in this example of ratings interpretation for probability
and impact matrix:

The project manager is in the Perform Qualitative Risk Analysis process. This process includes risk data quality assessment along with
probability and impact matrix development. It appears the project manager has not yet completed the matrix, which is used to sort risks
based on their probability and impact ratings. Trend analysis, the identification of triggers, and the development of fallback plans will
occur later in risk management.

Perform quantitative risk analysis

This process involves numerically analyzing the probability and impact (the amount at stake or the consequences) of risks that
ranked highest in qualitative risk analysis. Quantitative risk analysis also looks at how risks could affect the objectives of the
project.
The purpose of quantitative risk analysis is to:
• Determine which risk events warrant a response.
• Determine overall project risk (risk exposure).
• Determine the quantified probability of meeting project objectives.
• Determine cost and schedule reserves.
• Create realistic and achievable cost, schedule, or scope targets.

Differences between qualitative and quantitative risk analysis:

• Qualitative risk analysis → Remember that qualitative risk analysis is a subjective evaluation, even though numbers are used for
the rating.
• Quantitative risk analysis → In contrast, quantitative risk analysis is a more objective or numerical evaluation (Monte Carlo
simulation, sensitivity analysis, tornado diagram, decision tree analysis…); the rating of each risk is based on an attempt to
measure the actual probability and amount at stake (impact).

Expected monetayr value calculation: To evaluate a risk, you can look at the probability or the impact, but the expected value is a
better measure to determine an overall ranking of risks. The formula for expected monetary value (EVM) is simply: EVM = Probability
(P) multiplied by Impact (I).

Example:
If a project has a 60 percent chance of a $100,000 profit and a 40 percent chance of a $100,000 loss, what is the expected monetary
value (EMV) for the project?
We need to calculate both positive and negative values and then add them. Expected monetary value= 0.6 X $100,000- 0.4 X $100,000 =
$60,000 -$40,000 = $20,000 profit.

Plan risk responses

This process involves figuring out, "What are we going to do about each top risk?" In risk response planning, you find ways to reduce
or eliminate threats, and you find ways to make opportunities more likely or increase their impact.

The team, guided by the risk owner, may uncover many strategies for dealing with risks. Some of these risk response strategies
involve changing the planned approach to completing the project, such as changes to the WBS, quality management plan, resources,
communications, schedule, or budget.

Other strategies, called contingency plans, involve coming up with a plan to be implemented when and if a risk occurs.

Response strategies

There are response strategies for threats, opportunities and both:

Response strategies for threats

Avoid → Eliminate the threat by eliminating the cause, such as removing the work package or changing the person assigned to do
work. Avoiding the threat might even involve expanding the scope of the project. On an overall project level, if the threat is beyond the
organization's risk threshold, the project manager will need to take action to make the project acceptable. This could include removing
pieces of the project that are too risky in order to avoid cancelling the entire project.

Mitigate → Reduce the probability and/or the impact of an individual or overall project threat, thereby making it a smaller risk and
possibly removing it from the list of top risks on the project. Any reduction will make a difference, but the option with the most
probability and/or impact reduction is often the option selected.

Transfer → Make a party outside of the project responsible for the threat by purchasing insurance, performance bonds, warranties,
or guarantees, or by outsourcing the work. Here is where the strong connection between risk and procurement (contracts) begins.

Response strategies for opportunities

Exploit (the reverse of avoid) → Add work or change to the project to make sure the opportunity occurs. This could be on the individual
project risk level or on the overall project risk level.

Enhance (the reverse of mitigate) → Increase the likelihood (probability) and/or positive impacts of the opportunity occurring. This
could be related to the overall approach to scope and schedule, resources used, and project replanning as well as to individual project
risks.
Share → Allocate ownership or partial ownership of the individual or overall project opportunity to a third party (forming a
partnership, team, or joint venture) that is best able to achieve the opportunity.

Response strategies for threats & opportunities

Escalate → A threat or an opportunity should be escalated if it is outside the scope of the project or beyond the project manager's
authority. Remember that escalated risk needs to be accepted by the program or portfolio manager, at which point, data on the
escalation is documented, and the risk is no longer monitored at the project level.

Accept → Passive acceptance means to do nothing and to essentially say, "If it happens, it happens". This leaves actions to be
determined as needed (workarounds) if the risk occurs. Active acceptance involves creating contingency plans to be implemented if
the risk occurs and allocating time and cost reserves to the project.

EX:
You have identified several risks on your project for which purchasing insurance is a possibility. The insurance company your firm uses
has quoted reasonable rates, and your analysis shows that purchasing insurance makes sense as a contingency plan in these cases.
Your organization has a low threshold for risk but wants to keep costs in line as the profit margin on the product of this project is low. The
strategy of purchasing insurance is best considered an example of risk: Transfernace!
A risk is only escalated if it is outside the scope of the project or beyond the project manager's authority, which is not the case in this
scenario. Acceptance of risk means doing nothing (if it happens, it happens, or contingency plans are created). Avoidance of risk means
we change the way we will execute the project, so the risk is no longer a factor. Transference is passing the risk off to another party. Many
people think of using insurance as a way of decreasing impact. However, purchasing insurance transfers the risk to another party.

Risk Register Updates

The risk register is updated to add the results of risk response planning, including:

Residual risk
These are the risks that remain after risk response planning. After you have avoided, exploited, mitigated, enhanced, transferred,
shared, escalated, and accepted risks, there will still be risks that remain.

Secondary risk
Any new risks created by the implementation of selected risk responses should also be analyzed as part of risk response planning.
Frequently, a response to one risk will create the possibility of new risks that would otherwise not have occurred. For example, if a
portion of the project work is outsourced to a seller because the project team does not have the expertise to complete the work
efficiently, there may be a secondary risk of the seller going out of business. This was not a risk to the project prior to outsourcing. The
discovery of secondary risks may require additional risk response planning.

Contingency plans
Describing the specific actions that will be taken if the opportunity or threat occurs.

Fallback plans
Specific actions that will be taken if the contingency plans are not effective. Think how prepared you will feel if you have plans for
what to do if a risk occurs and what to do if the original plan does not work.

Risk owners
A key concept in risk response planning is that the project manager does not have to do it all, and neither does the team. Each risk
must be assigned to someone who will help lead the development of the risk response and who will be assigned to carry out the risk
response or "own" the risk.
Reserves
Having reserves for time and cost is a required part of project management. You cannot come up with a schedule or budget for the
project without them.

Types of reserves of time and cost

Time and cost each have two types of reserves: contingency reserves and management reserves:

Contingency reserves:
• They account for "known unknowns": These are items you identified in risk management.
• They are calculated and become part of the cost baseline.

Management reserves:
• They account for "unknown unknowns": These are items you did not or could not identify in risk management.
• They are estimated (for example, 5% of the project cost), and then these reserves are added to the cost baseline to get the cost
budget.

Projects can have both kinds of reserves. The project manager has control of the cost baseline and can approve use of the
contingency reserves, but management approval is needed to use management reserves.

→ A risk list, process updates, and sensitivity analysis are not outputs of the Plan Risk Responses process. Residual risks, fallback
plans, and contingency reserves are all outputs of the Plan Risk Responses process.

Implement risk responses

This process is really the heart of risk management, and where the value of proper risk management becomes most apparent.
When the preliminary work has been done well, this process can be handled smoothly, since the previously documented plans allow for
timely and effective responses to risk events.

Situation 1
If the project manager had performed proper risk management, he would have had a plan in place to avoid the risk of a change of
regulation (about data protection) impacting the project.

→ For example: The scheduled hardware/software implementation could have been moved to before or after the forecasted change
of regulation. If the project manager and the risk owners had actively monitored known risk triggers (such as political reports,
including new regulation conditions) and then implemented a risk response plan before the change happens, they could have
successfully avoided the rework and delays, along with the costs, resulting from that risk. Such preparation is critical to
successfully implementing a risk response.

Situation 2
Even though we do our best, sometimes our carefully developed plans don't have the expected result.

→ For example: Let's assume that a risk owner or the project manager in the previous story implemented a risk response plan to
reschedule the implementation, causing the schedule to be extended. Although the plan was executed as intended, the change of
regulation caused more damage than anticipated, and the schedule had to be extended beyond the planned number of days. Such
unforeseen results are managed through change requests to the cost and schedule management plans.

N.B.: First, you need to determine what the risk entails and the impact to the project, then determine what actions you will take
regarding the risk.

EX:
What do you do with noncritical risks?
Document them in a watch list, and revisit them periodically.

What risk management activities are done during the execution of the project?
Watching out for noncritical risks that increase in importance, and looking for new risks; implement contingency plans if triggers
indicate the risk is about to occur or is occurring.
How would risks be addressed in project meetings?
By asking, "What is the status of risks? Are there any new risks? Is there any change to the order of importance?"

Would you choose only one risk response strategy?

It depends. But you select a combination of choices.

Monitor risks
This process is done during control and monitoring to check if:

→ Risk is so important that it must be discussed at all team meetings.

EX:
Identify risks:
• Involve and engage stakeholders in the risk management process.
• Use tools such as root cause analysis, WBS, SWOT analysis to facilitate risk identification.

Perform quality risk analysis

• Subjectively determine the probability and impact of all risks.
• Qualitatively determine which risk events warrant a response.

Perform quantitative risk analysis

• Numerically evaluate the top risks.
• Quantitatively determine which risks warrant a response.

Plan risk responses:

• Create contingency and fallback plans.
• Determine secondary and residual risks.

Implement risk responses:

• Implement contingency and fallback plans.
• Change requests to project management plan, including schedule and cost baseline.

Monitor risks:
• Create workarounds.
• Update to the risk register and other project documents.

Earned Value Management System (EVMS)

According to the schedule baseline we can draft a slope. In the axis we have money (y) and time (x).
The Planned Value (PV) is represented by the baseline of my cost. The cost baseline is in the last point of the slope, the point is called
Budget at Complete (BAC).

The Actual Cost (AC) is the real cost (if the are above the PV and EV we are ahead schedule but over budget). The Earned Value (EV) is
below the PV. The can analyse the situation comparing the actual expense (by AC) and the the actual performance (by EV).

• PV → defined at the beginning of the project and is represented by cost baseline.

• AC → the expenses so far.
• EV → value created so far, it is the value of what we performed.

Performance on time:
• SPI = EV/PV → <1 we are under schedule, while if it is >1 we are above schedule
• SV = EV – PV → if negative it represents a loss (value not generated).

Performance on cost:
• CPI = EV / AC → if > 1 we are under budget (we have expended more than the value created). When we get exactly 1 we are
expended exactly the value created, in we are below one we can still expend a
bit more
• CV = EV – AC
• EAC = BAC / CPI → Estimate at Completion is the forecast of my actual cost
to the end if we do not recover from the bad situation we have found. The
result is the amount we are loosing.
• ETC = EAC – AC → Estimate to completion is the number we need from now to
finish within the budget initially forecasted.
• To Complete the Performance Index: TCPI = (BAC – EV) / (BAC – AC) → if we
get >1, this is a bad news because we are not being effcient.

Kahoot

Project Management Overview

A project can be defined as:

• The transformation of an idea into a reality
• A necessary condition about content and funcionality of a product
• A unique result to perform successfully a service
• Application of tools and techniques to meet the customer expectations

Project Management can be defined as:

• The application of tools and techniques to meet the project requirements
• Discipline to equip and support individuals to adopt a change
• Formulation of goals taken by an organization to improve its results

In the International Project Management Standard there are:

• 10 stakeholders and 5 processes
• 5 deliverables and 10 requirements
• 5 process groups and 10 knowledge areas
• 10 process groups and 5 knowledge areas

Which process groups must be included in every project?

• Planning, executing, and monitoring and controlling
• Initiating, planning, and executing
• Initiating, planning, executing, monitoring and controlling, and closing
• Planning, executing, and closing

In which project management process group is the detailed project budget created?
• Closing
• Executing
• Planning
• Initiating

The project sponsor has just signed the project charter. What is the NEXT thing to do?
• Begin to complete work packages
• Validate scope
• Start to identify stakeholders expectations and project requirements
• Start integrated change control

During which process group does the team measure and analyze the work being done on the project?
• Control & Monitoring
• Closing
• Planning
• Executing

Why is the project being done? On what financials can we justify doing a project?
• Business Case
• Key stakeholders list
• Project Title and Description
• Project Exit Criteria

The overall project management plan includes the baselines for the project:
• Scope, Risk and Quality Baselines
• Stakeholders and Risk Baselines
• Integration Baseline
• Scope, Schedule, Cost Baselines

Working with International Project Management techniques, allows companies to:

• Be more efficient and effective
• Be faster, better, stronger
• All the answers are right :)
• Uuild trust on their stakeholders

Stakeholders

Which one of these statements is related to Strategic Agility Mindset?

• It is important to embrace change
• Product only delivered when meets customer's specification
• All communication should be documented
• The most stakeholders you invite to a meeting the best result you get

Which one of the following statements about agile approach to developing solutions is true?
• They are incremental but not iterative
• They are not iterative and not incremental
• They are iterative and incremental
• They are iterative but not incremental

A project stakeholder is...?

• Anyone who is involved in the project
• Anyone who can influence the project outcomes
• Anyone positively or negatively impacted by the project
• Anyone who can affect/be affected positively or negatively by the project

Stakeholders can be identified in which project management process groups?

• Monitor&controlling and closing
• Initiating and planning
• Planning and monitor&controlling
• Initiating, planning, executing, and monitor&controlling

Information in the stakeholders matrix should be:

• Shared with others at the discretion of the project manager
• Accessible only to the project manager
• Available to all stakeholders and team members
• Available to the project manager and PMO staff
The degree to which a particular stakeholder may be able to positively or negatively affect a project is the:
• Level of interest
• Level of commitment
• Level of power/influence
• Level of engagement
The Kano model is an approach for:
• Product/service development and customer satisfaction
• Prioritazing project stakeholders
• Dealing with the transition or transformation of an organization's goals

In the Kano model, the perceived quality levels by the stakeholders are:
• Must-be, Desired, Attractive and Indifferent
• Impact, Influence and Interest
• Unaware, Resistant, Neutral, Supportive, Leading

Attractive functionalities/features/solutions...
• Have no impact on customers in one way or another.
• Deliver unexpected, novel, or new high-value benefits to the customer.
• Are to find good-looking people everywhere everytime
• Will not necessarily raise satisfaction if they are present.

A key to succeed as project manager is:

• To satisfy the stakeholders' needs and expectations
• How you involve stakeholders on your projects
• How you handle stakeholder relationships
• To be faster, better and stronger

Scope

The Work Breakdown Structure (WBS) is:

• Systematic approach to feature priorization
• Tool to review the key project stakeholders
• Visual, hierarchical deconstruction of the project deliverables
• Tool to define the details of project deliverables

During which part of the project management process is the project scope statement created?
• Monitoring and controlling
• Executing
• Planning
• Initiating

All of the following are parts of the scope baseline EXCEPT the:
• Traceability Matrix
• Project scope statement
• WBS dictionary
• Work breakdown structure

A requirement is:
• The transformation of an idea into a reality
• A necessary condition about content and funcionality of a product/service
• A unique result to perform a product/service as part of a project
• The application of tools and techniques to meet the customer expectations

A deliverable is:
• A necessary condition about content and funcionality of a product/service
• A unique result to perform a product/service as part of a project
• The transformation of an idea into a reality
• The application tools and techniques to meet the customer expectations

The WBS can BEST be thought of as an effective aid for _____communications.

• Customer
• Team
• Sponsor
• Stakeholders

We can find all the details of the project deliverables in:

• Work Breakdown Structure
• kano model
• Traceability Matrix
• WBS Dictionary

Which process group focuses on completing the project deliverables?

• Executing
• Closing
• Planning
• Initiating

To properly manage the development of a project you should ensure that are approved:
• Change management protocol
• Customer expectations and implementation tools.
• Corrective actions, preventive actions and change requests.
• The requirements and the project deliverables.

A traceability matrix allows to:

• Ensure all client requirements are matched to deliverables.
• Define the deliverable code, its responsible and resources.
• Ensure that all available resources are allocated.

Schedule

Technique used to analyse the sequence of activities with least amount of schedule flexibility
• Precedence diagramming
• Flowchart
• Critical path method
• Work breakdown structure

A dependency requiring that design must be completed before manufacturing is an example of:
• External dependency
• Scope dependency
• Discretionary dependency
• Mandatory dependency

The slack of an activity is:

• Determining lag times
• Performing a Monte Carlo analysis
• Determining the waiting time between activities
• Time an activity can be delayed without delaying the project

A project has 3 critical paths. Which BEST describes how this affects the project?
• It makes it easier to manage
• It makes it more expensive
• It requires more people
• It increases the project risk

In CPM, which of the following relationships is rarely used:

• Finish-to-Finish
• Start-to-Finish
• Start-to-Start
• Finish-to-Start

A schedule activity may begin 10 days before the predecessor activity finishes. That is:
• A dependency with lag time
• Precedence Diagram Method
• A dependency with lead time
• Milestone diagram

Which is BEST to do when asked to complete a project 2 days earlier than planned
• Work hard and see what the project status is next month
• Ask your manager
• Tell senior manager that is not possible to finish earlier
• Meet your team to look options for crashing or fast tracking

The Early Start of a deliverable is 12, the Late start is 14. The slack/float is...
• 2 days
• 0 days. It's a critical activity
• (-) 2 days

Cost

The reserve between the cost baseline and the budget can be BEST described as:
• Cost estimate
• Contingency reserve
• Management reserve
• Cost accounting

If EV = 350, AC = 400, and PV = 325, what is the cost variance (CV)?

• 350
• 400
• -75
• -50

A way to compute estimate at completion (EAC) is to take the budget at completion (BAC) and:
• Multiply by CPI
• Divide by CPI
• Multiply by SPI
• Divide by SPI

Estimate at completion (EAC) is a periodic evaluation of:

• The cost of work completed
• The anticipated total cost at project completion
• The value of work performed
• None of above

A schedule performance index (SPI) of 0.76 means:

• You are progressing at 24% of the rate originally planned
• You are progressing at 76% of the rate originally planned
• You are over budget
• You are ahead of schedule

The cost baseline, is an output of which cost management process?

• Estimate Costs
• Estimate Activity Resources
• Control Costs
• Determine Budget

During which PM process group are budget forecasts created?

• Control and monitoring
• Planning
• Initiating
• Executing

The cost contingency reserve should be:

• Hidden to prevent management from disallowing the reserve
• Maintained to cover cost overruns
• Added to direct costs of the project to manage known risks
• Added to each activity to provide a shorter critical path

If CPI=1.3, SPI=0.8, what's the status of the project?

• Under budget and ahead of schedule
• Over budget and ahead of schedule
• Under budget and behind schedule
• Over budget and behind schedule

EV = 100, PV = 110, AC = 100. The schedule performance index is:

• 0.91
• -10
• 1.1
• 1

'Estimate to Completion' ETC can be calculated as:

• None of above
• BAC - EAC
• EV / AC
• EAC - AC

Project budget=10.000. PV=4.000. Project is 30% completed and 20% of budget spent. The AC is:
• 3000
• 3.1415926535897932384626433832795028841971
• 2000
• 2400

You are managing a project with EV=15.000, PV=12.000, AC=11.000. The project is:
• Behind schedule and over its budget
• Ahead of schedule and under its budget
• Behind schedule and under its budget
• Ahead of schedule and over its budget

Risk

What tools would you use to identify risks?

• WBSD, SWOT, PESTLE and RBS
• WBSD, power/interest grid
• SWOT, RBS and Montecarlo simulation
• EVMS and SWOT

Purchasing insurance is BEST considered an example of risk:

• Transfer
• Acceptance
• Mitigation
• Avoidance

Which of the following processes has risk register as the primary output?
• Plan risk management
• Performa qualitative risk analysis
• Control and monitoring risks
• Identify risks

While preparing your risk responses, you identify additional risks. What should you do?
• Nothing to do
• Document the risk items and calculate the EMV
• Add reserves to the project to accommodate the new risks
• Add a 10% contingency to the budget and notify the client

The project document to list down all the risks in a hierarchical fashion is called:
• Risk Management Plan
• Risk Breakdown Structure
• Montecarlo diagram
• List of risks

During which stage of risk planning are risks prioritised based on probability and impact?
• Identify risks
• Perform Quantitative risk analysis
• Plan risks responses
• Perform Qualitative risk analysis

Modelling and simulation techniques to determine overall effects of risks on project goals are done during:
• Perform quantitative risk analysis
• Identify risks
• Plan risk responses
• Perform qualitative risk analysis

Which of these is not a valid response to positive uncertainty events?

• Mitigate
• Share
• Exploit
• Enhance

We measure the impact of uncertainty in a project on:

• Project resources
• Procurement and stakeholders
• Scope, time, cost and quality
• WBS, WBSD and traceability matrix

The tool used to quantify the monetary value of a risk is called:

• WBSD
• EVMS
• RBS
• EMV