What is inclusive leadership? What are the characteristics of inclusive leadership?

Inclusive leadership and the characteristics of inclusive leadership

An inclusive leader uses EACH attributes (Empowerment, Accountability, Courage, and Humility) to both increase awareness of these challenges and to overcome them with appropriate action. The components of EACH support inclusion by valuing people's individuality and finding common ground:

• Empowerment allows people to do things their way.
• Accountability holds people responsible for their own actions.
• Courage helps people put group interests above personal ones.
• Humility fosters connections by encouraging people to learn from one another and demonstrate vulnerability and trust.

Characteristics of inclusive leaderships:

• Leadership is about influencing others to achieve a common goal.
• Often, leadership is not as complicated as we think it is.
• Anyone can lead- whether you have authority over others or not. No matter where you are in your career or whatever your status or position, you can lead.
• Leadership requires simple action that anyone can do-for example, be willing to stand out from the crowd or support a new idea or ask a difficult question when no one else is asking.
• And most notably, "followers" are also leaders. The first follower turns a lone nut into a leader! Followers are leaders in their own right and in fact, inclusive leaders make space for others to lead, by following them.
• Inclusive leadership positively impacts everyone-on matter whether you are a man or a woman, old or young or of a particular race, color or nationality. Anyone can be an inclusive leader and everyone benefits from inclusion.
• Inclusive leaders value the diverse talents and experiences of people they influence or who are their teams.
• Inclusive leaders do not stereotype or alienate people they influence or who are on their teams or make them feel reluctant to share ideas that set them apart, which can lead to group think.
• When inclusive leadership is effective, people feel more included and are more likely to go above and beyond call of duty, snuggest new ideas and ways of getting work done.
• Inclusive leader are aware of their own biases and assumptions, taken action and execute the EACH method: Empower your direct reports and team members, hold them Accountable, be Courageous, and show Humility as a leader.
   

Inclusion values both:

• Uniqueness: Standing out from the crowd (coworkers, colleagues, team members, peers) and being and feeling recognized for what's distinct about you.
• Belongingness: Being and feeling accepted as part of the crowd, regardless of your differences or similarities with others.

 

What is project management? What are main characteristics of a project? What are the steps of project management life cycle?

 

What is project management: When people think about project management, they often have an image of large construction projects, buildings, and machinery worth millions of dollars. These type of projects represent project management at a very high level. But in reality, project management can be used in almost any setting.
 

Everyone, from teachers, students, wedding planners, through to office workers and do it your selfers
can employ the core skills of project management to help their day to day work run more smoothly,
and ensure a greater chance of success. Almost every job requires a level of planning, understanding of what and who is involved, how long it should take, and what it's going to cost.

Carefully managing each of these aspects and understanding what success looks like is exactly what project management is all about. This course has been designed to break the stereotypical boundaries of project management, to walk you through the core project management activities, and give you the tools and confidence needed to manage, lead, and communicate effectively throughout the project life cycle.

Whether you are involved in construction, information technology, corporate, or small business, or simply just running your own home project, a sound knowledge of essential project management skills
will ensure the result is far more successful, and reduce surprises along the way.

 

Project management transcends all industries. Projects can be large or small. They can be fairly simple and straightforward, or quite complex and time consuming.  

 

Characteristics of a project: Generally, there are four main characteristics of a project, regardless of its size and complexity.

1. Start and End Date: The first characteristic is that a project has a definite start and end date. It is a temporary undertaking within a fixed period of time, whether this is one week or six years. A project manager has to complete the project within the specified amount of time.

2. Goal or Outcome: The second key characteristic of a project is that it achieves a goal or an outcome. In other words, something is completed or achieved by the end of the project life cycle. In our examples, we saw that the end points were the wedding, the workplace system, and the tiling of a kitchen.

3. Benefit or Value: The third characteristic to consider is that a project provides benefit or value to the recipient. In other words, what will the recipient gain from the completed project? 

4. Allocation of Resources: Finally, a project requires an allocation of resources that need to be skillfully used. These resources will vary depending on the size and complexity of the project. And all projects will, in one way or another, allocate and use resources to achieve their goals or outcomes.
 

Project Management Life Cycle: Project management follows a distinct linear process or journey, which is known as the project management life cycle. The life cycle has four phases.
 

Initiation: The life cycle begins with initiation, which is the starting point of any project. It is usually the shortest phase but the most important, because it sets up the foundation of the project. It is in this phase that you flesh out the project objectives, success criteria, and high-level plan. Is also in this phase that you identify risks, stakeholders, and your team.

Planning: The second phase of the life cycle is planning. Planning is the primary function of any project manager and requires you to undertake a rigorous process of developing plans to ensure you achieve your project objectives. The area that you will focus on in this phase of the life cycle are scope, scheduling, and costing.

Execution: Phase three is project execution. This phase is about completing specific deliverables that are required to meet the scope and objectives of the project. In this phase, assessing risk and implementing strategies to reduce or mitigate risk is paramount. This phase also focuses on being an effective leader for your team and engaging your stakeholders in the execution of the project.

Closure: The final phase of the project management life cycle is the closure of the project. It is in this phase that the outcomes are achieved and the benefits of the completed project are experienced by the stakeholders. The closure of a project requires you to obtain feedback from your stakeholders and your team.
 

 

Large Scale Scrum (LeSS)

 Large Scale Scrum (LeSS) takes a completely different approach to scale. In fact, the term that LeSS uses is NOT scale, but De-Scaling as the pinnacle of the scaled organization for Scrum and Agile.

Where other frameworks look to align the Agile approach to teams within a Traditional Organization, or show how those people can now "fit" within the organization; the LeSS approach is to say 'no.' No more "pretend Agile" or "Fake De-Scaling" where all the parts of the products that come together are considered independent and managed independently. 

This leads to trap where teams try to act as independent teams within an organization:

• "Independent Teams" need a portfolio manager to ensure alignment of efforts, because otherwise they'll diverge
• Portfolio Management leads to integration and dependencies,
• Dependencies re-introduce the need for the Program Management Office (PMO) to institute rules of coordination
• Rules remove ownership and power from the Scrum teams, and quickly lead to additional complex teams to manage them

To avoid all this, the LeSS system provides two types of scaling of Products to remove other potential roles:

• LeSS - used for up to eight (8) teams of eight
• LeSS Huge - used for up to thousands of teams delivering products together in single increments

This way the organization can avoid unnecessary "dotted lines" that take away power and control from the Scrum Teams which in turn zaps productivity and pride of workmanship.

 

 The LeSS system provides two types of scaling of Products to remove other potential roles:

• LeSS - used for up to eight (8) teams of eight
• LeSS Huge - used for up to thousands of teams delivering products together in single increments

This way the organization can avoid unnecessary "dotted lines" that take away power and control from the Scrum Teams which in turn zaps productivity and pride of workmanship.

