Info iconThis preview shows page 1. Sign up to view the full content.

View Full Document Right Arrow Icon
This is the end of the preview. Sign up to access the rest of the document.

Unformatted text preview: • Case Study: The UniWord Project The UniWord case study presented in the next subsection describes a project, which did not perform much risk management, and therefore had poor results. It is described in terms of the assessment portion of an audit report done by a consultant hired to assess the status of the project. The case study is a synthesis of two projects, which between them experienced risk items very similar to the ones described. The UniWindow operating system, an extension of UNIX (TM Bell Labs) supporting fast, powerful window management. Universal is contracting with several software houses to produce software packages for the UniWindow. Universal developed a set of high-level functional specifications for a work-processing package called UniWord, and used these specifications as the basis for a request for proposals (RFP) which was sent to a number of software houses on July 15, 1983. Universal's schedule for the procurement was keyed to have a demonstrable set of products to exhibit at the 1984 National Computer Conference in Las Vegas, July 9-12, 1984. Thus, they scheduled one month for proposal response, one month for source selection, and nine months for software development, as follows: Audit Report: UniWord Project Scope This report presents the results of a two-week audit of the UniWord project. The project was undertaken by SoftWizards, Inc., under contract to Universal Micros, Inc., to develop a word processing system for Universal Micro's UniWindow workstation. The report will cover the audit's charter, procedures, findings, and recommendations. In this draft of the report, the recommendations are still to be determined. July 15, 1983: RFP August 15, 1983: Proposals due September 15, 1983: Project go-ahead June 15, 1984: Product delivery Charter The competition (July-September 1983): Five companies responded to the RFP. Three more declined to bid, saying that nine months was insufficient time to develop the amount of software specified. Two of the five bidders were clearly not qualified to do the job, and one company's price was much higher (over $1 million) than the two remaining bidders, SoftWizards and Text Products, Inc., each of which bid around $400K. Universal Micros asked these two companies to submit a Best and Final Offer. George Green, SoftWizards' president, felt that the UniWord job was a key win for his company. SoftWizards had done some text editors, but never a full word-processing package. UniWord would help SoftWizards achieve a leading position in developing software for multi-color, window-oriented personal computers and workstations, clearly the wave of the future for software products. Also, some of his systems programmers needed some contract coverage for their salaries. As a result, SoftWizards' Best and Final Offer proposed even more functionality than requested by Universal, reduced the price to $300K, and still committed to deliver the product in nine moths. There was a $10.00 per workstation license fee for UniWord also in the package, so George Green felt that he could recover his $100K if 10,000 UniWindows were sold. This bid was so much more attractive than Text Products' bid that Universal Micros accepted it at once. Final contract negotiations ($300k, fixed price) went smoothly, and work commenced on September 15, 1983. Project startup (September-October 1983): Six people were assigned to the UniWord project. The two key people were: The audit's charter was to determine the technical, financial, and management status of the UniWord project, to identify problems needing solution, and to recommend solutions. The audit was to be performed by one person within a two-week period. Procedures A kickoff meeting was held with Joan Black, Universal Micro's product line manager for the UniWindow product; George Green, SoftWizards, Inc. president; and Bill Brown, SoftWizards' project manager for UniWord. We agreed on the scope, charter, procedures, and information sources to be used in the audit. Interviews were held with all five remaining SoftWizards project personnel, one previous project member, and three Universal Micros personnel. Documents reviewed included the contract, project plans, and UniWord specifications, plus selected portions of the code listings, user documentation, and accounting records. Findings The audit findings are summarized in a project chronology and a project status assessment. Project chronology: Universal Micros, Inc., has been developing a new product: An advanced personal computer or workstation called the UniWindow. It will be driven by two Universal 3215 32-bit, 15-megahertz microprocessors, and will have the following major features: • • • • A high-resolution bit-mapped color display device 1 megabyte of main memory A 20-megabyte Winchester disk drive 1 Bill Brown, the project manager, had experience in developing a CP/M-based editor, but no experience with UNIX or with other components of a word-processing system • system (DBMS) and a full-capability query language, rather than a simple file system. Although this was not formal customer direction, Sam Silver responded eagerly. He quickly began to develop a good-sized relational DBMS with extensive natural language query capabilities. The extent of this redirection was not evident to Bill Brown until mid-April. When he found out about it and discussed it with Silver, he was concerned that it was a much bigger job than Silver could carry out in the time available. But Silver assured him that he could do it, and said that he had to proceed this way because that was what the customer wanted. Brown decided not to make an issue of this with the customer, as he was not eager to discuss other issues with the customer as well. Brown's main difficulty was in integrating the components of UniWord. It was taking virtually all of his time and attention. Each component now existed in several versions, and it was hard to determine which was the right one to use at any given time. Also, there were no interface specifications between the components, so when interface problems occurred, they were hard to diagnose. Worse yet, when an interface problem was identified, there was no foundation for determining who was responsible for fixing it. All of the UniWord developers were already busy trying to catch up on their own components, and nobody wanted to change their programs just to accommodate someone else's. This led to further arguments, delays, and loss of morale. SoftWizards' rescue attempt (April-May 1984): By this time, it was late April, and Bill Brown knew that there was no way that his current team could solve their problems and deliver UniWord by June 15. So he appealed to George Green, saying that customer wishes had caused SoftWizards to add some new capabilities such as the relational DBMS. These functions would be very valuable to SoftWizards, but they were causing him to have schedule problems with integration. If Green could provide him with four experienced people for six weeks to help with integration, the rest of Brown's team could concentrate on getting their components finished, and he could deliver on schedule. George Green considered going to Universal Micros to ask for schedule and budget relief to compensate for the added UniWord capabilities. Bill Brown recommended against this, saying that there was no written request from Universal Micros for the added features, and the likely result of the request would be a nonproductive delay. Green therefore decided to pull four people off some other SoftWizards projects for six weeks to work on integrating the UniWord components. The four rescuers were capable people, but they knew nothing about UniWord. There was very little documentation available, and it was generally out of date. So the new people had to spend a great deal of time asking questions of the component developers, with the result that the developers' progress slowed sown even further. Universal Micros assesses the situation (May-June 1984): By the end of May, it was clear that very little progress had been made, and that a June 15 delivery was impossible. George Green decided to present the strongest situation possible to Karen Gray, the deputy project manager, had considerable UNIX experience, was an expert user of the Unix text editor "vi," but had no word-processor system development experience Brown and Gray had significantly different ideas as to how the text editor should operate. Brown preferred to use a few simple commands invoked by function keys and menu choices. Gray preferred to use a powerful, extensive set of one-letter commands and a separate mode for text entry. All six project members gravitated into discussing and researching this issue, with little consideration going into the other components of the product. After about a month, Brown felt he needed to get the other parts of the project moving along, and decided to let Gray proceed to implement her model of a text editor. He then went on to develop the other components by using his approach. Early problems (October 1983-February 1984): Around January, some pieces of the product had been coded and debugged, and Bill Brown began to put them together to test them. This was initially difficult, because of a lack of test data and test drivers, but by mid-February some initial capabilities were available. Brown then found that the pieces didn't fit together very well. Karen Gray's file structures, edit buffer conventions, and window controls were incompatible with their counterparts in the format/runoff and file manager components. Clearly, some compromises were needed to get the components to play together, but after some extended arguments with Brown, Karen Gray left the company rather than compromise on her approach. Fortunately, her programs were extremely well-structured, but they capitalized on so many exotic capabilities of Unix and C that they were still hard to understand and modify. The file manager was proving too much of a challenge for the two junior personnel developing it. Key features were missing (e.g., list and delete files), and the features present were slow and cumbersome. Sam Silver, SoftWizards' DBMS expert, was brought aboard the project to rescue the file manager. Problem interactions (February-April 1984): By mid-March, work was proceeding on the various rescue efforts. Although he didn't have a specific schedule of events, Bill Brown was optimistic that the project's problems were solved, so he continued to report that the project was on schedule. Unfortunately, there were more problems than he realized, and even further problems were developing. Attempts to modify Karen Gray's text editor frequently encountered mysterious side effects, so it was decided to leave the text editor as is, and to build an outer layer around it to communicate with users and with the other UniWord components. This was harder to do, particularly for the user interface, than originally envisioned. Another difficulty resulted from a conversation between Sam Silver and an enthusiastic Universal Micros marketer, who said that UniWord really needed a relational database management 2 • Universal Micros. He arranged a meeting with Universal Micros at which he: • Demonstrated the strongest features of Karen Gray's text editor • Presented a summary of the added UniWord capabilities requested by Universal Micros personnel • Stated that by June 1, SoftWizards could deliver a package of software that literally satisfied the rather loose terms in the contract, but said that nobody would be happy with that outcome • Cited SoftWizards' additional $50K investment in getting UniWord to work, and requested another $100K and three months' calendar time from Universal Micros to deliver the full UniWord product Joan Black and the Universal Micros people were not at all pleased by this proposal. They did not like the Karen Gray text editor. They felt that it did not take advantage of the UniWindow workstation's strengths: its advanced mouse pointing-device and its rapid, flexible window management capabilities. Universal had prepared a great deal of publicity for the National Computer Conference, and the SoftWizards text editor came nowhere near fulfilling Universal's claims for UniWord. Some people at Universal felt that they should take SoftWizards to court, but others felt that Universal's legal case would be weak. In any event, what Universal really needed was a word processor, not a lawsuit. In a meeting on June 7, Universal's top management decided not to include UniWord in their UniWindow exhibit at the National Computer Conference, and to engage an external consultant to assess the situation and to evaluate Universal's options. George Green agreed to have SoftWizards fully support the consultant's audit. As a result, the author of this report performed a two-week audit of the UniWord project between June 14 and June 29, 1984. • In addition, the three components vary significantly in their use of color. An attempt was made to provide a front-end for the text editor to make its user interface comparable to that of the format/runoff component, but it was not very successful. Making the text editor and file manager consistent with the format/runoff user interface would require a major effort (at least four months' full-time effort of two highly experienced persons, one for each component). Product features-other: Structured code: One strong feature of all the UniWord components is that the code is highly modular and well-structured: Organization into components: The separation of the text editor and format/runoff components meant that the project missed the opportunity to integrate these functions into a single, "what you see is what you get (WYSIWYG)," text composition capability. This capability is particularly well-suited to the high-resolution, window-oriented UniWindow workstation. Overlaps and inconsistencies: There are a number of overlaps and inconsistencies among the components. Some examples are: • Project Status • The status of the UniWord project is summarized in six categories; 1. 2. 3. 4. 5. 6. The text editor component has two modes: one for commands and one for text entry. An overpowering variety of one-letter commands are available. They combine in powerful but obscure ways. There is relatively little user feedback on results. The file manager has an English-like query language approximating free text. It operates in a separate control window that provides user feedback, but otherwise it does not capitalize on UniWindow capabilities Product features: user interface Product features: other Product control Management Personnel Finance The text editor "quit" command has options for saving and naming files that don't match those of the file manager Format/runoff has edit features for formatting commands, page headers, etc. that don't match those of the text editor Inter-component interfaces: There are many interface inconsistencies between components. Some examples are: • • Product features: user interface: The most serious problem with UniWord is that its three main components have three entirely different approaches to the user interface: • The format/runoff component has the best match to the capabilities of the UniWindow workstation: a separate control window for menu options and user feedback, and the user of the mouse for menu selection • 3 Files with embedded format commands are structured differently than pure text files, complicating interfaces with the file manager Format/runoff assumes that an end-of-sentence is any occurrence of a period, question mark, or exclamation point followed by two blanks. The text editor has more complex rules, considering quotation marks, parentheses, brackets, etc. There are numerous inconsistencies in parameter passing, edit buffer conventions, and window controls Some team members are not well qualified for their assignments. Details can be provided separately. UniWindow interfaces: Universal Micro made several changes in the UniWindow workstation (window management procedures, mouse button interpretations, escape key conventions) that were only informally communicated to the UniWord project staff. This resulted in irregular and inconsistent accommodation of these changes among the various UniWord components. Finance: Universal Micros has paid $300,000 to SoftWizards in three equal installments. SoftWizards' financial reporting and control system is rather loosely structured. Their charges to the UniWord project are: Expenditures Outstanding Commitments Total Missing capabilities: Several UniWord capabilities specified in the contract have not been implemented. Some examples are table processing and section numbering capabilities. SoftWizards has agreed to pay the additional $4,563 in outstanding commitments. Product control: The UniWord project does not have a change control system. There are no baselined master versions of specifications or programs. Many versions of programs and documents are in circulation. There is no central directory of the product's components or deliverables. These factors cause many problems and delays in project activities, particularly in product integration and test. Options and Recommendations To be determined. This is the end of the case study. Its risk issues will be covered in the various parts of Section 2. Product Management Project plan: Beyond some high-level Gantt charts, there was no evidence of a project plan. As a result, no preparation was made for a number of downstream activities. Some examples are: • • $298,541 6,022 $304,563 Preparation of test drivers and test data for integration and test activities Preparation of library capabilities for programs and documents Reviews: No project reviews were held to determine customer satisfaction with the user interface or other product features, or to ensure that the project was ready to proceed to the next phase. Milestones: Other than the high-level Gantt charts, there were no individual milestones established to track progress. Team members' weekly status reports included percent complete estimates. These would generally reach 90 percent about halfway through the job, and would be useless thereafter. Scope changes: Changes in the project's scope of work were initiated without consultation with the customer, or consideration of their impact on schedule and budget. Personnel: Morale is very low among the project personnel. There are major doubts that the product can become successful, and a great deal of uncertainty about the project's future. There are still major unresolved differences among project personnel about technical issues: the user interface style, the use of color, the use of windowing, the type of modularization, and the extension of Unix capabilities. 4 ...
View Full Document

This note was uploaded on 04/12/2010 for the course CIS 635 taught by Professor Mcintyre during the Spring '10 term at Cleary University.

Ask a homework question - tutors are online