Case Study: To Replan or Not to Replan?

Directions

When reading this case study, focus on the activities and decisions that are part of planning and tracking a software project. In particular, note the issues associated with the need to replan. The case refers to a few standard but specific metrics that are used in practice for project planning and tracking. Therefore, it is particularly helpful to review the terminology for the case study before reading it.

Case Summary

Description

Nordic Petro has adopted an enterprise approach to managing its business operations. All business and management decisions will be based upon company-wide information accessed in real time. With this goal in mind, Nordic Petro converted its core business systems to a centralized SAP suite of software to manage human resources, finance, and sales and distribution. The software conversion yielded significant savings in operational expenses as well as increased revenues. The company now wants to add the SAP enterprise software for customer relationship management, supplier management, and asset management. The company’s goal is to reduce the costs of managing customer service and the supply chain as well as the expenses associated with the maintenance and use of plants, equipment, and other capital assets. The estimated cost for the Renaissance Project is 300 million Norwegian Kroner (approximately 50 million USD in June of 2007). The estimated rollout of all new systems is 2.5 years from the start of the project. The company has contracted a large consulting firm, IT Sphinx, to help with project planning and management, business and integration process planning, and software development and integration. The case scenario focuses on the project-planning phase.

Case Study Objectives

After reading the case study, you will be able to do the following:

• Understand better the following issues when managing software project plans:

• Determining when and why replanning is needed

• Selecting project management metrics and data to be collected

• Managing risks associated with project plans

• Identify the activities and decisions by which the software project managers manage the budget, schedule, and staffing plans.

• Explain the problems that occurred in the case scenario, the causes of the problems, some plausible solutions to the problems, and ways to eliminate the problems in the future or to reduce their impact. Relate these to the decisions faced by project stakeholders.

Subjects Covered

Budget planning, managing project plans, managing project risk, project planning, project replanning, project staffing, project tracking, and schedule planning

Setting

The setting is the information technology (IT) center at the global headquarters of Nordic Petro in Oslo, Norway. The company focuses on the exploration, development, and production of oil and natural gas from the Norwegian Continental Shelf but has recently ventured into renewable energy production. The company has business operations in more than 40 countries and operates four business segments: Oil Exploration and Production, Natural Gas, Renewable Energies, and Manufacturing and Marketing. Nordic Petro is publicly traded on the Oslo Stock Exchange.

Key Concepts

• Making appropriate decisions about when and why replanning is needed is important to the successful management of software projects.

• Deviating from software project plans is a common occurrence. Knowing the reasons why deviance typically occurs can help software project managers develop plans that are less likely to be impacted by deviance and can help them more effectively prepare for, recognize, and handle deviances when they occur.

• Software project managers need to collect project management data that will help them develop benchmarks for estimating the resource needs of similar projects in the future.

Terminology

Actual cost of work performed (ACWP): The sum of costs actually incurred in accomplishing the work performed (U.S. Department of the Navy).

In practice, ACWP is the sum of the hours (cost) actually used for all tasks that are complete by the end of the reporting period.

Budgeted cost of work performed (BCWP): See Earned value (EV).

Budgeted cost of work scheduled (BCWS): See Planned value (PV).

CEO: Chief executive officer.

CFO: Chief finance officer.

CIO: Chief information officer.

COO: Chief operations officer.

Cost Performance Index (CPI): The ratio of work accomplished versus work cost incurred for a specified time period. The CPI is an efficiency rating of work accomplished for resources expended (U.S. Department of the Navy).

In practice, CPI is BCWP/ACWP. (See the definitions for BCWP and ACWP.) CPI ≥ 1 means that the budgeted cost of work performed by the end of a reporting period is equal to or greater than the actual cost for this work. In other words, current project costs are within or below budget.

More detail: CPI is calculated as BCWP divided by ACWP (BCWP/ACWP). The budgeted and actual costs may be expressed as monetary values (for example, in dollars) or in another unit of measure such as hours. As a ratio of two values having the same unit of measure, CPI has no unit of measure. A CPI ≥ 1 is a preferred situation in which the budgeted cost of the work performed is greater than or equal to the actual cost for this work. On the other hand, a CPI < 1 suggests a less desirable situation in which the actual cost for the work performed exceeds the budgeted cost for this work. Also, a CPI that is much greater than 1 indicates that the original plan grossly overestimated the cost (in hours, dollars, and so on) needed to accomplish the planned tasks. The managers in the case study track the CPI for their project over time to determine how well their project stays on budget. A project’s CPI value does not reflect a project’s performance with respect to schedule. A project may be on budget while being on or behind schedule.

Earned value (EV): The amount or volume of work completed to date, commonly referred to as the budgeted cost of work performed (BCWP). When compared to the planned value (budgeted cost of work scheduled) and actual cost (actual cost of work performed), EV provides an objective measure of schedule and cost performance (U.S. Department of the Navy).

In practice, EV is the sum of the hours assigned to each task that is actually complete by the end of the reporting period.

More detail: Calculations of earned value typically consider units of work that are entirely complete, such as the completion of an entire task. Earned value calculations usually do not consider tasks that are partially complete. The related SPI and CPI indexes use EV to measure schedule and cost performance, respectively. EV may be expressed as monetary values (for example, in dollars) or in another unit of measure such as hours. Each unit of work (task) in the schedule is assigned a cost, as in hours, needed to complete it.

IT: Information technology.

Planned value (PV): The assignment of the budget for each reporting period for each work component, also called budgeted cost of work scheduled (BCWS) (U.S. Department of the Navy).

In practice, PV is the sum of the hours assigned to each task that is scheduled to be complete by the end of the reporting period.

More detail: Calculations of planned value consider the tasks that are scheduled to be complete to date. PV may be expressed as monetary values (for example, in dollars) or in another unit of measure such as hours. Each unit of work (task) in the schedule is assigned a cost as in hours needed to complete it.

Schedule performance index (SPI): The ratio of work accomplished versus work planned for a specified time period. The SPI is an efficiency rating for work accomplishment by comparing work accomplished to what should have been accomplished (U.S. Department of the Navy).

In practice, SPI is EV/PV. (See the definitions for EV and PV.) SPI ≥ 1 means the actual amount of work performed by the end of a reporting period is equal to or greater than what is scheduled to be complete. In other words, the project is on or ahead of schedule.

