Program Management: Scenarios and Rationale for Document Selection

As part of a volunteer work in guiding the distinction between project management and program management for their specific contributions within a medical affairs group, I saw questions arise between a business case and a charter. Unrelated to this body of work that I was doing and as part of the management training and independent career-coaching that I do, I felt there was ambiguity between scope statement and charter.  

Previously, I have defined the five essential management documents (Rajagopalan, 2020). So, please consult them for a quick refresher. Here, I am using this blog to demystify the business case, program charter and project (or component) charter, roadmap and the scope statement with a few important scenarios. 

Scenario 1: Stakeholders question the rationale for undertaking an initiative 

Document:  Business Case

Rationale: The business case is a justification document for the expected benefits, created during the program formulation sub-phase within the program planning phase. In the case of a program component, it is part of the component initiation and planning sub-phase for the component in the program delivery phase.

Scenario 2: Steering committee is evaluating the program/project to determine program continuation

Document:  Business Case

Rationale: The business case is a justification document for the expected benefits. That is the primary document the steering committee uses to determine if the benefits are being met. They may also consult the benefits register (this is called the value document) to determine if the benefits have been met according to the planned expectations at the phase gate or stage gate reviews to determine if the program should continue or not.  

Scenario 3: Stakeholders must reprioritize program when the market demands or priorities have shifted considerably

Document:  Business Case

Rationale: First, let us look at the root causes. Say, another competitor has delivered the benefit already at a price that the current program can no longer deliver value for the customer and the benefit. The ongoing continuation of the program can no longer be justified (hence business case). Alternatively, the market priorities (e.g.; pandemic, GDPR regulation) have shifted another program to be more justified than this program (the opportunity cost). The steering committee can kill the program completely in the former case or park the program temporarily reassigning resources to the new program.   

Scenario 4: Stakeholders are unsure about alignment of benefits with the business strategy to commit their resources (people, time, money)

Document: Charter (During Program Definition) 

Rationale: The charter is the authorization document that outlines the high level scope (note, high level; not detailed scope) as well as the resources required to deliver on the benefits identified in the business case. The charter is expected to outline this alignment, commitment, and engagement required for getting stakeholders' support. This is why I call the charter ACEs (alignment, commitment, engagement) stakeholders. So, anytime a stakeholder questions the alignment, commitment, or engagement, go to the program charter or component charter as appropriate. 

Scenario 5: New Stakeholders come to a program. They would like to get a list of initial dependencies and risks identified impacting their delivery. 

Document: Charter

Rationale: As the authorization document, the charter is expected to identify the initial list of assumptions, constraints, dependencies, risks, and known issues. While they are high-level, these are the "initial" set. So, a good starting point is only the charter. Subsequently, if they want to delve deeper they can review benefits management plan, integrated project management plan, assumptions or constraints log (assumptions, constraints), program roadmap, product backlog or project schedule (dependencies), benefit register and risk register (risks), or issue log (issues). Considering the stakeholders are "new" and they want "initial" information, starting with the charter is better.  

Scenario 6: Some risks are becoming more pronounced or secondary risks have materialized. Stakeholders need to consult issuing the change control.

Document: Charter

Rationale: As part of ensuring ongoing ACE, the processes towards the change control (or governance) is mentioned in the charter. The detailed steps may be listed in the project or program governance plan, which is a subsidiary document. So, it is better to start with the charter that may guide on the processes to follow, reporting requirements, authority of the component manager, program manger, and the steering committee. 

Scenario 7: Stakeholders want to understand when certain benefits can be delivered and/or ascertain how changing the order of delivering certain capabilities can impact the overall program 

Document: Roadmap

Rationale: The roadmap gives the high-level schedule with milestones and deadlines for benefit delivery, transition, and sustenance. When risks materialize (that means they are issues now) and stakeholders want to understand timeline for benefits delivery and the impact assessment for any changes to the schedule, the roadmap is the first option. The next document to review is the benefits management plan as it serves as the baseline document for the program benefits delivery. Subsequently, they can delve deeper into the other subsidiary documents as needed.  

Scenario 8: During program delivery phase, new or existing stakeholders would like to get clarity on the deliverables, direct or lateral dependency among requirements or design considerations for some of the requirements.  

Document: Scope Statement

