Infosys

KE1222

July 14, 2022

MOHANBIR SAWHNEY, VARUN PODDAR, AND CHARLOTTE SNYDER

Tapping into a Digital Brain: AI-Powered Talent Management at Infosys

In the autumn of 2017, Rahul Gupta glanced out of the plate-glass window in a conference room on the Infosys campus in Bengaluru, India, to see a large flock of starlings lifting off from nearby trees and soaring into the sky. As the birds swooped left and right in a stunning display of aerial acrobatics, he marveled at the mystery of nature that allowed so many birds to sense and respond as one. It was just this sort of agile synchronization that Gupta, the head of data and analytics at Infosys IT, sought to enable within his own organization.

Infosys was a global information technology consulting and software services provider that operated in more than 40 countries, with a market capitalization of about US$33 billion and revenues of US$10.5 billion in 2017.1 A large employer, Infosys had more than 200,000 employees,2 including software specialists and technical consultants. These employees traditionally had been assigned to projects based on a detailed manual assessment of their skill sets and experience. Two years earlier, however, delivery leaders at Infosys had recognized the need for the organization to optimize the talent allocation process based on real-time client project needs, available employees, employee skill sets, and upcoming technology trends. What had begun with

1 “Infosys Market Cap,” Macrotrends, accessed September 17, 2021, https://www.macrotrends.net/ stocks/charts/INFY/infosys/market-cap; “Infosys Revenue,” Macrotrends, accessed September 17, 2021, https://www.macrotrends.net/stocks/charts/INFY/infosys/revenue.

2 “Infosys: Number of Employees,” Macrotrends, accessed September 17, 2021, https://www.macrotrends.net/ stocks/charts/INFY/infosys/number-of-employees.

© 2022 by the Kellogg School of Management at Northwestern University. This case was prepared by Professor Mohanbir Sawhney, Varun Poddar, and Charlotte Snyder based on conversations with Infosys executives, to whom the authors are grateful. Cases are developed solely as the basis for class discussion and are not intended to serve as endorsements, sources of primary data, or illustrations of effective or ineffective management. For pedagogical purposes, the authors have fictionalized individuals, conversations, strategies, assessments, and other details to protect the identity of the people and institutions involved. To order copies or to request permission to reproduce materials, call 800-545-7685 (or 617-783-7600 outside the United States or Canada) or email [email protected]. No part of this publication may be reproduced, stored in a retrieval system, used in a spreadsheet, or transmitted in any form or by any means— electronic, mechanical, photocopying, recording, or otherwise—without the permission of Kellogg Case Publishing.

A I - P o w e r e d T a l e n t M a n a g e m e n t a t I n f o s y s KE1222

a one-page list of skills gaps in the workforce evolved into a broader effort to better understand each employee’s proficiencies and career aspirations, ultimately blossoming into a company-wide artificial intelligence and machine learning initiative to optimize the talent management function. The vision was to create an agile, dynamic organizational structure powered by a “digital brain.”

As part of this vision, Gupta was helping to construct a centralized data foundation for an AI-based talent management system that would provide a 360-degree view of open positions and available employees and make recommendations to optimize value, skills, networks, billing, and collaboration across the organization.

As the murmuration of starlings concluded their twilight performance and settled into the trees to roost, Gupta’s thoughts returned to the table, where he and two colleagues were working to make the talent management product vision a reality. Seema Krishnan led the execution team as the artificial intelligence and machine learning expert charged with building the pipeline and the models, and Praveen Pandey served as the domain expert who ensured synchronization with the talent management group.

The three had gathered to study the feedback they had collected during interviews with ground-level users of the current manual (off-line) process for allocating talent to client projects. Given the recommendations and needs of these various stakeholders, the project team now had to make several data, design, and deployment decisions before they could begin building the new solution. First, they had to consider what data variables should be used to define “supply” (i.e., employees available for assignments) and “demand” (i.e., staffing needs for client engagements). They also had to establish a system for ensuring that this data was accurate and kept up to date. For automated talent allocation to function effectively, the employees, managers, and talent management group at Infosys would need to comply with data collection and use the system in a consistent way. This would not be possible if these stakeholders failed to trust in the system’s recommendations. The team members wondered how they could drive adoption and build trust throughout the organization. Last but perhaps most critical, the team had to establish a plan for maintaining the system—even at this early stage. Determining how success would be measured and who would be responsible for tracking these key performance indicators would be the only way to enable continuous improvement.

