Chapter 6. Managing Process

Search in book...
Toggle Font Controls
Create new playlist

Name your new playlist

Playlist description (optional)
Sign In

Email address

Password

Forgot Password?

or

Continue with Facebook

Continue with Google
Sign Up

Full Name

Email address

Confirm Email Address

Password

or

Continue with Facebook

Continue with Google

Chapter 6. Managing Process

6.1 Chapter Objectives

After reading and thinking about the concepts and case studies presented in this chapter, you will be able to do the following:

• Recognize the key issues involved with process management

• Understand the relationship between product and process

• Understand the key factors that influence process in the eyes of the stakeholders

• Recognize factors that can significantly improve the development process with minimal cost

• Understand that process is not a dirty word

6.2 Context

A process is a set of steps with a purpose. A process is a framework for action whose purpose is to achieve a well-understood goal in a repeated fashion. A process consists of a set of actions or tactics to achieve the goal. A process is also a set of steps that standardizes the production of a product. Humphrey (1989) defines process as a set of tasks that, when properly performed, produces the desired result. In other words, a process can help you produce a product and also can serve as a filter to ensure that defects do not get into the product we are creating.

Viewing process as a filter enables a project to remove defects early when the cost is lower. We all know about the 10-to-1 cost when software defects are allowed to migrate into later phases of development. It is important that defects are encapsulated or removed before they spread out. If not contained or removed, they “infect” other code and therefore are harder to remove. The processes that you use can serve as a uniform, disciplined way to remove these defects so that the later phases of the project are not delayed because of the need for bug fixing. The process can save the engineer from having to expend time doing rework.

To use the software development process as a quality filter for the results of your software project tasks, you need to be able to perform the following activities to manage the processes used by the project members: define or select the process, teach the process, measure the process, evaluate the process effectiveness, and change the process to improve its effectiveness. Each project member who uses a process should be able to perform the following activities: understand the process, execute the process, evaluate the results of executing the process, and understand how to change the execution of the process to improve results.

As you examine process in this chapter, you will look at the decisions that a manager must make to influence or instantiate process in a software development effort. You can use the basic PEAK model to make decisions that will impact the activities performed by the project team. Table 6-1 presents what-if questions to answer when evaluating and making process decisions. For each what-if question, you can determine whether the PEAK input statements are true. Study the table, and think about how you would answer these questions to manage process for your current software project.

Table 6-1: Managing Process Decisions Using PEAK

Software project managers or software engineers can better eliminate defects by managing the decisions that they make about how they do their work. To manage these decisions, software engineers need to understand the way in which they complete tasks (or the processes that they use) and to be able to perform them in different ways if needed to achieve fewer defects. Changing the way you perform a process to improve its outcome is called process improvement.

Process improvement is a way to improve efficiency through the recognition of better ways to perform actions. When you write things down and are able to evaluate what you are doing systematically, then you can see “better” ways to do things. Many of the decisions you make with respect to process involve making the process more efficient or less error prone when applied. In a sense, process is a tool like any other development tool. It can be used badly or well. For software engineers, process is essential because the work they do is detailed and requires their best efforts. One guideline to remember in making decisions about process is that the process should serve the user. The user does not serve the process. Another guideline when making process decisions is to consider whether the process or the tools should come first. When these get reversed, teams get into trouble.

Activities of Process Management

Process is fine for other people. To paraphrase a line from the film Blazing Saddles, “Process? We don’t need no stinking process!” (IMDb.com, Blazing Saddles). Some people view process as a necessary evil. They think that it is needed because someone else wants visibility into the project. This is the wrong reason for process, although sometimes it used as the “stick” to get engineers to listen.

A useful way to view process is as a mechanism by which defects can be filtered from a work product throughout its creation. This is sometimes at odds with some people’s view of process, in other words, “process for the sake of process.” Process without value for the user is useless. Process is not an end in itself but a means of guiding and planning software project actions to achieve project objectives.

