THE FOLLOWING PMI-ACP^® EXAM TOPICS ARE COVERED IN THIS CHAPTER:

 Domain V: Adaptive Plannning

Adaptive Planning—Levels of Planning:

• Task 1: Plan at multiple levels (strategic, release, iteration, daily) creating appropriate detail by using rolling wave planning and progressive elaboration to balance predictability of outcomes with ability to exploit opportunities.
• Task 2: Make planning activities visible and transparent by encouraging participation of key stakeholders and publishing planning results in order to increase commitment level and reduce uncertainty.
• Task 3: As the project unfolds, set and manage stakeholder expectations by making increasingly specific levels of commitments in order to ensure common understanding of the expected deliverables.

 Adaptive Planning—Adaptation:

• Task 4: Adapt the cadence and the planning process based on results of periodic retrospectives about characteristics and/or the size/complexity/criticality of the project deliverables in order to maximize the value.
• Task 5: Inspect and adapt the project plan to reflect changes in requirements, schedule, budget, and shifting priorities based on team learning, delivery experience, stakeholder feedback, and defects in order to maximize business value delivered.

 Adaptive Planning—Agile Sizing and Estimation:

• Task 6: Size items by using progressive elaboration techniques in order to determine likely project size independent of team velocity and external variables.
• Task 7: Adjust capacity by incorporating maintenance and operations demands and other factors in order to create or update the range estimate.
• Task 8: Create initial scope, schedule, and cost range estimates that reflect current high level understanding of the effort necessary to deliver the project in order to develop a starting point for managing the project.
• Task 9: Refine scope, schedule, and cost range estimates that reflect the latest understanding of the effort necessary to deliver the project in order to manage the project.
• Task 10: Continuously use data from changes in resource capacity, project size, and velocity metrics in order to evaluate the estimate to complete.

 In this chapter, you will work through the tasks found in Domain V: Adaptive Planning. The tasks directly relate to the team’s ability to plan in an uncertain environment and adapt to the changing scope of work while maintaining focus on providing value.

The tasks in the content outline include creating and refining initial plans in a progressive manner and managing stakeholder expectations. This is all designed to give you a well-rounded idea of how to plan, adjust, and manage changes throughout the project. This includes elements of identifying key performance indicators and avoiding the misunderstandings that can occur in an Agile project while at the same time tracking performance across the project.

Much of project initiation and determining return on investment was covered in Chapter 4, “Agile Initiation and Stakeholder Engagement,” in the form of business case development and focusing on measuring benefits compared to costs. This chapter will address the planning that comes after initiation while keeping an eye on original value determinations.

Return on Investment and Benefit Measurement Methods

In Chapter 4, you reviewed all of the influencing factors that help to create a business case. Those included payback period, internal rate of return (IRR), and net present value (NPV). As organizations determine which projects to charter, a lot rides on the organization’s ability to obtain some type of return on investment (ROI). Even though ROI differs from organization to organization, the financial bottom line is always a concern. In this chapter, you will be fast-forwarding to the execution of a project and how value is both determined and tracked.

You will review many techniques, which can be executed at a variety of stages in the project. Since each iteration in an Agile project is itself like a mini-project, these best practices may be recycled as many times as necessary to determine budgetary constraints and need for changes as well as checking to make sure that you are building the right thing and building the thing right. All projects follow a type of progressive elaboration, or elaborating progressively on current plans as more information becomes available.

You will start with an approach called the earned value technique. The technique itself is a way to review current performance and compare it to what you thought the performance would be. In traditional project management, earned value is something that is used frequently to compare the current baselines to actual performance. If there is a variance that is too great, then a formal change may have to be enacted to put the project back on track in terms of scope, time, and costs.

While earned value may never show up on your PMI-ACP exam, earned value analysis will show up on the PMP exam should you ever want to pursue that as well. If you have already obtained your PMP, then you know that this section in class required you to memorize a lot of formulas in order to accurately answer questions on the PMP exam. Time to breathe a sigh of relief, mathematically challenged people, since you won’t see this on your PMI-ACP exams, at least not yet anyway. There are always updates and changes to these exams as new best practices are realized and older best practices resurface.