More detail: SPI is calculated as BCWP divided by BCWS (BCWP/BCWS). This is the ratio of earned value to planned value (EV/PV). The budgeted and actual costs may be expressed as monetary values (for example, dollars) or in another unit of measure such as hours. As a ratio of two values having the same unit of measure, SPI has no unit of measure. An SPI ≥ 1 is a preferred situation in which the work completed to date is greater than or equal to that which was scheduled. An SPI < 1 suggests a less desirable situation in which the actual work performed is less than the scheduled work. Also, an SPI that is much greater than 1 indicates that the original plan grossly overestimated the amount of time (cost) that would be needed to perform the planned work. The managers in the case study track the SPI for their project over time to determine whether their project stays on schedule. A project’s SPI value does not reflect a project’s performance with respect to budget. A project may be on schedule while being over or under budget.

Slack time: The amount of time a noncritical path task can slip before it affects another task; or, the amount of time between the latest finish time and the earliest finish time of a noncritical task.

The Case

Scenario

Project Proposal and Start (Late Spring and Summer 2007)

As the days lengthened in late spring, Henrik Holmann (a vice president of operations for Nordic Petro) and Bernard Rothstein (a partner with IT Sphinx) drafted a proposal for the next step in moving Nordic Petro toward a complete enterprise approach to managing its business operations. This next step, officially called the Renaissance Project, would involve integrating the SAP enterprise software for customer relationship management, supplier management, and asset management. The Renaissance Project would take about 2.5 years with a budget of 300 million Norwegian Kroner (approximately 50 million USD in June of 2007).

Figure 4-1 shows the organizational chart for the Renaissance Project as well as the related corporate-level committees.

Figure 4-1: Renaissance Project organizational chart

From their experience with the first integration project, Holmann and Rothstein knew that the Nordic Petro investment committee was more receptive to large projects that were composed of distinct planning and execution phases with separate budgets. The committee carefully managed its investments and preferred to provide seed funding for a planning phase that can be meticulously reviewed before approving the budget for an execution phase.

Holmann and Rothstein had used their own discretionary funds to recruit help in developing a proposed work breakdown and schedule for the Renaissance Project planning phase (Phase I). The Gantt chart in Figure 4-2 provides an overview of the high-level tasks for Phase I, which was scheduled for completion by late August 2008. Two key members of the team that helped plan the proposed schedule for Phase I were Guy Pierpont, a Nordic Petro executive in operations, and Natalie Souse, a Nordic Petro IT executive. Everyone understood that if the proposal were approved, Guy and Natalie would stay on the project to provide the needed business and technology planning expertise.

Figure 4-2: Gantt chart for Renaissance Project planning phase (Phase I) (Copyright 2007 Nordic Petro)

The Nordic Petro investment committee was enthusiastic about the Renaissance Project and readily agreed to allocate 60 million Norwegian Kroner (approximately 10 million USD in June of 2007) for the planning phase (Phase I). Their willingness was based upon the cost savings achieved by the prior SAP integration project.

Guy and Natalie would need help with the numerous activities involved in planning and managing the Renaissance Project. Therefore, Holmann and Rothstein organized a Project Management Office (PMO) to provide project planning and management guidance for the Renaissance Project. Kristen Sjo (a senior manager with Nordic Petro) would head the PMO. Rothstein recruited Erik Thune, who had significant project planning experience, from IT Sphinx to be the chief planner. Figure 4-1 shows that the PMO reports directly to Holmann and Rothstein.

Henrik Holmann also set up a Renaissance Project Leadership Team to “set a course, navigate, and steer” the project. See the dashed line in Figure 4-1 that denotes the Renaissance Project Leadership Team. Holmann (a former naval commander) was determined that by August 2008 the project would have completed Phase I and have received its next round of funding for Phase II (the execution phase). This would be about one year after the official start of Phase I on September 3, 2007.

Holmann’s rationale for wanting the Phase I tasks (up to the contracting of the project agreements for Phase II) to be complete by the summer of 2008 was based on advice from his boss (the Nordic Petro COO Nils Andersen). Since the Nordic Petro investment committee met quarterly, Nils had advised Henrik to submit the funding request for Phase II during the investment committee’s summer meeting in 2008. As Nils and Henrik had discussed, missing the summer meeting would result in at least a three-month delay in receiving the approval and therefore the funding for the execution phase of the project. The lapse would not only delay the rollout of the new business systems but would also cause continuity problems. It would be difficult to find alternative projects for all the project staff that would span only three months (the delay time).

During the first meeting of the Renaissance Project Leadership Team, Henrik gave his management crew this direction: “Full speed ahead. Project agreements and funding for Phase II must be in place by July 25, 2008!” Staffing for Phase II would be done in August 2008, as shown on the Gantt chart in Figure 4-2.

The Renaissance Project Phase I started officially on September 3, 2007. The Renaissance Project Leadership Team held weekly meetings to review the project status and to convey information that needed to be communicated to the various project teams.

Conversation Between Guy and Natalie (November 16, 2007)

“Ugh, no improvement. The SPI for our project is still around 0.88,” exclaimed Guy. “We are 11 weeks into the project, and we have not been able to catch up.” (SPI < 1 means that the project is behind schedule.)

“I know. I just got the bad news from Kristen Sjo. At this rate, we will never have the project agreements for Phase II, which is on the critical path, in place by July 25, 2008,” bemoaned Natalie.

“How did we get into this situation?” Guy asked. He then commented, “In the past, I might have suspected poor estimation, but I don’t think that poor estimation is the problem because the estimates were based on our experience with the first integration project. We should have the team leads check the actual expenditures of effort for the Phase I tasks that have been finished or are near complete with the effort that was planned for these tasks.”

Guy continued in an animated voice, “At first, we thought that the low SPI values reflected some problems that we had getting ramped up, but we have had all the staff in place for several weeks now. From our prior experience with the way our staff works, we thought that the actual work accomplished would catch up with the planned work. It’s as though there is a gremlin in our project that is wrecking havoc with the completion of tasks as planned!”

“Henrik and Bernard are not going to be happy at our leadership meeting on Monday when they hear that the project progress has not improved. They are adamant about the date when the agreements and funding for Phase II should be in place. Do you remember what Henrik said when we were working on the project proposal?” Natalie asked Guy.

Guy quoted Henrik with authority, “Full speed ahead. The project agreements and funding for Phase II must be in place by July 25, 2008!” Then he added, “I don’t think we can accomplish this with the current schedule.”

Weekly Project Leadership Meeting (November 19, 2007)

Attendees: Henrik Holmann, Bernard Rothstein, Guy Pierpont, Natalie Souse, Kristin Sjo, and Eric Thune

