The Close Sibling of Communications and Stakeholder Management: Resource Management

In my earlier article, The Twins–Communications and Stakeholder Management, I outlined how deeply and closely these two knowledge areas of the PMBOK® guide interact with each other. We saw a good number of overlaps.

Among other knowledge areas (KAs) that you will come across in project management, Resource Management comes in close when considered along with Communications and Stakeholder Management. For example, a plan for resources has information to drive communication and interactions with stakeholders. While other KAs can possibly interact with the twins like siblings in a family, no other area comes as close to the twins as Resource Management. This is why I call it “the close sibling.”

Like in my previous article on the twins, this will be less of a discussion on Resource Management and more about how the knowledge area interacts with its closely related sibling knowledge areas. If you are an aspiring Project Management Professional (PMP ®), your understanding of the interplay between these KAs should be solid.

First, let’s look at the basics of resource management.

Humans Vs. Resources

In my view, the term “human resource” is somewhat dicey. The word human, which is a noble word when combined with the word resources, becomes awkward.

The latest edition of the PMBOK® guide went with “Resource Management,” in place of “Human Resource Management” because this KA covers all possible resources – team resources and physical resources, alike. This is a key distinction to be aware of.

The word team referenced here is specifically referring to the project’s team members, not all the stakeholders. For stakeholders, we have the KA of Project Stakeholder Management. This is another key distinction that is important to understand. On the other hand, physical resources can be equipment, supplies, and materials (among others).

We will see the significance of these two high level categorizations of resources in the upcoming section on process interaction within the Resource Management KA.

Resource Management – What Happens?

Here we see three processes interacting with each other as shown below:

Below are the key points to note:

Plan Resource Management process: First, the “Resource Management Plan” is prepared in “Plan Resource Management” process. It allows the project manager to document how it is that he/she obtains and manages both team and physical resources. The created plan informs on when to hire and/or acquire and for how long. It also provides a plan for how to develop, reward, motivate, and manage team members. For physical resources, it tells you how to control.

The key output for this process is the Resource Management Plan (ResMP).I’m using the abbreviation, ResMP, here in place of RMP, as I’ve previously used RMP within the context of a Risk Management Plan and framework in Risk Management.

Estimate Activity Resources process: This process succeeds Plan Resource Management, and here you estimate the type and quantity of team and physical resources. We see the Resource Requirements for activities (or work packages), as a key output from this process. We also get the Resource Breakdown Structure (RBS), which tells the category and type of resources in a graphical way.

Acquire Resources process: In this process, you actually acquire or hire the estimated resources. After that, said resources are assigned to activities. Team resources result in Project Team Assignments, and physical resources result in Physical Resource Assignments. Another key output of this process is the Resource Calendar reflecting when and how long the resources will be available for.But wait! Can a newly joining team member perform from day one? Unlikely! For that you have to train and manage your team with interpersonal skills, set the ground rules, and possibly co-locate them together during initial stages. This happens in the next process, Develop Team.

Develop Team process: In this process, the decision to give rewards and recognition to team members is considered. Team Performance Assessments are the key output of this process.

Manage Team process: In this process, you track the team member performance, provide feedback, and manage issues when they are raised. You also recognize and reward your team members based on their performances, which you have assessed earlier in Develop Team process.

Control Resources process: While Develop Team and Manage Team processes are for team resources, the process of Control Resources is for physical resources. Here, you ensure that physical resources are continuously available as planned, as well as monitor and control the resource utilization.

The interactions among the processes of the Resource Management KA is explained in this video [duration – 4m:39s], taken from my PMP Live Lessons. For the best experience, you may want to go full-screen with HD mode and plug-in your earphones.

With this understanding of the Resource Management KA, let’s now move to the interaction of Resource Management with Communications and Stakeholder Management.

The Interaction of Resource Management with Communications and Stakeholder Management

We already know that the key documents and plans created in twin knowledge areas are as follows:

• Communications Management Plan (CMP)
• Stakeholder Engagement Plan (SEP)
• Stakeholder Register

In the preceding section, we also just saw that the key plan prepared in the Resource Management is the Resource Management Plan (ResMP).

The interactions among these knowledge areas will focus on these four documents and how they are flowing across the various processes of these knowledge areas, as well as cutting across the process groups.

Interaction Point 1

The ResMP prepared in the Plan Resource Management process focuses primarily on the confirmed and approved scope (Scope Baseline) and contains information on deliverables. These deliverables determine and drive the types of resources needed.

The Stakeholder Register already created in the Identify Stakeholders process acts as an input to Plan Resource Management. This is because some stakeholders have interest/impact on resources being selected and used.

At this stage, the created ResMP will document the roles and responsibilities of team members. This includes those responsibilities related to communications management and stakeholder engagement. Team members are not hired at this stage, and hence, are considered generic resources.

Interaction Point 2

After resource requirements are determined in the Estimate Activity Resources process, the Stakeholder Register acts to inform the Acquire Resources process because of stakeholders’ interests. For example, stakeholders may have a need that is apparent while getting a particular type of resource.

The Stakeholder Register is also updated in this process because new team members are actually acquired or hired in the Acquire Resources process. Such is documented in the stakeholder register. This is very significant because the team members are also stakeholders and their information has to be available in the Stakeholder Register (this is not so in any other document or plan generated in Resource Management).

Now, a project manager doesn’t need each and every resource at the beginning of a project. One of the best practices is to go for Just-in-time (JIT) acquisition. If this is implemented, change requests (CRs) are raised throughout the process.

Interaction Point 3

The ResMP, along with the Stakeholder Register, acts to inform the Plan Stakeholder Engagement process and creates a high-level Stakeholder Engagement Plan (SEP). While the names of stakeholders, including the team members, come from the Stakeholder Register, the roles and responsibilities for stakeholder engagement comes from the ResMP.

Next, the high-level SEP, the ResMP, and the Stakeholder Register created earlier, act as input to the Plan Communications Management process ultimately creating the CommsMP. The CommsMP lists out the communication requirements for all stakeholders, including those of the team members, who are also project stakeholders.

Interaction Point 4