So, you may ask, why the heck are we going through this? Because you may have some old-school customers or stakeholders who want this type of information. You may also be tailoring your projects to contain both Waterfall and Agile best practices and may be called upon to run a report with this information. Therefore, it’s a good skill to have in your back pocket just in case.

Earned Value Analysis

The beginnings of earned value occurred in manufacturing, but it was widely embraced in the 1960s by factions of the US government, specifically the Department of Defense (DoD). You can blame the DoD for the next several pages, because I know will! All kidding aside, the technique is designed to look at the three major constraints on a project—scope, time, and cost—and determine if the project is being successfully executed to the original baselines or not. NASA and the US Department of Energy also use earned value analysis to track their budgets and schedule performance based on the scope of work completed.

A fun fact on earned value is that a massive navel military project was cancelled in 1991 by then Secretary of Defense Dick Cheney because of the results found after an earned value analysis—not satisfactory results, as I’m sure you figured out. There was too much deviation from the plan and too much time and money being spent on the scope of work.

The Project Management Institute incorporated earned value into the first edition of A Guide to the Project Management Body of Knowledge (PMBOK Guide^®) in 1987, and there it has remained as a way for organizations to review project performance and make decisions.

To this day, I still have PMP students email me and say that they were asked about the technique in job interviews, and I also get my share of email from students freaking out about the math on the exam. So, now that all the hoopla as to why you should know this has been covered, here is what it is and how it pertains to your Agile and Waterfall projects.

First, we’ll start with an overview of schedule control, and then we’ll move to cost. I’ll review all of the formulas after the introduction to the technique in both areas.

Key Performance Indicators

Key performance indicators (KPIs) are ways that most Agile teams track performance. That is not to say there aren’t tailored approaches that include earned value, but it’s more to the point that earned value results could be a key performance indicator. KPI is a bit like ROI, meaning that it is dependent on what the organization or the team determines is valuable information to improve performance. You have reviewed burn down and burn up charts, velocity tracking, story points, and the like for running an Agile project. All of those results plotted out on charts and graphs could be considered information on performance in key indicators.

How much work is the team accomplishing in an iteration or sprint? What is the difference between what they thought they would get accomplished and what was actually presented to the customer in a review? These are questions that will need answers, and much of performance tracking includes real-time work and real-time results.

What are the key performance indicators that show how performance is being managed and how the work is being executed? That is up to your organization, and it is the key data necessary to drive the implementation of improvements.

We know that velocity fluctuates, and we know that scope will change. If everything is so uncertain, then how can you track performance? Many times, there are two types of data to review. The first is team performance, including but not limited to the amount of story points that they select versus what they accomplish. There is always a big focus on continuous improvements and working to improve the value stream or to output more value in less time. It’s part of the culture of Agile teams.

All that focus on team performance is important, but what about the product and its quality? It’s one thing to bust out a new software program in the time frame that we said we would, and it’s quite another situation if that software is buggy, doesn’t work, or doesn’t perform to standards. Then the team performance is really a moot point. I’d rather see that they slowed down a bit and did it right the first time.

As you determine how you and your team will perform, it is important to set some goals and, moreover, to make them smart goals. The mnemonic of SMART was originally referred to in 1981 in a magazine article written by George T. Doran as a way to help organizations make goal setting more explicit and to help zero in on the reason goals don’t get met.

There’s a S.M.A.R.T. way to write management’s goals and objectives.

George T. Doran, Management Review, AMA FORUM (1981)

Later, the idea of setting smart goals was attributed to Peter Drucker and the philosophy of management by objective, or MBO. Throughout the years, the mnemonic or acronym adapted and adjusted to different verbiage, but the crux of the thought process remains the same. How do you make smart goals and work to attain them?

In Figure 8.1, you can see how the SMART process of setting goals allows for a focus on each item and a way to determine what a goal should look like to make it more likely to be achieved.

I once read an article that said 92 percent of all New Year’s resolutions end up failing by February. That is why the gyms are filled with people on January 2nd and by February they’re empty, and you can actually hear crickets.

