Case Study: SEWeb and Russoft Technologies

Directions

When reading this case study, focus on the risks encountered in the project as well as any risk management activities taken to minimize or mitigate them.

Case Summary

Description

Gene Fisher, one of the faculty members in the University of Madison’s School of Computer Science, is facing multiple challenges while working with a Russian company for developing the departmental SEWeb project. To take advantage of the low-cost offshoring opportunity, Fisher had outsourced software development to Russoft Technologies and is now faced with multiple issues involving communications, culture, language, and others.

Case Study Objectives

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

• List the risks and the decisions faced by clients working with remote development teams

• Recognize the consequences of not performing risk management activities explicitly on a project

• Review risks taken and decisions made on a global development project and to explore various alternatives

Subjects Covered

Risk management, decision making, offshore development, requirements management, customer communications, project estimation, planning and tracking

Setting

The setting is the United States and Russia during the 2002–2003 time frame. The software project involves Web-based system development, an academic client, a small budget, and a short time frame (less than one year).

Key Concepts

• How to handle remote development teams to minimize project risks

• The risks faced by project teams working in today’s global environment of offshore development

• The effects of decision making on project risks and on successful project management

The Case

Scenario

Gene Fisher was staring outside and watching as people left their offices for the day. It was November 2003, and he had just returned from another frustrating meeting with his technical project lead, Alex Rau, a meeting in which they both struggled to understand the mixed messages from their Russian counterparts 6,000 miles away in Novye Cheremushki, a little suburb 15 miles southwest of the center of Moscow. With the time difference and the cultural issues, it seemed that this project was continuously moving one step forward and two steps backward. Fisher wondered whether his recent trip to Moscow, ten days ago, had affected the situation at all.

The meeting with Russoft, in a local Moscow restaurant on a late November afternoon, was good yet tense. Russ Laughlin, Russoft’s CEO, and the newly assigned project manager, Mark Urlanski, were present. Fisher decided not to push the envelope too far and risk alienating his service providers—yet he was adamant that some major changes were going to have to be implemented in Russoft’s software development management process for this project to be successful. The project was over budget, at least over the one originally discussed. It had certainly exceeded the time frame suggested by Russoft for project completion in August (the finish date was already sliding into November with no end in sight), and the project still did not include some of the pieces requested by Fisher and his staff. Fisher now felt as if that discussion had never taken place. Fisher was certainly at a loss.

The Setting

Almost a year earlier, in fall 2002, Peter Johnson, the new director of the Master of Software Engineering Program at the University of Madison (UW Madison), had given the green light to start working on a massive redesign and implementation of a new student-faculty-staff Web site to expand the national and international reach of the program. With increased costs of marketing, application processing, and content management, Johnson wanted to replace the obsolete systems they were using and adjust the working procedures to maximize efficiency and reduce cost. He gave the project to Fisher, who had joined the department only a few months before, because of Fisher’s previous experience at successfully designing and implementing such a system for a different department on campus and because of his willingness to take on the project.

The budget was small, and Fisher had the responsibility, with minimal approval and oversight required, to select a local development team or to outsource the project. As the high-level requirements were being finalized by a team of dedicated individuals within the department (assisted by program manager Jane Weber and system administrator Al Molsters), Fisher conducted a search to understand both the technical capabilities that the potential service provider would need and the costs associated with implementing the system. Figure 7-1 shows the UW Madison project team.

Figure 7-1: UW Madison project team

Fisher recalled what had led to the decision to look for an offshore development team instead of one in the United States:

Hourly rates in the United States for Web development were ridiculously expensive. It was as if the dot-com meltdown had no impact on what people or companies were charging for their services. A typical development hour for a U.S. software house was close to (if not more than) $100. The same development hour would cost $6 in China, $8 in India, and $12 in Russia. For someone with a constrained budget of roughly $5,000, who was willing to compromise on the location but not necessarily on the design, there was no beating offshore development. Yes, I was concerned with some of the offshoring issues, but the local stakeholders seemed willing to accept and work through them.

Some members of the program’s staff and faculty at UW Madison were not as enthusiastic about the decision Fisher had made. To cover all his bases and to get a good look at the “whole picture,” he decided to send out requests for proposals to four other companies (none of which had worked with academic clients before), besides Russoft, whose proposal he already had. He asked for bids from LogicArt, a New York-based company with Russian operations; Wisto Technologies, a large India-based company headquartered in Oakbrook, Illinois; Grapple Effects, a Cleveland-based company; and DesignIT solutions located in San José, California. Even though formal criteria for deciding among them were not explicitly defined, a simple analysis including cost, references or reputation, location, and experience convinced Fisher to go with Russoft Technologies Corporation, a decision that confirmed his initial “gut feeling.”

Vendor Selection: The Russian Connection

The choice of going to Russia was not taken lightly or done randomly despite how it appeared. The decision was primarily a result of a trip that Fisher and Emillio Arroyo-Lopez, the Argentinean-born director of the department’s distance education program, took to Moscow and St. Petersburg a few months before, in early 2003, at the request of a UW Madison alumnus.

Yuri Kashnovsky, who had just founded LearnIT, Inc., a software training consultancy in the Russian capital, wanted to collaborate with the university by having UW Madison software engineering faculty conduct executive education and training seminars in software project management for project managers in Moscow. Fisher had received that assignment in August 2002, and his first trip was arranged for early March 2003 during one of the school’s spring semester breaks. Fisher remembered:

People at UW Madison seemed apprehensive when we told them we might go to Russia. Emillio and I saw this as an excellent opportunity to watch a country in growth and to get a close look at what the market was like and what software development houses were doing. We were certainly curious to see their ability to compete in the global economy with the Israelis, Indians, and Chinese. We were very much aware of the cultural issues and the potential communist-type mind-set, but we were going with open minds to explore and bring back some knowledge.