As you prepare the Communications Management Plan (CMP), which comes as output of the Plan Communications Management process, the CMP, along with the ResMP and the Stakeholder Register, acts to inform the Plan Stakeholder Engagement process and a detailed SEP.

Remember, as noted before, the engagement of stakeholders’ responsibilities lies with the team members—those listed in the Stakeholder Register. The roles and responsibilities; however, for engagement are listed in the ResMP, and hence, this plan becomes vital to creating the SEP.

Interaction Point 5

The ResMP, CMP, and SEP prepared are executed in their respective processes–Develop Team and Manage Team for team members, Manage Communications for the execution of communications strategies, and Manage Stakeholder Engagement for stakeholder engagement.

As you develop your team members to improve skills, competencies, and enhance project performance, Change Requests (CRs) can be raised in the process of Develop Team. Similarly, while managing a team, it’s possible to experience staffing changes, reassignment of work, or replacement of team members who leave. In such cases, too, CRs can be raised in the Manage Team process.

Interaction Point 6

The CMP and SEP are monitored in their respective processes, as well. I am referring to Monitor Communications and Monitor Stakeholder Engagement.

Here too, the ResMP acts as input to the Monitor Communications process as it has information on roles and responsibilities related to project communications. Similarly, the ResMP inputs the Monitor Stakeholder Engagement process.

All change requests raised from the processes of Resource Management are analyzed, processed, and addressed through integrated change control, where the change control board (CCB) makes decisions on the fate of the CRs.

Hands-on Exercises

Now that we understand the processes, key inputs and outputs, and interactions among the Resource, Communications, and Stakeholder Management KAs, let’s do a few hands-on exercises.

In the below figure, each box or block represents a process in one of the three areas we’ve been discussing—Resource, Communications, and Stakeholder. I’ve put certain questions in these blocks. Can you answer them by replacing the questions with the name of the processes?

The answers should be one of the processes that we saw earlier within the Resource Management, Communications Management, and Stakeholder Management KAs. All change requests will be addressed via integrated change control.

Scroll down only if you have answered!

. . .

. . .

. . .

The correct answers are shown below:

For a better understanding, I’ve color coded some of the lines in the above figure. For example, unicolor coded lines such as green, orange, pink, or black represent a single input or output throughout the processes and across the KAs.  Can you share just one key output for each process? Do not scroll, before you have answered.

. . .

. . .

. . .

Note that in the above figure, the following is true:

• The Resource Management Plan (ResMP) is highlighted in green colored lines.
• The Communications Management Plan (CMP) is highlighted in orange colored lines.
• The Stakeholder Engagement Plan (SEP) is highlighted in pink colored lines.
• The Stakeholder Register is highlighted in black colored lines.
• The change requests (CRs) are highlighted in purple colored lines.

To explain further, I have another video [duration: 9m:54s] on how the twins and the close sibling interact with each other. The video is taken from PMP Live Lessons.

Guidance for the PMP Exam

The PMP exam tests your understanding on how knowledge areas interact and interplay with each other–why, when, and what inputs or outputs are used in various situational contexts or scenarios. Like with the twin KAs, questions can be tricky when the close sibling, Resource Management, gets involved. There are quite a few subtle differences among the three respective processes and associated documents that confuse many aspiring PMPs.

In my videos and examples here, I’ve referenced several documents and plans to show how all the three knowledge areas interact. Of course, there can be a number of other documents, plans, or subsidiary components of the plans that create other possible flows. Nevertheless, the aforementioned plans will be the most important for you in understanding the interactions between these KAs.

Key Points of Interplay between the Twins and the Close Sibling

Finally, as we close, I’m listing a few key points, out of many, about the interplay between the twins and the close sibling.

• Stakeholder Engagement Plan (SEP) is for stakeholders’ engagements, including those of the team members.
• The question of how to engage team members is a part of Stakeholder Engagement Plan (SEP), but, the question of how to manage the team members is addressed by Resource Management Plan (ResMP).
• The Stakeholder Register includes ALL stakeholders, including project team members.
• The names of the project team members are part of the Stakeholder Register, but roles and responsibilities of the team members are part of the Resource Management Plan (ResMP).
• The communications requirements for all stakeholders, including the team members, will be part of the Communications Management Plan (CMP).

What do you think? As management practitioners, how important are resource, communications, and stakeholder management KAs for your projects? Is there any other area which interacts closely with the twins and the sibling? I’d love to hear your views and thoughts in the comment section below.

--

This article was first published by MPUG.com on 11th November, 2020. 

References:

[1] PMP Live Lessons - Guaranteed Pass or Your Money Back, by Satya Narayan Dash

[2] PMP 35 Contact Hours Online Course - Full Moneyback Guarantee, by Satya Narayan Dash

[3] Book - I Want To Be A PMP, The Plain and Simple Way, 2nd Edition, Satya Narayan Dash

[4] Project Management Body of Knowledge (PMBOK) Guide, 6th Edition, by Project Management Institute (PMI)

The Twins – Communications Management and Stakeholder Management

 

The following true story was shared in one of my classes by a senior manager from a global corporation in South Korea. The manager’s team had worked over six months and was gearing up for a firmware release with a specific set of features.

The recently new Chief Technology Officer (CTO) of the organization participated in a pre-release meeting, and had dropped a bombshell, cancel the project! As per the CTO, similar kinds of functionalities were already available from another team, and he didn’t want to incur the associated operational costs.

What went wrong? How could this situation have been avoided?

In this article, we will look at two key knowledge areas: Communications Management and Stakeholder Management. We’ll look at how these interact and how they very much go hand-in-hand. Hence, the term of my title: the twins. If you are an aspiring Project Management Professional (PMP ®), you need to have solid understanding on how these two interact with each other.

This article is less of a discussion on Communications Management or Stakeholder Management, individually, per se. Rather, it’s more about how they interact within the knowledge area and with each other, the areas in which they overlap, and how they influence and impact each other.

Though Stakeholder Management is a separate and distinct knowledge area (KA) in the PMBOK ® Guide, the primary mode of engagement with stakeholders is communications. So, let’s start with Communications Management first. I’ll also mention some other important terms that will be used in this piece. 