What are the other 8 percent doing differently? They are setting realistic, smart goals. The key to specificity is removing the vagary from the equation. Instead of “I want to lose weight,” which is too vague, it could instead be “I want to lose 10 pounds.” That goal is more specific and it is measurable. How about assignable? Oh, I wish I could assign someone else to lose 10 pounds for me! Instead, we’ll focus on attainable for our goal. Is it attainable? Sure, people do it all the time. Not me, but you know, “people” do it all the time. How about realistic? That is a personal question, thank you very much, but a question nonetheless. Is losing 10 pounds realistic for the way life is rolling right now? If not, the goal will not be met unless my time frame is such that I can work around my crazy life and make it happen. Time-based goal, hmm: 2030?

In all seriousness, when I make goals now for life or for when I’m working with a team of people who need a bit more help to design their career goals, I use SMART goal setting. It’s a very different way of compartmentalizing what you want to achieve. If the stars don’t align across all SMART aspects, then that goal most likely will not be met.

If you have ever watched The Simpsons on television and seen the episode of Homer singing, “I am so smart, SMRT,” then you know if one piece of the equation is missing, it’s not so smart, D’oh!

Key performance indicators tend to be based on both tangible results, like work completed or time and money, and intangible items, like how the team works together, whether they have reached the performing stage, and what the Agile project manager’s day-to-day influence looks like. If you are having to remind your team every single day that stand-up meetings literally mean standing up, then you have your work cut out for you. If you are more of a servant leader, motivator, and coach, then the team performance is up to snuff.

Just as setting SMART goals is an important aspect of improving performance, keeping track of other team performance improvements are crucial to the project’s success as well. What is seen as a key performance indicator may rest solely on the framework you choose to use. Scrum KPIs may be different from XP KPIs. If you are designing software programs, performance indicators may be very different from a team that is implementing a new process or producing something more tangible.

From a business or customer standpoint, the scope, time, and money performance is crucial. From a team perspective, it may be improving best practices from iteration to iteration in how stories are estimated, what the definition of done is, velocity improvements, or actual stories completed versus planned.

As an Agile project manager and servant leader, coaching your team when needed begins with knowing what types of indicators show a high-performing team versus one that needs additional help and possibly a SMART goal-setting session. It’s always best to have the team determine what success factors need tracking and to understand management goals. Those success indicators and goals need to be explicit so that there isn’t any question as to what information will need to be reviewed and reported. The keys to success are performance indicators that are well defined and well reviewed throughout the course of the project.

The Triple Constraints

Most projects have a semblance of balance between competing constraints. The term the triple constraints or the iron triangle describes what was initially a way to document the big constraints of scope, time, and cost. Quality was later added to the mix because it is so closely tied to the scope of work. Now with risk and resources added to the list, the triangle has gotten a bit busy and is now referred to as the competing constraints. Our focus, however, will be on the big constraints of scope, time, and cost.

In a Waterfall project environment, the scope of work is fixed, while time, cost, and quality work around that constraint.

In Figure 8.2you’ll see that in an Agile environment, the triangle is flipped because cost and time are fixed, while scope is flexible and quality is dependent on the scope of work. In some cases, quality is very flexible if the development team knows they will be pushing out bug fixes or software updates in the very near future. The goal is to create a minimally marketable feature that is the simplest thing that works.

Determining what the scope of work really is will be the key to meeting requirements and providing value to the user. That scope will be driven by a fixed budget and schedule per iteration.

The Gulf of Misunderstanding

The gulf of misunderstanding sounds very much like the Bermuda Triangle of Agile and in fact is a fairly good description of what can happen when the customer/end user and the team totally miss each other’s point and land in the deep end.

The concept of the gulf of misunderstanding is more often called the gulf of evaluation in a software development environment. The gulf of misunderstanding is a catchier and more apt description, though. Both terms mean that somebody missed the point.

When applied to software development, the gulf of evaluation is the difference between what the end user wants and what is created for them. Because of the misunderstanding, the true results won’t match up to the needs of the end user and are a waste of time and money.

The hard part in a software design project is that the end user may not know what they want, or they may not understand the jargon. GUI sounds like something that sticks to the bottom of your shoe instead of actually meaning graphical user interface. It would be easier if someone just said, “You know those icons on your desktop? Yeah, that helps the computer understand what it is you want it to do without you having to know the language of the computer. So, what icons do you want?”

An end user may not understand the technical jargon and tell the team to “do whatever you want or think is right.” Now you may get some software developers working on something they think is cool but is completely out of scope for what the end user wants or needs. The gulf of misunderstanding strikes again.