Rationale: Questions around the deliverables to be produced, capabilities to be delivered, or outcomes to be integrated are very detailed. The design considerations for the requirements are frequently detailed - whether it is business, architecture, or technical dependency. Anytime specific details are relevant much more than high-level scope, then, the focus shifts from 'charter' to 'scope statement.' The scope statement can be the project schedule, Gantt chart, network diagram, release and iteration backlog, etc. If the question is more around the benefits and their realization, then benefit management plan (baseline document) or the benefits register (value document) are relevant. More granular focus may be at the definition of done (DoD) spanning completion (tasks) and acceptance criteria (test cases) covering performance qualification (PQ), operational qualification (OQ), and installation qualification (IQ).    

I hope these scenarios and the rationale help you with the importance of selecting the right documents. 

References

Rajagopalan, S. (2020). Five essential documents in project and program management. Retrieved from https://agilesriram.blogspot.com/2020/11/five-essential-documents-in-project-and.html

Qualifying Benefits in Benefits Management

As I was delivering a Program Management certification training, there were some discussions around the phrase, "Qualify Benefits" (Project Management Institute, 2024). Now, I have already blogged about what benefits mean (Rajagopalan, 2020) even within the context of strategic project management (Rajagopalan, 2021) and in a few follow-up discussions, it was clear to me that the action-oriented adjective, "Qualify," needs some explanation. 

"Qualify benefits" in the context of program benefits management refers to the process of defining, assessing, and validating the potential benefits that a project or program is expected to deliver. This involves several key steps. Let us consider an example of a company implementing a new customer relationship management (CRM) system as we identify some activities for each step listed here.

1. Identification of Benefits:

• Strategic Alignment: Ensure that the identified benefits align with the organization’s strategic goals and objectives.
• Stakeholder Input: Engage with stakeholders to gather their perspectives on potential benefits, ensuring that all relevant benefits are considered.

For the CRM system, the potential benefits include improved customer satisfaction, increased sales, and enhanced data analytics capabilities.

2. Definition of Benefits:

• Clear Description: Clearly describe each benefit, including what it is, who will benefit, and how it will be realized.
• Measurability: Define how the benefit will be measured. This often involves establishing key performance indicators (KPIs) or metrics.

The CRM system must define benefits like the a) improved customer satisfaction measured by Net Promoter Score (NPS), b) increased sales measured by revenue growth percentage, and c) enhanced data analytics capabilities measured by the reduction in time taken to generate reports.

3. Assessment of Benefits:

• Quantitative Assessment: Where possible, quantify the benefits in financial terms (e.g., cost savings, revenue growth) or other measurable units (e.g., time saved, customer satisfaction scores).
• Qualitative Assessment: For benefits that are difficult to quantify, provide a qualitative assessment (e.g., improved employee morale, enhanced brand reputation).

The CRM can perform this assessment either qualitatively or quantitatively or a combination of both approaches. The quantitative approach may assess the increased sales by 10% within the first year. The qualitative approach my assess the improved decision-making capabilities through better data insights.

4. Validation of Benefits:

• Feasibility Analysis: Assess whether the benefits are realistically achievable given the resources, timeframes, and constraints of the project or program.
• Risk Assessment: Identify and evaluate risks that might impact the realization of the benefits and develop mitigation strategies.

Validation may employ multiple approaches as well. For example, the CRM may validate feasibility (technical, operational, environmental) feasibility. An example could be validating that the CRM system integrated with existing systems and that training plans are in place.

Another validation is the ongoing risk management throughout the benefit lifecycle. Example risks may involve identifying potential resistance from sales teams and planning for change management initiatives. Quality is a function of risk (Rajagopalan, 2023b) and so it is critical for one to consider multitude of risks for risk driven development. 

5. Documentation and Communication:

• Benefits Register: Document all identified and qualified benefits in benefits register or benefits realization plan.
• Stakeholder Communication: Communicate the qualified benefits to all relevant stakeholders, ensuring transparency and buy-in.

The CRM documentation may involve creating a benefits realization plan outlining these benefits, how they will be measured, and who is responsible for them. The CRM documentation plan may also deeply engage in the transition (Rajagopalan, 2023a) and sustenance plan so that component transition can continue with benefit sustenance in operations. 

6. Establishment of Monitoring and Evaluation Framework:

• Tracking Mechanisms: Set up mechanisms to monitor the progress towards achieving the benefits throughout the lifecycle of the project or program.
• Review and Adjust: Regularly review the benefits realization progress and make necessary adjustments to ensure that the benefits are on track to be realized.

Examples of tracking systems for a CRM may involve regularly tracking NPS scores, revenue growth, and reporting times. Similarly, the review and adjust approaches may pivot around the monthly review meetings to assess progress and address any issues.