Communication vs. Communications

You may have noticed the word, “communications,” named such in the knowledge area. It’s not just “communication,” rather we see an extra letter, “s.” This is significant.

“Communication” is the process or act of information exchange. The information exchange among parties can happen in written or oral form, formally or informally, or take place with choice words, gesture, etc. On the other hand, “communications” is the means with which information is exchanged. These “means” include communication activities (i.e. meetings) and artifacts of communications (i.e. emails and reports). Simply put:

• Communication is the “process” of information exchange or the act of communication.
• Communications is the “means” of information exchange or the activities and artifacts of communication.

The Communications Management KA is about both communication and communications. This KA also addresses effective and efficient communication.

• Effective communication: Here the information (right message) is provided in the right format, at the right time, to the right audience, through the right channel, and with the right impact.
• Efficient communication: With this, only the information that is needed, nothing more, nothing less, is provided. If you give extra, unsolicited information, I call it “communication creep.” Like scope creep, communication creep is not desirable.

With these fundamental definitions in mind, let’s briefly see what happens in the knowledge area of communications management.

Communications Management–What Happens?

This KA has three processes and they interact with each other as shown below.

Below are the key points about interactions among these three processes.

• Plan Communications Management process: In this process, we first decide on an effective communication strategy. This leads to communication planning. The Communications Management Plan is prepared. This plan addresses how the information is needed and lays out the requirements of stakeholders, keeping in mind the needs of the project.
  In other words, here you plan for effective and efficient communication.
  The key output for this process is Communications Management Plan (CommsMP or CMP).
• Manage Communications process: Next, you distribute project information in accordance with the Communications Management plan in this process. Other than distribution of information, you also ensure that communication is timely, relevant, and appropriate.
  Here you ensure effective and efficient communication.
  The key output for this process is Project Communications, which includes project presentations, blogs, ad-hoc reports, and other communication artifacts.
• Monitor Communications process: Finally, we monitor the communications throughout the life cycle of the project. This ensures the changing information needs of the project (as it passes through various stages), as well as the needs of the stakeholders (as their engagement level changes along with the project life cycle) are met.
  This process ensures the optimal flow of information.
  The key output for this process is Change Requests.

The interactions among the processes of Communications Management KA is explained in this video [duration – 3m:31s], taken from my PMP Live Lessons. For the best experience, you may want go full-screen with HD mode and plug-in your earphones.

With this understanding of Communications Management KA, let’s move to a discussion of stakeholders and stakeholder management. 

The Stakeholders

A stakeholder is one who can positively or negatively impact the outcome or objectives of the project. The stakeholder can also be positively or negatively impacted by the outcome of the project. There is also a third aspect, and that is that a stakeholder is someone who perceives to be impacted by the outcome of the project. A stakeholder can be a person, group, or organizational unit—or even an organization. The term does not mean only a person. 

Examples of stakeholders are a project sponsor, a project manager, project team members, a funding organization, a performing organization, customer(s), user(s), potential customer(s), suppliers, government regulatory agencies, and media outlets, among others. 

Stakeholder Management–What Happens?

This KA has four processes, and they interact with each other as shown below. 

Below are the key points about interactions among these four processes.

• Identify Stakeholders process: In this process, we identify all possible stakeholders, analyze them, and document all needed information in a register–the Stakeholder Register, which is the key output of this process.
  In other words, identification of stakeholders and stakeholder engagement strategies happens in this process.
  
• Plan Stakeholder Engagement process: The Stakeholder Engagement Plan (SEP) is prepared. The plan documents appropriate engagement strategies to engage with the stakeholders throughout the life cycle of the project.
  In other words, documentation of stakeholder engagement strategies happens in this process. The SEP is the key output of this process.
• Manage Stakeholder Engagement process: Here we execute the engagement strategies, which we have defined previously. We communicate continuously with the stakeholder and use various interpersonal and team skills, as well as communication skills. We also address various issues raised by the stakeholders.
  You could say that execution of stakeholder engagement strategies happens in this process. The key output of this process is Change Requests.
• Monitor Stakeholder Engagement process: This is the last process of the Stakeholder Engagement KA, where we monitor the relationship with the stakeholder and adjust the engagement strategies as needs arise.
  In other words, monitoring and adjustment of stakeholder engagement strategies happens in this process. The key output of this process is also Change Requests.

The interactions among the processes of Communications Management KA is explained in this video [duration – 4m:11s].

Do note that while we are looking at the knowledge area of Stakeholder Management, the processes are with respect to engagement, and named so. This has been noted in the above video. 

The Overlap

To understand the overlapping that occurs between Communications Management and Stakeholder Management, you need to understand the content of each respective plan, (i.e. the CMP and SEP). I’ve noted a few below, and there are others.

Interaction Between Communication and Stakeholder Managements

In summary, the key plans and documents created within these two knowledge areas are:

1. Communications Management Plan (CMP)
2. Stakeholder Engagement Plan (SEP)
3. Stakeholder Register

The above artifacts will flow, cutting across the two knowledge areas and also other knowledge areas. Let’s look next at how, considering the twin areas of stakeholder and communications management.

Interaction Point 1

The stakeholder register is created in the Identify Stakeholders process. It lists requirements of all stakeholders, along with the power, interest, influence, and impact of the stakeholders. This register acts as an input to the Plan Stakeholder Engagement process to create the SEP. At this stage, it’s a high-level plan. Here, the stakeholder engagement assessment matrix is also prepared and is documented in the SEP. The engagement matrix informs on the planned and desired level of engagement with the stakeholders. There can be various engagement levels such as Unaware, Resistant, Supportive, Neutral, and Leading.

Interaction Point 2

A high-level SEP, in turn, acts as input to the Plan Communications Management process and its input is used to create the CMP. This is because stakeholder engagement strategies are primarily fulfilled through communications.

While preparing the CMP, the engagement assessment matrix, which was prepared earlier, will again come into play. However, here, the matrix used to plan for any additional communication requirements removes the gaps in engagement. Particularly for unsupportive or resistant stakeholders, a communication styles assessment is conducted.  The stakeholder communication requirements will be part of the CMP and can be referenced from the SEP.