Abbott: No. What is on second.

Costello: I’m not asking you who’s on second.

Abbott: Who’s on first.

Costello: I don’t know.

Abbott: He’s on third, we’re not talking about him.

Costello: Now how did I get on third base?

Abbott: Why you mentioned his name.

Costello: If I mentioned the third baseman’s name, who did I say is playing third?

Abbott: No. Who’s playing first.

Costello: What’s on first?

Abbott: What’s on second.

Costello: I don’t know.

Abbott: He’s on third.

Bud Abbott and Lou Costello

A large part of making sure time, effort, and money aren’t wasted on producing items that aren’t wanted, needed, or understood is the concept of prioritization, so there is a firm understanding of what will be created and in what order.

The product owner will communicate as often as possible to help the customer understand and/or help the team create something of value if the product owner is in fact the customer. The team will then work with the product owner and/or customer to prioritize what is most valuable or necessary now. All activities and transparent discussions are utilized to avoid falling into the gulf.

The rest of this chapter is designed around ways to provide value without misunderstandings. Some of the techniques you have reviewed in other chapters. Others are there to help you help yourselves and your customers/end users get what they want without rework due to misunderstandings. Remember, this all goes back to providing value and the organization getting the return on investment they expected for the time and money they allotted. It’s a win/win for everyone.

Dot Voting, or Multi-Voting

If you have a long list of items that need to be sorted in order of importance or in order of occurrence, it can be difficult to get everyone on the same page. However, if everyone has a say and that leads to a cumulative agreement, then it may not be so bad. This is where dot voting, or multi-voting, can help your team make decisions in a facilitated, orderly fashion—plus you get to play with stickers!

The concept of a democracy comes from the Greek word meaning rule of the people, or rule of the majority, and in this sense the best practice of voting was born. In an Agile environment, a dotmocracy may be necessary to reach consensus through voting.

Dot voting is a facilitated event in which the team has a set amount of dot stickers to their name. They are then asked to vote on certain options. The individual uses as many dots as they want for a cross section of options, and in general the options with the most dots are priorities.

In some cases, the team will use red and green dot stickers to represent what they agree or disagree with. There is often a lot of discussion around the decisions, but the goal is not to create an environment of groupthink. Groupthink is the opposite of a facilitated decision-making exercise, meaning that the strongest personalities usually influence the rest of the group. Meanwhile, the rest of the group doesn’t want to create conflict or analyze the options thoroughly, so they go along with whatever decision is made or whatever options are presented. The upside to groupthink is that decisions are made quickly and consensus appears to happen. The downside is that relevant information may not be discussed and major features may not be built. Now the stronger personalities get to win because they said so. Dot voting allows each person to have an opinion and openly vote on their opinion. They are then asked to explain the reasoning to the rest of the group as needed for the group to make informed decisions. Groupthink is the easy way out, and many risk events and key features have been missed because of it.

If this is a bigger group event that includes senior management or the customer, different color dots can be used to represent senior management’s votes versus team votes and even customer votes. That way, who voted for what is much clearer.

There is literally no wrong way to do dot voting, and I’ve found that, in some cases, it opens up the lines of communication a bit and allows everyone to have an opinion. When the dust settles and the votes are counted, it just “is what it is,” and everyone agrees to the decisions that were made. In a perfect world, the number of votes something gets describes a clear winner and that is that. However, since the scope of work changes regularly, voting doesn’t happen just once.

Embracing a dotmocracy may occur at every review or during backlog refinement or even in a retrospective when things didn’t go so well. Mostly, the process is about prioritization, discussion, and embracing all ideas. Dot voting is a quick, straightforward way to reach consensus.

Much as with everything we vote on, there are some downsides to dot voting. There could be a sense that even though something has been explained as necessary, others don’t buy in and views aren’t heard. There is also always the possibility that someone isn’t fully caffeinated and that they just stick stickers wherever so that they can get to the break room as quickly as possible.

This is a good lesson for Agile project managers whose job as facilitators rests on how the team engages with each other. With that in mind, it is better to set some ground rules about time to make decisions or time for discussions when holding any kind of voting. You know your team, and you will also know if this type of engagement would be effective in your own environment.