Talent Allocation at Infosys

In 2017, Nandan Nilekani, the CEO and a co-founder of Infosys, challenged the company to model itself after a living organism that could sense, respond, and adapt to the changing needs and conditions. His vision involved using data, artificial intelligence, and machine learning to remove latency, drive automation, conduct instant simulation. It also included gathering micro-feedbacks, with the idea that Infosys could transform itself into a sentient “live enterprise”: an organization capable of continually reimagining and reengineering processes to accelerate the testing and implementing of new ideas.3 This networked, integrated ecosystem would be designed to observe

3 Jeff Kavanaugh and Rafee Tarafdar,The Live Enterprise: Create a Continuously Evolving and Learning Organization (New York: McGraw-Hill, 2021), 13.

2 K e l l o g g S c h o o l o f M a n a g e m e n t

KE1222 A I - P o w e r e d T a l e n t M a n a g e m e n t a t I n f o s y s

and capture data continuously, enabling intuitive decisions with minimal human intervention. The goals were to free people from daily, mundane tasks that technology could handle more efficiently and to encourage constant experimentation to improve, simplify, or eliminate processes to yield more value.4

Allocating employees (“talent”) to client projects was an ideal starting place for the transformation that fit Nilekani’s vision. Even minor misalignments between talent and clients could increase the risks of client dissatisfaction or employee churn and have serious repercussions for the company’s bottom line. Infosys’s leadership believed that a superior employee experience would build resilience through longer employee tenure and stronger collaboration, ultimately enabling the company to outperform its competitors in innovation, client satisfaction, and profitability. Thus, ensuring that matches between people and projects brought out the best in individual strengths and group collaboration across the enterprise, which was crucial to the company’s overall success and impact.

Talent allocation at Infosys required significant time and resources—more than one million hours of effort per year.5 The tasks seemed simple enough: determine open positions for clients’ projects; evaluate the skills and experience they required; identify employees who were both available and qualified; and assign those who best matched the requirements of the projects. Historically, these tasks had been performed manually. Developing a concise list of prospective candidates for new projects took days or even weeks. Hiring managers followed a three-step process to allocate employees to projects; they identified an inclusion set based on who was available, an exclusion set based on who would not be eligible due to factors such as competitive constraints from previous projects, and finally, a list of required skills based on client needs to determine an appropriate fit.

As staffing decision-makers conducted each of these repetitive, high-volume assessments, they encountered several challenges. Infosys consisted of a large collection of mini organizations, each of which managed hiring and project allocation decisions independently. At any given moment, an employee on one delivery team who was unutilized might be a perfect fit for another delivery team’s needs, but a central team managing demand and supply across the organization was needed to recognize the opportunity. Information about which employees were available for new assignments needed to be visible across the organization, and the reliability of data had to be improved. And whereas Infosys had a predefined taxonomy of more than 2,000 skills that could be attributed to an employee (e.g., expertise in the Java programming language or the .NET software platform), the company recognized the need to have a more consistent process for attributing skills to employees. Some delivery managers chose to update lists of skill sets manually for their employees; others did not.

To alleviate these challenges, Infosys formed a Talent Task Force (TTF) consisting of a panel of experts with three main goals: streamline personnel recommendations; address career aspirations of employees; and determine areas in which the company should recruit new talent. This task force was responsible for providing recommendations to staffing decision-makers to facilitate more

4 Kavanaugh and Tarafdar, The Live Enterprise, 14. 5 Sunil Thakur, “Digital Brain for Talent Management,” white paper, Infosys Ltd., June 2, 2020.

K e l l o g g S c h o o l o f M a n a g e m e n t 3

A I - P o w e r e d T a l e n t M a n a g e m e n t a t I n f o s y s KE1222

efficient pairings between available employees and open projects, in effect, to fine-tune the process. However, the value of these recommendations relied on the true insight of demand, supply, and employee skill sets across the organization. The task force members did not make final decisions on talent placement; they provided recommendations to staffing decision- makers to facilitate more efficient pairings between available employees and open projects. Hiring managers might decide that the recommended employees did not have the required skill sets, or the employees themselves might refuse an assignment if they did not feel that it was a good fit. Consequently, TTF’s recommendations experienced significant rejection rates.