Interaction Point 3

As you prepare the CMP, which comes as output of the Plan Communications Management process, it acts as an input to Plan Stakeholder Engagement process resulting in the creation of a detailed SEP. The communication strategies for stakeholder engagement will primarily drive the stakeholder engagement strategies. As you can see, both the CMP and SEP are iteratively prepared.

Content of the SEP can be repeated in the CMP, or it can ONLY be part of the CMP. Refer to the above table for the overlapping areas. 

Interaction Point 4

The execution of the CMP and SEP happens, respectively, in the Manage Communications and Manage Stakeholder Engagement processes. In both these processes, both the CMP and SEP act as inputs. Also, both the CMP and SEP are updated in the outputs of these processes. Feedback and conflict management are key skills used while managing communications and stakeholder engagement.

Interaction Point 5

The monitoring of the CMP and SEP happens, respectively, in the Monitor Communications and Monitor Stakeholder Engagement processes. In both these processes, both the CMP and SEP act as inputs, and both the CMP and SEP are updated in the outputs.

The stakeholder engagement assessment matrix that was created earlier is used in both the processes of Monitor Communications and Monitor Stakeholder Engagement. However, the context changes somewhat.

In communications management, the engagement matrix is checked to see if the communication strategies employed have been effective or not. In other words, it checks the effectiveness of project communications. If any adjustment is needed in communications or a revision is needed in stakeholder communication requirements, then change requests (CRs) should be raised accordingly.

On the other hand, in stakeholder management, the engagement matrix is checked to see if the desired engagement level of the stakeholder has been changed as compared to the planned engagement level. If an improvement is needed for change in the desired engagement level, then change requests (CRs) are raised. 

Interaction Point 6

Stakeholder identification is an iterative process. When a new stakeholder is identified or an existing stakeholder changes, the process of Identifying Stakeholders is again invoked. Both the CMP and SEP act as input to this process in such subsequent invocations of the Identify Stakeholders process, and both these plans are also updated in the output. There can be change requests (CRs) raised in subsequent invocations of the Identify Stakeholders process.

All change requests raised from both Stakeholder and Communications Management are analyzed, processed, and addressed through the integrated change control, where the change control board (CCB) decides on the approval, rejection, or deferment of the CRs. 

Practical Exercises

Now that we understand the processes, key inputs and outputs, interactions, and overlapping areas between Communications and Stakeholder Management KAs, let’s do a few exercises.

In the below figure, a set boxes or blocks is shown. Each represents a process–either in Communications Management or in Stakeholder Management. Do note that these processes can interact with many other processes in other knowledge areas with project plans and documents flowing across. However, for the sake of this example, let’s focus on these two “twin” knowledge areas.

I’ve put questions in each of these blocks. Can you answer them and replace the questions with process names?

The answer should be one of the processes that we saw earlier for Communications Management and Stakeholder Management KAs. All the change requests are addressed via integrated change control.

Scroll down only if you have answered!

. . . 

. . . 

. . . 

Your results should look as shown below.

 

Next, can you identify one key output for each process?

Do not scroll, before you have answered.

. . . 

. . . 

. . .

The final figure with all the key inputs and outputs across the processes is shown below.

As you can see, the flow of Stakeholder Engagement Plan (SEP) is highlighted in pink colored lines, whereas the flow of Communications Management Plan (CMP) is highlighted in orange colored lines.

The interactions among the processes of the twin knowledge areas are explained in this video [duration – 7m:37s], with additional explanations. It’s taken from PMP Live Lessons. 

Guidance for the PMP Exam

Questions related to Stakeholder Engagement and Communications Management can be tricky in the context of the PMP exam. Since the concepts are overlapping, they can be quite confusing for many PMP aspirants. I’ve outlined the interactions between the twins of project management taking into account a few tools and techniques, plans, and documents. There are a number of other plans, tools, and techniques, as well as documents, which will flow across. I believe, with the explanations provided in this article, you should be able to understand those flows, interpret what’s being asked, and answer the exam questions. 

What Went Wrong

Before I close, let’s revisit what went wrong in the story I shared at the beginning of this piece, where the CTO cancelled the project.

As you may have correctly guessed by this time, the CTO was not even identified as a stakeholder or documented in the project’s stakeholder register. Hence, the CTO’s power, interest, influence, and impact were not at all considered. Obviously, this in turn led to no stakeholder engagement powered by communications or otherwise. This failure led to the cancellation of the project, which no manager ever wants to see. The lesson to be learned is that, as a project manager, you should be very careful to navigate both communications management and stakeholder engagement proficiently.

If you have comments, suggestions, or views, please do share them below.

--

This article was first published by MPUG.com on 28th July, 2020. 

References:

[1] PMP Live Lessons - Guaranteed Pass or Your Money Back, by Satya Narayan Dash

[2] PMP 35 Contact Hours Online Course - Full Moneyback Guarantee, by Satya Narayan Dash

[3] Book - I Want To Be A PMP, The Plain and Simple Way, 2nd Edition, Satya Narayan Dash

[4] Project Management Body of Knowledge (PMBOK) Guide, 6th Edition, by Project Management Institute (PMI)

Understanding Point of Total Assumption (PTA) in Procurement Management

Let’s say you awarded a contract of $1M to a vendor to deliver a critical component for your project. The contract with your vendor is set up with a fixed price, but you have incentivized the contact to get a better-quality component with good performance. As the manager of the project, you are currently witnessing cost overrun for this component. The overrun has not yet hit the final, fixed price yet, but the vendor is saying it is likely to go beyond it.

Now, as the project manager, a number of questions are bound to come up. If it is not you asking, your sponsor(s) and/or key stakeholders may be, and the most likely questions at this time are as follows:

• How much will be owed if there is cost slippage?
• Will you pay when the cost slippage becomes more than $1M (or an amount above the contact price)? If so, to what extent beyond?
• At what point will you stop paying anything to the vendor and hold them responsible for further cost escalations? In other words, will you let the contract become a pure fixed price contract?