The first time I tried this, there were more stickers on the team members’ backs than on the board due to rowdy team members who thought they were being funny. A week later, I still found dots stuck everywhere. That onus is on me for not setting ground rules and facilitating appropriately. It’s a cautionary tale. Otherwise, have at it! It can be a fun, relaxed way to make decisions as a team and to help get priorities straight.

MoSCoW

This section is just a reminder of the prioritization technique of MoSCoW that you covered in Chapter 3, “Key Aspects of Additional Agile Methodologies.” The entire premise of using the acronym is the process to determine what must end up in the result no matter what, what should be in the result, what could be, and what won’t be in the result. Obviously, things change, and in some cases what should be included will rise to the top and become a must-have, and what could be in the result can slide down the ladder to the won’t pile.

The MoSCoW Approach to Focusing on the Business Need

• MUST have this requirement to meet the business needs.
• SHOULD have this requirement if possible, but the project success does not rely on it.
• COULD have this requirement if it does not affect the business needs of the project.
• WON’T have this requirement, and the stakeholders have agreed that it will not be implemented in a release but may be considered for the future.

Prioritization is a moving target, but by simply asking the right questions during backlog refinement or in selecting work to be done, it is easier to use a categorization schema than to go in a million different directions and not get anything accomplished. The minimally viable product or minimally marketable feature would contain mostly must-haves. The goal is to have end users understand what value is and what items need to be in the increment. Reaching an understanding of the classifications can be difficult, though. Allow me a quick tangent.

In risk management, we often use a high, medium, or low classification for probability and impact. This can be difficult to quantify because if I have stakeholders who are risk takers, they may not look at an identified risk as high probability or impact, whereas someone who is a catastrophic thinker may see red flags everywhere. Who is correct?

It’s important to get everyone on the same page as to what is high, medium, or low. The same concept applies to must, should, and could. In risk management, you are considering the stakeholders’ level of tolerance for certain risk events, and in prioritization methods like MoSCoW, you are seeking an understanding of what is valuable. That can be difficult since what is valuable to one may not be valuable to another. I find it is best to quantify classifications and communicate around them.

Monopoly Money

If I were to hand you a million dollars today, how would you spend it? Would you travel the world? Buy properties? Start a business? Invest it? Buy a very expensive sports car? What is most important to you?

What I might do with a million dollars may be very different from what you would do with the same opportunity. I’m also aware of the curse of the lottery winners who spend all of their money in all the wrong places and end up with nothing in the end. From a business and financial perspective that sounds terrible, and you might think to yourself, I would never do that if I won the lottery; yet it happens all the time.

Organizations spend billions (with a b) every single year on projects that aren’t successful: good money being thrown after bad money. Such projects include customers who are disappointed with the quality of the work or the result that isn’t what they expected, recalls that end up on the news, and projects that are cancelled before they ever get off the ground. It’s the cost of doing business.

This is where a cool little exercise called Monopoly Money makes all the difference in the world. If you have never played the game of Monopoly, which originally was sold by Parker Brothers and now by Hasbro, then here is a quick overview. The object of the game is to become the wealthiest player by buying and selling property. There are also some pesky interruptions to that process, like not being able to pass Go without a payout and the possibility of landing in jail. The bottom line is that to win the game, you have to gain as much money or assets as possible before someone in your family flips the board over in frustration and announces that they are finished with the game. At least that’s how it works in my house anyway.

The interesting thing is that the game was originally created as an educational tool to explain the downsides of the single tax rule or having land concentrations in private monopolies. The game’s patent and sales history is quite fascinating if you are looking for ways to waste time at work, and if you find yourself playing trivial pursuit instead, it may come up in a question.

Rule No.1: Never lose money.

Rule No.2: Never forget rule No.1.

Warren Buffett

The question of what you would do with a million dollars and how you would spend it is the premise behind Monopoly Money as a prioritization technique. The sponsor or customer is given Monopoly Money in the equivalent of the current project budget and then asked how they would spend it and where. This eye-opening experience for both the sponsor and the team is an excellent way to see what is deemed a priority over another.