A decision to not have a defined process or a disciplined process is still a decision to have “a process.” In this case, the process is not managed to improve a project. So, another truism for process is that unless you manage it and define it, you cannot improve what you do.

Managing process requires planning, discipline, and proper decisions. Processes must be based on the business goals and needs of the organization, the project objectives, and “best practices” for the domain. Basic activities to be performed in managing process are the following:

• Defining, selecting, and understanding the process

• Teaching the process

• Measuring the process

• Evaluating the process

• Changing the process to improve its effectiveness

Table 6-2 describes these activities in more detail. Explore the table, and consider other activities that you think may be helpful in managing process.

Table 6-2: Descriptions of Activities in Managing Process

Making Decisions About Process

You cannot control what you cannot measure (DeMarco 1982). Process goes hand in hand with improvement. If your projects are running perfectly and you see no need to change anything, then you don’t have to worry about process because obviously you have good processes. But if your project is like many other software projects, the results are not always acceptable, and things are always changing. As the saying goes, “The only thing consistent is change.” Therefore, if you are making changes, you want to make sure the changes are improvements; and you can’t improve your process if you can’t measure it. So, decisions made about process usually focus on how to evaluate its effectiveness.

An important concept is that process and product can be viewed as two sides of the same coin. For this discussion, product consists of the artifacts that compose the output of a project. They can be customer or management focused. The execution of a process results in a product. Most of the time, the quality of the product is highly dependent on how the process is followed. People who insist on focusing on only product or only process are cheating themselves. As people who deal with software know, a software development effort involves compromise. The software project stakeholders make decisions regarding one alternative or another because of a slight advantage. The choice of how much effort goes into managing the process and how much goes into managing the product is a compromise at the project level. Project managers are constantly making decisions regarding the resources needed to manage process and regarding what and how much to measure to ensure that the project delivers the right product to the customer. The process resources include variables such as people’s time, reports, and reviews. Every project must decide which and how many resources to expend.

Schedules are key factors in making project decisions and are likewise dominant in making process decisions regarding how to execute the project in order to produce acceptable project deliverables on time. Process can serve as a defect filter that can reduce completion while improving quality. When selecting processes to be followed for a project, project managers are primarily deciding how many “issues” they would like to filter out as soon as possible within the project. The right amount of process is always a balancing act to manage effort and time while attaining the proper effect on the product. Usually this balancing act is directly related to quality (that is, zero defects), but most project managers have given up on the idea of process nirvana and strive for minimal rather than zero defects.

Process decisions often involve the search for ways to improve project speed through efficiency and productivity. One of the major decisions a project manager has to make is how much new process technology the team can handle. Many projects have suffered from the introduction of new support tools, languages, and hardware that is supposed to make the team more efficient, faster, smarter, and able to leap over buildings in a single bound. The project management always seems to be surprised when the team is slower than normal and spends all of its time “learning” these new systems. Project managers need to balance process changes with respect to the impact that they will have on the efficiency of the team. This is one decision area that can benefit highly from the application of PEAK, which makes transparent the statement of the problem to be resolved as well as the assumptions being made. One of the case studies addresses this issue directly.

Next, you’ll examine the process in the context of making decisions to achieve project objectives and to satisfy stakeholder expectations. You will consider the effect of process on the four dimensions of scope, schedule, quality, and cost. The following example applies the PEAK model to examine the impact that process can have on quality:

(P) Problem: A team sees it might be late for a delivery. The team members are deciding whether they should eliminate code inspections to reduce the time needed to get the software out the door.

(E) Experience: The software being delivered in this release contains only the GUI code. The complete software application will be delivered in the next release.

(A) Assumptions: If the team eliminates code inspections, the code will be “ready” for delivery sooner.

(K) Knowledge: The team understands that the software tests provide sufficient verification and may be willing to deal with the impact of releasing software with “less quality” more quickly.