The meeting started briskly with a quick review of old action items. Henrik Holmann queried the others regarding the move that the project had made to the new headquarters building on King Harald Street. “Were all of the teams settled? Did they have the physical resources that they need?” he asked. Everyone reported that the move was going smoothly, though there had been some minor delays in the transport of computing equipment.

Next was the review of project status. Guy reported that the project SPI was still running about 0.88. Natalie explained that a major data modeling effort that was to have been finished yesterday was significantly late. (The data modeling effort is task PP5 on the Gantt chart in Figure 4-2.) Guy added that the tasks for business process analysis were also behind schedule (tasks SP1–SP3 on the Gantt chart).

Henrik Holmann looked very serious when he said, “What is the likelihood that the current schedule slippage will negatively impact the completion of the project agreements for Phase II on time?”

Kristen replied, “With the current rate of schedule slippage, the project will not start contracting the project agreements for Phase II as planned on July 7, 2008, and therefore is not likely to be on schedule in completing this task.”

Holmann barked, “Do we have a plan in place for handling schedule slippage? What would it take for the project to catch up?”

Kristen cautiously answered, “We had planned to bring in more people if schedule slippage occurred, but this may not solve the problem. We need to look at the root causes for the slippage and study the current schedule, budget, and staffing plan to determine a good solution.”

Guy added, “The problems that we had in ramping up the project were solved weeks ago.”

“Well, I want you to find out what is causing the schedule slippage and to determine some ways to fix it. I would like to hear back with your proposed solution at a special leadership meeting to be held in three days,” Holmann ordered.

“If the CPI is still running around 1.04, we might have unused budget to expend on a solution,” Bernard Rothstein stated quietly but firmly. Bernstein had been closely monitoring the budget and knew that the outsourcing deal that they had negotiated for the data modeling tasks had come in below budget. The planned costs were more than the actual costs to date.

Holmann moved to the next items on the agenda, which were issues and risks. Natalie reported that the team analyzing the existing software did not have sufficient access to the Nordic Petro business systems. Natalie explained that the team was behind schedule because of this situation. She wanted some help in getting the CIO to provide more access to these systems.

Natalie also reported that the project might not be able to obtain a software package being developed by Asset Management & Solutions, LLC, that they planned to add onto the SAP asset management software in time for integration. She had read in a reputable trade journal that the release of this module was likely to be significantly behind schedule. Natalie said that with the current plan to use the module, the schedule for Phase II (to be developed in Phase I) would be dependent on the release date of this module. She requested that the risk management group look into and propose ways to manage this situation. (The risk management group is composed of people from various teams and is not shown on the project organizational chart.)

During the report on human resource management, Guy said that Lars Retter, the lead for the Asset Management Team, would be leaving the company in a month. Tartan Renewable Energy, a Scottish company that focuses on the exploration and development of alternative energies, had hired Lars to head up their asset management operations.

Holmann responded, “Lars will be difficult to replace. I will ask Human Resources to work on finding a replacement as soon as possible, but I am concerned that the project could be further delayed while we look for a replacement. In the meantime, Guy, I would like for you to fill in for Lars until we find a replacement.” Guy smiled but looked stressed. Guy thought they could manage for a while without a replacement but knew that as the project progressed he would not have time to provide adequate leadership to the team.

Next, Kristen announced that the project Christmas party was set for the second Friday in December, starting at 6 p.m. The party would be held at the Aurora Borealis Restaurant that overlooks the Oslo Fjord.

The leadership meeting ended with a review of the new action items. The highest-priority action item was Holmann’s directive for Guy, Natalie, Kristen, and Erik to determine the root causes of the schedule slippage and to propose ways to bring the project back on schedule. They had three days to work on this problem.

Special Project Management Meeting (November 20, 2007)

The PMO held a special project management meeting to explore the root causes of the schedule slippage. Guy, Natalie, Kristen, Erik, and the team leads attended the brainstorming session.

Leading the meeting, Guy said that their goal was to determine what was causing the schedule slippage and to brainstorm ways to fix the problem. He suggested that they start by reviewing the task areas that were behind schedule. Guy then projected the schedule for the high-level tasks of Phase I on an overhead screen.

The business manager and his team leads were managing the tasks listed under “Solution Planning,” while the IT manager and her team leads were heading up the tasks shown under “Project Planning,” as indicated previously in Figure 4-2. The staff working on many of the tasks consisted of people from business and IT. The special project management team looked at the current SPIs and CPIs for the high-level project tasks in progress, shown in Table 4-5. The SPIs in bold are 0.8 or less. (SPI < 1 means that the task is behind schedule. CPI ≥ 1 means that a task’s budgeted cost is greater than or equal to its actual cost.)

Table 4-5: Current SPIs and CPIs for Phase I Tasks in Progress

Each high-level task is composed of multiple lower-level tasks whose progress is tracked by the project team working on them. The SPI value for a particular high-level task is determined by the progress made on the constituent lower-level tasks.

The team leads grimaced when they saw the SPI values. Guy waited a moment and then said, “The numbers are poor, which indicates that the work efficiency is much less than planned, but I do not think that the speed of at which work is done when work is being done is the main problem.

He then explained, “I spoke with each of the business team leads and found that their staff members are not getting the information that they need from the business operations personnel. Team members are often working on other projects while waiting for information from the field.”

Guy continued, “The problem is not that the business analysis task work is being done more slowly than planned. The problem is that the business analysts are not able to work on their tasks. That is one reason why the CPI numbers for the project have been good for the last 11 weeks, while the SPI values during the same interval were dismal.”

An SPI value reflects the tasks that were finished with respect to the tasks that were planned to be completed within a given time period. A CPI value shows the budgeted cost of the tasks that were finished for a given time period with respect to the actual cost of completing those tasks. Figure 4-3 shows the plots of the project CPI and SPI values for week 1 through week 11 of Phase I. Note that though they are the ratios of cumulative values, CPI and SPI values are not cumulative values. Ideally, their values will be around 1.0 or better at the tracking points in time for a project.

Figure 4-3: Project CPI and SPI values for weeks 1–11 of Phase I (Copyright 2007 Nordic Petro)

The lead for the Asset Management Team, Lars Retter, then lamented, “My team has personally visited the people in business operations and still cannot get them to commit time to work on the Renaissance Project. When Henrik recruited me for this project, he promised that he would get commitments from the business operations people. I should have escalated this issue sooner. Before I leave, I will introduce you, Guy, to the key people who you need to help analyze our asset management processes. I didn’t expect this job offer and do not like leaving you with this problem!”