According to the philosophy behind LeSS, Scrum works as it is designed for one team. And it shouldn't be changed for one team. No matter the complexity of the product, it should remain that there are three roles:

• Product Owner (PO)
• Scrum Master (SM)
• Development Team Member (DT)

And in the LeSS these roles persist and remain the only roles for up to eight (8) teams. It's important to note that LeSS suggests that teams be aligned to features to maximize their ability to "specialize" on the architecture of a product and work independently.

Beyond eight (8) teams only one additional role is added to support the Product Owner. This role is the Area Product Owner, and they are needed because of the pressure on the Product Owner to manage such a large backlog is too great:

• Area Product Owner (APO) - provides a buffer of work definition and act as intermediaries to help manage an "area" of requirements
• Product Owner (PO) can have up to ten (10) APOs working with them to manage requirements, forming the Product Owner Team
• Can manage up to eight teams
• Cannot override the prioritization of the product backlog items - this still belongs to the PO

At this point there is enough "scaling" that it can handle global operations of product development. Sites can have multiple teams, and areas can include anywhere from five to ten teams. When multiplied this allows a single Product Owner to manage up to a thousand or more team members.

But why create such large structures of Scrum?

The answer is using Large Solutions to De-Scale the organization.  Organizations looking to create smaller, more independent teams to Scrum will drive towards an model that performs "Fake De-Scaling." These ideas are as follows:

• We create "independent" teams with internal and external markets, everyone has customers and are consumers of Agile teams
• For larger products, "independent Teams" need a portfolio manager to ensure alignment of efforts, because otherwise they'll diverge
• Portfolio Management leads to integration and dependencies because there are real-word physical dependencies in products
• Integration and dependencies drive the need for rules so teams can stay independent
• These rules re-introduce the Program Management Office (PMO) to control coordination
• Rules remove ownership and power from the Scrum teams, and quickly lead to additional complex teams to manage them

So what does the organization then look like for the LeSS company?

For those that there will be an enabling leader who is the "Head of Product." This person will provide coordination and support using the Servant Leadership model of management. The responsibilities include managing:

• Site Locations - ensuring the teams are supported with facilities, people, etc.
• "Undone Departments" - those departments that are still functionally aligned or separate from Scrum Teams
• Support Teams - these teams provide a lean service of support to the large teams (such as delivery or DevOps)
• Product Owner Team - led by the PO in charge of the product, this team develops and prioritizes the backlog
• Competence & Coaching - the functions of training and coaching to ensure continuous improvement

Higher levels of management are intended to provide similar types of "servant leadership" support for the organization. The goal being to enable teams to work according to the LeSS principles:

• Large-Scale Scrum is Scrum - LeSS is just dealing with the unavoidable scale of some products, but remains scrum
• Empirical process control - processes should be subordinate to the product and market needs
• Transparency - required to drive fear out and improvement into the workplace
• More with Less - gain better teams, ownership, and reduced waste with less process and control
• Whole-products - focus on the product in delivery, not just the part of the product, so efforts are aligned
• Customer-centric - by focusing on the customer, everyone aligns to the priorities and needs while reducing waste of other distractions
• Systems thinking - understand that the system is the focus, not the local performance of a team, so waste is reduced and flow is optimized
• Lean thinking - continuous improvement and the Go See approach to management drive a respect for workers and continuous improvement
• Queuing theory - understanding that long queues increase cycle time, reduce feedback speed, increase variability, and result in multi-tasking

To learn more about these concepts go to: https://less.works/

Sources:

• De-Scaling Organizations: https://less.works/blog/2015/05/08/less-scaling-descaling-organizations-with-less.html
• How too many rules at work keep you from getting things done: https://www.ted.com/talks/yves_morieux_how_too_many_rules_at_work_keep_you_from_getting_things_done#t-983376
• Requirements Areas: https://less.works/less/less-huge/requirement-areas.html
• Area Product Owner: https://less.works/less/less-huge/area-product-owner.html
• LeSS Organizational Structure: https://less.works/less/less-huge/organizational-structure.html
• More-with-Less: https://less.works/less/principles/more-with-less.html
• LeSS Role of a Manager: https://less.works/less/management/role-of-manager.html
• LeSS Principles Overview: https://less.works/less/principles/overview.html

Additional Great Video Resources:

• Scaling Agile with LeSS Large Scale Scrum: https://www.youtube.com/watch?v=dKEIaJ7qBew
• Introduction to LeSS (Large-Scale Scrum): https://www.youtube.com/watch?v=1BZf_Oa7W94

 

 

Disciplined Agile Delivery (DAD)

Disciplined Agile Delivery attempts to answer that question with the Disciplined Agile Framework.

The ideas in the framework is simple: every team in the organization should be Agile.

This means that teams such as Marketing, Sales and Finance should be Agile. So should the Legal, Human Resources, and IT Governance teams. All Development-Operations (what are called "Support Teams" by many or "Systems Teams" in SAFe) should also be their own agile teams.

This requires that the organization can create products that are consumable by the other parts of the organization. And it means that at all levels the whole organization is learning. However, this also requires that each team be Enterprise Aware a core tenant of the Disciplined Agile framework. In total there are a select number of key Disciplined Agile considerations that expand on Scrum, with an ultimate goal of having Scrum work over time, locations, size of teams, and the variety of teams needed to run whole organizations.

Key questions to consider as you think about Disciplined Agile Delivery, are as follows:

• What would an Enterprise Aware team of teams look like?
• How would you prioritize the work across the organization?
• How could teams manage their dependencies if they act as semi-independent Agile teams?
• How could learning and "flow" of value needed for continuous operations at scale be incorporated?

 

Disciplined Agile Delivery starts from one single premise: being Agile doesn't permit teams to be undisciplined.

Disciplined Agile Delivery (DAD) grew from origins in Extreme Programming (XP), Scrum, and Lean. As it's original forms were being codified it was clear that Agile was being used by many teams to avoid good practices of sustainable development. "We don't do that, we're Agile" was a common phrase that frustrated many in the Enterprise. DAD offers a compromise that many people today find extremely valuable in fitting into the organization.

The key characteristics of Disciplined Agile Delivery are:

• People first
• Learning oriented
• Agile
• Hybrid
• Goal-driven 
• Delivery focused
• Enterprise aware
• Risk and value driven
• Scalable

In order to achieve these goals, the Disciplined Agile Delivery process uses a hybrid framework with stages that align with the Traditional Stage-Gate model, from concept to retirement (disposal). It's focus in generally on very large solutions that are required for organizations or developed within large organizations that roll out a product line. 

The key difference between this model and the typical Scrum Model that starts when a team is initiated with funding is as that DAD uses a startup phase called "Inception." During this phase many important things happen to help scale:

• Modeling of the solution
• Proof of concepts are explored
• Shared architectures across teams are initiated
• High-level release planning and feature roadmaps are established