Solution: The team would release a software version that consists only of the GUI code, which would not be fully inspected. The next software release would contain all code and be fully inspected.

Assumed Risk: The team assumes that the consequence of delivering lower-quality code is not as severe as the consequence of delivering late code because the customer knows that this is an interim release. If this assumption is not accurate, then the consequence of releasing lower-quality code may be more severe than the team expects.

Cost is frequently a concern when project managers are considering the process that is best to use. The next example applies the PEAK model to clarify the impact that process can have on cost:

(P) Problem: Do you use the lab to test the software when the cost of usage is $1,000 a day, or do you use the simulator, which is less expensive but not as “complete”?

(E) Experience: The lab is a fixed-cost, highly utilized resource in which the entire new system environment is established with all hardware and connection configurations. The simulator has only some of the hardware features.

(A) Assumptions: The simulator produces test results that are as useful (with respect to accuracy and reliability) as those produced when using the lab for “certain” tests.

(K) Knowledge: We understand what tests are best suited for the simulator and which ones are best suited for the lab. We can clearly identify these in a project.

The use of process is a people issue. Businesses don’t perform processes, but people do. Process influences people to produce or not to produce higher-quality products that meet stakeholder expectations (Microsoft 2007). Refer to Chapter 8, “Managing People Interactions,” and Chapter 9, “Managing Stakeholder Expectations,” for more information regarding the relationship between people and process. See also Crosby (1995) for a discussion of how to achieve quality through satisfaction of customer expectations, and see Goldratt and Cox (1992) for information regarding how to use process improvement to improve the business of software development.

6.3 Case Studies

This chapter has two case studies. One case study focuses on the process decisions that have been made for a project and analyzes whether they were the right decisions for the project. The second case study examines decisions about processes that can directly impact the quality of the project deliverables and therefore the schedule.

In the first case, “Bank on the Verge,” two consultants are asked by a project manager to evaluate the project that he is working on. The project manager wants the consultants to evaluate whether his team has made good decisions on process and whether there are things that the team could do better. In particular, the project manager wants all the members in his group to work on the product to help ensure that it is the best that they can produce. He is concerned that if all of his team is not involved in this effort, then the expected product features cannot be delivered in the time allocated, and the product will not be the best that his team could achieve.

In the second case, “Damn the Process, Full Speed Ahead,” one project manager is asked to review a project with problems that is being run by another project manager to determine what can be done to improve the situation. The troubled project is behind schedule, and no one has been able to clearly identify what is causing the schedule slippage or what should be done, if needed, to fix the project’s processes or to help the project stay on schedule.

Case Study: Bank on the Verge

Directions

You can read the case independently of the chapter background, but you might benefit from reading the background material before reading the case study. If you choose to read the case study first, then read through it once quickly in “story-reading mode” to set some context for the information in the chapter. Then read the chapter material. Finally, reread the case study, and look for opportunities in which you can analyze and apply the chapter concepts.

Case Summary

Description

This case deals with consultants who have been called into a bank to help with general software engineering principles for all the developers. The person who asked the consultants to come and who was a former student of the consultants asks them to evaluate one of his projects and provide ways to “improve” what they are doing. The bank has evolved through an era in which traditional, though now outdated, software development practices became standard at the bank. For example, the bank’s software projects usually follow the traditional waterfall-like view of software development (Royce 1970) with the “added benefit” that developers work alone. The developers do not see projects as team efforts but as individual efforts that collectively make the project successful. New Agile methods that emphasize intense cooperation among developers are being adopted slowly, but some of the senior developers are resistant to process changes. The organization’s culture of working alone has been difficult to change, especially when project managers try to introduce new processes, such as Agile approaches, in which two people work together on one console (Beck 1999).

In particular, the sponsor for the consultants wants to know how he can get more of his senior engineers involved in process improvement efforts and whether the processes that his team are using can be improved to help all engineers better participate in the effort. He can see that the “senior” engineers are not as comfortable with the techniques being proposed as the “new” engineers.