The task force further recognized that reducing these rejection rates would require improving the current methods for identifying demand, supply, and skill proficiency.

Identifying Demand for Talent

Since the introduction of the task force, Infosys had a central, online system for managing staffing demands and identifying available employees; however, the information was not always accurate. Additionally, several open positions listed in the demand system were unreliable; some were obsolete, some were duplicates, and others had abstract descriptions that did not clearly convey the required skills. Some delivery managers did not use the company’s demand system unless they had a need that none of their internal talent could fulfill. Instead, as these delivery managers became aware of new demands in their sphere of operations, to ensure client satisfaction, they frequently staffed the new assignments with their own employees who were rolling off projects without ever entering their team’s needs into the central system.

Identifying Supply of Talent

To allocate people quickly and accurately to projects, the task force and staffing decision- makers needed accurate information regarding who was available for reassignment, as well as forecasting capabilities to anticipate who would be available in the short term.

The company’s fundamental sources of talent supply were employees about to roll off projects and those “on the bench” (i.e., not currently assigned to projects but still on the payroll); however, consistent, reliable information about employees’ work status was not readily available across the organization. Although the task force could theoretically tell when employees were eligible for new assignments based on the reported end date of their current projects, this data was not always reliable because managers could update it as the project progressed. As a result, the TPD had to engage in time-consuming, manual processes to confirm the availability of each person for every staffing recommendation.

Historically, all delivery managers had run their own talent pool of about 200 people. When employees finished a project, their profiles were supposed to be accessible in a central pool of available employees (“the bench”) for other delivery teams in the organization to recruit from. However, in the interest of retaining talent supply and ensuring client satisfaction, delivery managers tended to reassign their employees to new opportunities as projects wrapped up without officially releasing

4 K e l l o g g S c h o o l o f M a n a g e m e n t

KE1222 A I - P o w e r e d T a l e n t M a n a g e m e n t a t I n f o s y s

the employees to the bench. If appropriate opportunities did not immediately present themselves, some managers would place a “buffer” code on the employee’s profile, indicating that the employee was being held for a manager and was therefore inaccessible to other managers. These practices made true visibility of available talent challenging.

Identifying Employee Skill Proficiency

Matching employee skill proficiency with project requirements was crucial to ensuring maximum productivity and successful outcomes for both employees and projects. Hiring managers needed to be able to identify clearly both the skills required in each project and those each employee possessed to determine who would be the best fit for a particular assignment. However, limited data existed regarding how much hands-on experience Infosys employees had in working in a particular skill area.

The task force estimated an employee’s skill proficiency by looking at two sets of variables: (1) how long he or she had worked on a particular project, and (2) which skills were required for that project. This method was a good proxy of proficiency, but it was not perfect because not everyone on a project worked on everything. Hiring managers commonly rejected recommendations on the basis that the recommended employee turned out to lack sufficient expertise in a required skill.

In addition, the current age of digital transformation and constant technological evolution meant Infosys’s employees were always training to develop their existing skills and learn new ones, which added another layer of uncertainty when the task force was looking for skill matches among employees.

Designing the New Talent Management Solution

The goal of the new talent management system was to enable managers to feed their demand requirements into the system, which would then instantly provide them the top 10 qualified recommendation profiles (see Exhibit 1). The new system would support the TTF, in their work of matching employees to client needs, eliminating routine tasks and freeing them up to focus on higher-order functions.

Before that could happen, though, the project team first had to design a data strategy that addressed the following concerns: what data variables should be used to define supply (e.g., employees’ personal details, skill proficiencies) and demand (e.g., client details, project descriptions); how to ensure that the data was accurate and up-to-date; how to incentivize adoption of the new system; and how to measure success and enable continuous improvement (see Exhibit 2).

The project team hoped to expand its data foundation to include unstructured data from within the company’s systems, as well as from publicly available sources. By incorporating information from sources that included human resource systems and social media, data could become richer and potentially more accurate in predicting successful outcomes for both people and projects. The team members considered integrating employee LinkedIn and Facebook accounts to enrich the

K e l l o g g S c h o o l o f M a n a g e m e n t 5

A I - P o w e r e d T a l e n t M a n a g e m e n t a t I n f o s y s KE1222