The other business team leads agreed that their teams were having the same problem. The one bright spot was the process analysis for the CRM area. Apparently, the operations personnel in this business area were excited about the timesaving aspects of using an enterprise SAP CRM system. Therefore, they eagerly set aside time to work with the Renaissance Project staff.

“I have also heard that the data modeling people are having some of the same problems getting information from the business operations people. So, one root cause of schedule slippage is the lack of information and help from the business operations people who do not have scheduled time commitments to work on the Renaissance Project when needed,” Natalie concluded.

Helene Vind, the IT technical lead, then commiserated, “My team has had a related problem. We have not had adequate access to the existing business software. We are continually in a ‘beg and borrow’ mode that has delayed our progress. I understand that Natalie reported this issue at the last Project Leadership meeting. What is going to be done about it?”

“I asked for help in getting the CIO to provide us with more access to the business systems that we need to analyze. I will certainly follow up at the next Project Leadership meeting,” Natalie offered.

“Even if productivity is not the main cause of the overall project schedule slippage, I think we need to look at the productivity of the staff working on the data modeling tasks. The outsourced staff is less skilled than we expected when we negotiated the outsourcing contract. That may be why the bid came in lower than the budgeted amount,” Kristen commented.

Helene Vind quickly added, “The outsourced team members are good workers, but they require lots of guidance about how the data modeling should be done. This lowers the productivity of all the project staff working on these tasks. I think that the productivity of the data modeling teams is causing some of the schedule slippage.”

“We have identified lack of access to information and help from business operations personnel as well as limited access to business system software. We have agreed that these factors in addition to the low productivity of the data modeling staff [because of the lower than expected skill level of the outsourced staff] are root causes of the schedule slippage. I think we should also compare the actual effort to the planned effort for the completed tasks to verify that our effort estimations are appropriate. Are there any other root causes for the schedule slippage?” Guy asked.

No one offered other suggestions. Therefore, Guy stated, “I think the question is whether we can make up the schedule slippage without replanning or if we need to replan. In particular, can we make up the schedule slippage with the current schedule, or do we need to revise it? With the current schedule, we would need to increase the productivity of the data modeling staff that we have said is working more slowly than planned or possibly add more people. We have some unused budget that could fund this approach.”

Erik Thune then commented, “Consider task PP5, model data for assets, with an SPI value of 0.78. Getting back to an SPI of 1.0 would require about 29 percent increase in productivity [0.78 × 1.29 is about 1.0]. If this could be done immediately, we would not incur any additional schedule slippage, but to ‘catch up,’ we would have to increase the productivity by more than 29 percent. Training the outsourced data modeling staff to help them be more productive would incur more time and cost.”

Erik continued, “Adding people may or may not help. Brooks’ Law says that adding people will make a late project run even more behind schedule because of the additional coordination, communication, and other management issues. In any event, we should look more closely at the data modeling tasks to see whether there is another solution” (Brooks 1995).

Eric paused and then stated, “We also have the problems associated with lack of access to information and resources. I think we are beyond the point at which we can make the current schedule work. I think we must replan. This will probably involve the schedule and staffing plans as well as the budget allocated to each task.”

“I agree with Erik that adding more staff often does not solve a schedule slippage problem. I noticed in the project PERT chart that there is slack time for some of the noncritical tasks and that most tasks do not overlap,” said Kristen. A program evaluation review technique (PERT) chart indicates the dependencies between the tasks and shows the critical path or series of dependent tasks, each of which must be completed on time in order for the project to finish on schedule. A task in the critical path has no slack time.

Eric replied, “We scheduled many of the Phase I high-level tasks without overlap because upper-level management is more comfortable with a waterfall schedule. In addition, dependencies between tasks that overlap are more difficult to manage. However, I think there are some high-level tasks that could start before the tasks on which they are dependent end. For example, we could start to verify and validate the requirements before the elicitation of the requirements ends, and the development of the system architecture could start earlier.”

“OK. We need to replan. What should the replanning entail? Is there slack time that we can use? Can we overlap more of the tasks? Would adding more people actually help? What else should be done? Will we be able to contract the Phase II project agreements by July 25, 2008?” Guy summarized the questions still to be answered.

“At our next meeting, I would like for us to develop revised plans that we could present to the Renaissance Project Leadership Team. Please bring your task, staffing, and cost plans with you to the meeting,” Guy requested. “Also compare the actual effort with the planned effort for the tasks that are done or near done. I want to verify our effort estimates for the tasks in Phase I as we replan. We will meet off-site at the company retreat center starting ‘pronto’ at 8 a.m. tomorrow. I will reserve the Elk Room for our replanning session.”

Case Problem

The Renaissance Project is behind schedule. The actual work accomplished is 88 percent of the planned work (SPI = 0.88) and does not appear to be improving. Henrik Holmann, a lead manager for the project, has asked the project managers and planners to determine the root causes for the schedule slippage and to propose a way to bring the project back on schedule. At a special meeting, the project managers and planners identify some root causes for the schedule slippage. They discuss the problem of whether to replan and make a decision to replan the schedule, staffing plans, and budget.

At the upcoming replanning session, the PMO will work on the problem of adjusting the schedule, staffing, and budgetary plans so that the project can complete the Phase I tasks on time and within budget.

Case Analysis

Analysis Activity

Analysis Background

(P) Problem: In the case study, the project managers and planners must identify the root causes of the schedule slippage and decide whether replanning is needed. In particular, they must decide whether adjustments to the schedule are necessary.

(E) Experience: The project managers and planners communicate their understanding that adding more people to the project may actually cause the schedule to slip further because of the extra communication, coordination, and management that would be needed. Their understanding of this phenomenon may be from experience, or it may simply be that they have studied and agree with Brooks’ Law (Brooks 1995).

(A) Assumptions: The project managers and planners assume that the estimates used to schedule the tasks and allocate resources are good since they were based upon a similar project from the past.

(K) Knowledge: At the special project meeting, the managers and team leads identified the following factors that they think have caused the schedule slippage and are related to the decision of whether replanning is needed.

• The business process analysis and data modeling staff have not been able to complete their tasks because of a lack of information and help from business operations personnel.

• While waiting for information from the business people, some project members have worked on tasks outside the project.

• The staff members analyzing the existing software have had inadequate access to the software.

• The skill level and productivity of the outsourced staff working on the data modeling tasks is lower than expected.