Case Study Objectives

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

• Understand the decisions associated with the introduction of new process technologies

• Understand that there are different stakeholder points of view regarding process

• Understand how process decisions can affect a group of engineers

Subjects Covered

Process management, quality issues, life-cycle development, and buy-in from rank-and-file engineers

Setting

A software consultant must help a development manager decide how new processes can be taught to all engineers in a development group while continuing to produce project deliverables on time and with the right quality. In particular, the consultant must assess the development group’s processes and help develop an effective way to measure the successful introduction of new Agile processes to traditional development engineers and management. The company is hiring many new engineers who are comfortable with Agile development processes. The decision to use these new processes is being reviewed with respect to what the consultants have learned about the developers in the company and about how management makes decisions.

Key Concepts

The following are basic concepts to keep in mind when making process management decisions:

• How much process change can a project handle?

• Who is affected by the decisions about development processes?

• What are the best ways to integrate new processes into a development group?

• How do you ensure that process changes meet expectations?

Process management involves the consideration of long-term issues. The processes used today must be able to deliver expected development information for the past and the future. (The process must enable the use of metrics to evaluate how well the process is working.)

Different project stakeholders view process management in different ways and to different degrees. For example, management views it with respect to schedule and budget, and customers view it with respect to quality and cost.

Terminology

ATM: Automatic teller machine

The Case

Scenario

Tom Moresay is a consultant and, as part of his job, was visiting a bank in a former Soviet-bloc country. In 2006, the country was moving quickly in the direction of modern information management. Software project managers were experiencing the issues typically found in immature organizations developing software.

Tom’s client was one of the largest banks in the region. The bank was embarking on a number of development and modernization efforts to improve its position as a bank of choice among the clients looking for banks in that region. With a changing consumer society, the bank was positioning itself to be a major player among banks in the new society evolving after Soviet rule.

The client knew Tom and his consulting partner, Wil Narat, through their relationship as instructors at a major university in the United States. The contact at the bank, Tanak, was a former student who had returned to his country after completing his degree. Tanak understood the concepts of process improvement from his studies but lacked experience in leading improvement efforts. He asked whether Tom and Wil could support his effort and asked how they might do this. Tanak wanted to know whether the efforts he had already begun were worthwhile and whether they were improving the state of the software development practices at the bank, in particular those used on his project.

To understand how the management at the bank viewed key software problems, it is important to understand how the consultants got involved. The request for software process support provided the opportunity to work with the bank and to help with its software development process improvement effort. The effort had been running for about three years and had begun when both Tom and Wil taught their first class on-site at the bank. The consultants could provide solutions to the bank as they discussed issues from the bank projects during their classes. In addition, the software developers and project managers taking the courses could ask the consultants for advice on how best to deal with problems on their projects.

Tom and Wil put together the following questionnaire in an e-mail to set the context for what needed to be done to improve the bank’s software development processes. (This series of e-mails followed some online discussion and other e-mails in which Tanak indicated that they were having issues that “plain old hard work” could not seem to resolve. The e-mails that follow set the context in which the process decisions were being made.)

Tanak,

I am repeating what I told you over MSN last night (morning for you). Now that our previous discussions have shown that you are interested in process improvement, we would like to make sure we provide you with the best service possible and teach the things that:

1. Are applicable for the bank

2. Provide the best result for your immediate needs

3. Help in uncovering other needs

We can come in and teach anything, but we try to be a lot more service oriented and meet our client's expectations. To do that, we need to know what those expectations are and would like to conduct a short mini-assessment (free of charge) to help identify the bank's areas of pain and where we think we can offer some education to help with it.

Please ask the following questions of your department head and of several key project managers in your department:

1. What are some of the things that are being done well (or done correctly) on current software projects?