employee dataset; however, they knew they would need to tread cautiously to ensure that they did not introduce sources of bias into the data. Optical character recognition (OCR) could be used to mine data sets such as project descriptions, project rules, development strategies, and personnel lists to bring visibility to similarities in employee experiences and networks—though OCR did have its shortfalls, as it wasn’t always as accurate with nonstandard documents, such as those with background images. All of the data could potentially be modeled as an employee knowledge graph (EKG), linking each employee with his or her skills, projects, networks, interactions, and devices. Ideally, the EKG could drive contextualization and search, expedite staffing, improve matching, enhance the employee experience, and increase client satisfaction.

As the project team turned its attention to determining data variables that would accurately profile employee skill sets and client engagement needs, the potential impact of the new system on the lives of each employee in the company weighed heavily on data and analytics head Gupta.

“We must recognize that the machine learning initiative we are building is not just about our company’s operations or even simply about our customers,” Gupta told the team. “It’s going to profile all of our colleagues and play a significant role in defining their career paths by either recommending them or filtering them out as job opportunities arise. You don’t get any more sensitive than this. Everyone needs to be able to trust this system.”

Execution team leader Krishnan agreed. “This is why we must put as much data as possible into it so that the algorithms can form the most thorough and accurate picture,” she said. “Computers will not discriminate, as people might. Hiring managers might think they know who would be good for an upcoming project, but the system itself will be better equipped to find the most qualified people across the entire organization for each position.”

“Perhaps, but that was not the case for women who applied to Amazon for software engineer positions at one point,” Gupta countered. “Amazon’s AI-based recruitment tool was supposed to assist in finding the most qualified candidates, but the data fed into the system was biased; it was based on the company’s predominantly male work force. Because software development roles are filled mostly by men, the algorithm deduced that they must perform better than women, so it ended up discriminating against female applicants. Although it’s true that computers should be able to make unbiased assessments, it’s also possible that our data could be biased in ways that we aren’t even aware of. Our company prides itself on being employee-centric, and we must make sure that we are looking out for our people’s best interests.”

“With access to literally hundreds of data variables across our internal systems, I’m sure that we can integrate rich sources of information into the new recommendation engine without causing bias,” replied Krishnan, looking over some brainstormed lists of variables the team was considering for inclusion in the solution (see Exhibits 3 and 4).

“But what variables seem most critical to include in our new data foundation, and what variables would be too sensitive to include in the system? Should we, for instance, exclude gender as a variable in profiling employees?” Gupta asked. “At a minimum, we need to maintain comprehensive, granular data on where our talent is deployed, what each individual is doing, what they are good at, and how relevant their skills might be on other client engagements.”

6 K e l l o g g S c h o o l o f M a n a g e m e n t

KE1222 A I - P o w e r e d T a l e n t M a n a g e m e n t a t I n f o s y s

“Our hiring managers have told us that the biggest reason that they reject candidates is due to a lack of skill proficiency,” domain expert Pandey replied. “We need to improve our skill proficiency assessments. We know hiring managers also want to know what potential candidates have been doing in the most recent two years in terms of skills and training. In addition, they have requested that we highlight staffing or project connections in the recommendation profiles. As you know, they believe that teams composed of people who have previously worked on similar accounts or projects are predisposed for success. They also want individuals with outstanding performance ratings to receive a higher match percentage.”

“Wait a minute—increasing the match percentage for individuals with outstanding performance ratings doesn’t seem right. By doing that, we might we inadvertently create a prediction system in which only the best employees feel valued, and the average performers get demoralized. We need to tread carefully here,” Krishnan cautioned.

“Understood,” Gupta said. “Switching gears for a moment, however, we certainly have lots of data, but we don’t have the luxury of sensors automatically sending terabytes of information on each individual every two minutes. How can we make sure that our data is consistently available, reliable, and up-to-date?”

“The most important thing we can do to ensure strong data hygiene and to improve the system over time is to require everyone to use it,” Krishnan said. “Employees should be required to update their skills regularly—maybe even as part of their performance reviews. Managers should update all their employees’ skills as well, so that we aren’t just relying on self-assessments. When hiring managers want to staff positions, they should have to fill out a demand in the system. And the person they hire has to be recommended by the system. If hiring managers don’t find whom they want through the system, they need to keep adjusting their demand requirements until their perfect fit shows up. We can use telemetry to track engagement with the system. And once someone is hired, the system can reflect that new position automatically on both the supply and demand sides in employee profiles, client profiles, and project descriptions. The system will be able to sense, respond, and adapt—and it’ll just keep getting smarter.”