We always stick to features during this process because what the team might find as a valuable day-to-day practice, the sponsor sees as having no value and vice versa. I know I’m not throwing money at an earned value report lest someone ask for one, and the sponsor may not see value in our little dotmocracy. Stick to the features. For some reason, when money, fake or otherwise, is in the mix, the seriousness of decision making becomes more prevalent. Fun with stickers is one thing, but with money, oh now we are really getting somewhere!

Just like any other conversationally driven, facilitated event in Agile frameworks, you will walk away with a better understanding of what is valuable to everyone involved. The sponsor will understand how their money may be spent, and the team can now determine of all the valuable items, what stories need to be written and selected to accomplish in the next iteration.

The goal in any project is to provide a quality result in a way that is within budget, within schedule, and within the scope of work. The almighty dollar speaks volumes in this technique, and it quantifies the work for all involved.

100 Points

The 100-point method is like Monopoly Money in the sense that there is an allocation or distribution of something across features and the ability to vote on features. Everyone has 100 points that they can allocate however they want to. Some team members may feel very strongly about one feature and use all of their points to prove a point, but mostly the team will use their points in a way that shows priority. Much of the time my team agrees on the big features and the priority of them, but the features that have less priority to some are higher in priority to others.

Because the team is voting and can use their points, however, like our facilitated voting event, it will often include a rousing discussion by technologically savvy people speaking in code and using sci-fi references to make a point. (I’m usually the one using the sci-fi references.) The rest of the team is discussing the ins and outs of the features and the technology behind the features, and with that stream of consciousness some support items may come to the surface. This happens more times than not due to some supportive features becoming necessary.

If a main feature is a priority but it needs something in a lower priority ranking executed so that it can actually function, then that lower-priority feature has moved up the ranks.

Just as with any other activity to determine priority, priorities change, and, using a technique of 100-points can help the team distribute priority across multiple features in multiple iterations.

Kano Analysis

What defines priority may come down to personal opinions of what is most interesting or exciting about a result. I know that if I have some technology that I love because it does something I really want it to do, I can forgive it crashing a few times or being a bit buggy. That is because something I see as super cool was created: I bought it and I use it. There are some reasons consumers line up around the block for the next big technological thing, even though in most cases it’s just an updated version of the thing they are currently using. “Did you hear the headphone jack is at the bottom now? Somebody please take my money!”

What excites us about software and technology are all the things that can help make our lives easier. In order to do that, there is a fine balance that must be met of whether or not the product works well, or whether or not it has exciting features that I want, or whether it contains any deal breakers that would make me go to the competition. Welcome to software development! Kano analysis is a model of determining distinct categories of needs or wants and quality of product.

The beginnings of Kano analysis were created by Professor Noriaki Kano in the 1980s as a way to classify the preferences of customers. The theory was based on quality. The various category labels may have changed over the years, but the premise remains the same. There are certain things that cause customers to buy and other things that cause them to walk away. That is the beauty of a capitalistic society; everyone has the option to do either based on their needs at the time.

If that is the case, then as an Agile practitioner it’s important to be able to classify features based on very distinct categories.

Delighters or exciters, satisfiers, and dissatisfiers.

Delighters or Exciters These are the features and functions that the customer finds super cool and is excited to begin using.

Oh my. There is a watch that is like a phone, and I can use it to track my sleeping patterns? I must have one right now.

Satisfiers My watch answers phone calls and allows me to receive emails and texts even when my actual phone is somewhere else.

Dissatisfiers My watch keeps telling me to breathe every hour to relax, and frankly I find it annoying and it’s stressing me out.

Here’s the deal with exciters and satisfiers—they change over time. What I find exciting about technology today will be replaced with something else tomorrow.

I forget things almost instantly. It runs in my family… well, at least I think it does.

Finding Nemo

The odds of customers finding new shiny things to be excited about on new or updated products on a regular basis is very high. What once was an exciter is now simply a satisfier. We still like it and want it, but we are not jumping up and down about it anymore.

The importance of continual analysis of what is deemed valuable and necessary today also has to be balanced with what the end users find exciting. The goal is to attempt to balance that and add it to the mix if the feature doesn’t take away from the performance of a satisfier.

Kano analysis shows that innovation and exciters become basic needs in the long run. The goal is to make sure that the satisfiers are always included in the product and that they work. If satisfiers don’t work effectively, then dissatisfaction occurs. In Figure 8.3 you can see a very simple example of Kano Analysis which can be used as a discussion piece when determining features.

