ETE-June 2010 Page 1 of 3 IMT-100

INSTITUTE OF MANAGEMENT TECHNOLOGY CENTRE FOR DISTANCE LEARNING

GHAZIABAD End-Term Examinations – June 2010

Subject Code : IMT-100 Time Allowed : 3 Hours Subject Name: Software Project Management Max. Marks : 70

Notes: (a) Answer any FOUR questions from SECTION-A and CASE STUDY as given in SECTION-B.

Each Question (SECTION-A) carries 14 MARKS and (SECTION-B) Case Study carries 14 MARKS. (b) For students enrolled before January 2008, the Question Paper would be treated for 50 marks instead of 70 marks. (c) No doubts/clarifications shall be entertained. In case of doubts/clarifications, make reasonable assumptions and proceed. SECTION-A MARKS : 56

Q.1 (a) What do you mean by Work Breakdown Structure (WBS) in context to software Project and product? Discuss with example. Also list three benefits of WBS?

(b) It has been said that the design cannot be directed by technical experts alone. Do you agree with this statement? Write in detail to support your views. Give various responsibilities of a project manager along with structure of organization.

Q.2 (a) End user demands are the source of most software project. Also give various steps of a software project plan.

(b) What are the three main elements of a project charter?

Q.3 (a) As size is the main factor determining the cost of a project, an accurate size can be used to estimate the cost and schedule of the software project. Give your views in favour and in against of the statement.

(b) It seems odd that cost and schedule estimates are developed during software project planning before detailed requirement analysis or design has been conducted. Why do you think that this is to be done? Are there circumstances when it should not be done?

Q.4 Explain the following life cycle model in detail.

(i) Waterfall model

(ii) Prototype model

Q.5 (a) Who are the important stakeholders in software projects? Identify. Who are the important stakeholders in software projects? Identify.

(b) In the context of project management, explain the following terms: Activity, task, milestone, critical path, and slack.

Q.6 (a) What is SOW? In what document does the SOW appears. Briefly describe scope creep?

(b) What is PM triangle?

Q.7 You and two other students have been hired by a local swim team to develop a website that will provide information about the team. The information on the website will be used to recruit new swimmers and will provide information to current members about upcoming meets and practices. In addition, team and individual statistics will be posed after each swim meet. Before you begin, you need to develop a quality plan, the plan should include:

a. You own quality philosophy b. Two metrics for ensuring that reliability standards are met. c. A means for validating and verifying that your client’s need and expectation will be met.

ETE-June 2010 Page 2 of 3 IMT-100

SECTION-B (Case Study) MARKS : 14 Sunil was completely shattered. He was totally exhausted, both physically and mentally. He felt his career as a software professional was doomed. After toiling for almost nine months on one of the most grueling software project assignments he had ever had, the project itself was scrapped by the customer. He was totally at a loss to imagine what had gone wrong.

Although the project started nine months ago, to Sunil it seemed just a few weeks ago. Sunil was a lucky project manager indeed; he had been selected to lead a very prestigious software project. Almost all the components of the project seemed to be right. The project was being executed for one of the company’s largest customers. The customer team was tech savvy. The technology was state-of-the-art. The application being developed was expected to bring a dramatic increase in business for the customer, based on some very innovative thinking by the business users. Above all, Sunil felt confident this would be a successful project due to the excellent environment in which he was working. His manager was a very good senior software professional, and the team members were well skilled in the technology on which the application was being developed. All the required tools and other development environment were in place.

Sunil’s team followed all the processes needed in good software project execution. The requirements were done with due diligence and after a couple of thorough reviews, the customer signed off on the project. The design was carefully done, keeping both function and performance in view. The team included good developers and the code generated was of good quality. Early tests of some of the modules showed good results. Everything seemed to be going fine, Sunil recalled.

Of course there were a few hiccups on the way, but Sunil thought he addressed them quite well. Although there were a few slip-pages in the schedule, Sunil was confident of recovering. But now, as he recalled the events that happened during the early days, he wondered whether he really did a good job of fixing the issues and the connected risks. Did he fail to recognize the early warnings? He remembered each of these situations quite vividly:

Project Kick-Off: Immediately after the customer signed off on the big contract for the project, Sunil decided to do a detailed evaluation of the scope first including derived effort and schedule estimations. He brought a couple of senior team members and did an effort estimation based on the past experience of delivering similar projects. They had not previously sized a project of this magnitude; however, they had completed smaller projects and thought they would be able to do an extrapolation and arrive at a good guesstimate for the current project. They quickly realized that it was indeed a very large project. After several rounds of deliberations, it was decided to fix the delivery schedule at 15 months with an average team size of 30 members. The team was aware that the customer had a tight deadline and any further extension of schedule might not be allowed.

Schedule Renegotiation: During discussions with the customer on project execution strategy, team members realized that the customer was quite inflexible on the 10-month delivery schedule agreed upon during contract negotiations. Sunil had no option but to return to the drawing board and recalculate the project schedule and the related impact on other project delivery aspects. They had to do several review rounds to arrive at the best possible project execution plan. The reduction of schedule by 30 percent (from 15 months to 10 months) had a direct impact on the average team size, increasing it by a whopping 50 percent (from 30 members to 45 members). In order to reach this timeframe, they also reduced the buffer that had been built in earlier. As a result, all the phases of the software project were very tightly planned with little scope left to maneuver slippages.

Requirements Phase: During the requirements gathering phase, the scope was reviewed with the business users. The business users pointed out that due to recent changes in government regulations, the software application required specific changes in order to comply with the new regulations. This also meant changing the functional workflow of activities. Sunil’s team included all the relevant changes and did a quick re-estimation. The overall effort had gone up by another 6 percent. Once again, a negotiation with the customer to increase the schedule was denied. The result was an increase in team size by another three members. Sunil was worried about the possible impact and increased risk but was confident his team would deliver.

Design Phase: First serious signs of problems surfaced during design phase. The software was being developed on the Java platform. The technology vendor had recently introduced a new product that would dramatically change the way the business workflow could be manipulated directly by the end users. Although the product was a boon to the users, it meant two significant deviations to the project team: the team had to learn and understand features of the new product, and the team would need to invest additional effort to include the new product into the revised architecture of the software application. Overall, the effort went up again. Sunil’s team was rightly worried this time. The size of the project was ballooning, but the end date of delivery was not allowed to change.

Project Progress Review: Sunil felt it was time to escalate the situation to his manager internally. His manager decided to do a complete review of the project status. Another surprise was soon to be discovered. The project had already slipped by two weeks. The late changes in project scope and the last-minute changes due to the addition of the new product had made their impact on schedule slippage. This situation was further aggravated when it was discovered that the new product was still in beta and had quite a number of bugs that needed to be removed by the

ETE-June 2010 Page 3 of 3 IMT-100

vendor. By now the team size had grown to 50 members and it was looking almost impossible to meet the 10-month schedule.

Build Phase: During the coding stage, one of the key senior members fell ill and had to take two weeks leave. Two other developers decided to quit, thus adding salt to the wound. The early schedule slippage had a crunching impact on the time provisioned for the coding (build) phase. Despite Herculean efforts, the team found it impossible to meet the original deadline. Sunil had no other option but to go back to the customer to negotiate more time.

During discussions with the customer, the critical nature of the whole project emerged. The business users had planned strategically for this project to be ready in 10 months in order to meet a possible window of business opportunity that would last only a few months. Missing the deadline would mean a loss of business opportunity. The chances of similar opportunity occurring in the near future were almost nonexistent. Sunil was a depressed project manager when he returned from the meeting with the customer. The project team met to discuss the situation. Many enthusiastic younger team members felt there still was a last chance to meet the deadline if everyone pitched in with extra effort. The team decided to work extended work hours and weekends. There was an air of expectation and things seemed to improve.

But not for long. During early tests, serious performance issues were detected. Inconsistencies in coding standards followed by different groups within the project team were also found. This again was a setback that had a direct impact on delivery schedule. It was now impossible to meet the deadline under any circumstances. After internal deliberations with the team and Sunil’s manager, it was decided to convey the sad news to the customer. The only option was to extend the delivery schedule by three months. The customer was aghast at the proposal. The matter was escalated to higher management and after a couple of rounds of senior level meetings it was decided by the customer to scrap the project.

Questions

Q1. What really did go wrong?

Q2. In your opinion, What Sunil could do for avoiding this type of situation?