2. What are some of the things you need improvement on (or things not going well) on existing software projects?

Please send us the information. We will assess it, provide our input on how we can help, and then schedule things from there.

Let me know if you need more information to proceed.

After Tanak answered the questions in the previous e-mail, Tom and Wil followed up with these questions:

1. The available number of personnel does not satisfy the huge number of projects. Is it a problem in getting the right people or a problem in getting enough people into the bank?

2. What kind of painful problems are you having because of lack of documentation?

3. Do people leave the company often, looking for other jobs? Or do they get fired?

4. Is there a training plan for new people hired? From your previous answers, you are using busy human resources to get new hires ready to work. What training do you give these new recruits?

5. Why is there no clear distribution of roles/responsibilities in your project teams?

6. Is any risk management done in your projects?

7. Why are project slippages (in schedules) common? What are some of the things that you are doing to stop that from happening?

8. A lot of rework can be caused by a number of things. What is the main reason for your rework? Is it a quality issue (not getting the right quality the first time), or is not understanding exactly what the customer needs/wants causing you to have to do some rework to get it right.

9. Is someone measuring quality? How many bugs do you have to fix per 1,000 LOC on average? Is quality getting any better?

The answers to the original and the follow-up questions provided insight into an organization that was divided into three main areas. Each of these areas had its own development processes and issues, as explained in Table 6-3.

Table 6-3: Software Development Groups in the Organization

Figure 6-1: Organizational chart for Kossi Bank

The three groups were distinct from each other, and although they used the same information base and customer information for all their development, they all viewed this information differently. Some developers viewed this information with respect to the customers of the bank, while others viewed it simply as account numbers that they had to maintain.

The first group had a significant legacy program that was primarily in maintenance mode and needed few major changes other than to rehost the system on a new hardware platform when the old system became obsolete. This represented the main computational model approved by accounting to perform transactions on accounts. This was the area that was governed by laws of the country to maintain proper accounting practices. The quality had to be highest in this area. Development in this area followed a waterfall life cycle: Requirements were well defined before proceeding to design, changes to requirements or design were written and approved, coding was done with inspections, and the transition and turnover process occurred after exhaustive testing. The software quality was paramount, with zero defects being the goal.

The second group dealt with the most novel software and was “pushing the envelope” to support online banking at an ATM kiosk. They were looking for new ways to generate revenue for the bank. These kiosks could do everything from selling stamps to paying the electric bill. They did not reliably enable the users to access their bank accounts and get money, which was supposed to be their primary function.

The third group was somewhere in the middle between hardcore, disciplined, waterfall-like processes (Royce 1987) and the “hacker-like” processes of the ATM group. They were maintaining old legacy software while implementing new software to replace the old proprietary code that was no longer fully supported. They had to interface with other banks and with the largest clients of the bank. Their job was to make sure that the system provided enough visibility into the transactions so that issues could be reported quickly and reliably to the customer.

Tom and Wil had been working with another company in the Soviet bloc and had delivered a number of software management seminars. The slides for these seminars had been translated into Russian, which was good and bad for this new client. It was good in that obviously the people who attended the seminars from the bank could easily understand the slides, but it was bad in that it made making any changes to the slides difficult. This was important because the consultants could not adjust the slides to compensate for issues they identified in the bank projects. This slowed down the effort in transferring new ideas that would help the bank’s software developers improve their projects.

Tanak had requested that all the seminars be performed with translation. This created a new situation for Tom and Wil in which lectures actually took 50 percent longer than in English. So, a two-day seminar now took three days, and the presentations and exercises had to be adjusted accordingly. The additional time resulted in the developers having to work on weekends because the bank did not want to give up two or three days of development time. This put extra pressure on the developers compared to the seminars that Tom and Wil delivered in other parts of the world.