• The productivity of the Nordic Petro staff working on data modeling is lower than planned because of the extra time that the staff must spend guiding the outsourced project members whose skill level is less than expected.

• The increase in productivity needed to make up the schedule slippage for the data modeling tasks is more than can be practically achieved.

• There is slack time in the schedule for some of the noncritical path tasks.

• The schedule for the high-level project tasks exhibits a waterfall pattern with minimal overlap between tasks.

Solution: The project managers and planners discuss the following factors as root causes of the schedule slippage and consider whether replanning is needed.

Factors considered as root causes:

• Lack of information and help from business operations personnel

• Limited access to business system software

• Low productivity of data modeling staff because of the lower than expected skill level of the outsourced staff who are working on data modeling

Approaches considered regarding whether to replan:

• Do not replan. Simply increase productivity of the data modeling staff.

• Use current schedule and adjust the staffing and budgetary plans. Catch up by adding people.

• Replan the schedule and adjust the staffing and budgetary plans.

• Adding people may or may not help and will be considered with caution.

• Effort estimates for tasks will be checked and revised if needed during the replanning session.

• Tasks with slack time and tasks that could overlap offer opportunities to adjust the schedule so that Phase I might still be able to complete on time.

For all approaches, the Renaissance Project Leadership Team must ensure that the project obtains the needed information and help from the business operations personnel as well as sufficient access to the business systems software. In addition, Guy will lead the Asset Management Team until a replacement for Lars Retter is found.

Assumed Risk:

• The project managers and planners have assumed that the task estimates are good. In fact, some of the task estimates may not be good. Using faulty estimates for replanning is likely to result in a new schedule that does not provide appropriate allocations of time for tasks and a repeat of the schedule slippage problem. The managers and planners can help mitigate this risk by verifying the estimates for completed tasks at the replanning session.

• Lars Retter, the lead for the Asset Management Team, is leaving the company in a month. Guy Pierpont will lead the team until a replacement for Lars is found. This may work for a while, but as Phase I progresses, Guy will not have time to provide adequate leadership to the team. A replacement for Lars may or may not be found quickly.

Analysis Questions

1. Consider the reasons that the software project managers and team leads have given for the schedule slippage. What other factors, if any, not identified by these stakeholders do you think might be contributing to the delay?

2. Explain why the stakeholders think that replanning is needed. Do you agree or disagree with their decision? Explain your reasoning, and describe any additional information that you may like to have before making this decision.

3. Now suppose that you have been asked to lead the all-day, off-site replanning session. What replanning options would you like the stakeholders to consider? Identify issues that you think should be discussed as potential action items or for which special action plans may need to be developed.

Discussion

At the special project meeting, the managers and planners first identify factors that they have determined are causing the schedule slippage and discuss a few approaches to solving the problem. The factors (such as inadequate access to information, help, and software) highlight issues associated with obtaining and enforcing time and resource commitments from business operations personnel. Another factor is the lower than planned productivity of the data modeling staff that is a result of the extra time spent guiding the outsourced project members whose skills are lower than expected. The solution to the schedule slippage problem must ultimately address these issues.

As a second step, the project managers decide whether they need to replan. They discuss two commonly considered strategies for making up schedule slippages: adding more people to project tasks and increasing the productivity of the people working on tasks. The managers and planners reason that adding more people or increasing productivity will not resolve the delays because of lack of information, help, and resources. They are also aware that adding more people may or may not speed up task completion. They calculate that the necessary increase in productivity, in particular for the data modeling tasks, to “catch up” is unrealistic. Increasing the productivity of the data modeling teams would require extensive training or replacement of the outsourced staff, which would require increased expenditures of time and money.

The project managers decide that there is no way that contracting the project agreements for Phase II could be complete by July 25, 2008, without replanning. They decide to meet again to adjust the project plans as needed to achieve the target completion date. The project managers and planners identify some features of the schedule that offer replanning opportunities, such as using the slack time of noncritical path tasks and overlapping more tasks. At the end of the case study, the question remains as to what the replanning should entail and which project plans (for example, schedule, staffing, and budget) and policies (for example, obtaining and enforcing time commitments from the business operations personnel) will be adjusted.

Conclusions

The arguments that the project managers and planners make for replanning are reasonable. They think that strategies such as increasing productivity and adding people are impractical or may not solve the problem. At the replanning session, the managers and planners will adjust the schedule as well as the staffing and budgetary plans to be used in guiding Phase I to completion on time and within budget. Part of the replanning will include the verification of estimates used for the tasks that are done or near done. This may help the managers determine whether they need to adjust the estimates for the tasks that still need to be completed. The managers should also develop plans for how to obtain time commitments from the business operations personnel as well as sufficient access to the business software.

Key Ideas to Remember

• Project execution frequently does not proceed as planned.

• Replanning is necessary when the current plans no longer help managers guide their projects to completion on time and within budget or help them achieve project objectives.

Case Study: Managing Plans Is in the Details

Directions

When reading this case study, focus on the activities and decisions that are part of planning and executing software projects that share resources with other projects or activities. Observe the points of view taken by people who manage software development projects in comparison to those who manage field service activities. You may find it helpful to review the terminology related to earned value for the first case study in the chapter (“To Replan or Not to Replan?”).

Case Summary

Description

SmartElectronics is a company that has fine-tuned its technical expertise but has limited management expertise. Managers struggle to plan projects in a timely fashion and often find that their projects deviate from the plans. The resource needs of different projects and software activities frequently conflict. The company’s director of software development, Alice McCaddish, creates a Process Analysis Team called PAT to study these problems and to propose ways to improve the management of software projects and resources. The case study gives an overview of the PAT discoveries and lets you decide what improvements should be made.

Case Study Objectives

After reading the case study, you will be able to do the following:

• Understand issues, problems, and decisions related to the following activities:

• Planning and tracking projects

• Managing dependencies between plans and subplans

• Managing software projects that share resources

• Selecting and using software project management metrics and tools

• Explain the problems that occurred in the case scenario, the causes of the problems, some plausible solutions to the problems, and ways to eliminate the problems in the future or to reduce their impact. Relate these to the decisions faced by project stakeholders.

Subjects Covered

Managing projects that share resources, project management data and metrics, and project planning and tracking

Setting

The setting is the software development center for SmartElectronics in Adelaide, Australia. The company specializes in the research and development of medical devices. SmartElectronics is a privately held company founded by professors from Southern Australia University. The company employs more than 500 people, including a large proportion of software engineers.

Key Concepts

• Software project planning and tracking requires attention to detail.