Customized Procurement

Procurement is pretty much always necessary on any type of project. Whether it be Waterfall or Agile related, there will always be a need for goods and services, materials, and equipment from an outside source.

Most organizations that run projects have a procurement department, or at the very least a legal team who helps with terms and conditions and negotiates the agreement. It is rare that an Agile project manager or a Waterfall project manager would be doing the actual negotiations and contractually binding their organization to that of another without an attorney present.

The bottom line is that the project manager will understand the scope of work and may be tasked with creating a procurement statement of work (PSOW) that is itemized for the procurement needs. They would then need to understand what constitutes a viable option when bids start coming in. Basically, that involves determining if a bid or proposal goes into the Yes or No pile and understanding the source selection criteria, or in other words, the criteria by which we select our seller.

Many times, in a more traditional Waterfall environment, the project manager would be the one who is responsible for protecting the organization from future costs and litigation (litigation bad; negotiation good!) as well as having the skill sets to weed through a variety of bids, quotes, and proposals to determine which sellers meet the project needs.

Also, traditionally contracts have been very rigid in their terms and conditions. For traditional projects, fixed-price agreements were good for the project because the scope of work is well known and the project can budget the costs easily. Cost-reimbursable contracts, on the other hand, are more flexible for scope changes but a little too flexible on the cost side, so budgeting is more difficult. No matter what, though, when I think of a contract, I think of something that would be very difficult to change or adapt as needed on an Agile project where change and flexibility are necessary.

You can adapt to different flavors of contract types in either category by adding words like incentive fee or fixed fee and adding tons of terms and conditions, but a contract is still a contract, and a breach of contract isn’t acceptable. What to do? Create a change control procedure that is a bit easier to work with but have an attorney present for all changes? That is a lot to ask for in an Agile environment. Because of the need for flexibility on the scope side of things, and to still have some semblance of planning ahead, much more flexible procurement options are available.

As far as the assorted flavors of Agile procurement, there are many more than what you will see here, and some may have different terminology based on your organization. As a high-level overview, here is a list of the types that you could see in your organization or as they pop up in an exam question.

Fixed-Price, Fixed-Scope (and possibly Fixed-Time) Good when requirements are known or stable and very common in both Waterfall and Agile environments. Very simple terms and conditions, and it just “is what it is” for cost, scope, and time as needed.

The Fix and Switch Fixed-price, fixed-scope (and possibly fixed-time) but vague enough that the contract can be altered to meet customer needs. The downside is that it isn’t the easiest contract to get sellers to agree on due to the vagary of the contract itself and because collaboration is needed with the product owner/customer in order to alter scope.

Time and Materials This contract is very common in all project types. Basically, it is designed to pay for the work as it gets accomplished, or for materials/equipment as they are needed and used. Good for flexible scope, and typically has a ceiling price or not to exceed number.

Not-to-Exceed with Fixed-Fee (NTE/FF) This type isn’t so flexible but might be relevant if it is used for an iteration or a point in the project where the specific scope of work is known. There is flexibility to a point, but as soon as the ceiling is hit, it’s done, and the seller will receive a fixed fee as a profit. It will have a definitive ceiling price.

Fixed Price per Function Point or Story Point This type allows for reprioritizing scope and calculations based on velocity and embraces the agility of many project types. Keep in mind that velocity tends to fluctuate in the beginning and then plateau, so costs may be a bit wonky until that happens.

Graduated Fixed Price Finally, this contract type allows for incentives and focuses more on other items in the project that may be more important than money. This agreement may provide for different hourly rates for early, on-time, or late delivery of work in a tiered approach.

Regardless of the types of contracts your organization works with, you may find that the sellers or suppliers are also part of your team or are for sure considered stakeholders. With a lot of the more flexible contract types for Agile projects, both the buyers and the sellers share some of the risk, especially the cost risk. When the scope of work is flexible, it’s more difficult to set requirements in stone. With fluctuations in scope come the inevitable fluctuations in cost. This can be concerning for sponsors or customers because typically time and cost are fixed while scope is flexible. Because budgets may be created per iteration, it can lead to some creative contracting.