All these questions lead us to a concept known as Point of Total Assumption (PTA). To understand PTA, we will first look at some basics in procurement management. These are quite foundational and easy to understand, but important as we proceed further.

If you are aspiring to be a Project Management Institute® Project Management Professional (PMP)®, you will need to fully grasp this concept, as questions on PTA can come up on examinations.

Price, Cost, Profit, Incentives

In any contract, there are usually two parties, the buyer and the seller. The buyer obviously pays the seller to purchase an item. The buyer pays the price for the item purchased, but there are differences among price, cost, and profit.

The formula combining them all is this:

Let’s say you bought toothpaste for US$10. This is the price you pay to the seller, not the cost of manufacturing the toothpaste. The cost for the seller to manufacture the toothpaste may be US$8, and hence, their profit becomes US$2. In such a case, the following is true:

• Cost = US$8
• Profit or Fee = US$2
• Price = US$10

Of course, items like toothpastes are commodities, but these concepts of price, cost, and profit still apply.

Another term to consider in contract management is incentives. Incentives come into play because sellers are mostly focused on profit. Buyers are more focused on cost, schedule, quality, performance, etc. Incentives help bring together the objectives of the seller, as well as the buyer. An incentive motivates the seller to put forth the best effort designed by the buyer where efficiency is needed. Types of incentivized contracts can be:

• Fixed Price with Incentive Fee (FPIF)
• Cost Plus Incentive Fee (CPIF)
• Cost Plus Award Fee (CPAF)

Point of total assumption (PTA) is applicable for Fixed Price with Incentive Fee (FPIF) contracts. I will say more on that shortly.

Terms Related to PTA

First, let’s understand the terms of price, cost, and profit in the context of incentivized contracts. In the case of incentivized contracts, the terms used are target cost, target fee, and target price, respectively. You see, you are incentivizing the contract, and therefore, you are pre-pending the terms with the word, target!

Target price, target cost, and target fee are the ingredients of a FPIF contract, and with these, we derive a formula for PTA. We will see this shortly, but first I’ll define the terms we are considering:

• Target Cost (TC): The amount taken by a seller to create or develop an item.
• Target Profit or Margin or Fee (TF): It is the margin taken by the seller on top of cost.
• Target Price (TP): Target Price is very similar to price, but used for comparison with Final Price. It is the measure of success. The formula for TP is Target Price (TP) = Target Cost (TC) + Target Fee (TF).
• Buyer Share Ratio (BSR) or Share Ratio (SR): Sharing Ratio describes how cost savings or cost overrun will be shared between the buyer and seller. For example, 80%:20%. The first percentage is for the buyer, and the second is for the seller. For every $1 cost overrun, 80 cents will be paid by the buyer and 20 cents by seller.
• Ceiling Price (CP): Ceiling Price is the highest price the buyer will pay. In other words, profit for the seller at CP is minimal because by that time, a cost overrun has happened. The CP is typically 115% to 120% of the Target Cost.
• Point of Total Assumption (PTA): It is actually the point of total cost assumption or the cost beyond which the buyer will not pay a cent more to the seller.

With these basic definitions in mind, let’s get deeper into the definition of PTA, the formula to calculate the PTA, and an example of PTA hopefully providing further explanation.

PTA Definition

Point of Total Assumption can be defined as follows:

Point of Total Assumption is that point during cost overrun where the ceiling price of a fixed price incentive (FPI/FPIF) contract has been reached. At this point, the FPI contract converts to a firm-fixed price (FFP) contract.

To elaborate further, these statements are characteristic of PTA:

• PTA comes into play during cost overrun of a contract.
• When we talk of PTA, it is actually associated with cost. Hence, a default PTA term can also be called “PTA Cost” or even “Point of Total Cost Assumption.”
• At the PTA cost, the ceiling price (CP) is reached. Hence, “PTA Cost” is also known as “Ceiling Cost.”
• With cost overrun and before PTA, there can be various sharing ratios between the buyer and seller, as negotiated. Beyond PTA, the sharing ratio (or buyer sharing ratio) is ALWAYS 0%:100%.
• Beyond PTA, the FPIF contract converts to a firm fixed price (FFP) contract. After all, at PTA cost, the ceiling price is hit, and beyond this price, the buyer won’t pay anything at all.

PTA Formula

As we know, PTA is for cost overrun. This cost overrun happens when the cost is obviously above the target cost. Hence:

Cost overrun at PTA = PTA cost – Target Cost

At PTA, the buyer’s share of cost overrun will be:

(PTA Cost – Target Cost) × BSR

The total price paid by the buyer to the seller will include this share amount, too. Hence:

Price at PTA = Target Cost + Target Fee + (PTA Cost – Target Cost) × BSR

We have seen earlier when exploring the basics of procurement management that:

Target Price = Target Cost + Target Fee

Using this in the above equation, we will get:

Price at PTA = Target Price + (PTA Cost – Target Cost) × BSR …. [1]

We also know that when PTA cost is hit, the ceiling price is reached. In other words, when PTA is reached in the cost curve, the price curve will hit the ceiling price (PTA price equals ceiling price). Hence:

Price at PTA = Ceiling Price …. [2]

Considering both equation [1] and equation [2]:

Target Price + (PTA Cost – Target Cost) × BSR = Ceiling Price

=> (PTA Cost – Target Cost) × BSR = Ceiling Price – Target Price

=> PTA Cost – Target Cost = (Ceiling Price – Target Price)/BSR

=> PTA Cost = (Ceiling Price – Target Price)/BSR + Target Cost.

“PTA Cost” as we know is the default PTA term. Hence, the formula for PTA will be:

An Example

Let’s consider an example to get a better hold of the PTA concept. Remember, when I am saying PTA, by default, I mean “PTA Cost.”

Let’s say that in a contractual agreement, the buyer and seller agreed to a cost of $300,000 and a profit of $30,000. The buyer has informed that the ceiling price will be $360,000. Beyond the target cost, the sharing ratio between the buyer and seller will be 60%:40%.

What is the PTA? To solve this question, first, we need to assign values to the various components:

• Target Cost (TC): $300,000
• Target Fee (TF): $30,000
• Target Price (TP): $300,000 + $30,000 = $330,000
• Sharing Ratio (SR or BSR): 60:40
• Ceiling Price (CP): $360,000

Now, the PTA is as shown (by applying the formula):

= [ (C.P – T.P) / BSR] + T.C

= [ ($360,000 – $330,000) / 0.6] + $300,000

= [ ($ 30,000)/0.6] + $300,000

= $50,000 + $300,000

= $350,000

In this case, the point of total assumption (PTA) or PTA Cost comes as $350,000.

Next, let’s see how PTA Price equals the Ceiling Price. After all, this is what I’ve outlined as the definition of PTA.

Cost overrun at PTA = PTA Cost – Target Cost, so:

= $350,000 – $300,000

= $50,000

The buyer’s share in this cost overrun is as follows:

= 60% × $50,000

= $30,000

The seller’s share in this cost overrun is:

= 40% * $50,000

= $20,000

Hence, the Price at PTA = Target Price + Buyer’s share, so:

= $330,000 + $30,000

= $360,000

The above value equals the ceiling price or C.P. In other words, at PTA or PTA Cost, the ceiling price has been met. You can also say you’re at ceiling cost when the ceiling price has been met.

Another thing to note is this: Cost overrun has already happened when the cost crossed over the $300,000 threshold, or the target cost, in our example. Of course, with cost overrun, the profit margin will decrease.

Now, the questions that are likely coming to mind may be:

• Is there any profit at PTA?
• Does profit become zero at PTA?

Let’s calculate the profit!

Profit at PTA = Price at PTA (or C.P.) – Cost at PTA, so:

= $360,000 – $350,000 = $10,000

This is not the initial target fee of $30,000, but a reduced fee of 10,000. So, we have some profit at PTA, although it is much reduced than the initial target profit.

Significance of PTA

Now that we know how to calculate the PTA, let’s check the significance of PTA by using the above example. With this, many misconceptions related to PTA will be dispelled.

1. At PTA, the profit is not equal to the target profit before. Rather, at PTA, the profit or margin is usually reduced.

As we saw in our example, at PTA, the margin is reduced from$30,000 to $10,000. Hence, while plotting a graph for PTA, if you see that the margin is kept the same (as before the PTA is reached), the graph is wrong. In my experience, many project managers use such wrong graphs.

The profit at PTA can be a reduced by one, zero, or negative. This is dependent on the BSR. Obviously, at a higher BSR, profit will be more, as compared to a lower BSR.

2. From the point of cost overrun till PTA, the sharing ratio will be the BSR. Beyond PTA, sharing ratio becomes 0%:100% (effectively irrelevant).

As shown in the example, from the point of cost overrun till PTA, the sharing ratio is 60:40. That is, for every $1 overrun, the buyer will pay 60 cents whereas the seller will pay 40 cents. Beyond PTA, the buyer won’t pay anything more, hence the sharing ratio becomes 0:100. For every $1 cost overrun, the seller’s profit decreases by $1, or said another way, loss increases by $1.

3. At PTA, the FPIF contract becomes a FFP contract.

The seller assumes all responsibility for further cost overrun beyond PTA. Incentives no longer apply. Hence, the contract becomes a firm fixed price (FFP) contract.

4. PTA incentivizes the contract and asks the seller to put forth a better performance.

For every one dollar overrun beyond PTA, the seller will pay (or lose) that dollar. This money will come from the seller’s margin. Therefore, PTA incentivizes the contract and asks for the seller to control cost. From the point of view of the seller, PTA can be considered to be the inflection point.

5. PTA doesn’t usually apply to a Cost Plus Incentive (CPIF) contract, rather it’s used in Fixed Price Incentive Fee (FPI/FPIF) contract.

As we have seen, the calculation of PTA requires a ceiling price (CP). The ceiling price is not set in a CPIF contract, so PTA is not usually set or calculated in CPIF contracts. Rather in CPIF contracts, a Range of Incentive Effectiveness (RIE) is usually considered.

Graphical Representation

The concept of PTA can be explained graphically. Graphical representation is very helpful because we are able to pictorially represent various incentive scenarios.

Following our example, when we plot a graph for PTA in a cost-profit curve, it looks as shown below. The graph is drawn with the help of MS Excel software.

As shown, we have the cost depicted in the X-axis, whereas the profit is shown in the Y-axis. This graph has two lines: the “Sharer Line” and the “Ceiling Line.” The sharer line meets the ceiling line at PTA.

In the beginning, the target profit or margin is $30,000 with the target cost being $300,000. This is represented with the yellow dotted line. When cost overrun happens, the profit margin starts decreasing.

When we reach the PTA, we reach an inflection point and the ceiling line takes over. This line is utilized because, at PTA, the ceiling price has been reached. As you can see, there is still some profit of $10,000. The ceiling price of $360,000 is reached at the PTA cost (or ceiling cost) of $350,000. This is represented in the red dotted line.

This curve also explains how PTA incentivizes the contract. The buyer is willing to share a certain amount of cost overrun based on BSR, but beyond PTA, as the ceiling price is hit, the seller is fully responsible. As we have seen before, from this point onward the contract becomes an FFP one. If further cost overrun happens, obviously, the seller will incur losses and they will be a steeper!

Analyzing PTA - Video

I’ve put together a video depicting a graphical interpretation of PTA. It is taken from my PMP Live Lessons, and uses our example showing how PTA is used in cost overrun. I also plot the data for every $10,000 cost overrun in MS Excel. My video [Duration: 5m:29s] shows how the graph is plotted and the significance of PTA along with the ceiling line and sharer line.

For best experience, you may want to go full-screen HD and use earphones.

A Note on the PMP Exam

If you are an aspiring PMP, you may be wondering about the kind of questions you would be getting on PTA in the PMP examination. The questions are likely to come, but will be easy to solve if you have understood the concept I’ve outlined here well.

It’s always better to assume with facts than blind or total assumption. The concept of PTA nudges us in that direction—assume, but with data and facts.

You may also like:

• Range of Incentive Effectiveness (RTE) in Procurement Management
• Range of Incentive Effectiveness - How to Derive the Formulas?

--

This article was first published by MPUG.com on 19th May, 2020. 

References:

[1] PMP Live Lessons - Guaranteed Pass or Your Money Back, by Satya Narayan Dash

[2] PMP 35 Contact Hours Online Course - Full Moneyback Guarantee, by Satya Narayan Dash

[3] Book - I Want To Be A PMP, The Plain and Simple Way, 2nd Edition, Satya Narayan Dash

[4] Project Management Body of Knowledge (PMBOK) Guide, 6th Edition, by Project Management Institute (PMI)

Troubleshooting in Lean-Agile Development

Many project managers utilize a Lean-Agile approach when there is high change or churn in project requirements, significant lack of clarity in scope, high complexity to their projects, and/or a larger number of risks associated with such. As these approaches have gained wide acceptance in a number of industry verticals, there has also been an increase in the problems being reported.

In this article, we will explore some of the practical problems faced by Lean-Agile practitioners during development of a new product or service and/or the building of a solution. When facing these challenges, Lean-Agile approaches have certain inherent or built-in mechanisms and execution best practices.

At this stage, I want to inform that problems and subsequent troubleshooting challenges the occur in a Lean-Agile approach can be divided into two broad categories:

• Iteration-based
• Flow-based

Two Lean-Agile Types

Earlier, in one of my articles, I had mentioned that Agile is both iterative and incremental in nature. We also previously explored the differences between iterative and incremental development with an example. I’m using the Lean-Agile approach here because many aspects of Lean are becoming increasingly a part of Agile (i.e., pull system, just-in-time planning, flow, visualization, waste elimination, error-proofing, and small batch-size, among others).

When I referred to the two Lean-Agile types, the categorization is based on an incremental delivery aspect. Let’s understand these two types a bit more.

Iteration-based Lean-Agile

In this type, the iterations are prescribed. Each iteration is timeboxed to the same size. Each timebox results in a working a set of tested features. The team pulls the item from a backlog of features, decides which can be delivered at the end of an iteration and usually provides an increment at the end.

An example of this type can be the Scrum framework. 

As shown in the above diagram, we have a number of iterations, and each iteration length is timeboxed to the same duration. 

Flow-based Lean-Agile

In this case, the iterations are not prescribed. Rather, the emphasis is on flow while having incremental delivery. The team pulls item from a backlog of features based on their capacity, and it’s not based on an iteration timeline. When the feature is complete, it can be delivered. It’s usually based on a cadence.

The number of features that can be taken on is based on a work-in-progress (WIP) limit. An example is the Kanban method, which has its original roots in Lean manufacturing.

As shown in the above figure, there is no regular timeboxed iteration, but incremental delivery can happen in cadence.

With these fundamentals in mind, let’s now explore the problems faced by Lean-Agile teams. In some cases, I’ll be using the terms Agile and Lean-Agile interchangeably. 

When the Product Owner is not Available Full-Time for the Team

This problem is predominantly seen in geographically distributed teams, where developers are working in one continent, but the product owner (PO) is operating from another. The product owner, while closer to the market, manages multiple products. This results in constraints because the PO is not fully dedicated to one team or present with them.

Any Lean-Agile team needs strong product ownership. This is crucial for success of the team and the product being built. The PO needs to be committed to the long-term objective(s) of the product (Product Goal or Vision) and continuously participating in the team’s project activities.

To resolve the problem of a PO being only partially available for the team, ensure that the PO is full-time, irrespective of the size of project or his/her location. An absence of this can lead to handicapped team performance and may even little value delivery.

To reaffirm, one of the principles of the Agile Manifesto is:

Business people and developers must work together daily throughout the project.

The PO can be the business owner or in some other structure, the PO can be paired with the business owner directly or via the Agile Project Management Office (PMO).

Nevertheless, the PO should be involved daily with the team members, not on a part-time basis. The PO is the team member who is responsible for the business success of the product. He/she is also accountable to the business. 

When There is too Much Complexity in Product Architecture

As noted in the beginning, Agile approaches are designed to tackle complexity, but sometimes project complexity can be too high and one may not know where to begin.

In such a case, one can use:

• The concept of Sashimi, or
• Take a tracer bullet approach

Sashimi is a Japanese word particularly used within the context of food. In Japan, a delicacy is thin slices of raw fish and sometimes served with rice—it’s called Sashimi. Each slice of fish is complete in itself, as well as tastes similar to other slices. This concept can be applied in Agile.

When using Lean-Agile approaches, we develop functionality that cuts across all the layers of a product, which has multiple layers – say front end, middleware, and backend. We are not developing the backend first, or the middle part or frontend. Rather, we deliver functionalities by cutting across all the layers.

The tracer bullet concept is based on the idea of firing in the dark! When you fire a gun in the dark, it’s difficult to aim due to the lack of light. However, when the path of a bullet is lit up (tracer bullet), you can see the trail and use it to inform your next aim. In other words, the tracer bullet helps to improve your aim for subsequent firing.

You can say, a tracer bullet of functionality is very similar to a Sashimi approach. We see the path of a bullet passing through all the layers or a functionality consisting of all the layers of a product. We are shown the path to build other functionalities. 

When Inaccurate Estimation Results in Delayed Delivery

This is another problem frequently seen irrespective of industry verticals. Developers, with all due respect to them, are generally optimistic people. The trouble is that when there are high uncertainties or complexities in a project, optimism may not be your best friend.

Estimates are often inaccurate because they are made in absolute numbers. For example, it will take five days to complete a feature/backlogged item or six hours to complete an activity.

One way to resolve this challenge is to use story points for estimation. Story points are relative estimation techniques and have unitless measure. Story points are relative estimates because they compare size, complexity, difficulty, and risks among other items being estimated.

To utilize story points, estimate the tasks (i.e., stories decomposed into tasks) into ideal hours. While the usual time unit used is eight hours a working day, it’s not always the case because of other activities such as meetings, unforeseen customer escalations, and interruptions, among others. When estimating using ideal hours, the time consumed for all non-productive, but necessary work is not considered.