• When making decisions about using techniques and tools for project planning and tracking, software project managers should consider the following:

• The capabilities and limitations of the techniques and tools

• The nature of any tracking data that will be collected as well as how it will be analyzed and used to manage the project with respect to the project plans

• The ease by which the project staff can use or learn to use them

• The ease by which they can be used across projects that share resources

Terminology

Earned value (EV): See the definition provided in the “To Replan or Not to Replan?” case study.

Planned value (PV): See the definition provided in the “To Replan or Not to Replan?” case study.

The Case

Scenario

Alice McCaddish, the director of software development, has gathered the following software project managers for a weekly status meeting:

• Alan Brown, manager for Release 2 of the Robo Surgeon Assist (RSA) product

• Sansan Chin, manager for Release 3 of the Robo Nurse Assist (RNA) product

• Deepak Patel, manager for Release 1 of the Robo Home Healthcare (RHH) product

“Good morning, and welcome to our weekly status meeting,” Alice greeted the project managers.

“As shown in the meeting agenda, we are going to spend some time today discussing project planning and management issues or problems that you think are affecting our ability to deliver quality software on time and within budget. Our objective is to find areas for improvement that will help us to keep our products competitive in the market,” she continued.

“But first, we will review the status of our projects. Alan, how is your project going?” Alice asked.

“My project is still behind schedule. The earned value is running about 95 percent of the planned value. Our actual costs are about 98 percent of the planned costs. One problem is that we are short-staffed. Two of our key software engineers are currently fixing an ‘unacceptable feature’ that was detected in the field for Release 1 of the RSA product. We need these engineers to help complete the requirements and effort estimation for Release 2,” reported Alan.

“What is the feature, and why is it unacceptable?” Alice asked.

“The feature involves calibration information that was used when designing Release 1 of the RSA software. The customer reviewed and approved the calibration requirements for Release 1, and the software passed the system tests based on this information. Now the customer has different assumptions about calibration that invalidates some of the earlier calibration requirements for the software. The software does not perform in the field as the customer expects. This is why I call the feature unacceptable rather than defective,” Alan explained.

“This must be the issue that you called me about last week, the one regarding the robot arm that jerks when being calibrated. Are the customer’s assumptions valid?” Alice inquired.

“That is the one. Though the customer’s environment is not typical, the customer’s assumptions are valid. Robert Davis [the director of field service] has made it clear that this customer will purchase more RSA robots once Release 1 passes the customer’s tests. The unacceptable feature is not a safety issue but is considered important by marketing and sales,” Alan replied.

“Are there other staff members who can temporarily replace the software engineers who are modifying the calibration software?” Alice asked.

“Probably, but it would take more time and money to find qualified staff and to bring them up to speed on the product than it will to modify the software. We’re trying to shorten the planning time for Release 2 by using a more systematic approach to effort estimation based on an analysis of the historical data from Release 1. This will help if we are not bogged down in resolving issues regarding the requirements and modifications to the architecture for Release 2. I have encouraged the project planners to move forward by defining tasks with time allocated for the exploration and resolution of open issues instead of waiting for the requirements and architectural issues to be resolved,” Alan explained and sighed.

Alice raised her eyebrows and then asked, “How is the RNA Release 3 progressing?”

Sansan reported, “The project is almost on schedule with the earned value running about 99 percent of the planned value. There were fewer defects reported in the field for Release 2 than for Release 1, so we can spend more time on new features for Release 3.”

Then she added, “The field service organization has once again [with emphasis] requested our help in providing a feature enhancement between releases for a very important customer. The additional feature involves the tracking and reporting of patient vital signs over time. The staff members who are most knowledgeable about the tracking and reporting parts of the system related to the enhancement are currently needed for the detailed design of Release 3. Their expertise is particularly important for the review of the detailed design, test plans, and test cases. Most notably, I have only one software engineer working on creating graphical displays, which the customer wants to be part of the report.”

“Robert tried to convince me that the enhancement was critical to the customer and that the feature upgrade could then be offered to other customers in Release 3. He is asking us to expand the scope of Release 3 in order to satisfy his service request,” Alice stated. “Can we split the time of the software engineers so that they could perform the review tasks while working on the enhancement?”

Sansan cautiously answered, “Yes, but we would still take a hit on the Release 3 schedule.” Then she asked, “Who will pay for the additional development cost?”

Alice said, “Please provide me with an estimate of the projected impact on the schedule and budget. Meanwhile, I will talk with the marketing and sales people to learn more about the need for this feature between releases.”

“How is the RHH project coming along, Deepak?” Alice inquired enthusiastically.

Frowning, Deepak replied, “Well, we have the typical new product challenges. Project planning is slow with the earned value at about 93 percent of the planned value. There has been some confusion in tracking progress. For instance, some people count tasks that are complete or nearly complete to determine the earned value; others count only the tasks that are complete. I have asked the team leads to count only tasks that are complete and to be certain that their teams do the same. The software engineers working on the architecture are slow in reaching a consensus, which is holding up task planning. Because RHH is a new product, we do not have any historical data for estimating the effort for tasks.”

Deepak lamented, “Many of the software engineers who worked on my past project are currently involved in other projects. I am finding it difficult to find suitable staff members for my project. The employee profiles in the Human Resources (HR) database are not complete, and the terms used to describe employee skills and knowledge vary a lot. I wish that we had a more effective way to recruit staff members for our projects. For instance, I am looking for a software engineer who has developed software to interface with radio frequency identification (RFID) devices. We want to use RFID technology to sense and track items in a person’s home.”

“A thorough search of the HR database yielded no results. Then yesterday in the cafeteria, I overhead a colleague, Joe Montgomery, mention that the company has hired a few software engineers with experience in developing RFID applications. Joe is helping me locate the new employees. It should not be so difficult to find qualified staff within the company,” Deepak complained.

Alice replied, “Let me know if you need my help in obtaining time for one of the new employees to work on your project.”

She waited a moment and then said, “We have some common project management problems to solve. Let’s list a few that you highlighted in your status reports. I’ll start with an obvious one: the way in which we handle field service requests is interfering with our development projects. What others do you see?”

Alan contributed, “We have problems in planning development projects. We are slow in making decisions about tasks and resource needs. Estimating the resources that we will need for project tasks is difficult.”

Sansan added, “I think we could improve our estimates if we would systematically compare past project estimates to the actual data and make suitable adjustments. We do not have access to historical data for products other than the ones on which we have worked, and we do not fully understand how to use historical data across products and projects.”