After the answers to the questions came back, it was decided that Tom and Wil would deliver a number of seminars over a two-year period as time permitted, usually every six to nine months for bank software developers. Each time, another seminar and topic was delivered to keep the interest up among the software developers in the bank. The manager of the development group who was responsible for all three of the software areas, Hitmuk, tried to attend the seminars with his engineers. This showed buy-in from management for the time that the engineers were spending on the seminar work. Because the seminars were conducted in the bank, many of the engineers performed their “regular” days of work after the seminars were completed. This put a large strain on the engineers.

The bank was hiring software people as quickly as it could but found, as many other companies have, that if you don’t have clear written processes, then it becomes hard to integrate new engineers into an organization. The new engineers were fresh out of school with little experience but with a great deal of software engineering knowledge. This allowed Tom and Wil to teach more and to concentrate on examples from their experiences managing software efforts. The primary topics that were provided as courses to the engineers were the following:

• Risk management

• Managing technical people

• Quality assurance

• Planning and tracking

• Change management

• Estimation

• Requirements management

As the final lectures were being given at the bank, Tanak Voriba, Tom, and Wil had a conversation. Tanak was the person who originally had established the need for the training at the bank and had asked the consultants to come and teach.

Tanak commented, “I am not sure if my project is going well. Can you guys take a look at it?”

Tom replied with a smile, “Sure, what makes you think there is a problem?”

Tanak said, “Well, only the youngest developers want to work on it, and I can’t seem to get good advice from anyone.”

Wil then asked, “What are you looking for us to provide you?”

Tanak sighed and said, “I don’t know. You guys are smart. You will see what I mean and can probably help.”

Tom and Wil exclaimed quizzically, “OK?!?”

The project that Tom and Wil reviewed had been in the works for three months and was planned to launch in another three months. The product was intended to replace a proprietary and aging system that was not being supported anymore by the original Russian company that had developed the software. The reasons for the project appeared to be sound, and the project was far enough along that many of the decisions about the product were already validated. But some process decisions were still left to be made. Life-cycle processes were still in flux. Tools to support the development process were being introduced in an ad hoc fashion. A mix of technology, people, and processes were being used to address many of the process issues identified in the seminars.

Tanak wanted to know whether an object-oriented development process that was being used by the team for their project was the right choice. The primary issue was that many of the more senior developers in this group and in other groups were unable to help with the project because they didn’t understand the processes being used. Agile techniques, such as Scrum (Takeuchi and Nonaka 1986), had been practiced by the junior engineers in school, but the senior engineers were still waiting for “all the requirements” to be written down so that they could plan their work. The junior engineers were already coding. The architecture was straightforward, but it was obvious that the legacy systems were having a major influence on some of the components. Understanding the legacy systems required a systematic and disciplined method that the senior engineers knew how to do, but the junior engineers were less familiar with this method. Deciding how much of the legacy system with which to work and at what level was an issue.

Tanak wanted to know whether they should change some of the developer information to be more similar to a traditional development approach or whether there was something else that the team should consider doing to help with this transition and support.

Tom and Wil discussed the techniques that the team was using to control the project. The processes that the team was using were, in general, Agile techniques (Scrum-like). The main characteristics of the processes were the following:

• Pair programming among the younger developers.

• Burn-down charts for status reporting that were posted on white boards for all developers to use. (Burn-down charts show the units of work that have been completed against a prioritized set of tasks. They provide a view of how fast the team can complete work assigned.)

• Tight interaction with the customer and use of interviews and surveys to make sure the customer expectations were understood.

The project they were working on was a critical banking application (see Figure 6-2). It was the core for all large client interactions between major customers and the bank. Many of the customers had been with the bank since the days of the Soviet Union. The interactions included the following:

• Making payments in local currency

• Making exchange rate operations

• Transferring money between international accounts and local bank accounts

• Sending service request messages

• Getting account balance information and statements

• Getting exchange rate information

• Transferring payroll to large companies

Figure 6-2: New project under development

This application had great visibility and importance to the continued operations of the bank.