By qualifying benefits early and continuously, organizations can ensure that their projects and programs are aligned with strategic goals, have clearly defined and achievable outcomes, and provide measurable value to stakeholders.

References

Project Management Institute (2024). The Standard for Program Management. 5th Edition. Newtown Square, PA: Project Management Institute.

Rajagopalan, S. (2020, August 14). Lessons learned on Strategic Project Management from a Dental Visit. Retrieved June 16, from https://agilesriram.blogspot.com/2020/08/lessons-learned-on-strategic-project.html

Rajagopalan, S. (2021, June 14). How different is Strategic Project Management? Retrieved June 16, 2024, from https://agilesriram.blogspot.com/2021/06/how-different-is-strategic-project.html

Rajagopalan, S. (2023b, March 10). Quality is a function of Risk. Retrieved June 16, 2024, from https://agilesriram.blogspot.com/2023/03/quality-is-function-of-risk.html

Rajagopalan, S. (2023a, October 23). TREAD carefully to transition benefits. Retrieved June 16, 2024, from https://agilesriram.blogspot.com/2023/10/tread-carefully-to-transition-benefits.html

PICTURE your way to understand Program Manager responsibilities

Frequently, people keep asking what the role and responsibility of a project or program manager is. While the project manager focuses on generating the outcomes contributing to the benefits for the organization, the program manager focuses on integrating the benefits towards the strategic value. Therefore, both the project and program manager should understand the strategic focus of their role in tailoring their responsibilities. 

As the program manager is also held accountable for the operations as part of the benefit management, the primary value the program manager offers is their readiness to adopt strategies to optimize the delivery of benefits to the performing or sponsoring organizations.

Have you heard of the saying, “Picture speaks a thousand words?” So, I used PICTURE as an acronym to describe a few key responsibilities of the role. 

P – Program Definition. This covers the key elements of formulating and planning the program.

I – Interdependencies among program components including operation
C – Communication with the right stakeholders at the right level at the right time facilitating governance

T – Tailor the program management activities and processes by evaluating the outcomes against planned benefits and adapt as frequently as necessary.

U – Comfortable around Uncertainty 

R – Resolve challenges and constraints using a proper governance structure

E - Empower team by enabling them to deliver

How do you relate to this acronym to understand the program manager responsibilities?

Executives need to understand Program & Project Management

As a firm believer in continuous improvement, I have always been monitoring the external environment to find new trends and equip myself with this knowledge. One of these interests was understanding more about Program and Portfolio Management. Although I had executed successfully a few program initiatives and been part of the strategic portfolio management, my interest to pursue Program Management certification became strong with an announcement of Project Management Institute on Program Management Improvement and Accountability Act (President Barack Obama Signs the Program Management Improvement and Accountability Act, 2016). It was then I made a commitment to pursue PgMP certification which I passed successfully this month.

During the pursuit of this journey, I felt the inexorable gap in people in strategic leadership positions not truly understand the value of Project Management - let alone the program management. Many viewed program management that focuses on benefits delivery and benefits sustenance the same as project management that focuses on unique product or result. Mark Langley, the CEO of Project Management Institute, claimed how the lack of understanding project management culture among chief executives such CFO leads to money being wasted on projects failing to meet their strategic objectives or not having the appropriate structure for strong project management culture is a recipe for organizational failure (Langley, 2015).

If the culture of project management that touches on scope, schedule, cost, quality, risk, stakeholder, procurement, human resources, communication, and integration can't address servicing customers, delivering good quality products, and retaining talent, what other professional discipline can be part of the operational excellence that touches on all areas of middle management to address customers, products, and people? It is no wonder Ireland (2006) claimed almost ten years back why executive management needs more project management skills than technical skills or delegation skills to effectively lead the organization. Several years later, Gale (2012) reports on a few organizations as a case study to support the case for increasing role of project management.

As I went through the program management framework that lays the foundation for strategic benefits, coordinated planning, complex interdependencies, deliverable integration and optimized pacing, the role of program management in benefit delivery was conspicuous. The focus of programs not only dealt with incremental benefits delivered through component projects but also on the consolidated benefits through structured governance to resolve quin constraints aligning the program efforts to organizational direction, identifying and responding proactively to risks across the projects and into operations, and leading, coordinating and collaborating multiple work streams. When such a program level leadership role is not identified to go through a program delivery framework, lots of productivity loss becomes transparent to the organizations.