Many organizations find it better to work with adaptive contracting across the board. A master service agreement (MSA) may be more realistic for your organization due to its flexibility regarding future changes. Many times, a master-level service agreement allows for acceptance of terms and conditions that will apply in the future as well, regardless of scope changes. Both parties will agree to those terms and conditions on the front end about how decisions will be made in the future. This keeps all necessary negotiation focused on the scope of work changes rather than continuously updating or negotiating on other terms and conditions.

Master service agreements may also include open-ended fields that can be adapted throughout the project. In most cases, a Statement of Work (SOW) is written into the service agreement as well. Along with the scope of work, there are also provisions (as in all contracts) for risk allocation and indemnification.

Risk allocation is setting very specific standards for how risk will be handled during the agreement and who are the responsible parties. Indemnification allows one party legally to exclude the other party from payments or damage in the future. In simpler terms, it would be written in the contract that Party A will not hold Party B accountable for financial losses in the future based on decisions made today regardless of who is at fault—lots of legalese that you don’t need to know about unless you are managing procurement in your organization.

Here are some concluding thoughts on procurement. It is typically the project manager’s role to protect the organization from future litigation and to manage good, working relationships with the sellers, meaning don’t breach contracts, don’t allow them to breach contracts, and engage the sellers as you would any other stakeholders on the project regardless of the framework or methodology you practice.

Summary

In this chapter, we covered the execution of work on an Agile project and revisited some of the items that not only can determine return on investment (ROI) by using benefit measurement techniques but can also show whether ROI has been met. We reviewed some of the specific key performance indicators (KPIs) that drive project performance, and I included an overview of the earned value technique (EVT) used on many project types to track scope, time, and cost completions. This data can also be used to predict project performance should the project move forward with the same performance trends.

Next we reviewed some of the many ways that value is determined both by the customer and the team. Some of these were reviewed at a high level in other chapters, like the MoSCoW technique of determining what must, should, could, and won’t be included in the deliverable or result.

Then we covered other techniques that allow specific ways to help determine value and gauge if the ROI is being met while avoiding the gulf of misunderstanding between customer and team. Techniques like dot voting, Monopoly Money, and 100 points allow for transparent communication and consensus to be reached before anything is produced.

We also reviewed Kano analysis, which is likewise used to determine value for features and items that can create excitement in the end user while maintaining that the satisfiers are met as well.

Finally, we covered some ways that Agile organizations utilize a more flexible procurement approach. This allows an organization to enter into a contractual relationship with sellers while allowing for changes in scope to be added and removed more easily. Having more flexibility in procurement is key to creating and maintaining good relationships with the sellers and to reduce the risk of breach of contract or other alternative dispute resolutions like arbitration, mediation, and litigation.

Exam Essentials

Be able to understand how return on investment (ROI) is determined. Understand why it is important to know how your organization views what is considered to be valuable and how benefit measurement methods extend past a simple business case and creation of the project charter.

Understand the concept of earned value technique (EVT). While you may not be tested on actual formulas and equations, it’s important to understand how project execution can be tracked using schedule and cost variance information as well as indexes of efficiency. This can lead the team to adapting and adjusting their strategy to meet organizational goals.

Be able to understand the different ways to determine value. Having a misunderstanding about what the customer or end users want will lead the team to create an incorrect increment. This causes lost time and money and a significant amount of rework. Avoiding the gulf of misunderstanding is crucial to project success. Dot voting, MoSCoW, Monopoly Money, and 100-point assessments can clarify the requirements and allow for a consensus to be reached.

Understand Kano analysis. You won’t be heavily tested on this concept, but this analysis technique is an excellent way to categorize qualitatively what the end users find exciting in a feature and what is necessary to maintain satisfaction in the result. Conversely, it is also useful to understand what might be a dissatisfier or feature that isn’t valuable to the end user so that additional money and time isn’t wasted producing something that the customer doesn’t want, need, or even like.

Be aware of different ways to utilize procurement contract types. Because the scope of work is more flexible or malleable on Agile projects, it is important to have a procurement process that is as well. You won’t get many questions on the exam about contract types specifically, just the need for scope flexibility and how different agreement types can accommodate that need. Having a good high-level understanding of procurement is also important in your day-to-day procurement endeavors, should your organizations utilize the use of sellers or suppliers.