As part their trip preparation, both Fisher and Arroyo-Lopez took the opportunity to see who among the UW Madison faculty had previously traveled to Moscow and could give them useful tips and recommendations on what to pack, how to behave, what to see, and what problems might arise. They also discussed the trip with the following students in the software engineering program: Mukhit Ashgirov, a student from Kazakhstan; Natalya Girienko, a student from Russia; and Oksana Milov, a student from the Ukraine. The students reassured them that traveling in Russia was quite safe and that they would have an enjoyable time in the former Soviet Union.

The visit lasted more than a week and took Fisher and Arroyo-Lopez to two main Russian development centers, the capital city Moscow, and the city of St. Petersburg (formerly Leningrad) on the Baltic Sea. They met, through what seemed at the time to be an endless number of meetings, people from Motorola, HP, IBM, and Oracle. Sparing nothing during their visit, the Russians took them to the best restaurants and were gracious and generous hosts. Emillio Arroyo-Lopez reported:

We landed in Moscow on a flight from Spain where we had attended a conference. The Russians took us around and showed us the charms of their city. Their hospitality was impeccable. We even got a chance to see the magnificent Kremlin and Red Square. We really had a good time. Our week in Russia seemed to run too short, and we very much looked forward to coming back a second time to continue what we started. While in St. Petersburg, we met with Dr. Viktor Polutin, who was the managing director of Motorola’s R&D center in Russia. The facility was rather impressive. We toured a facility that looked like an American laboratory with high-end equipment, extremely motivated engineers, and experienced management.

While teaching project management concepts to a large group of 50 software project managers gathered from all over the country, Fisher and Arroyo-Lopez also met prominent Russian professors, local industry leaders, and representatives of the two leading IT trade organizations, Fort Ross and Silicon Taiga.

Through these meetings and the lengthy discussions that followed, some lasting well into the night, both Fisher and Arroyo-Lopez had an interesting firsthand glimpse at what it was like to develop software in this new and growing Russian economy. In a country that only a few years before was mass producing things primarily for government use, the spirit of capitalism and entrepreneurship was certainly at full swing. It was interesting to gain a better understanding of the practices used in Russia, of how the Russians were currently developing software, and of whether they had any gaps in their ability to work with U.S.-based clients using industry best practices.

Toward the end of their visit, Fisher and Arroyo-Lopez also met with the two co-chairs of the Information Technology and Telecommunications Committee of the American Chamber of Commerce in Moscow. Russ Laughlin and Peter Kower had been partners in a few business initiatives. The biggest one was Russoft Technologies Corporation, a company Laughlin had founded in Canada in the late 1980s as a software development house.

Russoft Technologies Corporation

Founded originally in 1989 by Russ Laughlin, a Canadian residing in Toronto, Russoft Technologies Corporation was a small software development house that specialized in custom development for the local North American market with a small established clientele in Canada and the United States.

In early 1992, Laughlin, a savvy entrepreneur with an acute business sense and a flare for adventure, was able to capitalize on an opportunity to work on a project developing software in Russia. Laughlin observed that the country was in dire need of experienced project managers and an “Americanized” style of doing business, because it was still in turmoil following Mikhail Gorbachev’s failed attempt at perestroika. He knew that those skills, coupled with a strong English-speaking ability, would give him and his company a substantial competitive advantage and a niche position in the market. The Russian industry back then had just started to convert from a government-centric provider to a private-sector-driven industry that did not know how to win foreign business, especially business coming from the United States and Canada.

Laughlin decided to relocate his entire technical operation to Moscow and to leave a small staff contingent in Toronto, Canada, in what later became his “official” headquarters for Russoft. Legally speaking, the company was based out of Toronto with offshore operations in Russia. Technically speaking, the company operated out of the fifth floor of building 219 on Profsoyuznaya Ulista, in a quiet, old, working-class neighborhood on the outskirts of Moscow.

By 2001, Russoft had four working offices worldwide, with Toronto and Moscow as the big centers and with Phoenix and Almaty as field offices to run projects in the United States and in the oil-rich country of Kazakhstan, respectively. With more than 50 full-time employees and a solid track record of delivering outsourced projects internally within Russia and externally to customers in Europe, Canada, and the United States, Russoft was fast becoming a noticeable player in the Russian outsourcing landscape.

Dennis Bramer, Russoft’s U.S. managing director, explained:

I joined Russoft Technologies in 2001 as the U.S. managing director. I was extremely impressed with Russ Laughlin, the company’s founding partner. In a country that wasn’t known to forgive business mistakes, Laughlin guided Russoft through more than ten years of market turmoil and grew it into a formidable second-tier provider of international software development.

Russ Laughlin was not only business savvy but also showed integrity. He was someone who was serious, didn’t joke around, and yet seemed like a real people’s person. He certainly knew how to network, was very involved in the local chapter of the American Chamber of Commerce, and knew the foreign business community quite well. In Kazakhstan, he was working on a very large project for one of Russia’s top oil producers, and people thought very highly of him and his services.

Commenting on the Russian operations, Dennis added:

In a country where only a handful of software companies had more than 100 full-time employees and where most development houses consisted of young entrepreneurs working out of their own backyard garages, Laughlin’s office was bustling with 50 to 60 full-time employees and was certainly something to notice, by any Russian standard.

The SEWeb Project

It all started more than a year before, in late summer 2002, as Prof. Peter Johnson was taking over the position of program director from Prof. Ed Schubert. Johnson, a pioneer in the field of software architecture, decided to increase the Web presence of the professional programs in software engineering through a rollout of a new Web interface.

As an analytical person who did not like to make fast, impulsive decisions, Johnson was concerned about what his staff was telling him regarding the way prospective applicants were now searching for software engineering graduate programs and what appeared to be the lack of the program’s readiness to address this trend.

John Foote, a faculty member, reflected:

We were witnessing a growing trend of people learning about our programs mostly through online searches and connections with program alumni. We typically polled incoming students at the start of the first term to gauge how and where they heard of us. Fewer and fewer people seemed to indicate that they used print ads, the famous Peterson catalog of colleges and universities, or even conferences where the program had an advertising booth. The World Wide Web was gaining momentum in how people searched for education, and this wasn’t just in the United States alone. We were a global program with more than 70 percent of the applicants coming from outside the United States. Naturally, having an outdated Web site didn’t make us look good, especially since we were one of the premier programs in the world in software engineering.

Seeing three different Web sites, all saying different things at three different locations, Johnson had every right to be concerned, and he thought that his decision to simplify and coordinate this online information was justified.

The project was more complicated than a simple graphical user interface (GUI) design because the requested system had to be linked to a content management system (CMS) to help with maintainability. The program also wanted a system that could tie into existing legacy databases used by the department; provide dynamic content generation of elements such as news, events, and announcements; and be documented to enable ease of future maintenance by providing a clear understanding of how and what went into its design and implementation. The department had never done anything like this before.

Al Molsters, the department’s system administrator, stated:

This project wasn’t just about designing and implementing a system for a typical “techno-phobic” kind of client. This system must support a premier program in the United States for teaching software engineering. People around here not only knew what they wanted but also knew how the developers should develop the system. They wanted specific documentation that would help them extend the system in the future. They wanted maintenance to be a task that a support person without HTML skills could perform. In addition, the system must have reliability built in as a standard operating procedure.

Gathering Initial Requirements

It only seemed logical that gathering internal requirements would easy to do in a place where most people were technical experts who are familiar with both software processes and software project management. Unfortunately, the task proved to be anything but easy.

The world of academia was very different from industry and the public service with which Fisher was familiar. In typical “university” projects, the notion of “getting things done” did not get in the way of “getting things right,” and the word urgency had a different meaning. Fisher recalled:

It was very frustrating to have to collect requirements when you were given the responsibility and not the authority to do so. Decisions were typically made as a committee where consensus was highly desirable. If we had a project “champion,” I was supposed to be it. Don’t get me wrong, people did want to contribute, but people were so busy with their own work that I literally had to plead and cajole them to provide me with their input. This project just wasn’t a high enough priority. I really didn’t feel that we were working on this as a team.

Fisher received the assistance of Alex Rau, a new person with very little experience who had just been hired for the Webmaster position, to help with requirements. Rau was tasked to help coordinate, test, and monitor this offshoring development project under Fisher’s supervision. Rau said:

I was very excited to work for UW Madison. Having just returned from Africa where I taught English with the Peace Corp, I really didn’t have a lot of experience. I certainly had a lot of Web coding experience; but at 23, I had never done any of this before. With a year in Namibia under my belt, I was very comfortable working with other cultures. I was happy to assist where I could and to have Fisher, who was experienced, mentor me along the way.

To get the list of requirements, Fisher and Rau interacted for more than three months with Johnson and Arroyo-Lopez (program directors for the on-campus and distance education programs, respectively), the other full-time faculty, the department support personnel and program managers, current students, some of the program alumni, program mentors, and so on. Fisher remembered:

We used a list of questions given to us by Russoft as one of the tools to gather requirements. (See Tables 7-3, 7-4, and 7-5.) The list was long and comprehensive and covered various areas of design, technology, need, and system characteristics. Russoft gave it to us well before any contract was signed to allow them to estimate the scope of the work based on our answers. Again, this action made us feel like we were working with a team of professionals and not with just a mom-and-pop operation. This was a standard way of doing business for them, and they used our input to make the final proposal.

Table 7-3: Original Requirements Questions and Answers: Current Site

Table 7-4: Original Requirements Questions and Answers: Content

Table 7-5: Original Requirements Questions and Answers: Technology

The interviews, answers, and interactions of Rau and Fisher with the program faculty and staff resulted in a rough requirements document that divided the project into two phases. Phase 1 involved all the static informational pages and a temporal part that included events, news items, and an announcement calendar. Included was a student planner to help organize classes, course schedules, and prerequisites. Lastly, Phase 1 also included the functionality to allow students to download, fill out, and submit surveys and forms online for course grades, change requests, course adding and dropping, and so on.

Phase 2 of the project focused on creating an intranet that could be accessed securely through the Web site to enable access to various levels of information to program staff, faculty, existing students, and alumni. Because requirements for Phase 2 existed only at a rudimentary level, it was agreed that currently only Phase 1 would be contracted, estimated, and budgeted. When time and budget permitted, a business arrangement would be further negotiated to the satisfaction of both the client and the software developer (see Figure 7-2).

Figure 7-2: Project phases

The Work Begins

With the development contract signed in late June 2003, the project plan was laid out, at least on a basic level, by Dennis Bramer, the account manager located in Phoenix, Arizona. The plan called for spending some time to do more requirements gathering to understand the client’s needs and the state of current Web site designs before proceeding to database design and coding work in Russia. Dennis Bramer reflected:

We had a budget of only 400 working hours for this project. Fisher had negotiated our hourly cost down to the bare minimum for a fixed-cost contract. I thought that he might have gotten the price he wanted but that we were left with “no fat on the bones” from a profit perspective. Russ Laughlin [Russoft’s CEO] must have really wanted this project to allow the negotiations to go this way. Having the University of Madison’s name as a client reference was a major opportunity for a company like Russoft, even if this was a small-budget project.

Since this was important for Russ, I didn’t want to spend too much time collecting requirements. There wasn’t enough time in the plan anyway for it. We already had what was needed as part of the plan that Fisher approved. We needed to get into design fast so that we could use most of our hours for coding rather than talking. I was hoping we could get everything done that was needed in the time we had.

The design, or the “look and feel,” seemed to be one of the big-ticket items for the system. Fisher wanted to make sure that people were “happy” with what the Russians came up with because this was going to be the system of choice for a few years to come. He knew that Johnson and the other full-time professors were very particular in how they thought the system should look. Fisher said at the time:

The designers in Russia provided us with a few potential designs that I had shared with my internal team. I didn’t think that I needed to discuss every little detail with every member of the staff. When we finally picked a design we liked, we presented it to our general committee.^* It was then that we got a lot of flack from one of the professors.

* The software engineering program held a monthly meeting for people involved in teaching, assisting, or interacting with the program (dubbed the “general meeting”).

Alex Rau recalled:

For some reason, one professor adamantly did not like having the site page in a three-column template in the center with equal margins on both sides. He must not have realized that this was how most companies back then chose to design their Web interfaces. I pushed back and might have been a little too “animated” in how I responded to his questions, but then, I did not know who he was at the time.

Rau’s hiccup with Levin, the Norbert L. Graf professor of computer science, was just another wrinkle in the project as far as Fisher was concerned. It did raise some questions regarding the readiness of people to commit to a GUI design that was otherwise “imposed” on them. To speed things up and clear any misunderstandings, Fisher instructed Rau to search for samples from known Web sites with a similar look and feel to get some of the faculty comfortable with the particular design they had chosen. Fisher said:

I wasn’t about to change our entire design just because one professor objected to having a three-column layout. That seemed foolish to me. I knew that we would not be able to please everyone and that we would have to live with this.

Fortuitously, Fisher was scheduled to be in Moscow the following month (September) for a teaching seminar. He was always concerned that they had not budgeted for travel in this project to meet their vendors. Luckily, it worked out that he could use the business excursion to also meet with Russoft and discuss how things were going. He approached Sergey Nizamov and Russ Laughlin from Russoft to arrange a meeting to see their office firsthand and to discuss project specifics. To get ready for the trip, he asked Rau to identify ongoing and open issues that needed to be addressed. He also spoke to Bramer in the United States to learn how the project was going from his perspective and to obtain a detailed account of the hours spent, though the later information was not provided.

Visiting Russoft Technologies in Moscow

As usual, Fisher traveled to Russia directly from the United States via Delta Airlines, where LearnIT’s CEO, Yuri Kashnovsky, picked him up at the airport. Kashnovsky was a young (23), well-connected entrepreneur with a remarkable track record of start-up companies in Silicon Valley, where he resided after graduating from UW Madison’s School of Computer Science at the age of 19 in 1999. For someone so young, he was impressive in how he always seemed to know what the latest business buzz was, where to get it, and how to bargain for it. He never let go of an opportunity when someone from UW Madison was in town to “arrange” a meeting with potential investors, existing clients, or managers in companies he was considering as targets for merger or acquisition.

The trip from Shermetyevo International Airport, a gloomy old-style Russian terminal on the outskirts of Moscow, was a traffic nightmare in the late hours of the morning. A three-hour ride to cover a 15-mile distance was a usual event. Likewise, the gray “train-like” apartment houses lined up in every direction along the four-lane highway did not add much to the charm of the trip. When Fisher landed, he was surprised to find out that they were not going directly to the hotel but rather stopping to “knock off,” as Kashnovsky put it, a meeting with Laughlin at Russoft. Kashnovsky commented:

Gene had asked me to arrange a meeting with Russ [Laughlin] at their offices near Cheremushki market sometime during his visit. It was outside Moscow and the easiest way to do it was on our way from the airport. I didn’t have a car, and going via the metro would take us an hour at least each way. I knew Fisher was tired, probably hungry, and still unadjusted to our local Russian time, but he played along with it. It wasn’t his first trip to Russia, and we generally packed his schedule with meetings from dawn to dusk to maximize the use of his time in the country. Usually, he was easy going, and I figured we might take advantage of the opportunity.

When they reached the building and Russoft’s offices on the eighth floor, Fisher had mixed feelings about what he saw. Fisher reflected:

On the one hand, everyone was very courteous, spoke English, and treated me with the utmost respect as a guest of the CEO and as a professor from the United States. On the other hand, the office had a haphazard appearance, with confused-looking people working out of every available nook.

Russ Laughlin remembered the meeting quite well, “We brought in Sergey Nizamov and Mikhail Pisarev, the project leads, to discuss the specifics on GUI design, ongoing issues that needed to be resolved, and the planning that lie ahead of us. Fisher was very business-oriented and seemed very happy with our designs.” Figure 7-3 shows the Russoft project organization.

Figure 7-3: Project organization

Sergey, the project lead on the Russian side, was just about done discussing the various design options when Laughlin and Pisarev were called to a phone conversation with a client who needed some help. Fisher stayed on to discuss the project progress one-on-one with Sergey. Sergey recalled:

I gave him a few color schemes from which to choose. He said that he would get back to me with an answer after he showed it to some of his people in the United States. He also wanted to know how many hours we had spent on this design so far. I really didn’t have an exact answer for this. I said I thought we had spent about 30 to 40 hours so far. Fisher was very pleased with my answer and reiterated that we need to make sure we didn’t spend too much time in design because we won’t have enough left for implementation. I didn’t really understand what he meant. Didn’t he want a good GUI for his system? My designers were working extra hard to custom tailor the graphics. Fisher gave us some guidance on what he wanted, but he must have known these were going to take time to complete. Overall, I think he was happy with what we produced so far.

Are We Getting Anywhere?

Upon his return to the United States the following Monday, Fisher updated both Bramer and his own department about his visit in Moscow. He asked Bramer to provide him with a formal count of the hours spent on the project thus far. Bramer recalled:

Fisher asked me to get him the true count of the hours spent so far on the project. As a customer, he wanted to make sure enough hours were left for implementing the critical parts of the system. When the count from the Russia office came back at 130, Fisher was flabbergasted. He told me Sergey’s original count (4 days before) of roughly 30 to 40 hours and mentioned that not much had changed in the GUI design to hike up the numbers that much. He was honestly upset and irritated. He didn’t know whether Sergey had lied to him, was just inexperienced, or had thought this was the way that Russoft was used to doing business. The project was already behind schedule, and all I could do was apologize while trying to reassure him that I would get to the bottom of this first thing in the morning, when people in Russia were back in the office.