“Project planning is delayed by our slowness in architecting the software for new products. We are plagued by analysis paralysis,” Alan said. “Project planning is also delayed when planners wait for the resolution of requirements issues rather than planning for the exploration and resolution of these issues.”

Sansan commented, “My teams also find it difficult to plan tasks and schedule staff when tasks go across subplans and when staff members work on tasks that are described in multiple plans. Our project management tools do not help us to coordinate tasks and resources across plans.”

Deepak suggested, “I think we should add to the list the problem of staffing our projects. When the company was small, the project managers knew all the staff and could easily recruit project members with the needed knowledge and skills. As the company grew, the employee profiles became important for locating new project members, but these profiles are not adequate.” He expounded, “To add fuel to the fire, there is the competition between field service and development for software engineering and product expertise that Alice mentioned.”

Alan explained, “The reason for this competition is the way in which we handle problems found in the field. In the past, defects involving safety and reliability issues took precedence over product enhancements; but because of increased competition, marketing and sales is pressuring us to handle more customer requests between product releases. Our competitors are catching up with us in their acquisition of core robotic technology and will start to compete on features such as user interfaces and report generation.”

Sansan added, “After the first release of a product, we must conduct a trade-off between new features and bug fixes for successive releases. We are slow in establishing the requirements for a product release, which in turn slows project planning. This will certainly hurt us down the road.”

“OK, here is the next step,” Alice said. “We are going to quickly ramp up a small team of experienced software engineers to study these problems in more depth and to identify others that we may not have mentioned today. I will bring in a consultant to lead this study and to help us develop and execute a plan for resolving our project planning and management problems. I would like each of you to recommend a team lead who is interested in these issues and who is also available to work on a process analysis team that we will call PAT. Please send me your recommendations by next Tuesday.”

PAT Study and Approach

Alice McCaddish hired a consultant, Georgiana Howard, to lead the PAT study. The three lead software engineers selected for the team were Michelle Bowman (Robo Surgeon Assist product), Chakra Neil (Robo Nurse Assist product), and Rob Lin (Robo Home Healthcare product).

To kick off the first meeting of the PAT team, Georgiana asked, “What area of project management do you think needs the most improvement?”

“Project planning,” Michelle, Chakra, and Rob quickly replied in unison.

“Especially task planning and estimating the effort and resource needs for tasks. I dread this part of project planning,” Chakra said.

Michelle added, “We spend a lot of time developing a project plan, and then we have to replan because of an ‘urgent request’ from the field service organization. These requests always seem to take the wind out of our sails just as we ramp up a project. We eliminate most defects through extensive review and testing, but there are always some ‘high-priority’ requests from the field for every product release.”

“I wish that I had time to attend a project management class or a training seminar on project planning,” Rob commented.

“It sounds as though you agree on a major area for change. However, before we can suggest changes to be made, we need to understand better the problems that exist. To start, we have the list of problems identified by the project managers of the RSA, RNA, and RHH products. To gather more information, I suggest that we interview all the managers of software development projects as well as the team leads. We can also interview the director of field service, Robert Davis. We should develop a list of questions to structure our interviews,” Georgiana explained.

“That sounds like a good idea. How extensive should these interviews be?” Rob asked.

“Since you all agree that project planning is a key problem area, I suggest that we focus at first on project planning and tracking. We can review the results of the interviews to see whether we need to make any adjustments to our approach before we move on to other areas of project management. We can start by outlining some of the major tasks involved in planning and tracking,” Georgiana said.

“We could ask the interviewees how their projects accomplish each task and what problems they encounter in doing these tasks,” Chakra reflected.

“That’s what I had in mind,” Georgiana replied.

“I would like to know more about the metrics and tools that our projects use. I think we could be more effective in project planning and tracking if we could use metrics and tools appropriately. Maybe we also need some new tools,” Michelle said.

“At this time, we know that Deepak Patel reported confusion in the way people on the RHH project were reporting earned value. In addition, Sansan Chin said that the management tools do not help project planners coordinate tasks and resources across plans. We should learn more about these issues and determine whether there are any other problems or issues involving the use of metrics or tools. We might also look for opportunities to improve project planning and tracking through the use of metrics or tools,” Georgiana replied.

The PAT team listed activities involved in software project planning and tracking. Then the team composed directives for the people being interviewed.

For software project planning and tracking, the PAT team asked the interviewees to explain how their projects perform each of the following activities:

1. Determining an appropriate task breakdown

2. Determining the human skills and nonhuman resources required for tasks

3. Estimating the effort and cost required for tasks

4. Developing a schedule and budgetary plans

5. Selecting and scheduling staff (staffing plan) and nonhuman resource usage

6. Creating and working with subplans

7. Tracking project status with respect to plans

8. Handling customer service requests

9. Measuring project success

In particular, the team asked the interviewees to describe any issues or problems that their projects had encountered when performing these activities. To gather information about issues involving the use of software project management metrics and tools, the team asked the interviewees to describe the following:

• Metrics and tools that your projects use to measure status and success with respect to scope, time (schedule), quality, and cost (budget)

• Issues or problems that their projects have encountered in using project management metrics or tools

In particular, the team asked the interviewees to explain how these issues or problems have affected the ability of their projects to achieve project objectives.

Results of the PAT Study

Over the next three weeks, the PAT team conducted the interviews and summarized the results. You may want to scan the results for each planning and tracking activity now and read them in more detail later when you work on the analysis activity.

1. Determining an appropriate task breakdown:

• Establishing the requirements is frequently slow and delays task planning.

• Developing a high-level architecture for a product or system delays task planning (especially for the first release of a product or system). The software architects are prone to analysis paralysis.

• Planners wait for the resolution of requirements or architectural issues rather than move forward by planning for the exploration and resolution of issues.

• Creating and tracking tasks across plans and subplans is tedious and errant.

• Product teams differ in their development approaches and documentation. There is almost no reuse of knowledge about tasks across products.

2. Determining the human skills and nonhuman resources required for tasks:

• This is particularly challenging for the first release of a product because no staff has worked on previous versions of the product.

• There is limited reuse of knowledge across product lines with similar product features.

3. Estimating the effort and cost required for tasks:

• Different approaches to estimation yield inconsistent estimates within and across projects or field service activities.

• There is no transfer of knowledge when staff members leave the company.

• There is limited reuse of historical data across product lines or projects.

4. Developing a schedule and budgetary plans:

• Project planners struggle with how to schedule tasks that are dependent on the resolution of issues such as those related to requirements or architecture.