During this phase the teams often work in functional and cross-functional groups. This startup phase allows for a shared understanding going into the solution development or "Construction Phase."

Disciplined Agile also believes in many more roles than Scrum does:

• Primary Roles:
• Stakeholder - these are the same as in Scrum - anyone who is impacted by the solution being built (owners, support, customers, etc.)
• Team Member - focuses on producing solutions for stakeholders, the Scrum "generalizing specialist"
• Team Lead - servant leader that coaches and helps organize delivery, and often considered an "Agile Project Manager"
• Product Owner - provides the "voice of the customer" as either the representative, actual customer, or business line expert
• Architecture Owner - can be simple as the "senior developer" or an architect; with the goal of reducing technical debt risk at scale
• Secondary Roles:
• Specialist - may be the specialist in a certain technology or tool that's used in the solution
• Domain Expert - provides detailed domain expertise on critical topics for parts or details of complex solutions
• Technical Expert - can be experts in key non-functional areas (user interface, security, databases, etc.) needed for performance
• Independent Tester - can be required for complex solution environments or for regulatory requirements (such as government)
• Integrator - can be a separate role for integration and delivery mechanisms in complex solutions, such as DevOps teams

Disciplined Agile Delivery works by always having the Primary Roles (although sometimes the Architecture Owner and Team Lead are the same person). Then it adds the Secondary roles as needed.

In order to scale across teams, DAD uses the "team of teams" model, building on the "Scrum of Scrums" concept invented by Jeff Sutherland.

• DAD Agile teams meet in Daily Standups
• DAD Team Leads meet separately to coordinate delivery, as the Product Delivery Team
• DAD Architecture Leads meet separately to coordinate architecture and remove dependencies, as the Architecture Team
• DAD Product Owners meet separately to coordinate planning, as the Product Management Team

These teams of teams models are then coordinated, as needed, by an overall Program Manager role. 

From this basic scaling model, Disciplined Agile then extends these concepts to the organizational level. How can we mature the organization into a "Learning" organization. In fact, the ideas are that the Agile model is a startup model for Disciplined Agile that can be used to eventually create a lean-agile organization that continuously performs the "stages" of development as needed.

Concepts that are built in are the idea of scaling the "Supporting Cast." Those in the secondary role can become their own Agile teams that produce products used by the Disciplined Agile teams to delivery new product. Support teams include everything that could be considered "Development-Operations" or DevOps:

• IT Operations
• Customer Support
• Security
• Data Management
• Release Management

These teams are then further scaled up into the total Product Management realm, deemed the "Disciplined IT" realm including Governance and Reuse of products (COTS, GOTS, FOSS), as well as Enterprise Architecture, People Managemenet, and Portfolio Management.

Then Disciplined Agile goes one step higher, suggesting that the entire Enterprise can behave in an Agile manner. Every part of the organization can be its own Agile team or team of teams. This applies to Sales, Marketing, Legal, and Finance, as well as other organizational areas.

To keep the entire organization aware of its own structure, there is a need for "Organizational Assets" and the "Knowledge Base." This means that the Organization becomes its own market for consuming products both internally and externally. By managing a central portal to access the key information and tools needed to run the organization, each team can run without being directive to the others.