When Fisher returned from Russia, the semester had already started. He had left the day-to-day project interaction to Alex Rau, who kept him in the loop through his e-mail communication with Sergey Nizamov. Fisher was uncertain whether the ongoing communication issues that he and Rau were observing were caused by an issue they themselves had created, a cultural or language barrier, or a misinterpretation of the requirements communicated by Bramer to the Russians when the project originally started.

The following are typical e-mails exchanged between Alex and Sergey. They contain text that has not been edited for grammar, spelling, or other textual errors.

----- Original Message -----
From: Alex Rau
Sent: Tuesday, September 12, 2003, 11:17 AM
To: Nizamov, Sergey
Cc: Gene Fisher; Bramer, Dennis
Subject: Re: Madison :: Website sources

Sergey, Hi!

I know what you mean about IE with the extra bad tags issue.

Well, this is the idea that Gene had in mind, again almost along the same line in terms of functionality as what Contribute does from Macromedia at http://www.macromedia.com/software/contribute/. All in all, I will need to be able to edit the pages in the future using Dreamweaver and FrontPage, whether it be images or text.

There may have been some confusion in terms of the functionality of this admin console and that's understandable.

We need to have the Search Engine functionality and Username and Password w/ option to Register working. Can you host the SQL stuff yourself so we can at least see it in action and then have a System Admin guy take care of the installation and transferring of files for maintenance?

Thanks for the hard work,

Alex

----- Original Message -----
From: Nizamov, Sergey
Sent: Wednesday, September 13, 2003, 5:22 AM
To: Rau, Alex
Cc: Gene Fisher; Bramer, Dennis
Subject: Re: Madison: Website sources

Alex, hello,

First, about the graphic design. I have already asked to Web-designer to make some changes according with the new requiremens and I'm expecting to get new version today evening or tomorrow morning. I let you know when the site be updated.

About AdminTool: I know a little bit about Macromedia Contribute product. This is the rather solid product. Unfortunatelly we did not mention those functionalities before so we estimated AdminTool as 40 hours' task.

Anyway, I have already asked to the programmer to compare currently existing AdminTool with Contribute and deside what kind of changes are possible to add to our tool to simplify them or to improve the functionality. If it will be possible we implement it.

See you,

Sergey

At this point, it seemed to both Fisher and Rau that interacting with Sergey directly and having Bramer there to run interference in case things went off-course was a prudent way to make things work. Fisher, who did not like the fact that no official communication channels had been designated thus far in the project, let the inexperienced Rau get his feet wet firsthand with project management. Fisher knew that he could always call Russ Laughlin directly as a last resort.

In late October, with the project already two months past its estimated completion date (originally planned for August) with no end in sight, Fisher was notified that Bramer was leaving the project and Russoft. For various occupational and personal reasons, Bramer, who by now was friendly and on a first-name basis with Fisher, decided to move on with his life. Laughlin called from Moscow to reassure Fisher that he would be keeping a close eye on the project while Russoft were busy searching for a replacement in the United States. Fisher reflected:

Losing Dennis was a big blow for us. He might not have been physically in Russia, but Sergey seemed to listen to him. He was a reassuring voice in this sea of madness. Whenever we thought things were over the edge, Dennis [Bramer] was able to let us relax and get things working again. I felt good that Russ [Laughlin] was actively looking for someone to take his place, because managing the project directly across continents seemed to be too much to handle. I hoped he would find someone just as capable and approachable.

Roughly a month later, when Fisher traveled to Russia for yet another teaching engagement, he finally met with Russ Laughlin and his newly appointed U.S. project manager, Mark Urlanski, at a local restaurant in Moscow. Mark Urlanski explained:

I was just in Russia for a few days before Russ asked me to meet a client on a project I was going to handle. It was a relatively simple project involving a Web-based system for UW Madison. The project was not going as planned, and Russ, who was meeting the client in Moscow, wanted me there as support. Fisher, who had a list of things with him that needed addressing from the project management perspective, was calm and composed throughout our discussion. It appeared that most of his claims had somehow to do with the local person Sergey and his “unique” way of doing things. We listened very carefully, trying not to interject objections. Both Russ and I reassured Fisher that things were going to change effective immediately now that I was supervising the project and that I would more closely watch Sergey from this point forward.

Back in his office the following week, Fisher heard from Alex Rau that there was yet another snag in the project. This time the issue concerned the database implementation. While the requirement was to use an open source MySQL implementation, Sergey had decided to use Microsoft SQL Server, a different and costly database. The change might not have been a problem, but the stakeholders had not discussed it beforehand. Al Molsters, the department’s system administrator, was out of the office for a couple of weeks to install servers at one of UW Madison’s remote campuses, so Fisher could not immediately test the new database. The schedule would slip even more. Sergey had indicated in an e-mail that he thought Microsoft SQL Server was a better choice for them, but Fisher was not convinced. Fisher, who had to give a status report to his boss the next morning, was truly at a loss.

Case Problem

The following are the main problems and decisions to be made that involve risk management:

• How should this offshore development project be restructured to minimize future problems through risk management?

• What risk management practices and activities are needed to reduce future project risk?

• What should be done to mitigate the project risks associated with people, process, and technology?

Case Analysis

Analysis Activity

In this section, we will try to analyze the case study using the PEAK decision model. We will focus on factors that influence the decisions to be made by the stakeholders in the case study.

Analysis Background

Let’s look at the PEAK inputs to see how they can help us understand alternative solutions to the following key problem:

How should this offshore development effort be restructured to minimize future problems through risk management?