Organizations today are changing dramatically. The need to respond to changes rapidly is an essential fabric to maintaining market share amidst the political, economic, societal, technical, legal, environmental, ethnic, and demographic changes and competitive edge. So, the need for executives to understand the project, program, and portfolio management is not a luxury but a necessity.


References

Gale, S.F. (2012). The case for project management. PMI Executive Guide. Retrieved August 31, 2017, from https://www.pmi.org/-/media/pmi/documents/public/pdf/publications/pmi-executive-guide.pdf

Irelend, L. (2006). Executive Management's role in project management. International Project Management Association. Retrieved August 31, 2017, from http://www.ipma-usa.org/articles/ExecRoles.pdf

Langley, M.A. (2015, August 6). 3 Things CFOs Should Know about Project Management. CFO.com. Retrieved August 31, 2017, from http://ww2.cfo.com/business-planning/2015/08/3-things-cfos-know-project-management/

President Barack Obama Signs the Program Management Improvement and Accountability Act (2016, December). Project Management Institute. Retrieved August 31, 2017, from https://www.pmi.org/about/press-media/press-releases/president-barack-obama-signs-the-program-management-improvement-and-accountability-act 

Client Management: The Influence of Powerful Questions

I had a wonderful opportunity to be with one of my mentors in three different client settings. I am sure people in project, account, product, and sales setting have gone through the stakeholder management aspects. Whether it was a formal status meeting, casual hallway conversation, informal dinner meeting, or an internal project evaluation meeting, I found it very inspiring to see how my mentor was skillfully weaving these questions to eliminate ambiguity and establish a solid business relationship. 

While I added a few of my own color from account and project management, I felt such a strong reinforcement of these questions that I felt compelled to package these questions for the community at large. So, here goes the list. Feel free to add - focus however on strategic account & project management and not bury with technical aspects of platform and feasibility here!

1. What are your goals and objectives? Are you interested in market expansion, market penetration, or both? What's your timeline? 
2. What are your challenges to meeting these goals and objectives? How would addressing these challenges benefit you and your organization financially?
3. What are the profiles of stakeholders that you are looking at to satisfy with your campaign?
4. What types of population are you planning to target? Why are these targets important to you?
5. What types of channels are you planning to use? What data points do you have to support these channels to effectively reach your population? 
6. How much of your budget are you willing to spend on these channels? What's your exit strategy?
7. How would meeting these goals and overcoming challenges enhance the competitiveness of the product?
8. If you were to meet your goal, what would this mean to you? 
9. If these challenges are not met or goals accomplished, what does this mean to you?
10. What's an example of a successful campaign or meeting? What data points are you looking at to evaluate the effectiveness of the campaign or efficiency of the meeting? 
11. What's your communication style? 
12. What's your risk profile? Are you adventurous and creative to try new things? 

Risk Managemeent: Key to Advancing into Program Management

The Project Management Institute (PMI) introduced the principles behind program management with a critical focus on maximizing benefits.  Often project management focuses on controlling scope and schedule using available workflow tools that they miss an important component of not understanding the value of the project on a larger scale.

The question to ask here is what role did the project play in increasing the value to the performing organization, customer, and the society?  When we think about this and focus on the benefits, we step into the next stage of ensuring the project risk is constantly monitored.  There are various tools to managing risk but constantly keeping focus and most importantly the risk register.

Understanding these risks is a critical element to the next stage called program management.  Why? This is because the program management focuses on what an individual project can't deliver. The impact on value maximization is high in program management. If the risk is not more actively monitored, there will be too many interproject dependencies that may impact these projects more. So, when advancing to program management, active risk management is critical and is a sine qua non for project management excellence.

Furthermore, risk management is at the epicenter of value management. While project management focuses on delivering products, services, or results, program management focuses on benefits delivery. Since the extent to which businesses and customers derive the benefits describes value, in delivering products or benefits, lean principles advocate flow by avoiding delays. As the day passes, value should be incrementally built. Even when the project may not have been launched and the anticipated benefits realized, we monitor the progression of work so that projects don’t slip, tasks don’t wait, or decisions are not delayed. From the discipline of earned value management, this is why we even look at the 'value' earned in a snapshot in time!

One thing that I was very proud of in my current workplace is that there was an all-hands meeting from all account managers, project managers, development representatives, script writers, creative artists, testing team, and operational team members. The project management team was responsible for holding this meeting on a weekly basis at a predetermined time on Tuesday with remote representatives and traveling account managers on the telephone bridge. This meeting served as the 'synchronization' meeting where everyone synched on raising their part of the risks and issues as well as the impact to the project, client, and the revenue to be recognized by the company! Everyone was willing to pivot accordingly because there is only limited capacity of time/resources available! 