As Tom and Wil talked over the decisions being made on the project with some of the developers, it was evident that everyone who was a stakeholder had a good understanding of the decisions that had been made. The question of whether the process being used on this project was the right thing do was not really the question they wanted to answer. The primary concern was how to show management that the process they were using was the right one.

Tom and Wil referred to the questionnaire that the bank originally had completed. It was evident that management at the bank judged the success or failure of the process being used by its ability to guide software developers in delivering the product on schedule and with minimal defects. Using these as criteria, Tom and Wil began to question the team on how it could show this to management. The team broke down the problem into the following decisions to be made about their processes:

• How could they show management that they were going to deliver the software on time with the process they were using?

• What would be evidence that the quality of the software was better than the old system in spite of the fact that the team also was tasked with maintaining the old system?

• What was a clear indicator of the improved quality of the system over the previous system that management would understand?

Tanak seemed to understand what needed to be shown to management and how he could present the process information to show that his team was meeting its expectations.

Case Problem

Managing the process is more about finding the right type and amount of process rather than being a “taskmaster” to make the people fit the process. Understanding that the process should help the users is critical in understanding how to manage process. Process for the sake of process probably will not result in higher product quality. Also, process that is not embraced by the users creates a problem for management. Everyone needs to buy in to a process, or there will be a problem in getting people to use the process that is proposed. In the case, finding the right level of process is critical for success. If there is too much, the young people will quit, and if there is too little, the more senior developers think they are just “hacking” the code. We’ll leave you to judge whether the manager does a good job of balancing the right amount of process.

Results

The reengineering project was initiated on June 30, 2006, after a horrific week of updating the legacy system for the bank to a new version. The total number of developers at the time of reengineering was eight, including Tanak. The system had not been updated for three to four years, and it missed a couple of critical updates because of some issues with the cost of updates. (That is, the bank was not willing to spend extra money for an “old system.”)

To the developers, it was evident that the old system was going to die some day. The support engineers had to make regular reboots of the system, once a day on average. Corporate customers were very angry with the bank (the bank was considered a corporate bank since its customers were mainly corporations and firms).

The vendor of the system was a Russian software company that sent one of their software consultants to do the system update. While updating the legacy system, the development team and the consultant realized that the system would continue to cause problems even after the update. The consultant discussed the system condition with her company, and the company advised the bank’s developers to consider reengineering the system.

The process of acquiring an understanding of the legacy system along with requirements elicitation and analysis started on July 15, 2006, and ended on September 15, 2006. The effort invested for this stage was 8 developers × 2 months or 16 man-months. The new system design and architecture started on September 15, 2006, and ended on November 30, 2006. The effort for this stage was 8 developers × 2.5 months or 20 man-months of effort. The new system prototyping started on October 15, 2006, and ended on November 30, 2006.

The new system development for the corporate bank market started on December 1, 2006, and ended on February 28, 2007. The new system was integrated and tested using ten offline customers. The system included one simple security policy and supported only five types of business documents. The integration included only one back-office system. The system for the bank was rolled out on March 30, 2007.

The new system development for a corporate market started on January 30, 2007, and ended on May 31, 2007 (three months later). This system would support 10,000 customers and provide the following features:

• Ten types of business documents

• Offline and Web client interfaces

• Three complex security policies for the offline client

• Two complex security policies for the Web client

• One complex security policy for the offline and Web client

• Integration with five back-office systems

The new system for the bank was rolled out on June 8, 2007. The system displayed no significant defects after the rollout. The system was delivered nearly on schedule.

Case Analysis

Analysis Activity

Analysis Background

First Case Problem

(P) Problem: The software development process is creating a gap between groups of engineers on the project, and Tanak wants to prevent the gap from causing problems on the project.

(E) Experience: The previous projects in the bank have used a software life cycle and process that force a great deal of documentation and that focus on quality as the primary aspect of the new system no matter how long it takes. New development processes are not understood or trusted by many of the senior engineers in the organization.