This is the actualization of the ideas of a adaptive learning organization. The stages of which are below (shorted from longer forms you can find at http://www.disciplinedagiledelivery.com/dae/):

• Tribal - impulsive, and driven by urgency; management "preys" on its employees
• Traditional - Authoritarian, driven by protocols and formal roles and hierachies
• Scientific - Profit or growth-oriented, driven by innovation and meritocracies of ideas
• Post-Modern - Consensus driven, with values-based decision making
• Living - Cellular models of management with an evolutionary purpose

Do these ideas make sense to you? What kind of organization do you work in?  You can learn more about the concepts and ideas of Disciplined Agile Delivery here: http://www.disciplinedagiledelivery.com

Other Sources of key pages cited here:

• Introduction to Disciplined Agile: http://www.disciplinedagiledelivery.com/introduction-to-dad/
• Disciplined Agile Lifecycle: http://www.disciplinedagiledelivery.com/lifecycle/agile-lifecycle/
• Disciplined Agile Enterprise: http://www.disciplinedagiledelivery.com/dae/
• Disciplined Agile Teams: http://www.disciplinedagiledelivery.com/roles-on-dad-teams/
• Disciplined Agile Teams at Scale: http://www.disciplinedagiledelivery.com/agility-at-scale/large-agile-teams/

 

 

Scaled Agile Framework (SAFe)

SAFe offers a means of scaling Agile very quickly within an organization that is currently highly Traditional in nature, and large in scale. The key principles being a blend of Lean and Agile thinking. 

SAFe looks to blending the ideas behind Lean and Agile to provide answers to the questions:

• How does management give up control, when it's still responsible?
• How do we develop products for hundreds or thousands of customers?
• How do we coordinate work across teams when the work requires dependencies?
• How do we fund, architect, and implement large hardware and software systems with enormous dependencies over years?

In fact, SAFe has three four levels of implementation to help answer these ideas:

• Essential SAFe - basic SAFe with only Business Owners managing as executives often on a single Agile release train (ART)
• Portfolio SAFe - includes a portfolio management function to align funding across teams or trains
• Large-Solution SAFe - Introduces the concepts of having Suppliers that integrate delivery along with multiple ARTs on a Solution Train
• Full SAFe - Includes a Portfolio Management function above the Large-Solution when managing across Solution Trains and other ARTs

 

SAFe introduces many new roles to the Agile framework beyond the Scrum's three main roles of Product Owner, Scrum Master, and Development Team member. These roles considered essential to manage the integration and flow of products across many Agile teams running concurrently. 

• System Teams - those that manage delivery and integration of products produced by individual Scrum teams
• Architecture Teams - manages and promotes the shared architecture framework across teams
• Product Manager - leads the Product Owners as the primary person in charge of targeting features and EPICs
• Release Train Engineer - leads the Scrum Masters on each of the Scrum teams, and conducts the large team or team ceremonies

By adding these essential teams, and others when needed, many teams can work together. These teams help make up what is termed the "Agile Release Train" or ART.

ARTs are how many agile teams work together on a single product or part of the business. For instance if there is a Financial company that wants to develop a new mobile banking application for loans, then all Agile teams working on that application might be on the same Agile Release Train. There then might be a separate Agile Release Train or "ART" for developing internal accounting software.

SAFe aligns ARTs to the business Value Stream. By modeling the business as a Lean process (remember Week 2), the organization can then continuous improve how it delivers value to customers using the Plan-Do-Check-Act (PDCA) cycle.  ARTs are the teams that build and deploy changes to each step in the business value stream. 

• Agile Release Trains (ARTs) align to one or more similar parts of the Business Value Stream
• ARTs are limited to up to 120 people, keeping on the lowside of Dunbar's number
• ARTs work together through the Sprint process, with shared ceremonies at the Release boundaries

This introduces the need to coordinate very large groups through the typical Sprint processes of Planning, Development, Review and Retrospectives. One of the most prominent aspects of SAFe is what's called the "Big Room Training" and "Big Room Planning" during Release Planning. Each Release is called a "Program Increment" and usually takes four to six sprints.

Program Increments (PI) Planning:

• All Agile Teams get in a room (can be up to 200 people, when accounting for stakeholders and Systems Teams)
• The Release Train Engineer organizes and coordinates the Planning Day
• The Product Manager provides a shared vision, set of features, and priority for the next Release
• Product Owners and Scrum Masters each play their role to execute Planning
• Points are considered absolute (at least at first) to compare across teams with one point equal to one person for one day
• Teams commit to complete PI Objectives, instead of stories (which belong to the team)
• PI Objectives are given business value points by Business Owners
• Teams identify their dependencies across each other during this planning
• The Program Board captures all work and dependencies across teams
• The Teams "ROAM" risks: Resolve, Owned, Accepted, or Mitigated
• Everyone gives a "vote of confidence" on whether they can meet the objectives, and keeps going until the whole team puts up "5 out of 5."

Program Increment Inspect and Adapt (IA):

• System demo is performed across all teams
• Often includes the Project Sponsors (Business Owners)
• Humanizes management
• Business Owners give feedback on achievement of business value points
• Retrospectives are run briefly to identify the most important problem to solve
• Problems are then addressed using workshops that include Business Owners, with clear outcomes and support by leadership

A couple of the principles that make SAFe work are:

• Take an economic view - Instead of just responding to customer wishes, work is evaluated in terms of cost of delay (CoD).
• Plan on cadence, release on demand - All teams must plan together, but they can release whenever work is ready.
• Base milestones on objective evaluation of working systems - The work is only considered done when it is fully demoed at the system level
• Visualize and limit WIP, reduce batch sizes, and manage queue lengths - leverage the Lean principles of limiting WIP and managing queues with small batches helps prevent turning independent teams back into departmental-like groups

Another issue that SAFe addresses at scale is the need to continuously explore, develop, and deploy new solutions. This is embodied in their ideals of "Continuous Everything;" which promotes the movement of potential work, work-in-progress, and done work through Value streams.

SAFe has three four levels of implementation to help answer these ideas:

• Essential SAFe - basic SAFe with only Business Owners managing as executives often on a single Agile release train (ART)
• Portfolio SAFe - includes a portfolio management function to align funding across teams or trains
• Large-Solution SAFe - Introduces the concepts of having Suppliers that integrate delivery along with multiple ARTs on a Solution Train
• Full SAFe - Includes a Portfolio Management function above the Large-Solution when managing across Solution Trains and other ARTs

 

To learn a little more about SAFe, check out these great videos as well that can help guide you through the 

• Explanation of SAFe in 5 minutes: https://www.youtube.com/watch?v=tmJ_mJw8xec
• SAFe Version 4.5: https://www.youtube.com/watch?time_continue=1&v=qTG4I6jUbj4
• Scaled Agile Framework Online: https://www.scaledagileframework.com

 

 

What type of Scrum will you use in your workplace?

We're going to present all the basis you need for deciding the best framework for you and your organization now, by giving the the context and insight you need into all the major frameworks, including:

• Scrum in the World of Agile
• Hybrid Agile Framework (aka "Iterative Waterfall")
• Scaled Agile Framework (SAFe)
• Disciplined Agile Delivery (DAD)
• Large-Scale Scrum (LeSS)

Watch out for the shameless plugs we've purposefully put in this course to asking you to verify for Applied Scrum. We've done it because you really should verify! Not only do you get a certificate from UMD proving your excellence, you'll also get access to lots of free content and tools to start applying these lessons right away.

The last lesson, Pitfalls and Benefits of Agile, is especially focused on helping you consider the best way to continue and not get stuck while starting to apply Agile on your team.  More of these ideas are discussed in greater detail in the verified content (yes that's another plug, but it's true!).

We hope you continue to stay engaged, have fun, and be curious as you explore the world of Applied Scrum at it's most applied: the Agile Frameworks. Time to actuate and pick what kind of Scrum you'll use.

It is official across multiple surveys: roughly half of all projects are now, at least in part, Agile in nature.

And, of those types of projects almost ALL the projects in the organization use Scrum or some hybrid of Scrum at its base. The reason being that Scrum is so effective with small teams that it forms the team-level model for nearly every Agile framework. The four largest "Agile Scaling" frameworks all use the Scrum model as their basis:

• Scaled Agile Framework (SAFe)
• Scrum of Scrums
• Disciplined Agile Delivery (DAD)
• Large Scale Scrum (LeSS)

Both the Project Management Institute (PMI), which has been very Traditional in nature ("Predictive" as they call it); and the Verizon One "State of Agile" report across industries that over 50% of organizations are using Agile.

Note these surveys are very representative across industries of all sizes. In fact, over half the respondents to the PMI survey had organizations worth over $500M in total annual revenue.

According to PMI's Pulse of the Profession:

• 23% of projects use Hybrid (Agile and Predictive/Traditional) methods
• 23% of projects used Agile
• 7% used "other" approaches
• Only 47% were Predictive / Traditional projects
• 71% of organizations report "Agility" as being essential to staying competitive

According to Verizon One, who also surveyed a similar distribution of companies (although skewed towards technology and finance):

• 56% of all projects used Scrum
• 75% used either Scrum, Scumban, Scrum/XP, or Kanban

Therefore, the World of Agile has arrived. Now it's time to figure out which framework fits you best!

 

Scrum in the World of Agile Summary Points

The World of Agile is HERE!

According to PMI's Pulse of the Profession:

• Only 47% of projects use Predictive / Traditional approaches
• Almost 1/2 of all projects are now Agile in nature
• Half are "pure Agile" and usually Scrum
• Half are hybrid Agile
• Most organizations see Agility as essential to staying competitive (71%)

This means that you've made a great investment learning Scrum, because no matter what you're likely going to need these skills in one out of two projects you conduct professionally. In fact, if we look at the primary reasons why projects fail we see the likelihood that Agile will continue to grow.

Here are the top reasons why projects fail according to PMI's Pulse of the Profession:

• Change in the organization's priorities - 39%
• Change in project objectives - 37%
• Inaccurate requirements gathering - 35%

And these were all tied for fourth at 29%

• Inadequate vision or goal
• Inadequate, poor communication
• Opportunities and risks were not defined

When you review these aspects, who do they align to the Agile Manifesto? How do they align to the benefits we've discussed in Week 3 on how Scrum works? 

The reality is that Agile addresses the primary challenges facing projects today directly: objectives, requirements, and communication.

Understanding that Agile continues to grow, we also see in Verizon One's State of Agile report that most projects use Scrum:

• 56% use "pure" Scrum
• 75% use Scrum, Scrumban, Scum/XP, or Kanban methods

This is because Scrum is simple, works, and is great for small teams. But as we've reviewed, there's no greater "organization" in the Scrum model. So what about Scale? How do these organizations that use Scrum scale their Agile approaches?

There are four major types of scaling methods used today, according to Verizon One's survey:

• Scaled Agile Framework (SAFe) - 29%
• Scrum of Scrums - 19%
• (Internally Created Methods) - 10%
• Disciplined Agile Delivery (DAD) - 5%
• Large Scale Scrum (LeSS) - 5%

This accounts for the major majority of methods used. Often we see that internally created methods tend to look like Hybrid methods. In the next sections we'll explore SAFe, DAD, and LeSS. Each has the following items in common:

• All use Scrum as the base model for managing teams
• All have Product Owners, Scrum Masters, and Development Teams
• All differ on how to mange "Support Teams" and how to make an organization Agile.

The simplest means of understanding Agile at Scale is to look at the two methods originally used to Scale Agile:

• Scrum of Scrums - teams coordinate work through sending representatives to have Daily Stand Ups across teams.
• Hybrid Methodology - teams are coordinated by using Predictive or Traditional controls, such as stage gates, to manage delivery

Scrum of Scrums:

• Scrum of Scrums Stand Ups: Teams send a representative, although usually this is a Product Owner or Scrum Master
• Can take literally just a long as a standard Daily Stand Up
• Focuses on reporting out completions and blockers
• Opportunity to identify need for coordination among team memebrs
• Scrum of Scrums have a Scrum Master
• Usually a senior person in the organization
• Responsible for facilitating the coordination of work
• Responsible for overall productivity of the Scrum of Scrum Teams
• Scrum of Scrums applies when two teams have potential dependencies
• Share resources (people, services, etc.)
• Shared product in development
• Shared goal or vision
• Originally this was proposed by Jeff Sutherland, one of the founders as Scrum and signatories of the Agile Manifesto in 2001
• "Agile Can Scale: Inventing and reinventing SCRUM in Five Companies" - Jeff Sutherland, Cutter IT Journal, 2001
• Provides story of using Scrum of Scrums at IDX, where weekly product line Scrums and Monthly Management Scrums occurred.
• Some teams became "hyper-productive," a state of Scrum teams that Jeff Sutherland talks of being 4 to 5 times more productive

Scrum of Scrums offers a very simple, and yet elegant means of scaling Scrum. In fact, the practice has been used by many very large scale organizations to achieve organizational agility. 

In the HBR Article, Agile at Scale (2018), there are examples of Scrum of Scrums spanning hundreds of people in less than one hour:

• Saab's aeronautics business has over 100 agiel teams for its Gripen fighter jet ($43M project)
• Daily Stand Ups occur from 7:30 AM to 8:45 AM
• By the end of the the Stand Ups using Scrum of Scrum approaches, the executive team knows the critical issues it needs to address
• That's over 500 people fully reporting using word-of-mouth in less than 90 minutes

This model is having a resurgence now among many Agile practitioners. Especially as many organizations are expanding their understanding of Agile and using Hybrid means or SAFe to transition into becoming an Agile organization.

The Hybrid model that is most commonly used by organizations is rather simple:

• Traditional means are used to control major decision points
• Stage Gates are leveraged especially for Requirements, Design, and Operations (Deployment)
• This offers a chance for the Traditional / Predictive leadership to approve the next "Stage" of the project
• Agile (Scrum) methods are used to rapidly and iteratively develop products in each stage
• Whole teams are used to develop Requirements, Designs, Development, and Verificatoin
• Whole teams are able to prototype and create reusable document
• Requirements are managed as User Stories
• Stories are generated in Requirements, refined in Design, Implemented and closed in Development
• Development is often still iterative and incremental for speed and learning
• Development may have multiple releases to a "staging" or "pilot" environment
• Verification is run for system-level requirements against use cases

This effectively looks like iterations between stage-gates; and is often more successful in organizations that resist Agile. Since organizational resistance to Agile and misunderstanding of Agile are the primary reasons for Agile failing (according to Verizon One), this makes sense for many new entrants learning Agile for the first time.

When looking at the major reasons that Agile fails, we see the following:

• Organizational culture at odds with agile values - 53%
• General organizational resistance to change - 46%
• Inadequate management support - 42%
• Lack of skills/experience with agile methods - 41%

These statistics show why the Hybrid model is so popular among about half the practitioners of Agile in more traditional organizations. For this reasons "Internal Agile" is a great means of proving the effectiveness of the method when there's no upper management support. However, the only means of truly achieving agility is to have leadership support and good Agile training.

So how do we convince the leaders who are disbelievers in Agile? Show them the data:

• Reasons for Adopting Agile
• Accelerate Software Delivery - 75%
• Manage changing priorities - 64%
• Increase productivity - 55%
• Better alignment of business and IT - 49%
• Increased software quality - 46%
• Benefits of adopting Agile (percentages show counts, not impact)
• Better management of priorities - 71%
• Project visibility - 66%
• Alignment of business and IT - 65%
• Delivery speed / time to market - 62%
• Team productivity - 61%

And in terms of impact, the benefits can be four to five times the productivity and value output; as seen in the Ambysoft survey in 2013.

Now that you understand the Scrum in the World of Agile, and you know that world is here (!):

1. What framework will you choose?
2. How will you achieve the benefits (speed and innovation)?
3. How will you manage the change (leadership and control)?

The other lessons in this week will try to help you answer the first question. To answer questions 2 and 3, we highly recommend you sign up for the remaining courses in the Agile Project Management Certificate. Just like in this course, if you Verify you'll get tools, additional resources, and insights that go beyond these lectures and notes to enable the change in your projects.

Now, go be Agile and win!

 

PMP Certification Exam Questions and Answers - Project Resouces Management

1. Data analysis during the Control Resources process can include _____ analysis, cost-benefit analysis, performance reviews, and _____ analysis.

A. alternatives; trend
B. funnel; alternatives
C. decisions; contingencies
D. trend; allocation

Ans: A
Data analysis during the Control Resources process can include alternatives analysis, cost-benefit analysis, performance reviews, and trend analysis.

2. Agreements are one of the inputs of the Control Resources process. What term is synonymous with agreements?

A. Affirmations
B. Decisions
C. Contracts
D. Collaborations

Ans: C


3. The Control Resources process falls under which process group?

A. Schedule and Budget
B. Acquire and Develop
C. Plan and Communicate
D. Monitoring and Controlling
Ans: D


4. While managing a team, what is the purpose of a team charter?

A. Describes how the team will handle meetings, allocate rewards, and manage schedules
B. Describes how the team will make decisions, handle meetings, and deal with conflict
C. Describes how the team will deal with conflict and what tasks each member is responsible for
D. Describes the offsite events the team will use to build collaboration 
Ans: B
Describes how the team will make decisions, handle meetings, and deal with conflict

5. While managing a team, if the team is already performing well, what can the manager still provide?

A. Intervention and support
B. Mentoring and rewards
C. Rewards and recognition
D. Critical and constructive feedback
 Ans:C

6. Phil is trying to resolve a dispute between two divisions of the software development teams. This is a part of which process?

A. Manage Stakeholder Engagement
B. Manage Team
C. Develop Team
D. Acquire Resources
 Ans: B


7. Forms of training for your team can include online training, _____, classroom training, and on-the-job training.

A. competitive immersion
B. virtual training
C. mentoring
D. graduate school training
 Ans: C
Forms of training for your team can include online training, mentoring , classroom training, and on-the-job training.


8. Two of the motivational theories you should be aware of for the PMP exam are Maslow's Hierarchy of Needs and _____.

A. Fiedler's Contingency Theory
B. Herzberg's Uncertainty Theory
C. McGregor's Theory of Force
Kramer's Double-Dip Theory
 Ans: A

Introduction to Project Management: Definition of Project, Characteristics of Project

What is a Project? What are the characteristics of Project?

According to the Project Management Institute:
 "A project is a temporary endeavor undertaken to create a unique product, service, or result." 

Let's break down this definition into its components to understand further what a project is (and what it is not) and try to understand project characteristics:

⇛ It is a temporary endeavor:- what does that mean? It means that it isn't endless; it has a start date and an end date. Projects do not go on indefinitely. Activities that go on indefinitely are typically known as processes or operations. So how do we understand when a project ends?

The project reaches to end when one or more of the following condition(s) met:

• The project’s objectives have been achieved;
• The objectives will not or cannot be met;
• Funding is exhausted or no longer available for allocation to the project;
• The need for the project no longer exists (e.g., the customer no longer wants the project completed, a change in strategy or priority ends the project, the organizational management provides direction to end the project);
• The human or physical resources are no longer available; or
• The project is terminated for legal cause or convenience.

⇛ It creates a unique product, service, or result:- which we call a deliverable. Unique means that it is unlike any other project. It may be similar to other projects but it is never identical to one. This is what distinguishes a project from a process. A project is unique; a process is repeatable and strives for consistency, standardization, and no deviation from a standard. Deliverable means that it has a tangible or intangible outcome: i.e. a new software product, a new drug, a new building, a merger of two companies, improved customer service, etc. The outcome may be a product, goods, or a service.

Fulfillment of project objectives may produce one or more of the following deliverables:

• A unique product that can be either a component of another item, an enhancement or correction to an item, or a new end item in itself (e.g., the correction of a defect in an end item);
• A unique service or a capability to perform a service (e.g., a business function that supports production or distribution);
• A unique result, such as an outcome or document (e.g., a research project that develops knowledge that can be used to determine whether a trend exists or a new process will benefit society); and
• A unique combination of one or more products, services, or results (e.g., a software application, its associated documentation, and help desk services).

 ⇛ It drive change in the Organization:- From a business perspective, a project is aimed
at moving an organization from one state to another state in order to achieve a specific objective. The term Current State, Future State, and Transition State are used to describe change in organization.  

• Current state: is the state of organization before the project begins.  
• Future state: is the desired or resulted state where the organization will be driven by the project. 
• Transition state: For large projects, if there are milestone deliverables, transition state refer to the state where organization reaches after each milestone is delivered.

⇛ It enables business value creation:- business value is the net quantifiable tangible, intangible, or both benefit to the stakeholders derived from a business endeavor. It is considered the return, in the form of elements such as time, money, goods, or intangibles in return for something exchanged.

Examples of tangible elements:

• Monetary assets,
• Stockholder equity,
• Utility,
• Fixtures,
• Tools, and
• Market share.

Examples of intangible elements:

• Goodwill,
• Brand recognition,
• Public benefit,
• Trademarks,
• Strategic alignment, and
• Reputation.

⇛ It initiated in some context:- projects are created in context of organizational factors by organizational leaders. Four fundamental categories of factors are there, which illustrates the context of initiating a project:

• Meet regulatory, legal, or social requirements;
• Satisfy stakeholder requests or needs;
• Implement or change business or technological strategies; and
• Create, improve, or fix products, processes, or services.

⇛ It has defined objectives:- The goals expected to be achieved. There can be technical goals (develop new technology), legal or political goals (to meet governmental regulations), and/or business goals (beating or eliminating competition). These objectives should be measurable.

⇛ It has scope:- All the work required to deliver the product or result and satisfy the objectives for which a project was undertaken at a level of quality expected by the customer. The scope includes all the deliverables required to meet the project objectives.

⇛ It has cot:- The planned cost of conducting the project; it includes human and physical resources.

⇛ It has Time/Schedule:- The planned time to complete the project, as well as the Milestones along the way. 

EXAMPLES OF PROJECTS:

• Building a house
• Developing a new pharmaceutical compound for market
• Building a mobile application
• Expanding a tour guide service
• Developing a new product
• Merging two organizations
• Improving a business process within an organization
• Improvement of a service (i.e. customer service, Six Sigma initiative)
• Modifying a computer software program used in an organization
• Conducting research to develop a new manufacturing process

EXAMPLES OF PROJECT OUTCOMES:

• Pyramids of Giza,
• Olympic games,
• Great Wall of China,
• Taj Mahal,
• Publication of a children’s book,
• Panama Canal,
• Development of commercial jet airplanes,
  Polio vaccine,
• Human beings landing on the moon,
• Commercial software applications,
• Portable devices to use the global positioning system (GPS), and
• Placement of the International Space Station into Earth’s orbit.

Further reading on PMP:

1. Project Management Life Cycle
2. Project Management Certifications Questions with explanation.
3. Free PMP Certification Questions

Free Project Management Professional (PMP) Certification Exam Questions Part 2

This question set is continuation of Free Project Management Professional (PMP) Certification Exam Questions


40. Defining the project and product requirements includes: (select all that apply) 

A. Documenting the requirements
B. Documenting requirement priorities
C. Input from only the most important Stakeholders
D. Only identifying the requirements for the end product/result/service
E. Traceability to the project objectives
F. Traceability to project deliverables

Ans: A, B, E, F

41. Identifying requirements is important because: (select all that apply) 

A. They are the basis from which the work is defined to deliver the project
B. We need to understand the most critical requirements
C. We need to be able to deliver all requirements that the Stakeholders want
D. We need to understand what to put in the Project Charter

Ans: A, B


42. The Project Scope Statement is an important project planning document because the Scope Statement: (select all that apply) 

A. Provides what will be delivered on the project
B. Provides what won't be delivered on the project
C. Provides the details of the financial scope of the project
D. Is more detailed than the Project Charter
E. Is only used by the project manager to understand what has to be delivered
F. Should never be changed once it is written
G. Aids in the control of the project scope during Execution

Ans: A,B,D, G


43. The project deliverables section of the Project Scope Statement includes: (select all that apply)

A. The final deliverables for the project correct
B. The deliverables needed to manage the project correct
C. The deliverables created during project planning correct
D. The deliverables created during project execution correct
E. The deliverables that will not be included in the project
F. The requirements for the project

Ans: A,B,C,D

44. Activity duration estimates are: (select all that apply)

A. Used to determine the project budget
B. Used to determine the project schedule correct
C. Related to the resources available for the project correct
D. The hours required to complete an activity

 Ans: B,C

45. Your team has estimated an activity to take 24 effort hours and 3 days in duration. You have one resource working on the activity. During the planning of the project, your Project Sponsor informs you that the resource you were expecting to use won't be available to you full time on the project. They will only be available for half of their time. 

What should you do with your estimate for the activity this resource is assigned to?

A. You don’t need to do anything because the activity can still be finished in 3 days.
B. You don’t need to do anything because the activity can still be finished in 24 effort hours.
C. You need to adjust the activity effort to 12 hours because the resource is only available for half of their time.
D. You need to adjust the activity duration to 6 days because the resource is only available for half of their time.
Ans: D








For training you can choose:

• Become an Expert in AI and Deep Learning with TensorFlow.View upcoming batches!
• Become an Expert in Blockchain.View upcoming batches!
• PMP Live Online Training by Edureka
• Top online course certified by Project Management Institute (PMI) Get in-depth knowledge and understanding in various Agile Tool & Techniques.
• Data Science Training by Edureka Drive Business Insights from Massive Data Sets Utilizing the Power of R Programming, Hadoop, and Machine Learning.
• Big Data and Hadoop - Training by Edureka Become a Hadoop Expert by mastering MapReduce, Yarn, Pig, Hive, HBase, Oozie, Flume and Sqoop while working on industry based Use-cases and Projects. Know More!
• Hadoop Administration - Training by Edureka Become Hadoop Administrator by Planning, Deployment, Management, Monitoring & Tuning in Hadoop Cluster. Know More!

PMP Certification Exam questions with Answers & Explanation

Project Management Foundations

1. Your organization runs numerous projects and wants to choose the most appropriate resources for each project team. Which of the following is the best tool for identifying project resources?

A. scheduling software
B. a spreadsheet program
C. enterprise project management software
D. a collaboration tool
Ans: C
Enterprise project management software offers tools to find resources with the right skills and availability.



2. A project that you manage is behind schedule. You have identified an approach that would get the project back on track, but it would require you to break one of your organization's policies. What is the best course of action?

A. Determine if the rule is one that can be broken and come up with a plan of action if your approach doesn't work.
B. Inform the management team that there is no way to shorten the schedule given your constraints.
C. Move forward with your plan because you can ask for forgiveness later.
D. Ask the management team for permission to break the rule.
Ans: A
Some rules can't be broken without severe consequences. If you determine that the rule can be broken, you can deliver earlier with minor consequences. You must have a plan for what you will do if you break the rule and don't deliver earlier.


3. During the ---------- project management process group, you, as project manager, orient your team members to the project and the parts they play in it.

A. monitoring and controlling
B. initiating
C. planning
D. executing

Ans: D
At the beginning of the executing process group, you kick off the project, get resources on board, and explain the rules for the project.


4. Which of the following skills is not crucial for a project manager to possess?

A. accounting
B. business expertise
C. leadership
D. interpersonal skills

Ans: A
Project managers do need to understand aspects of finance, but accounting skills can be provided by others.


5. What are the components that differentiate a project from operational work?

A. a unique goal, temporary endeavor, and a budget
B .a unique goal, temporary endeavor, dedicated resources
C. a unique goal, deadline, specific objectives
D. specific requirements, set start and finish dates, budget
Ans: A
The definition of a project is "a temporary endeavor that has a unique goal and usually a budget."


6. Why is it important to document the project scope?

A. because it's a standard project management deliverable
B. to have a paper trail of the project boundaries
C. to remind stakeholders what they agreed to and to prevent scope creep
D. because it's needed for project contracts

Ans: C
With the project scope in writing, you will be able to identify whether requests are within scope or need to be handled by change management.


7. Why do you identify risks when you initially define a project?
A. so you have an idea of the accuracy with which you can estimate work, cost, and schedule
B. so management can determine the amount of contingency funds to set aside
C. so management can decide whether the risks are serious enough to warrant skipping the project
D. so you can prepare a risk management plan before getting approval to begin planning
Ans: C
If the project has numerous, serious risks, management might decide to choose a different project that offers benefits without so much uncertainty.


8. In a project you manage, it is taking much longer than expected for the customer to approve project deliverables. What is the most likely reason for these delays?

A. The success criteria aren't clear and quantifiable.
B. The deliverables are truly not acceptable.
C. Your testing process is flawed.
D. The customer isn't sure what they want.
Ans: A
Success criteria that are unclear or not quantifiable can make it difficult to determine whether deliverables are acceptable.


9. Project objectives help you flesh out a project by _____ and _____.

A. defining project scope; identifying the best approach to use to achieve the goal and objectives
B. breaking the goal down into its components; identifying the work that needs to be done to deliver those components
C. describing the challenges the organization faces; identifying what must be done to address those challenges
D. defining the project deliverables; identifying the work needed to complete deliverables

Ans: A
Project objectives help identify the items you include in scope. They help identify the approach that best satisfies the objectives.


10. Several stakeholders for a project disagree on the priorities of several project objectives. You ask the _____ to help you resolve this issue.

A. a functional manager
B. project customer
C. the most outspoken stakeholder in the disagreement
D. project sponsor

Ans: D
The project sponsor wants the project to succeed and has enough authority to help you resolve issues, particularly with other stakeholders.


11. Why is it important to define a project?
A. so the project team knows what work to do
B. so the customer can decide which project manager to assign to the project
C. so the customer or sponsor can decide whether to approve the project
D. so the customer can create the project charter

Ans: C
By defining the project, the customer can make an informed decision whether the project makes sense for the organization.


12. Why is a face-to-face meeting the best approach for obtaining approval to proceed?

A. It's easier to get everyone's signature.
B. You can observe people's facial expressions and body language.
C. You can ensure that stakeholders understand the project plan before they formally commit to it.
D. Stakeholders can review the plan before signing.
Ans: C
Obtaining approval is about buy-in. The approval meeting gives you a chance to present the plan, answer stakeholder questions, and resolve any final issues.

13. The IT department says that there are several products on the market that do what the project needs. What is the most important thing you need to ensure that you select the product that best meets the project requirements?

A. descriptions of your procurement processes
B. clear and prioritized requirements
C. a clearly defined make-or-buy decision process
D. information from potential vendors describing their products' capabilities
Ans: B
Clear and prioritized requirements make it easier to choose the product that meets the requirements and doesn't provide more than is needed.

14. The change review board can't get through all the change requests that are submitted. They want to focus on requests with significant impact. What is the easiest way to allow the review board to focus on significant changes?

A. Allow for occasional halts to submitting change requests until the review board has caught up.
B. Allow for emergency meetings of the change review board when change requests are outstanding.
C. Ask the change review board to meet more frequently.
D. Set thresholds so you or team leads can decide what to do with small change requests.
Ans: D
Setting thresholds for time and cost will reduce the number of change requests that the review board has to handle.

15. The development team has a problem with one of the software features and needs to quickly brainstorm a solution with the vendor team, which is not local. What method of communication would you choose for the brainstorming session?

A. face-to-face meeting
B. conference call
C. videoconferencing
D. online chat session
Ans: C
Videoconferencing is the ideal method because people can see and hear other people's reactions and the session can be scheduled quickly.


16. One risk to your schedule is that a hard drive with customized software fails and you lose the work that was done. The development team regularly backs up their work so they can resume work quickly after a hard drive failure. What type of risk management strategy do backups represent?

A. risk acceptance
B. risk transfer
C. risk avoidance
D. risk mitigation
Ans. D
Backups mean that you can restore the files you need, so you lessen the impact of a hard drive failure. Risk mitigation means that you limit the impact or probability of the risk.


17. To get early warning that a risk might occur, what is the key item to document in your risk information forms?

A. data from similar projects about when the risks occurred
B. a forecast of when the risk is most likely to occur
C. the events that might trigger the risk
D. who owns the risk so you know who to email with status requests
Ans: C
If an event might trigger a risk, documenting these events will give you early warning. The event doesn't mean the risk will definitely occur.


18. To create a project schedule, you need to perform several tasks. Which choice is not one of these tasks?

A. Assign resources to activities.
B. Set a deadline for the project.
C. Estimate the effort activities will take.
D. Put activities into sequence.
Ans: B
Management might set a deadline for your project, but that isn't needed to build the schedule. You build the schedule first and then adjust it, if necessary, to meet the deadline.

19. Which estimate on a normal distribution provides the best chance for a project being selected and completed successfully?

A. the best-case value
B. the worst-case value
C. the average of the worst-case value and the 50% probability value on the normal distribution
D. the 50% probability value on the normal distribution
Ans: C
This choice is not so high that the project won't get selected, yet it provides an 86% chance of delivering at or below your estimates.

20. When would you create a work package that describes the work to be done in explicit detail?

A. the work is complex
B. several people will perform the work
C. the assigned resource is inexperienced
D. the work is crucial to project success

Ans: C
A detailed work package can provide an inexperienced person with guidance on what needs to be done, how it needs to be done, how to tell that the work is complete and completed correctly.


21. A work breakdown structure diagram shows work broken down into manageable pieces, which provides several benefits for managing projects. Which choice is not a benefit?

A. assigning work to resources
B. identifying deliverables
C. estimating time and cost
D. measuring progress

Ans:B
Deliverables drive the creation of the work breakdown structure, not the other way around.



22. When you start a project plan, what information do you identify first because it drives most of the plan?

A. the resources assigned to the project
B. the work that must be done
C. the budget
D. the processes you'll use to run the project

Ans:B
The work that must be done determines the skills and resources you need, the effort the work will take, the cost, and so on.


23. The project customer and other stakeholders have approved your project plan. After you save the project baseline, those documents will be under the control of the _____.
A. quality management process
B. communication management process
C. change management process
D. scope management process
Ans. C
The baseline documents represent anything that you want to control with change management. Any changes to the baseline are change requests.


24. The critical chain approach can help prevent delays and even deliver a project earlier than with other approaches. Which choice is not part of the critical chain approach?
A. Schedule from the project finish date.
B. Add buffers to task sequences on the critical path.
C. Add buffers to task sequences.
D. Focus on the most limited resources first.
Ans. B
Actually, you add buffers to every task sequence in the schedule as well as at the end of the project, so tasks share buffers.


25. Now that your project is underway, all resource assignments are running late. What is the most likely cause?

A. not taking into account resource productivity when assigning resources
B. poor estimating
C. not taking into account the hours that resources spend on non-project work each day
D. assigning resources to too many simultaneous tasks
Ans. C
Non-project time affects everyone in the organization, which is why this is the most likely cause of every resource being behind schedule.



26. Milestones can be used in many ways. What is not something that milestones do?

A. summarize schedule and cost performance
B. indicate completion
C. reschedule
D. show progress

Ans. A
Milestones don't have duration or assigned resources, so they can't summarize cost. However, looking at only milestones does provide a high-level summary of the schedule.


27. When you assign resources to a task, what do you need to know to determine how long the task might take?

A. how many people are allocated to work on the task
B. days that people are available to work on the task
C. the number of people assigned to the task
D. all of these answers
Ans: D
Duration is determined by how many hours of work can be performed in a day, which depends on the number of people assigned, the percentage of their regular work schedule allocated to the task. Duration is also affected by days that resources are or are not available to work.


28. Which activity is not part of the Adapt stage?

A. Review what was completed to ensure that it does what it is supposed to.
B. Compare what was planned for the iteration to what was completed.
C. Review what has been completed and what is still on the backlog to choose the features for the next iteration.
D. Hold a lessons-learned session.

Ans: C
Although the Adapt stage includes a review of what was completed, you do not choose the features for the next iteration.


29. The customer has identified several new features since the original backlog was built. What do you do to address them?

A. At the beginning of the next iteration, re-estimate, reevaluate, and re-prioritize the backlog features to decide which ones to include in the iteration.
B. Talk to the customer about adding the features to a future project.
C. Estimate and prioritize the features, and start work on high-priority features immediately.
D. Add the features to the end of the backlog.

Ans. A
The customer can add features at any time, at which point you estimate and prioritize them in the backlog. Because things can change, at the beginning of each iteration, you re-estimate, reevaluate and reprioritize backlog features before you decide which ones to add to that iteration.


30. The Agile project management life cycle _____.

A. includes activities similar to a Waterfall approach but performed in a different order and with different emphasis
B. includes the same activities as a Waterfall approach performed in a different order
C. is totally different than a Waterfall approach
D. is shorter than the Waterfall project management life cycle

Ans. A
Agile project management includes activities similar to Waterfall. In Agile, planning, execution, control, and closing are performed in iterations. In addition, Agile project management activities emphasize things differently, such as interacting and documenting when needed.


31. Which choice is not a characteristic of Agile project management?

A. more emphasis on people and interaction
B. no documentation
C. customer is more engaged
D. appropriate when business needs change
Ans: B
Agile projects produce less documentation than a traditional Waterfall approach. They do not totally eliminate documentation.