(P) Problem: This case study highlights the problem of conducting offshore development projects without systematic risk management. The solution should provide structured processes to promote effective communications, productive meetings, appropriate review and feedback, and ongoing issue identification and resolution with a remote development team (because the lack of these has contributed to the troubled state of the project).

(E) Experience: The skill sets for the project stakeholders are as follows:

For UW Madison:

• Good understanding of software engineering processes

• Extensive work with global projects

• Some expertise in risk management

• Some work expertise involving companies in Russia

• Extensive project management experience

For Russoft Technologies:

• Experience working with U.S.-based clients

• Experience in managing Web development projects

(A) Assumptions: The project stakeholder assumptions might include the following:

• The offshore development team recognizes the need to restructure the project to be more effective and is willing to cooperate.

• The key stakeholders on the project, both internal (within the department) and external (offshore), are interested in managing risks before they become problems.

• There are enough resources (budget, time, knowledge) to conduct process improvement.

(K) Knowledge: The knowledge base for the project stakeholders includes the following environment and facts:

• This is an offshore development project with stakeholders in the United States and Russia (environment).

• The project currently conducts no explicit risk management (fact).

• The project has multiple problems in the areas of planning and budgeting, communications, and scope and requirements (fact).

• The need to fix ongoing problems is immediate. There is no time for a “wait-and-see” approach (fact).

Solution: Alternative solutions to the problem might include some combination of the following:

• Apply Agile methodologies to structure a communication mechanism that allows stakeholders to acquire status and other project information regularly and expediently. The project management and staff need to be involved and knowledgeable.

• Create structured processes to achieve the project objectives through the performance of well-defined tasks to achieve milestones according to a clear and definitive schedule.

• Alter communication and control mechanisms to increase upper-level manager oversight and to decrease dependency on developer control of the project.

• Invest some process time and effort for both the U.S. and Russian stakeholders to formally identify project risks and to mitigate, track, and control those of high priority.

Requirement for the solution: Create a structured process that involves doing specific steps and taking specific actions at registered milestones with set timelines for software artifact delivery.

Assumed Risk: The following are the potential risks associated with the alternative solutions:

• Restructuring the project (essentially investing time in defining and executing different processes) might take longer than expected and result in further schedule slippage.

• The project stakeholders may resist changing to a more process-oriented approach.

• The project stakeholders may not like or distrust an approach that involves more management control. The result may be an “I don’t care” mentality or attitude problems.

Analysis Questions

1. What risk management practices and activities would help minimize future project risk?

2. What should be done to mitigate project risks in the areas of people, process, and technology?

Discussion

Since we are attempting to restructure a project in a way to minimize risk, the decision regarding what to do is dependent on evaluating the risk associated with alternative solutions. Whatever risk is assumed must still allow the project to succeed even if an assumed risk materializes. Naturally, any decision that negatively impacts the project requirements, schedule, or budget (which have already been compromised) is not a good choice. Fisher and his boss Johnson should look for solutions that would maximize their control over scope, time, and cost.

The solution needs to minimize the risk associated with communication and cross-cultural barriers because these are primary contributors to the problem. Handling the communication issue would be a viable mitigation strategy to reduce the likelihood that open issues fester into problems. Another approach might be to improve or to reduce the impact of the poor project management skills exhibited by the Russoft staff members assigned to the project.

With respect to cultural differences regarding work styles, the decision should focus on the amount of project control and oversight needed by the U.S. managers. Fisher should realize that giving Russoft unlimited flexibility in how it executes the project is a risk that he cannot afford. Fisher must also justify to his boss that he has the ability to control the project and to minimize the downside of working with Russian software developers. To do this, he must oversee and control the project deliverables, project execution processes, and communications with the developers.

Conclusions

Both Fisher and Laughlin face tough decisions that, in addition to influencing the daily implementation details, concern their ongoing relationship, reputation, and how each of their respective organizations is perceived. There is a tendency to ignore long-term implications when trying to finish a troubled project. Fisher and Laughlin should step back and carefully analyze their situation to avoid making a hasty decision without evaluating the options and risks.

Risk management is a way for decision makers to proactively handle project challenges. Although Fisher has not yet done this effectively, he is aware of the problems that his project has encountered and wants to minimize or solve them. Finding fault is easy for both Fisher and Laughlin, especially because of the distance and cultural issues. Future project risks might be greater if one of the key stakeholders takes a coercive stance with statements such as “Do it now because I said so.” Fisher and Laughlin need to analyze the results and assumed risks of their previous project decisions before deciding how to go forward.

Key Ideas to Remember

This case study presents a typical project in which neither the developer nor the client explicitly practiced risk management. In general, the lack of risk management has led to a number of problems that could have been foreseen and avoided. We hope you will remember the following ideas after reading this case:

• Risk management needs to be planned and executed as part of the overall project plan. Decision makers often make decisions with limited information and under time constraints. Project managers should invest some of their time at the start of their projects to identify project risks and to mitigate those that might preclude project success.

• As projects become more complex, in terms of environment and domain, the need for explicit risk management increases. Complex projects usually involve multiple components, technical sophistication, and many decision makers. Project environment also contributes to project complexity, and even a small project with two to three project engineers may involve complexities associated with distance, culture, language, expertise, and so on. It is often easier to deal implicitly with project risks on a less complex project in which risk management practices are done on the back of an envelope. As project complexity grows, the complexity of the decisions made by project stakeholders also increases. Decisions for complex projects often involve more time, effort, and resources.

• Ignoring risk management, even for small-scale projects, can lead to significant problems. Decision makers use benefit-cost analysis to evaluate the value of performing risk management activities. From a business perspective, this may be a reasonable approach because it is often very difficult to precisely value the impact of various risks. Ignoring project risks may result in unexpected and significant project delays, poor product quality, and cost overruns.

Case Study: Falcon Edutainment and the RiskSim Project

Directions

When reading this case study, focus on the risks associated with the miscommunications taking place during a short, time-constrained project. Identify issues associated with managing customer expectations and the risks they pose to the continuation of the project.