Now, will synchronization alone contribute to seamless value flow? Let us see. While each team had their independent meetings to discuss what was in their backlog. The creative team had a weekly meeting to discuss department specific projects and client specific projects. The development team had its daily standup with the onshore and offsite engineers. The account management team had their own retreats (that's the name they used) to discuss client and deal with specific issues. So, each team had its own cadence on when to meet, what to discuss, etc. 

Therefore, although both cadence and synchronization were present, some of the challenges that we repeatedly discussed in the synchronization meeting emphasized that there were other forces at play impeding value flow. The most common things that came up are the following:

• Lack of Visibility: There was no combined backlog or a visible backlog of what happened inside every team. If a team discussed a new project that is slowing work for other initiatives, that was a surprise!
• Multitasking: Some teams had a single person working on multiple things. For example, a creative artist was assigned to more than project extending the amount of time taken for both projects. This diffused the need for more resources required to meet the increasing demand. Delays in projects slowed value delivery and revenue recognition. 
• Size of the Work Commitments: Some work commitments made were large. There was not enough questioning of the estimates to the commitments made. Sometimes, there was only one single person available to do such work introducing the key candidate risk. 
• Complicated Workflow: Some review and approval steps in the process were unnecessary, increasing the amount of time taken for people to wait on those steps. The time zone and the manual processes fueled this fire further. 

I believe value is proportional to the waste reduced (value = f (waste reduced)). Some of these value blocking forces causing waste are common in many companies. We tried to address it by having cross-functional representatives in other cadence meetings, consolidating tools on a single ALM tool, introducing role-plays with team members rotating with others, and reviewing steps in the workflow to minimally required to ensure compliance. What other techniques could have worked? Please share.

Cost of Quality: The increasing value of acceptance testing besides automated testing

There are two prevalent themes in software development in the corporate world: “Zero Quality Errors” and “Doing more with less”. The dominance of both these concepts has critical importance in their implementation.

1. Eliminating the number of testers increases the level of effort on the remaining testers to check every test case as thoroughly as possible introducing errors. The testers that have the accountability to ensure that they don’t release features without signing off are under pressure compromising the quality.
2. Keeping more testing resources also does not guarantee zero quality when the testers don’t keep up with the current trends. The number of communication lines increase with the QA manager, test lead, offshore test coordinators, and testers. This functional hierarchy removes the testers from the developers defeating the self-organized team requirements. Consequently, the requirements dilute and morph leading to management problems as the customer complaints increase, time to market slips, and product reviews decline.

The logical solution is “Automated testing” making the system do testing detecting more defects at earlier points in the development life cycle as well as continuously testing deployed code for production bugs. The solution is logical and practical as it accomplishes doing more work with fewer resources consistently, continuously, and almost effortlessly compared to the needs to have a human present to manually test. 

Does that mean automated testing is a perfect solution where we can enable computer assisted software tools (CAST) to as many testers as possible? The agile engineering practices recommend automated testing but also emphasize acceptance testing where the business owners also are involved in testing. But how far are our people in client-facing roles like product managers, project managers, program managers, and account managers increasing their knowledge of the business domain and related technical tools to test the releases?  How much is the management attuned to this fact?

1. The client facing roles mentioned earlier may question why they should do this testing that the testing department is accountable for? It is a valid question but when buying a car why do you want a test run? Why do we do our own walk-through inspection of the home instead of leaving the work completely to the home inspector? We do this because we are equally responsible for the outcome. As these roles face the client who can claim escaped defects or the features for enhancement, how could these responsibilities have downplayed?
2. Let us face another argument of being busy doing this acceptance testing! When automation is introduced, the developers and testers must write additional lines of code and test scripts to ensure that the automation works according to the 3A principle (Arrange what needs to be tested, Act by developing code to test, and assert by evaluating the outcome against the expected).  This needs more time commitment and learning additional tools where the developers and testers need to immerse themselves to evolve to the expectations of today’s workforce. So, if one group that is busy can increase their competencies, why should not these client facing roles elevate their skill-competency gap instead of claiming the busy life?
3. Another important angle to consider is new functional non-customer value add requirement but a business value-add requirement, such as the heartbeat monitors, exception log checks, and time taken to test checks as part of the automation efforts. None of these requirements are part of the actual product feature a customer sees but are additional scope of work that the business mandates on the execution wings to design, develop, and test. When these are baked into the level of effort or timeline and when customer asks to reduce the time to market, the client facing roles cripple the quality by not standing up for best practices.

If quality were a coin, automation testing and acceptance testing are its two sides. Efforts spent only on one side won’t have the completely desired economic impact.  Automation is a shift in the way the code is developed, tested, deployed, and monitored requiring refined skills. It is an important element in reducing the cost of quality but so is the acceptance testing that requires additional skills. If we fail to recognize and implement both these effectively, then, the efforts spent in automation may be offset by escaped defects due to lack of acceptance testing.  A new breed of client facing roles is therefore on the rise and the management needs to focus on both the automation testing along with acceptance testing. 

RACI: An important tool to manage project outcome and stakeholder expectations

A few years back in a 2-day workshop on organizational strategy to structure, I saw the facilitator came up with the RACI chart and fumble on the RACI explanation confusing “A” in RACI to “Aid.” In a different situation, the vice president of a client management group was referring to giving copyrights to his manager for coming up with the RACI model. Recently, when I saw the RACI matrix for a process map on a sales-to-execution role definition, I saw processes where the same owner was both responsible and accountable and some areas where there was no person was identified as accountable.  The more I am in management, the more I am feeling that key important stakeholders should become trained on fundamentals of project management, such as the tools associated with Project Management, so that they can position the projects for success and even inadvertently don’t derail the projects.

There are several reasons why a RACI chart is required. The most common ones include when the organization is large enough that simple project communication tools alone would not eliminate role ambiguities efficiently controlling costs to the organization. The subtle reason for requiring a RACI becomes essential when the organization is siloed where several members are working on similar tasks creating waste and not making the organization lean. From a project, program, product, & portfolio management perspective, this RACI tool surfaces to the top of managing risks to these strategic initiatives as middle management wonders if they have the authority to implement their job or projects experience schedule slippage, scope creep, cost overrun, and escaped defects.

So, how does this manage strategic initiative from project to portfolio management?  Now that we realize the importance of the tool, let us ground our thoughts here in relating this tool to stakeholder and risk management. Here are my thoughts!

Role	Description	Stakeholder
Responsible	The individual performing an activity.	This person does the work. It may be a developer, tester, data analyst, or network administrator in software development or a project manager in a project.  In the Power-Interest grid, the R members are mapped to the "Keep Informed" (Low Power, High interest) quadrant for the most part.
Accountable	The individual ultimately accountable.	This person is answerable to the management in managing the client and the project’s profitability. An account manager, product manager, project manager, executive sponsor, functional manager are all examples. This person should also use the risk register effectively by mapping the risk owner to the RACI. In the Power-Interest grid, the A members are mapped to the "Manage Closely" (High Power, High interest) quadrant for the most part.
Consulted	The individual required to offer input and contribute to the activity.	This person offers 2-way communication and is a domain expert. This person should hold both “Responsible” and “Accountable” person in check if only they consult. This person alternative risk management techniques like the root cause analysis, force field analysist, and SWIFT (Structured What If Thinking) promoting thoughts that may otherwise be missed impeding flow. May be able to roll up the sleeves to do what these above roles should do. Can take on the roles of Director, Proposition Manager, Business Architect, Project Manager, etc. In the Power-Interest grid, the C members are mapped to the "Keep Satisfied" (High Power, Low interest) quadrant for the most part. But they could also come from any other quadrant.
Informed	The individual that needs to be informed of the decision and its impact.	These are the people that PMBOK calls as stakeholders that can be positively or negatively impacted by the project’s outcome. These stakeholders must be managed so that unnecessary escalation and project derailment does not happen.  The “Informed” is not limited to organizational employees and business units but customers, vendors, partners, and end-users depending upon projects or product’s goals. In the Power-Interest grid, the C members are mapped to the "Monitor Marginally" (Low Power, Low interest) quadrant for the most part. But they could also come from any other quadrant.

Every tool in the Project Management Book of Knowledge is so critical that it has its place in managing the project’s outcome. Understanding its purpose and utilizing it appropriately is critical to any organization’s job. RACI is an important asset to any management to eliminate waste, increase efficiency, and enhance stability.

Now, how do you foresee its use in your organization, business unit, and product or project management? Share your thoughts!

References

Project Management Institute (2013). Project Management Book of Knowledge. Fifth Edition. New Town Square, PA: Project Management Institute.