• Some project planners allocate extra time to tasks to allow for estimation errors and other unplanned events, while others do not. In the first case, project managers frequently argue with marketing regarding the need for a longer time to product release; and in the second case, project managers often must defend the need to extend the product release date.

• The project planners do not effectively use product scope and quality (through iterative product releases) to control the time to market.

• SmartElectronics does not have standard cost models to help in determining the budget for projects or field service activities. (There is a standard overhead to cover expenses such as building maintenance, utilities, employee benefits, and so on.)

5. Selecting and scheduling staff (staff planning) and nonhuman resource usage:

• It is difficult to find appropriate staff using HR’s employee profile database.

• The terminology that employees use to describe employee skills and experience varies and is not consistent.

• Hiring of new staff occurs even when there are available, qualified staff members in-house because it is difficult to locate them.

• Employees tend to stay on the same product line for a long time. It is therefore difficult to share experience across product lines and projects.

6. Creating and working with subplans:

• Scheduling and tracking tasks that go across plans or subplans is a tedious and manual process with no assistance from project management tools.

• Scheduling and tracking staff whose tasks go across plans or subplans is also a tedious and manual process.

7. Tracking project status with respect to plans

• Project members are inconsistent in collecting data to track project status.

• Staff members on the same project may vary in their approach to tracking project status (for example, some project members use partial earned value, while others use the traditional approach of counting only completed tasks). This leads to confusion.

• Project managers are reluctant to “abandon” plans that are not working.

8. Handling customer service requests:

See the “Synopsis of Key Resource Management Problems” section on the following page.

9. Measuring project success:

See the discussion that follows.

Software development projects measure success with respect to scope (completion of planned project deliverables), time (days ahead or behind schedule), quality (passing system tests), and cost (percentage below or above budget). Completion of a product release that demonstrates the required quality attributes on time and within budget constitutes success.

Although the field service group also measures success with respect to scope, time, quality, and cost, the field service definitions for these dimensions of stakeholder expectation are different from those for software development projects. Some example definitions are the following: scope (number of customer service calls closed per reporting time period), time (average response time to handle a customer service request), quality (weighted average of customer service ratings with the weights dependent on the importance of the customers), and cost (average cost per customer service request).

Their different views of success make it difficult for software development projects and field service to share resources. For instance, a software development project may determine that the additional time and cost associated with having project staff work on a particular field service request does not add sufficient value to the scope and quality of the next product release. Meanwhile, the field service group may perceive that the field service request has high value because the request is from an important customer. Likewise, servicing a field request often involves the issue of whose budget will cover the cost of work done by software development staff. There is currently no company policy for how to budget the cost of shared resources.

The PAT team discovered the following issues or problems regarding the use of project management metrics or tools:

• Software engineers must learn “on the job” how to collect and use data that can help them plan and track their projects.

• The use of project management metrics and tools depends on the interest of the project managers or team leads. There is limited sharing of knowledge.

• Software engineers are reluctant to spend time collecting data about their work and how they do it. The tools do not make data collection easy and automatic.

• The tools being used do not provide automated help with effort estimation, which is a particular problem for project planners.

• The tools do not help in coordinating tasks or staff across plans or subplans.

The PAT team members also drafted a synopsis of two key resource management problems that they identified through their interviews. Their synopsis appears next.

Synopsis of Key Resource Management Problems

Problem 1: After a new product release, conflicts frequently occur between the staff needs of the software development and field service organizations.

In general, field service engineers are able to handle customer service requests on their own. They receive training after the release of a product and continually increase their own knowledge as they help customers use the released product. “Low-priority” defects found in the field are typically not repaired until the next release of the product and therefore do not usually place demands upon the development organization between product releases.

The conflict occurs when the knowledge and skills of software engineers who developed a product are needed to repair “high-priority” defects detected in the field or to enhance a product between releases. These engineers are usually working on the next release of the product and must be taken away from their current development activities to produce interim versions of the software. Software project managers must first determine the overall impact of the time spent on interim bug fixes or enhancements and decide whether they can accommodate these field service requests. Delays in responding to field service requests often occur. As a result, the field service engineers take their requests for help from the development organization to the director of field service, who in turn takes them to the director of software development. The overall process of coordinating bug fixes and handling special enhancements between product releases is slow and disruptive.

The problem is complicated by the fact that software engineers tend to move on to similar development assignments in successive product releases. Software developers become experts on particular aspects of products and become the “owners” in some sense of product features. Software engineers are rewarded for high productivity and low error rates, a policy that motivates them to focus their knowledge and expertise within a particular product and on specific product features. This specialization makes it difficult to find alternative staff members who can work on field service requests. It also constrains the staff planning for a project.

Problem 2: Resource planning across software projects for different products, as well as across development projects and field service activities, is difficult to manage.

The tools for software project management do not automatically take into account the use of staff members and other resources across different software development projects and field service activities. There are currently no master plans other than the HR employment records that show staff allocations. Software projects to support product-line development tend to invest in and reuse their own project members and equipment. There is minimal sharing across product lines. Software development managers have discussed the need for master plans across product lines and projects to track staff and other resource allocations. To date, the development organization has not addressed this issue with the field service organization.

Recommendation for Project Planning and Tracking Improvements

The next step for the PAT team is to draft a recommendation for process improvements that would alleviate the issues and problems outlined in the results of their study.

What recommendations do you have for solving the problems outlined in this case study?

Case Problem

The SmartElectronics software development organization is not able to manage its projects effectively. Most notably, project planning is frequently behind schedule, and diverting development staff to handle high-priority field service requests results in project delay. Managers find it difficult to staff their projects because accurate and complete information about employee knowledge, skills, and experience is not available. There is little sharing of historical data across products and projects.

Case Analysis

Analysis Activity

Analysis Questions

1. What are the primary problems that plague the SmartElectronics software development organization?

2. After a careful review of the PAT study results, draft some recommendations for improving the way in which the software development organization plans and tracks projects. Include some recommendations for managing resources across products, projects, and field service activities.

3. If you were a software project manager at SmartElectronics, how would you decide to implement your recommendations for improvement? Is there other information that you need to know to make this decision? Use the PEAK model to evaluate your decision.

4. What do you think are the training or educational needs of the software development organization?

Key Ideas to Remember

• Project management requires attention to multiple details in a timely manner.

• Successful project planning and tracking depends on the appropriate use of metrics, tools, and processes. It is worthwhile to study how your project performs project planning and tracking to make any needed improvements.