(A) Assumptions: The engineers have the skills needed to deliver the new system on time and with the right quality and features.

(K) Knowledge: The project is developing critical software to be used by some of the bank’s most important clients. The project team will be composed of senior engineers and new hires from the bank.

Solution: Use some new Agile techniques, and through training attempt to persuade more senior engineers to learn and adopt these new techniques. Use this project as a learning model for other projects in the bank.

Assumed Risk:

• The senior engineers have not been trained and may not be able or willing to adopt Agile methods, which would have a negative impact on the team and cause the project to be late.

• The new engineers engineers are using Agile techniques and may not be able to deliver a project that meets the quality expectations of management.

Second Case Problem

(P) Problem: The new development process being introduced on the project is not being tracked well by the old tracking methods. Tanak needs a new tracking method for the Agile processes being introduced.

(E) Experience: The other projects at the bank, except for those in the ATM group, were using a traditional method that bank management understood. The management could easily ask the question, “Where are you?” and the project could answer with a phase name.

(A) Assumptions: Tracking information is universal to software projects. If Tanak could find the right “metrics,” then he could report the status in a way to meet management’s expectations.

(K) Knowledge: All projects appear to measure themselves by size and features developed.

Solution: Tanak needs to develop a measurement method that reflected how the output of the Agile method was meeting the requirements of the project.

Assumed Risk:

• Management would need to trust that what Tanak was saying about the features being delivered was true and that the features represented management’s expectations for the software.

• Management may focus on the traditional artifacts from projects as a method of measuring progress on a project and therefore may not be open to understanding Tanak’s new metrics for representing project progress.

Analysis Questions

1. What were the major concerns that Tanak had about the software development processes being used by the bank, and how might he improve those processes?

2. How did the software processes affect the quality of the software system, and how could these processes be changed to ensure that the right quality was produced for the system?

3. What were the dominant environmental drivers working against the use of new processes, and who was providing the drivers?

Discussion

Tanak, the key character of the story, thought that the main objective of the project was to increase the number of customers (in other words, to increase sales). Was this evident in the story? Sometimes what we want and what the people who work for us understand that we want are two different things. Management in the story had a perception that the objective of the new system was to provide new features, but the developers knew the system was “unreliable.” Was this evident? Sometimes quantitative evidence about the project and project deliverables understood by all the stakeholders is needed to ensure that everyone is working toward the same goal. Otherwise, the project stakeholders must draw their own conclusions about the project deliverables. See the Chapter 9, “Managing Stakeholder Expectations,” on managing stakeholder expectations to develop a better understanding of this concept. The customers thought that the software system was unreliable, but in a new environment, this view can sometimes be mistaken because customers do not know what they want. Once again, quantitative values can help determine what the process should change to make what is being done better. So, even though Tanak had to appease management by adding features, he also had to appease the customer by making the system more reliable and to appease the developers by giving them more control. The processes that were used seemed to achieve all of these requirements. To management and to Tanak, the project was a success.

Conclusions

As you can see from the results of the project, the process seemed to deliver the right quality, to meet stakeholder expectations, to handle the requirements, and to deliver a product that worked. This shows that process crosses many of the domains discussed in this book and is sometimes hard to separate from other aspects of software management. Decisions concerning process affect not only the development team but also everyone involved with the project. As a process manager, you must not only make a process visible but also teach, use, and measure it to ensure that the process is always improving or doing the job that is expected. People often have the attitude that because something has always been done a certain way, they are going to do it the same way. Process needs to evolve in a systematic, disciplined manner to satisfy project expectations.

Key Ideas to Remember

• Process and product are related, but they are not the same thing.

• Decisions to introduce the right amount of process are dominated by the needs of the project. The solutions must be measured against success criteria for the project as well as the processes.

• Process without measurement cannot be improved.