“Some of this sounds a bit draconian,” Pandey said. “I worry that all of these requirements could spark a backlash from hiring managers.”

“If the system works well, then everyone will appreciate it,” Krishnan replied.

“Maybe we can find other ways to ensure that the talent management system recommendations will be implemented,” Pandey said. “I would rather have everyone want to use the system. What about word of mouth? If we have some early success stories, we can publicize them widely to help everyone see the benefits of using the system. We can make the user interface super intuitive and highlight how fast and reliable the system is. And the new talent management system’s recommendations are accepted at higher and higher rates, so we can promote the metrics and show how great the results are to drive further adoption.”

“Results speak for themselves,” Krishnan commented. “With accurate data that provides true visibility into our supply, demand, and skill proficiency, the system’s recommendation engine will

K e l l o g g S c h o o l o f M a n a g e m e n t 7

A I - P o w e r e d T a l e n t M a n a g e m e n t a t I n f o s y s KE1222

be able to shift from micro-optimization within specific delivery teams to macro-optimization across the entire organization. As soon as delivery managers start benefiting from new people who have the skills they requested, they’ll recognize the system’s value and speed—and they’ll never look back.”

“It would be great if people would want to use it voluntarily,” Gupta said. “But what if delivery managers don’t choose to use it and try to hoard their talent? We have encountered this problem in the past. Giving managers an option to use the system can be ineffective. It allows for a wide range of acceptable usage and creates ambiguity about what needs to be accomplished.”

Pandey interjected. “Speaking of accomplishment, we need to define key metrics so we can measure success, develop a baseline, and continue to drive adoption,” she said. “We could measure employee satisfaction and manager satisfaction by conducting a survey four weeks after a match recommendation is executed. It would help us assess how effective our predictions are. We could work with HR to incorporate performance appraisals so we can assess if better matches were correlated to better job performance. We would need to identify a good control group though. Maybe we should even bring clients into the feedback loop.”

“We have some obvious choices for quantitative metrics here,” Gupta said. “Lowering the rejection rates for recommendations seems like a fairly direct measure of whether the system is working as expected. Ideally, we should also be able to reduce the amount of time employees are idling on the bench and get more of them actively moving from one project to the next without downtime. Turnaround time to an accepted recommendation seems to be another important metric.”

“I was thinking about the possible effect on employee attrition,” Krishnan responded. “Better talent mobility and matching should reduce our attrition rates. High attrition impacts company culture, hurts morale, and leads to the added cost of hiring and retraining new employees. I truly believe this system can have a transformational impact across our entire organization.”

“And who will have access to this all-encompassing system?” Gupta asked. “Hiring managers certainly need to, but what about clients, engagement leads, and individual employees who are asked now and then to update data? We’ll need to be very careful about privacy and consent issues.”

Conclusion

As Gupta walked across the Infosys campus later that evening on his way home, he knew he and his team still had much to consider.

Logic suggested that the more data the system had, the better its recommendations should be. The project team had access to hundreds of variables, each of which could contribute a fuller picture of the employee and client project, resulting in a higher rate of match acceptances. Yet some of the data was likely not usable—some variables might introduce unintentional bias into the algorithm or might be too sensitive to include. The way Gupta saw it, three options were available. Option A would be to use as many variables as possible and let the models select the statistically

8 K e l l o g g S c h o o l o f M a n a g e m e n t

KE1222 A I - P o w e r e d T a l e n t M a n a g e m e n t a t I n f o s y s

relevant ones. Option B would be to be conservative at the start, and only select the current job situation and recent engagement variables, setting aside all individual preferences and historical engagement variables. And Option C would be to spend some time pre-processing the data, which would entail combining, converting, or eliminating variables so the project team could identify the most influential and relevant variables.

Whatever data variables were chosen, the project team had to ensure the data itself was reliable, accurate, and consistent. The old talent allocation system, under which managers could hoard talent by reserving certain employees for future projects or refusing to rotate them off existing projects, had to be erased from institutional memory and replaced with the new system— but how to do this? One option would be for the project team to issue a series of mandates: that both employees and managers update skills at appointed times; that managers must use the system for each staffing request; and that if managers rejected a recommendation, they would have to resubmit a revised staffing request until the system provided a recommendation they accepted. It might be difficult, however, to achieve compliance simply by mandating it.