Case Summary

Description

Brain Wenzel is managing a short, six-month project for Falcon Edutainment. The project deals with converting a risk management simulation into a Web-based platform. When different opinions on “creative” choices arise between client and developer and the developer presses on with the project despite the lack of clear feedback from the client, both sides end up with having to manage the resulting “fallout.”

Case Study Objectives

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

• Understand the risks and the decisions faced by developers working with little or vague feedback

• Understand the consequences of adding or changing requirements on project timelines and schedules, as well as the need for rework

• Review risks taken and decisions made on a small-scale project

Subjects Covered

Risk management, decision making, managing customer expectations, requirements management, and stakeholder communications

Setting

The setting is a small project involving Web-based system development in the United States for a training/simulation application. The project is constrained by a small budget and a short time frame (approximately six months).

Key Concepts

• How to minimize project risks related to requirements, lack of client feedback, and constrained schedules

• The effects of decision making on project risks and on successful project management

• The downside of managing risks implicitly with no defined plan

The Case

Scenario

Brian Wenzel had plenty of time to think while driving to work this morning. He was stuck in traffic on one of the main highways heading into Boston in what seemed like an endless attempt to reorganize the travel patterns around the bustling metropolitan. It was early in the morning, and Brian was already having one of those throbbing headaches related to the e-mail he had gotten the day before from Lee Orman, the lead on the RiskSim project. Orman, a young graduate of Yale’s School of Management, was the risk management practice director for ExecSoft and his principal client on the project. Wenzel knew he needed to manage the growing project risks while balancing scope, budget, schedule, and his customer’s expectations. He didn’t know where to begin.

RiskSim was one of the flagship teaching tools used by ExecSoft to train software professionals in risk management concepts. The company, a U.S.-based risk management training consultancy, had developed a board-based simulation to provide a lifelike environment of a software development project. The simulation was rather successful, and the company decided early in the year to turn it into a Web-based simulation. Though it was still under active development, the team at ExecSoft thought the simulation had matured enough to be able to move it to the online environment. To that extent, they had contracted with Falcon, a company that specialized in education centric software development. At Falcon, Wenzel, together with three other engineers, were put on the project. Figure 7-4 shows the ExecSoft and Falcon Edutainment organizational chart.

Figure 7-4: ExecSoft and Falcon Edutainment organizational chart*

* Arrows represent a drilled-down view of people working within various business units.

Wenzel recalled:

ExecSoft was interested in having us help them webify their board-based simulation. It was a no-brainer because we’ve done these things multiple times in the past. After listening to what they were interested in doing, we explained how we did things and how we worked on eliciting requirements and doing the design, the project management work, and the actual development. The meeting was rather successful because it led to a short contract negotiation and a rather immediate work date. One thing that did strike me as odd was that ExecSoft put one of their new people to head the project. Don’t get me wrong, Ms. Orman seemed very capable but not in the least experienced in anything that even resembled software development, education, or simulations. I feared having to spend too much time walking her through the ropes in explaining why we did certain things.

Orman remembered:

While searching for a company with a solid track record of developing educational focused simulations, we came across Falcon. One of our managers knew someone who was on their board of directors. They apparently were heavily involved in project work with universities, the U.S. Department of Education, and a number of large Fortune 500 companies who used their services for creating local in-house training simulations. Though I was still learning the ropes with respect to software development and simulations, the staff at Falcon seemed eager to help and get to know more about the project.

The work contracted between the two companies was for a fixed-fee, six-month-long contract for a working prototype. The timeline included a short requirements elicitation period, mostly to understand the existing simulation, its rules, assumptions, and mechanics, followed by three iterations of the actual prototype to refine the game’s look and feel and to elicit feedback on other important characteristics such as ease of use and playability (see Figure 7-5).

Figure 7-5: RiskSim project timeline

RiskSim: Elicitation Phase

As soon as the project started in March, Wenzel met with Orman and one of the original simulation developers, Danny DeVite. DeVite, who was an expert in risk management, had a very clear idea of what he wanted to accomplish using the simulation. He wasn’t sure, though, of how that would translate into the computer environment. Devite recalled:

Two years earlier, a group of us involved in the risk management practice at ExecSoft developed a risk-based simulation to help practitioners understand how to use risk management in the context of a software development project. The simulation was extremely successful with glowing feedbacks on its realism, fun factor, and depth. We knew we wanted to port it to a computer to make it more robust, to make it easier to control, and to add elements we couldn’t on a board. We were hoping that Falcon Edutainment could provide the guidance on how to do it. We were not experts in developing these kinds of systems. If we were, we wouldn’t have needed Falcon. We needed their expertise to make it engaging and entertaining in the virtual sense. It was my understanding that we would be getting some advice on what works best under our constraints while keeping the rules of the simulation the same and the spirit of how it is played.

The Falcon team had spent the first few weeks getting a feel and a better understanding of how the simulation worked. They peered over design documents, user manuals, and two active off-site simulations conducted for two independent government organizations in Washington, D.C. Equipped with a solid understanding of how the simulation is played and having read what seemed like a cart full of documentation, Wenzel and two of his associates, Frank Lapel and Bonnie Jones (a human computer interaction specialist), set out to design a paper mock-up of how a GUI might look (see Figure 7-6).

Figure 7-6: Paper prototype of the GUI produced by Lapel and Jones

The design seemed to impress Orman and her colleagues at ExecSoft yet appeared to create more problems than expected.

Charlotte, a software engineer at Falcon, recalled:

We interacted with the simulation quite a bit to understand the rationale of how it was designed. We then created a design that conformed to the existing rules and mechanics of the game. From a design perspective, we wanted to achieve a balance between adapting the playability of the game to a setting where players would be drawn to playing it more than one time. This was not easy because the game on the board was rather simplistic and did not offer much interaction. We therefore used a different approach than the clients had asked for originally and went for a more interactive “office-like” environment rather than the simplistic Monopoly-style design.