This is depicted in the below figure. Ideal hours are considered here to be four/day. 

When Backlog Items are Insufficiently or Improperly Refined

Backlog refinement is a common practice and widely used in both iteration- and flow-based Lean-Agile types. The team starts off on the iteration or can take the item to the flow of work.

Let’s consider an example of an unrefined backlogged item: As a user, I can manage my settings, so that I’ll have the setting related information.

This is not exactly a small user story, but a very big one. In fact, this story can be decomposed further into three:

• As a user, I can manage my address details.
• As a user, I can set or reset my password.
• As a user, I can set my email preferences.

The address part alone comes with multiple parts, and a user has to utilize multiple operations to manage it. For example, add, edit, and delete. For this purpose, the product owner or product manager needs to have a good understanding of (user) stories, as well as refinement techniques.

To address this issue of improperly refined backlogged items, one can use the Definition of Ready (DoR) skill. Definition of ready is a checklist, which needs to be checked off step by step to see if the team has all the needed information before working on the item. DoR can be used before the beginning of the iteration or before taking a work-item into the flow of work. 

When a Deluge of Defects Occurs

There are many scenarios in which this can happen:

• Team is new to development
• The team has a lack of strong engineering practices, among others.

When the team is new to Lean-Agile development, it’s always a good idea to have training to understand the values and principles of Agile. The most difficult part, however, is the internalization of these values and principles (i.e., applying them daily during the project work). With a correct Agile/Lean coach, this understanding will be needed to sustain the project.

In addition, good engineering practices are not only necessities, but vital to stop deluge of defects and provide good-quality products. Some are noted below.

High test coverage and testing at all levels: You can implement high test coverage both at the system level, as well as unit test level, with automated test cases. The team should have testing at various levels, such as:

• Unit testing: Testing done at the lowest level.
• System testing: End-to-end testing of the full system or product.
• Smoke testing: Lightweight testing to ensure workability of the most important parts, and others such as black-box testing and regression testing.

Refactoring: Many associated refactoring is done within the context of software, but it can very well be applied to any product work. In fact, it’s a product quality technique with which you improve the design of the product through maintainability, but without changing the external behavior.

Simply put, with refactoring, you can change the internals of a product without changing the external behavior. With continuous refactoring, technical debt (i.e., legacy debt due to deficiencies in design, documentation, code (or product work), associated third party tools) is gradually reduced and defects are kept in check.

Continuous Integration: Any (product) increment given at the end of the iteration or continuously as in flow-based Lean-Agile, should be incorporated into the whole product. Post integration, the product still should work as intended.

Test first, develop next: In XP lingo, it’s called test first programming and in common Agile parlance, one can call it test-driven-development (TDD). Automated tests are written before doing the product work or creating the product. Next, work (or coding is software) is done to meet this test. This results in a built product with lesser defects.

Collective Ownership: In XP parlance, it’s usually referred to as share code. This concept says that the product work is owned by everyone in the team. You can also say, product quality is everyone’s responsibility. 

When Rework or Incomplete Work Happens

While working with an iteration-based Lean-Agile approach, an increment can be achieved on a cadence or on-demand. One the principles of the Agile Manifesto tells us this:

Our highest priority is to satisfy the customer through early and continuous delivery of valuable software (or product).

If increments are not being delivered early and frequently, then the main purpose of going with a Lean-Agile approach is lost.

When the team delivers an increment, it must be fully “done” or complete. For this purpose, Definition of Done (DoD), an Agile artifact is used. Definition of done is primarily a checklist of items, which needs to be crossed-off, before a backlogged item or a story is considered finished.

To have proper work completion, the DoD should be exhaustive and clear. A sample DoD is shown in the below table. Only when a backlogged item has cleared the checklist of items listed in the DoD, is the work considered to be complete. Within this context, the issue of rework and/or incomplete work is addressed.

When Product Demonstrations or Reviews are Dysfunctional

While retrospectives are considered to be the most important practice in a Lean-Agile approaches, a close cousin is the practice of product demonstration or reviews. This is a very important event because Lean-Agile is fundamentally about value delivery to customers early and frequently, getting feedback, and customer collaboration – all of which happens in a demonstration or review collection.

While new teams can have failures during demonstrations, it’s also seen for experienced teams. Here are some situations that may occur:

• The (product) increment is not behaving as expected
• Features promised have been missing the demo
• The product crashes, or
• Worst of all – the PO and key stakeholders don’t accept the increment

Multiple dysfunctional product reviews can have a serious impact on the trust customers have in the team and equally, the self-confidence of the team who is delivering. To resolve this challenge, several things can be done.

Prepare early before the actual meeting: You should have a set of items or checklist of items prepared prior to the review or presentation. Not only should the team should take some time preparing for the meeting, but for an iteration-based type, they should use a checklist similar to the sample template below. 

Next, while running the meeting, document the decisions being made. This event, as noted before, also involves getting feedback from the customer/stakeholders and incorporating that feedback subsequently. With an eager clientele, a number of enhancements, new stories, or workflows will come up and it’s important that you note them.

Towards the end of the meeting, ask for acceptance on the increment. The acceptance may be conditional or there may be a time lag, before formally being accepted, but do ask for this, as it allows the increment to be released. This also tells the team that the increment delivered has met the definition of done (DoD).

Above all, never cancel the meeting. Sometimes it’s possible that you have very little to show or even that you know your product increment may crash. Still, go ahead with this event, as you will get feedback, and can make course corrections, if needed.

—

There are a number of problems or issues that can come-up while implementing a Lean-Agile development approach. In this article, I’ve outlined some of the challenges along with possible solutions.

What are the problems that you face? What approaches do you take to meet these challenges? Let me know in the comment section below.

--

This article was first published by MPUG.com on 9th March, 2021. 

 

References:

[1] Course: ACP Live Lessons – Guaranteed Pass, by Satya Narayan Dash

[2] Book: I Want To Be An ACP, The Plain and Simple Way, by Satya Narayan Dash

[3] Agile Practice Guide, by Project Management Institute (PMI)