Perhaps the team should focus instead on making users want to use the new system, creating positive word of mouth by publicizing early wins and making the interface as easy to use. High match rates from the start would seem necessary for this option. A third possibility might be striking a balance between the voluntary, free-will approach and the draconian mandate—perhaps starting with a proof of concept with one or two teams. Instead of a general commitment to “use the system,” these teams could be armed with the steps required to make decisions based on the predictions, and the project team could support them with specifically designed objectives.

Gupta knew the success of an AI initiative was rarely about the AI; it usually came down to the people and the politics of an organization. The project team’s choice of data strategy had to consider long-term adoption, compliance, and maintenance. Yet he wanted to ensure that his team did everything possible to build a talent allocation system that would be embraced by clients, staffing decision-makers, and employees alike.

K e l l o g g S c h o o l o f M a n a g e m e n t 9

A I - P o w e r e d T a l e n t M a n a g e m e n t a t I n f o s y s KE1222

Exhibit 1: Talent Management Solution-Product Vision

Talent - Matching Output

Talent Det ails

Source: Infosys internal documents.

1 0 K e l l o g g S c h o o l o f M a n a g e m e n t

KE1222 A I - P o w e r e d T a l e n t M a n a g e m e n t a t I n f o s y s

Exhibit 2: Process Diagram for Creating and Maintaining the

Talent Management System

Collecting the Data • What data is available? • How is the data reported/collected?

Measuring Success and Continuously Improving the System • How will success be measured?

• Who will be responsible for maintaining the system after launch?

• How will the system be updated/retrained for continuous improvement?

Assessing Data Quality • How recent is the data? • How accessible/available is the data?

• How accurate is the data? • How consistent is the data?

• How relevant is the data?

Adoption and Compliance • How to ensure buy-in across the organization?

Defining the Variables • Which variables should be included?

• Which variables should be excluded?

Source: Created by the authors.

K e l l o g g S c h o o l o f M a n a g e m e n t 1 1

A I - P o w e r e d T a l e n t M a n a g e m e n t a t I n f o s y s KE1222

Exhibit 3: Sample of Supply Variables under Consideration

Current Job Situation Individual Preferences Historical Engagement Recent Engagement

• Current role

• Salary

• Projected end

date of current

project

• Current

department

• Current location

• Current

appraising

manager

• Current

manager

performance

rating

• Previous

manager

performance

rating

• Self-tagged skills

• Manager-tagged

skills

• Ethnicity/nationality

• Language(s) spoken

• Gender

• Age

• Disability

• Home city/country

• Preferred locations

• Willingness to

travel/ relocate

• Educational

background

• Marital status

• Normal working

hours

• Positions applied

for in past 2 years

• Positions rejected

• Career/skill

aspirations

• Length of service

• Amount of leave

taken in past year

• Amount of sickness

in current/previous

years

• Average time in

each salary level

• Average time with

each manager

• Number of manager

changes in past 5

years

• Training courses

completed in

past 2 years

• Certifications

completed in past 2

years

• Background check,

including

confirmation that

employee has not

worked for a client

competitor

• Time in current position

• Time in current grade

• Time since last leave

• Time since last

salary change

• Time until

contract

expiration

• Time until next

review cycle

• Time until work

permit or visa

expiration

Source: Created by the authors.

1 2 K e l l o g g S c h o o l o f M a n a g e m e n t

KE1222 A I - P o w e r e d T a l e n t M a n a g e m e n t a t I n f o s y s

Exhibit 4: Sample of Demand Variables under Consideration

Client Context Current EngagementHistorical Engagement

• Client name

• Number of years

as client

• Client location

• Client size

• Client market cap

• Client revenue

• Client industry

• Language(s)

required

• Current project

with client

• Company

project

engagement

lead

• Project manager

• Employees on

project

• Project scope

• Required skills

• Staffing start date

• Staffing end date

• Project budget

• Billing rate

• Outside vendors

involved in

project

• Number of past

projects with client

• Number of

current projects

with client

• Client satisfaction rate

• Amount of

budget variance

from initial

projections

• Number of projects

with extended

staffing end dates

• Number of projects

that required

additional staff

during their span

Source: Created by the authors.

K e l l o g g S c h o o l o f M a n a g e m e n t 1 3