Orman had a different take on things than what the people at Falcon had anticipated. Orman remembered:

I was highly impressed with Falcon’s technical abilities. Wenzel’s team looked like they were taking it seriously the first few weeks in trying to understand what went into RiskSim. We did our best to educate them on how we did things and for what reasons. Then, when we finally got the mock-up, it was as if they haven’t listened at all. RiskSim was designed using a board concept, and they came up with an office-like environment. Though the concept was certainly worthwhile, I distinctly recall DeVite saying in a closed team meeting he wasn’t sure that this concept fit in with his ideas. I was the one who was going to have to tell Wenzel he had to go back to the drawing board. The poor guy . . . it almost seemed easier not to say anything at this point and simply wait for a better time to discuss more than just the mock-up—perhaps over the phone or in person.

Through this initial cut at the mock-up and the vague feedback that followed, it became clear to Wenzel that his clients were interested only in a replica of the exact simulation they had on the board. They seemed far less interested in having a creative expert provide them with an opinion on what would captivate an audience playing it. In line with that, Wenzel updated his project plan to reflect less time spent on “creativity” and more toward focusing the effort on replicating what existed.

Requirements Revisited

Wenzel decided to use a two-pronged approach for this project. As an experienced engineer, he wanted to utilize what he already had as initial requirements to build a notional architecture (see Figure 7-7). In parallel, he wanted to spend a little more time refining and verifying both the architecture and the requirements before moving into development. Sticking to his milestones, he was able to produce a draft of the initial requirements specification (SRS) that included a set of detailed use cases from the information he gathered from Orman.

Figure 7-7: Notional architecture

Remembers Orman:

When I got into the office on Monday, I had an e-mail waiting for me from Brian. It had a rather large document attached that included the RiskSim features we discussed put into a more technical language. I liked how the information was laid out in scenario-type format with a sequence of steps the player/user would go through to perform certain tasks. I remember printing it out and showing it to DeVite who said he would look at it later.

While DeVite and his colleagues were reviewing the requirements document and thinking of how to proceed, Wenzel instructed his team to press on with the GUI design work required before implementation. He did not want to waste time while waiting for more feedback from Orman. Lapel and Jones were strongly opposed to this move. It was their understanding that driving forward as fast as they could might lead to future rework for the team. If anything was to change, it was probably going to be the GUI. Any work done up to this point would most certainly go to waste. Lapel mentioned this to Wenzel over lunch the following day:

Brian, I am not sure we are serving the best interest of our clients by pushing forward as fast as we can without validating our designs. The idea behind the GUI was to elicit requirements and refine them, not draw a line in the sand from which we can’t go back. Do we even know whether they liked what we did?

Wenzel reacted:

I don’t need you to tell me how to run my projects! I have far more experience than you in doing this kind of thing. We are on a tight schedule, and we don’t have the luxury of waiting until Orman and her gang gets to decide exactly what they want us to do. For all I know, they could change their minds regardless of what we show them.

Back at ExecSoft, DeVite and Orman discussed the requirements specification with one of the other RiskSim designers, John Morris. Morris was keen on integrating more features into the project based on recent feedbacks from two focus groups he had run through the simulation a month or so before. When Orman mentioned that adding more to the project currently was not in their original plans, Morris hinted that they could divide the project into two phases instead of one, where the impact on development would be minimal. DeVite remembered:

John had an interesting idea. He wanted to incorporate some enhancements into the existing RiskSim effort. He was basing those enhancements on some user surveys from a recent run of the simulation with a group of 35 executives working at three different telecommunications companies. John shared our opinion that the computer version we were working on should have a design that followed our true-and-tried board concept but strongly encouraged us to talk to Falcon and see whether they could accommodate his enhancements. He asked whether we had finalized the requirements spec for the project. When I mentioned we had not, he suggested that we break the project into two phases, with only the first phase going through implementation but having the requirements captured for both.

Reluctantly, Orman communicated the request to Wenzel in an e-mail the following morning. She thought her colleague’s approach might be a mistake but deferred to DeVite and Morris as the experts on what the simulation needed to make it a training success. In her e-mail to Wenzel, she mentioned they were interested in discussing additional requirements but specified these were only minor rule adjustments and not so much conceptual modifications. Orman had also discussed their desire to revisit the GUI concept with the office environment versus the playing board approach. She wasn’t very specific on what she meant by that and finished her e-mail by saying she would also be available to discuss these requirements further on the phone once the RiskSim team at Falcon had time to review it.

Case Problem

The following are the main problems and decisions to be made that involve risk management:

• What project risks are associated with ExecSoft’s request for change in the requirements?

• What risk management practices and activities should Falcon use to minimize and control future project risk?

• From a project management perspective, what key decisions should Orman consider to minimize the occurrence of similar issues on other projects?

Case Analysis

Analysis Activity

Analysis Questions

1. What are the most important risks faced by Wenzel? What should he do to mitigate them?

2. What are some of the PEAK inputs that Wenzel needs to consider before evaluating and making a decision about alternative solutions to his problem?

3. How could have Wenzel avoided some of the problems faced on this project, specifically those that affect the way in which he managed his clients’ expectations?

Key Ideas to Remember

The goal of this case study was to examine what could happen when project managers focus too much on their short-term project success without attempting to identify and mitigate risk conditions that might prevent long-term project success. Decision makers need to remember the following:

• Managing risks explicitly on software projects is very important. Identifying and mitigating project risk directly correlates to project success.

• Risk management is an activity that should be conducted throughout the project. Thinking about risk early in a project provides decision makers with more options and time to deal with potential future problems.

• Project success needs to be defined in a way that enables decision makers to understand what might preclude them from being successful (that is, risks). This threshold of success should be the criteria against which project actions are evaluated. Actions that directly contribute to project success should be performed, and those that detract from it should be avoided.