Part-II Project Management Processes

Project Management Processes and Activities

Part III

Chapter 9

Project Life Cycle: "In-Stream" Activities

"Plans are nothing; planning is everything."

Dwight D Eisenhower

Differences between "umbrella" activities and "in-stream" activities - The main in- stream activities-Layout of the chapters in this part-Process/project database.

DIFFERENCE BETWEEN UMBRELLA ACTIVITIES AND IN-STREAM ACTIVITIES In Part II, we covered the umbrella activities of a project. In Part III, we will cover what we call the "in-stream activities". The primary difference between the umbrella activities and in-stream activities lies in when 9.0 these activities are carried out.

• Umbrella activities take place throughout the life of a project. For example, metrics and configuration management are carried out to find out whether the project is in the requirements phase or the implementation phase. Of course, what we measure or subject to configuration management may vary with each phase but their generic activities do not change throughout.

In contrast to the above, in-stream activities take place sequentially and only at some specific times during the project life cycle. For example, project initiation (that we will study in the next chapter) is done only at the beginning of the project. Similarly, project closure (that we will study in Chapter 12) will happen only at the end of the project.

THE MAIN IN-STREAM ACTIVITIES

9.1 If we were to decompose a project life cycle from a software engineering perspective, we would end up with different phases/ activities, such as requirements, design, implementation, testing, etc. This is the perspective that shall be covered the next part. But if we look at the project 148 Managing Global Software Projects

management aspects, we can take a different cut at the life cycle. The main in-stream activities during a project life cycle can be summarised as shown in Fig. 9.1. From a project management perspective, there are four main in-stream activities-project initiation, project planning, project monitoring/ tracking and project closure.

As discussed in Chapter 2, each project has a definite beginning and a definite

end that demarcates the project. The beginning of the project is when the project is signed off to be executed by the organisation's management. Project initiation takes place at that time and marks the official commencement of the project. It is a way of announcing the start of the project and also briefing everyone in the organisation on what their roles are and what the organisation expects of them. The details of project initiation activities are discussed in Chapter 10.

A project plan is put together that serves as the roadmap to steer through the project and to evaluate and measure progress. The primary responsibility for putting together the plan lies with the project manager identified prior to the initiation phase. A number of activities go into putting together this comprehensive 149 Project Life Cycle: "In-Stream" Activities

project plan (also known as the Software Project Management Plan or SPMP for short). Once the project is initiated, planned and is in the execution phase, it has to be monitored to ensure that it is adhering to the plan. Risks are identified and contingencies deployed; it is ensured budget and other constraints originally stipulated are not violated. The details of this Project Planning and Monitoring (Tracking) Phase are discussed in Chapter 11.

Finally, every project comes to an end. It is important to glean some learnings from each project and apply those learnings judiciously in subsequent projects. That is what the Project Closure phase is about. This phase is discussed in Chapter 12.

PROCESS/PROJECT DATABASE

9.2 For each of the in-stream activities, we discuss the details of the parts that make up that activity; the success measures and the common pitfalls to watch out for. In order to gain leverage from the learning from a project and effect continuous improvement, it is important to capture and analyse the data from each of the in-stream activities. The vehicle for capturing this information is called Process (or Project) Database". At a very high level, such a database simply consists of

Organisational and operational processes The project plans for the various projects / products in the organisation

(schedule, resources, etc.). Snapshots/ status information on the various projects that gives a point in time view of the projects (progress, status reports, alarms, etc.).

Metrics about the projects (end goal metrics, in-process metrics) :Lessons learnt from the project (what went right, what went wrong, etc.)

This information comes from the various steps of the in-stream activities discussed in this part of the book, such as Project Initiation, Planning, Tracking and Closure. In order to understand the specific information gathered from each of the activities, we have a section at the end of each chapter that discusses the interfaces to the Process Database. _______________________________

Note that we are using the term Database in a generic sense, as an aggregation of the documents and data.

Chapter 10

Project Initiation

"Begin with the end in mind. II

Stephen Covey

When does a project get 'initiated? An overview of typical activities in project initiation - Outputs, quality records and completion criteria in project initiation - interfaces to the process database.

INTRODUCTION 10.0 As discussed in Chapter 2, each project has a definite beginning and a definite end. When would you say that a project has started? A project is said to have started when the senior management of the organisation understands a very high level description of what needs to be achieved from this project (goals) and makes a commitment that it would undertake the project. Project initiation is an activity that marks the formal start of a project. At this stage, the senior management also identifies a project manager whose charter is to take the responsibility and work towards achieving these high level goals. In the case of a geographically distributed team, local project managers (i.e., a project manager for each location) are usually identified at this stage.

As can be seen from the above discussion, the commitment of the senior management is one of the primary inputs for project initiation. It is to be noted that at this stage, a statement to this effect is made at a very high level and typically does not carryall the details. In addition to the commitments, the second input to project initiation is usually the list of constraints under which the project is to be carried out. The constraints could be on the budget, deadlines, resource usage, or any combination of these factors. Some examples of such constraints are: 151 Project Initiation

This project should be carried out within $500,000 The project should be delivered well before Christmas so that we can make it

to the holiday season The product should be designed within a cost that does not exceed $200

ACTIVITES DURING PROJECT INITIATION 10.1 In this section, we go into the details of some of the important activities carried out during the project initiation phase:

Management team building Scope and very high level work division agreements Decision of management reporting/ escalation procedures Involvement of infrastructure / support groups Team formation Project kick-off meeting.

Management Team Building As we will discuss in Chapter 19, global teams face some unique challenges because of the reduced opportunity for face-to-face interaction. Hence some amount of pre- planned, pro-active, and up-front relationship building between the teams is very essential. Project initiation is the time when this relationship building starts.

It is highly recommended that the identified local managers have a face-to-face meeting for the first few days. Ideally, this meeting should take place at a location where a large part of the team is currently residing / will eventually reside. Such a meeting serves the following purposes: It enables the team members to understand one another and to build a

cohesive management team: The success of a geographically distributed team depends on how well this team can function as a single unit. Close co- operation and understanding between the members of the management team is an essential pre-requisite for this. It is difficult to achieve this cohesion effectively without meeting the team members in person. Such a meeting puts a face to the email id and that always helps!

Minimises the impact of cultural and language barriers: It has been proven that the most effective communication is non-verbal (i.e., using gestures, eye contact, body language, etc.). Conventions of using language gestures etc., vary significantly from one country to another. If such cultural differences and traditions are appreciated by team members belonging to other countries, it may lead to misunderstandings. A face-to-face meeting enables the people

152 Managing Global Software Projects

to overcome these barriers. It enhances their communication and understanding by enabling them to discern the intent as well as the content of communication.

It is a sign of commitment: In today's typical scenarios, where teams get distributed between diametrically opposite ends of the world-e.g., California and India-travel is an expensive and a time consuming proposition. Taking the time to travel=-especially by the management team- acts as a show of commitment by the people involved and indicates their seriousness and willingness to make the project successful. By making the project managers travel early in the project, there is a demonstration of leading from the front in an attempt towards team building.

As the project progresses, it is important to continue this team building exercise by encouraging (to the extent that is reasonable and permissible from the budget point of view) travel and face-to-face meetings. Also, some amount of socialising, that is not just confined to project meetings, has been found to be highly beneficial in increasing the cohesiveness and gelling. of the teams. More about this in Chapter 19.

Scope and High level Work Division Agreements When the local managers meet during project initiation, one of the goals to be achieved (other than rapport building described above) is that they should clearly understand the overall scope of the project and the roles and responsibilities of each manager (and his team).

We will cover the details of Scope Review and Requirement Planning in Chapter 14. For the moment, the purpose of scope review during the project initiation phase includes:

Verifying that the scope is clearly documented and consistently understood by all the members concerned.

Identifying any obvious bottlenecks or impossible constraints and alerting the management on these.

Doing some initial risk analysis and contingency / mitigation planning.

After the scope of the work to be done is reviewed work allocation across the

different sites is agreed upon at a very high level. Some of the work allocation questions discussed during project initiation include: '(a) How does the work get divided among the various groups? (b) What are the components that each group should be working on? (c) What are the task types that each group should be working on? (d) How do the groups communicate with each other? 153 Project Initiation

This high level work allocation serves as the basis on which the Work Breakdown

Structure evolves in the project planning and tracking phase (which we cover in the next chapter).

Management Reporting and Escalation Procedures

We cover Status Reporting as a separate topic in detail while we discuss Project Tracking in the next chapter. For now, it should suffice to say that project initiation is the time when some of the expectation setting for status reporting, such as the following, takes place:

1. Whose responsibility is it to document the progress and actions? 2. Who would track the action items to completion? 3. What would be the time out period for resolutions / responses to issues raised?

Geographically distributed project teams have dependencies upon one another; when issues need to be resolved across the teams, there should be a uniform understanding with respect to prioritising the issues and the timeframes in which to except resolution of these issues based on the set priorities.

4. Who would be the recipients of the reports and what action would they be expected to take on the reports?

5. What would be the level of detail, content and format of the status reports? 6. What would be the modalities of communication between the various groups:

Conference calls? Travel? What would be the Frequency?

Involvement of Infrastructure/Support Croups

A project group does not operate in isolation. For success, it requires the active participation, support and co-operation of other infrastructure groups, as illustrated in Fig. 10.1. For example:


Human Resources group: responsible for hiring, training and working out policies for retention. Even though the training function is usually a part of Human Resources, in our discussions, we treat if as a separate function because of its complexity and importance.

Facilities Management group: responsible for allocating and maintaining common facilities like office space.

Administration group: responsible for travel and other logistics. Hardware Infrastructure group (also called the"Data Center Management

Group"): manages all the machines, network, etc. Finance: for budgeting, cash flow management, etc. Corporate Quality group: for aligning / adapting the organisational processes Senior Management: for providing the overall support and commitment

needed.

During the project initiation phase, it is important that the expectations from each of these groups are conveyed to them clearly so that they can plan and optimise their workload and procedures accordingly. Typically, the interaction with each of these groups is in line with the model depicted in Fig. 10.2:

1. The project manager arrives at some initial estimate of the service levels and

resources needed from each of the infrastructure groups and conveys the 155 Project Initiation

same to them in a project kick-off meeting. This meeting is attended by all the infrastructure groups so that every one gets a consistent view of the project.

2. The infrastructure groups take these inputs in the context of similar information they have from the other project groups and arrive at an estimate of what all is required to satisfy the needs of the entire organisation.

3. The infrastructure groups work together to identify common dependencies among themselves. For example, there would be dependencies between the data center and the purchasing groups or between the recruiting and the training group.

4. The infrastructure groups come up with aggregate plans and processes to optimally and effectively satisfy the company-wide business objectives and the needs of individual projects. For example, when the purchasing group is armed with the estimate of the number of workstations / pes that are required on a company-wide basis, they would be able to negotiate a better deal with the suppliers based on volumes.

5. As and when the requirements for the project change, the project groups convey them to the infrastructure groups who in turn fine-tune their processes to cater to the changing scenarios.

The table below lists some of the specific interactions between the global project

teams based on the above generic model.

Table 10.1' Infrastructure Group Functions

Group Initial information to be supplied by the project manager

Aggregation done by the group

Challenges to watch out for

Staffing (HR) Number of people Date when required Skill sets Experience levels

Arrive at the total number of people needed and optimise on recruiting trips, advertisements, etc .

Get an economy of scale to be a force to reckon with in the recruiting market

Timely availability of people

People not turning up after accepting an offer

Overseas attraction (especially when working in countries like India)

(Contd.) 156 Managing Global Software Projects

Group Aggregation done

by the group Challenges to watch out for

_.

Trailling-{HR)

• Arrive at vofumes to facilitate negotiation

• Identify trainers , Evaluate in-house

training to minimise travel and other costs

• Explore the "Train the Trainer" approach

• Explore e-Learning opportunities (see Chapter 20)

.Non-availabilityof - qualified trainers

• Clash of schedules between project deliverables and training

Facilities

• Consolidated floor plan

• Arrangements for other supporting facilities

• Space fragmentation resulting in reduction in face-to-face communication between the project team members

• Sub-optimal space utilisation

Travel

• Volume discounts • Availability

leveraging • Value-added

services like visa co-ordination

• Change in governmental procedures

• Inability to satisfy travel needs because of non- availability of airlines ticket and external constraints

• Short notice from the project teams in cases of emergencies

Hardware infrastructure (Data Center)

• Consolidating the server and other common hardware requirements from various groups to share these across projects and locations.

• Volume purchase to get better rates

• Under-estimation of hardware

• Changing requirements • Support availability • Governmental

regulations

(Contd.) 157 Project Initiation

Group Initial information to be supplied by the project manager

Aggregation done by the group

Challenges to watch out for

Negotiation for better support commitments from vendors

Exploration of infrastructure capacity planning (e.g., power, UPS, network capacity, etc.)

Corporate Quality

What organisation -wide processes would this project use?

What is the tailoring needed to adapt the processes to this project / product?

Aggregation and abstraction of tailoring

Keeping the corporate process assets updated

Striking abalance betweengenerality and the specificity

Finance Financial commitments needed for this project in terms of manpower, infrastructure, travel etc.

Cash management Cost management Profitability

management Budgeting

Projections are not always accurate; the practical impact from the financial aspects is difficult to side-step

Senior Management

Overall needs from the organisation that needs senior management's support (e.g., special infrastructure)

Overall resource planning

Each project may feel its needs are important. So there could be conflicts between project groups

Among the above interactions, those pertaining to staffing, training, and facilities

are probably not very different for a single-site project than for a geographically distributed team. In contrast, travel and infrastructure planning acquire new dimensions in the case of geographically distributed teams.

One of the biggest cost drivers and operational challenges in the management of global project teams is travel. For a project to be successful, a certain amount of travel has to be planned for and some of the reasons for this are: 158 Managing Global Software Projects

Delivery demands: certainactivities require on-site testing Government regulations: some software cannot be exported for security

reasons Minimising time: sometimes it is expedient to co-locate the teams in one

place to speed up deliveries Building team-work: it has been proven that better team-work can be built

when the team members work together in the same location for some time

Travel has the maximum external dependency (airlines, holiday season, visa availability, etc.). Even with the best of planning, travel is often most difficult to schedule (slippages, personal commitments, etc.) Finally, travel is extremely expensive. Because of all these factors, any extra effort that goes into better planning, managing, and controlling travel will be well worth the while as it will contribute to the success of the project and cost-effectiveness of a geographically distributed project team.

With regard to hardware infrastructure planning, again some unique challenges come into play for geographically distributed teams. As compared to a single site team the overall hardware requirements for a geographically distributed team are more difficult to predict. Some of the reasons that add complexity include:

Hardware requirements for geographically distributed team entail communication bandwidth and higher costs. The demands on the bandwidth depend upon the project mix, which phase of lifecycle projects are in, etc. All these factors make it difficult to provide information on the exact requirements.

In order to reduce dependency on the communication infrastructure, some of the information may be replicated in local sites. This arrangement, besides opening up configuration management issues of keeping the replica in sync, would also entail additional costs.

In some countries, lead time for any purchase is high and during this time the various hardware models and configuration may become obsolete. This could lead to a discrepancy in the configurations used by the team members in different locations.

Team Formation

The final activity of project initiation is the formation of the complete team. It is related to the hiring activity. Normally, in geographically distributed project teams, 159 Project Initiation

a seed team is formed first and the planning (and rest of the hiring) starts later. The extent to which multiple teams gel together will depend on the rapport between the members of the management team to start with. Once the people come on board, this rapport building must percolate down to the next level through personal visits, video conferencing and a host of other team building exercises. Project Kick-off Meeting The project kick-off meeting is formally attended by all concerned so that everyone has a common understanding of what is expected of them. It can be viewed as a sign off meeting. The minutes of this meeting are recorded and circulated to all concerned. The kick-off meeting minutes is the link that formally triggers the project planning phase. OUTPUTS, QUALITY RECORDS AND COMPLETION CRITERIA FOR THE PROJECT INITIATION PHASE 10.2 Project initiation marks the formal beginning of the project. At this time, what we have is a very high level understanding of the requirements of the project and the demands placed on the supporting infrastructure. The real success measure of the project initiation phase depends on how good this initial understanding is. Some of the traits of a successful project initiation are:

How well the requirements are understood: This is reflected through how often and how drastically the final requirements change from the original understanding.

How good is the gelling between the management team members and the engineers working on the project: Some of the indications of this gelling are escalations, attrition etc.

How good is the gelling between the different teams that are geographically distributed: An indication of this is how seemlesly the teams work together.

How accurate were the infrastructure requirement specifications: For example, after the project started, how many hardware upgrades were requested? How many unscheduled travels took place?

How effective was the infrastructure consolidation: Even though this is not a direct outcome of any single project, this factor is something to watch out for. If the initiation and the subsequent planning is done right, the


infrastructure groups would have sufficient inputs to optimise their functions. Outputs/ Quality Records/ Completion Criteria

A statement of understanding of what the requirements and constraints of the project are

A statement of understanding of the requirements from the support/ infrastructure groups

Identified set of people to work on the project (if selecting from the existing set) or forming a seed team with clear hiring targets

INTERFACES TO THE PROCESS DATABASE 10.3 Table 10.2 Process Database Interface for Project Initiation Entity Description

Experience of similar projects in the past

This information is used to benefit from any lessons learnt in terms of constraints faced, resources needed, etc.

Needs from infrastructure groups

This information is input into the database. As the project progresses, this information may change. The extent of change is a measure of (in) accuracy of the initial estimates; also used by the infrastructure groups to perform their aggregation and optimisation.

Members of the management team and description of reporting/ escalation procedures

This information is input into the database and acts as a guide on communication

Initial scope This is input into the database. It serves as the high level roadmap for the project.

161 Project Initiation

CONCLUSION A well planned and well executed project initiation usually augurs well for a good project and enduring relationships. The intensity of some aspects like team building depends on the relationship that already exists between the different project team members and whether they have already worked together. For some activities like scope review and requirements definition, a certain amount of formalism is usually in order and is also effective. The challenge lies in making the project team strike the right balance between formalism and relationship build- mg at the project initiation stage. At the end of this chapter we present a checklist of points to look for in a successful project initiation.

REFERENCES [DEMA-87] covers some of the aspects of team building we have discussed in this chapter. The People CMM covered in [CURT-95] provides some formalism into the mechanics of some of the areas we have covered in this chapter, like hiring, training, etc ..

CHECKLIST FOR PROJECT INITIATION Has the Senior Management documented high level commitments?

Have the underlying constraints been documented? Have the local project managers been identified? Have the local project managers met? Has the scope of work been identified, documented, and agreed upon by the local

project managers? Have the high level work allocations between the various locations been decided?

Have management escalation procedures been decided and documented? Have the skill sets needed for the project been identified and communicated to the

human resources group? Have the hiring requirements and the timings been conveyed to the human resources

group? Has the facilities management group been notified the need for office space and other

facilities? Have the direct and infrastructure related hardware and software requirements been

documented and agreed upon with the data center management group? Has some preliminary estimate of travel been made?


Have the financial budgets been cleared with the finance department? Have the organisational processes been customised / adapted / tailored for this project?

? PROBLEMS/QUESTIONS 1. What would be the impact of not having the infrastructure groups present in a project

kick-off meeting? 2. Consider a geographically distributed project team. A project group typically knows

only about the specific hardware that it requires. Usually, at the beginning of a project, the exact load on common facilities like the bandwidth required, common configuration management servers etc. would not be known. To complicate the matter further, the performance of the network is determined by the work load of the entire project portfolio at any given instant rather than a single project. What steps would an organisation take to plan the capacity of these common resources so that project teams have an acceptable level of performance while not over-investing in them?

3. An audit of an organisation revealed that there were three different maintenance projects and that each of them had its own methods and procedures for what is essentially the same generic function. Do you think this is acceptable? Can this be improved? If so, how? Now, assume that the organisation is embarking on a fourth maintenance project. You are the quality manager of the organisation and you are at a kick-off meeting for this new project. How would you add value to the meeting and to the project?

4. Form a cross-cultural group of people in your organisation. Explore ways of promoting teamwork in this multi-cultural, multi-lingual group.

Chapter - 11

Project Planning and Tracking

"Failing to plan is planning to fail." • Anonymous Components of project planning and tracking- Identification and quantification of goals, arriving at work breakdown structure and size estimates (the WHAT part)- Prioritisation of features and translating size estimates to effort estimates (the WHAT COST part) - Identifying dependencies and milestones (the WHEN part) - Tailoring of organisational processes for the project (the HOW part) - Work Assignment (the BY WHOM part) The SPMP-Tracking procedures-Status review and reporting-Com- munication - Inferfaces to process database. 11.1 Project Planning can be viewed as the putting together of five inter- related pieces as shown in Fig. 11.1. COMPPONENTS OF PROJECT PLANNING AND TRACKING

164 Managing Global Software Projects The "WHAT" part (contents): Planning a project entails deciding what needs to be delivered. For a product, the WHAT will translate into what features to deliver, on what platforms and in what environments. For a service, the WHAT refers to what is the service we are going to provide (number of people available on-site / number of people available off-site etc.).

The WHAT COST" Part (money, qualtty ', performance): Everything comes for a price! In the previous chapter, we discussed some of the constraints that could be specified by the senior management during project initiation. The "WHAT COST' part of project planning is about understanding these constraints clearly and accounting for them in the project plan so that the constraints are not violated. It helps understanding the scope of the work and focuses on how to get the maximum bang-for-the-buck.

The WHEN" Part (schedules): As discussed in Chapter 2, each project has a definite start and a definite end date. The WHEN part of project planning is about timelines of when we will deliver what parts of the project or the product. Project tracking is about ensuring that such timeline targets are achieved and the product reaches the market within the stipulated time by completing each activity as per the time schedule.

The HOW" Part (processes): If you view a project as a game that is being played to win, the project plan can be viewed as the play book that is used by the coach at the beginning of a game to evolve the specific moves and situations in order to win the game. The project plan should specify what processes are to be followed, how they are different from the processes currently being used in the organisation, and how to re-use the existing processes and fine-tune them for the specific needs of the project. Just as one can't win a game without having some idea of the "How" aspect in place before starting the game, one can't execute a project successfully by merely knowing the WHAT, WHEN and WHAT COST aspects. It is essential that one has some idea of the HOW part of the project. The "HOW" should have sufficient flexibility to adapt to changing situations that will arise once the project gets under way.

The BY WHOM" Part: The BY WHOM part of the project plan lays out the roles and responsibilities of the various members and what is expected of each one of them. This builds upon the responsibilities of each local team as was initially agreed upon during project initiation.

_______________________________

1 Note that by "Quality" we mean "Quality of Design" as explained in Chapter 7; we certainly do not suggest that quality of conformance should be compromised!

165 Project Planning and Tracking

Why are we discussing the planning and tracking together? Project planning is really a one time activity (In this sense, one can call project planning and track- an umbrella activity instead of an in-stream activity). The project manager is always in the planning mode. He sets up an initial plan based on the above five dimensions and then keeps his antennae open (which is what we call tracking). Depending on the signals he looks for and receives during the tracking process, he fine-tunes his plan. Sometimes, the fine-tune may even be as severe as a U turn, which would involve undoing an action or a plan made earlier. But all this is a part of the game! Remember that sometimes the quarterback in American Football does play calling at the line of scrimmage and that a cricket captain has to change his planned allocation of overs to the bowlers based on which batsmen come to bat and what form they are in!

We would like to draw a parallel between project planning tracking and risk identification/ risk monitoring. In the chapter on risk analysis, we mentioned that risk monitoring is done on a continual basis by looking out for symptoms of risks and then re-evaluating whether there is any change in the risk factors. Project planning and tracking are similar. When you track the project on a continual basis, you may find that there is a need to change the WHAT, the WHEN, the HOW, the WHAT COST or the BY WHOM components. Thus, through this entire chapter, most of the discussions apply to project planning as well as the project tracking phases. These "phases" can also be viewed somewhere like the umbrella activities that happen throughout the life of the project.

THE "WHAT" PART OF A PROJECT PLAN 11.1 You should start a project only when you know what you want to achieve. The "WHAT" part may be a bit fuzzy to start with in terms of details but at least you know roughly what you are heading for. If you don't have even a rough idea, it is a serious problem! By starting with a rough idea of what you need to achieve, and then using the techniques and tools described in this chapter and by performing a systematic requirements management (as will be discussed in Chapter 14), some (or most) of the fuzziness can be removed.

When starting a project, one starts with some statement of what the stated requirements are. These could be macro level statements like "Design of an Invoicing System that automates our Order Processing" or "Designing the next version of a database that supports features Fl, F2, F3 on the platforms PI, P2, P3". One also

/ 166 Managing Global Software Projects starts with a set of implied requirements (as discussed in Chapter 7). Such implied requirements can be something like "the system should be user friendly" or the "system should be robust", etc. As can be seen most of the implied needs tend to be somewhat hazy in character. When the project is planned properly, the haziness that surrounds the implied requirements clears and most of them get paraphrased into stated requirements. This is accomplished by using the Work Breakdown Struc- ture discussed below. Work Breakdown Structure What Is Work Breakdown Structure?

Work Breakdown Structure is the decomposition (dividing) of the project into smaller and more manageable parts (called work breakdown structure units or WBS units), with each part satisfying the following five criteria:

Each WBS unit has a clear outcome. The outcome has a direct relationship to achieving the overall project goal Each WBS unit has a single point of accountability. Each WBS unit is something that can be tracked and monitored as an unit. Each WBS unit has a well defined interface to other WBS Units.

Why Do Work Breakdown Structure?

Divide and Conquer: Decomposing the project into smaller and more manageable components falls in line with the Divide and Conquer approach. The smaller components are likely to be less complex to understand and crack than the original (larger) project.

Estimate the size of the final product more accurately: When a large size project / product is broken down into manageable WBS units, it becomes possible to more accurately determine the size of the that unit. As we discussed in Chapter 4, having an initial size estimate of a component leads to a better effort and schedule estimate later.

Means to explore re-use: It is almost certain that no complete project is exactly like another complete project. But it is more than likely that parts of one project are similar (if not identical) to parts of another project. Consider the example of building say, a report generation tool and a data entry tool. These are definitely completely different in terms of their functionality. But these two tools do have some parts in common, e.g., the terminal handler, the routines that access the database for information, etc. The WBS can identify such commonalities so that the existing components can be re-used.


Ability to identify skill sets: Building a 'prodtrct can involve a range of different skill sets, e.g., design skill sets, skill sets for coding, testing, implementation and documentation, etc. The WBS divides the entire spectrum requiring heterogeneous skills into multiple, smaller parts each of which require skills that are somewhat homogeneous; thus enabling the identifying and scheduling of resources with the right skills. Ability to multiplex people and hardware resources: Following through from the last point, another benefit that the WBS provides is scheduling of machine resources. When the WBS is performed appropriately the tasks emanating out of the WBS can maximise the utilisation of the hardware resources to achieve the maximum parallelism. Linking WBS units with milestones as ways of measuring progress: WBS and milestones can be viewed as two sides of the same coin. The WBS partitions the work needed to accomplish the entire project and milestones partition the time frame between the start and the end of the project. A good WBS results in effective milestones and vice versa. A good WBS produces meaningful interfaces: Each WBS unit can be viewed as a self sufficient unit with well defined interfaces to the other WBS units. A well designed WBS will have the inherent advantage of being easier to specify, debug, and maintain. How Is Work Breakdown Structure Done! Figure 11.2 presents one way to arrive at Work Breakdown Structure Units.

Fig. 11.2 Work Breakdown structure


First, an overall requirements study is done. This can make up one WBS unit.

The outcome of this WBS unit is the documentation of what the requirements of the system are. For a complex system or a system that spans several geographic locations, this WBS unit can be further subdivided into smaller units either on the basis of its functionality or on the basis of its geographically distributed users. The skill sets required for this WBS unit are typically a sound domain knowledge and good interaction with people. Some amount of technology knowledge is also required.

The next WBS unit can be viewed as arriving at an overall architecture for the system. By architecture, we mean aspects like: What are the overall components of the system? How do the components interact with each other (in particular, what

interface do these components provide?). Are there any technology constraints on the components? For example,

any adherence to standards may be a typical architectural constraint. Which of the components can be re-used (or should be made re-usable)?

For example, standardised validation routines may be reusable. The outcome of the architecture is the identification of distinct modules or

units that need to be worked on. Also some initial estimate of the size of the WBS units is obtained at this stage that acts as the basis for further effort/ schedule estimation.

The individual modules or units are then analysed for dependencies to determine relative sequencing of the modules. If the interfaces are well defined, stub routines that mimic the interfaces can be written to achieve some degree of parallelism of releasing building blocks or modules. But as the project progresses, some of this parallelism will reduce as there would be a need to synchronize and use the actual interfaces.

The definition of the WBS units is further strengthened by prioritisation/ sequencing of the required resources and skill sets.

The factors that determine the success in arriving at effective WBS units are:

Identifying logical components: A well structured WBS is natural, i.e. "logical components" automatically become WBS units and invariably end up as functional components (e.g., terminal handlers, database handlers, etc.) or life cycle components (like requirements, design, etc.) or geography based components (like requirements for a specific location).

Identifying discrete components of a project (e.g., relationship management): Sometimes, work breakdown structures may arise out of identifying discrete logical

169 Project Planning and Tracking components of work. For example, several project groups may be dealing with an external agency or a contracting firm. In such a case, managing the relationship with the external entity would become a logical unit by itself. It would make sense to make this a separate WBS unit and assign responsibility to one individual. This would enhance communication with the external entity by presenting a single point of contact to them from the organisation. Having clear deliverables: Each WBS unit has a clear deliverable that is easily identifiable and trackable. By identifiable, we mean that the deliverable is tangible, e.g., requirements specification document / test case design document / source code identified by a particular label/ test log that shows the presence or absence of results of running a set of tests, etc. By trackable, we mean it is possible to specify whether a particular deliverable is say 50% complete or 80% complete. It is in this context that the size estimate assumes importance. Offering well-defined interfaces: Each WBS unit should be usable in other WBS units. When the deliverables from one WBS unit are used in another WBS unit and there is some unexpected behaviour, there should be a clear cut way of identifying and tracking which WBS unit is responsible for the misbehaviour. In order to do this, each WBS unit must have a well defined set of interfaces. So long as the WBS unit produces these interfaces, it is supposed to have done its job. Minimising communication overheads between WBS units: One of the main goals of decomposing the project into WBS units is to enable as much parallelism as possible between all the tasks. To achieve this, it is important that the communication overheads are not too high. The WBS units should have a fair degree of isolation among them and the clear deliverables and interfaces should be the only means of communication between them. Also, the need for human communication between the WBS units should be minimised. Providing autonomy and authority for WBS units: One of the advantages that the WBS is designed to offer is that we can break down the project into smaller parts that are relatively well defined. It is important that each WBS unit has a certain amount of autonomy that enables it to decide independently on how to implement functionality it is striving to provide. Work Breakdown Structure for a Global Project Team When a product spans several teams across the globe, choosing a proper work breakdown structure assumes paramount importance. We will discuss the challenges and issues of global teams in detail in Chapter 19; here we will just outline the different models that can be used for identifying WBS units for a global team.

170 Managing Global Software Projects In the case of a global team, the WBS units must be even more clearly defined as

there are more communication barriers arising from cultural issues, time difference, and other such factors.

One way of identifying and allocating WBS units for a global team would be to use a Resource Model. In this model, the different teams are not on a peer-to-peer relationship with one another. One team acts as the primary location which exercises management control and treats the team(s) in other locations (called secondary locations) as resources. Work is palmed off to the resource team on a need basis. This model has several issues with respect to motivation and retention of staff in the secondary locations. Besides, this model inherently is not based on having clear cut interfaces (unlike the life cycle model discussed below).

Yet another way that the WBS units get assigned to individual locations could be by giving responsibility on specific life cycle activities to teams in specific locations. For example, the activities of requirements gathering and specifications can best be carried out by a team that is in physical proximity of the actual market. Another example would be that if a team in a particular location has exhibited skills in certain special areas (e.g., Design / Programming / Test Development, etc.), it would make sense to package these activities as one or more WBS units and assign them to the team in that location.

A third model could be when the teams in different locations act as peers. The leaders of each of these teams arrive at the WBS units by taking stock of the strengths and aspirations of all the teams, the deliveries to be made, the timeframes involved, and work as one team to arrive at WBS units. In this case, each WBS unit may span geographic boundaries and would therefore require tighter management.

THE "WHAT COST" PART OF A PROJECT PLAN

11.2 The WHAT COST part of a project is closely linked to the WHAT part. Once the requirements crystallise into stated requirements, they should be prioritised as per the following categories: Essential or committed: These are features or functionalities that the product absolutely must possess in order to succeed in the market place. They can be the USPs (Unique Selling Propositions) that will give the product an edge over the competition or just the bare minimum functionality that will make it usable. In


other words, the project is not considered complete unless these essential WHATs are accomplished. Nice to have: These features, though not absolutely necessary, are highly desirable in a product. They may not be essential to complete the product/project but would add value if we could provide resources and accomplish them. They can be incorporated as stretch achievements to shoot for once the essentials have been achieved. In order of priority, these "nice to have" features will find their place below the essentials. Frills: These are even lower in priority and can be taken up only after the first two categories are over.

It is also possible to number the priorities as 1,2,3, etc., with 1 being the highest priority and the successive numbers corresponding to relatively decreasing priorities.

The WHAT part and the feature prioritisation part of WHAT COST provides an initial size estimate of the project. The size estimate could be expressed in terms ci KLOCS, function points, feature points or any other methods discussed in chapter 15.

The WHAT COST part of the plan determines the effort estimate. To arrive at the effort estimate from the size estimate, historical productivity figures are needed. While translating the size estimate to effort estimate, the following should be taken care of: The technologies available are similar: When the old productivity figures are used, the new projects should be using similar technologies too. For example, if the earlier projects used an IDE (Integrated Development Environment), it is inappropriate to use the data from these for arriving at effort estimates of new projects which do not use an IDE. The projects are similar: It is not appropriate to compare the effort estimate of an application project for developing say, an operating system or a database management system. Even if both of them are in C language, the effort estimates would most likely be different for the two projects. The skill sets of individuals are similar: If there are new team members, their experience levels should be considered before using the existing productivity figures. For example, when there are people with less experience, you may have to account for training time and thus discount the earlier productivity figures. All aspects of re-use are considered to minimise cost: When a project is carried out, its decomposition into WBS units would bring forth the existence of re-usable com-

172 Managing Global Software Projects ponents. When arriving at an effort estimate, such re-use possibility should be actively considered to minimise the overall effort on the new project. THE "WHEN" PART OF PROJECT PLANNING 11.3 The WHEN part is about timelines of deliveries. The planning of the WHEN part can be accomplished by the following three steps: Identify- ing external dependencies, identifying internal milestones, and identifying sync points. Identifying External Dependencies

Each project is bound to have certain external dependencies, i.e., dependencies beyond the direct control of the project manager. The actual completion date of a project (or part thereof) can only be stated as an offset from the dates that these external events happen. Thus the first step that should be taken is to identify these external events, assume certain reasonable dates for these events to take place and then calculate the other internal dependency dates as offsets (or relative dates) from these external events. When there are multiple external events that need to take place before a particular project step can be taken, then the offsets should be with respect to the furthest date. In order to reduce the delay in the final delivery, the project manager should try to accomplish as much internal milestones (discussed in the next section) as possible with as little dependence on external events as possible.

Some of the typical external dependencies are:

Staffing: People have to come on board for a project to be delivered. Either they will have to be moved from other projects within the organisation or they will have to be hired. While this is an activity in which the project manager does get involved, there are significant factors at play that are beyond his control, e.g., the speed at which the recruiting department is able to act, the external market forces and the organisational policies on compensation. Training: In some projects, there would be a need for the staff to get trained on new technologies or tools. The availability of qualified trainers may be a constraint. One way to minimise this dependency is to use e-Learning (see Chapter 20). Acquisition and commissioning of new hardware: For commodity hardware like PCs, there may not be any delay in the delivery and commissioning of hardware. But in the case of esoteric hardware like large servers or process control machines,


there would be a lead time for delivery and commisssining of hardware that has to be factored in. If the project takes four months of calendar time, this has to be relative to the time the machines are commissioned. Availability/completion of modules/products from other projects/vendors: If the product requires another product or a new version of another product, one may have to wait for that (second) product/version to be available. This is similar to the scenario for acquiring new hardware, but the difference is that this could recur multiple times during a project. For instance, one may get a new version of an underlying (pre-requisite) software, find that the version has a bug, report the bug to the product owner / company and then be forced to wait for him to fix the bug before going ahead. If the development of the product takes an elapsed time of one month, the one month would be from the time the underlying prerequisite software is available in a usable state. Travel: At some point of time, the staff would be required to travel from one location to another-it could be for initial planning or training or for some on-site testing/benchmarking or for the final delivery. While one can plan these in advance, delays are still possible. There may be visa restrictions (causing the most qualified person to be ineligible for travel) or non-availability of tickets (e.g., travel during the holiday season) or other such factors. If on-site testing requires one week of calendar time, it has to be relative to the date that the engineer lands on site. Internal Milestone Identification The ultimate goal of a project is to produce the end deliverables required by the customer within the stipulated time frame and compliance with the cost constraints. Strictly speaking, the project plan can simply be "do what it takes to produce the end result"! But such an abstract and high level plan is obviously not of much use because we would neither know what we are getting into nor be able to spot the landmines sabotaging a project until it is too late. Hence it is important to set some internal milestones for a project. What are the internal milestones? They are the measurable and quantifiable attributes of progress They are intermediate points in the project which ensure that we are on the right track. They are basically fully under the control of the project manager.

What are some of the characteristics of effective internal milestones?

174 Managing Global Software Projects Milestones should be outcome based and not activity based: Milestones are sometimes stated as "perform review meetings". This is not sufficient as it merely stipulates that an activity is completed. A milestone is about achieving certain outcomes that measure the progress of the project. The above example is just about a meeting taking place and that does not say anything about the progress. An outcome based milestone for review could be: "design review is completed and signed off by the customer and the project manager".

Milestones should be at reasonable time intervals to the duration of the project: How many milestones should we have in a project? If the project is a short, urgent project which spans, let us say, just a few weeks it would be very appropriate to have a daily milestone (i.e., what should have been accomplished on each day) because changes do take place very fast and you have to respond to them very quickly or else the opportunity is lost. On the other hand, if it is a one year project, would it make sense to do have daily milestones? Probably not - for two reasons: First, changes do not take place that fast; second, it is not necessary to respond to the changes with the same alacrity as in the high pressure two-weeks project. A weekly or bi-weekly milestone would probably be more appropriate in this case.

Milestones should have the SMART criteria that enable one to objectively assess whether or not the goals have been achieved: Milestones can be viewed as mini project goals. Hence most of the criteria that apply to project goals (SMART) apply here as well. "Complete as much testing as possible" is not a valid milestone whereas "complete testing to produce 90% code coverage" is an acceptable milestone. (See Chapter 5 for more details on the SMART criteria).

Milestones can be absolute or relative: A milestone can state, "complete testing by May 31, 2001" or it can be, "complete testing within two weeks after the code is frozen". The former is an absolute milestone and the latter a relative milestone. While absolute milestones are desirable, having all the milestones as absolute is likely to compromise on the quality of the product. If, for example, code freeze happens very late, compressing the testing time to meet an absolute deadline does not make sense as the product is sure to go out with defects that would prove costly in the long run.

Milestones should be communicated consistently to all the team members: Since the milestones have internal dependencies, all the milestones and their impact on other milestones should be communicated consistently to all the constituents. This will ensure that everyone understands the critical path of the project and has a consistent sense of urgency.


Identifying the Sync Points In the above two sections, we have seen that there are external dependencies and interal milestones. The WHEN part of project planning is not complete until the various dependencies and milestones are synchronised so that the management, the project manager and the team members can get the full picture.

One of the tools for synchronising the various activities is a PERT chart. The various activities are represented as nodes in a graph. Each node has several edges with incoming arrows which indicate that the activity represented by the node on the receiving side of the arrow can be started only after the activity represented by the node on originating side of the arrow is completed. When there are multiple incoming edges to a node, it is obvious that that activity can start only after all the activities represented by incoming arrows are completed. The Critical Path of the project is the path with the longest dependent duration from the start to finish. In order to speed up the project, it is essential to speed up the activities on the critical path.

Widely used project planning tools provide mechanisms to identify the sync points and the critical path. More coverage of the PERT and Critical Path can be found in the literature referred to in the References section. THE "HOW" PART OF PROJECT PLANNING: TAILORING OF ORGANISATIONAL PROCESSES FOR THE PROJECT 11.4 The HOW part refers to the process by which we are going to make the deliveries. Each project is unique in its own way and hence there would be some differences in the specific steps or processes followed for each project. But it is not so unique that it requires complete re-invention of all the processes. For example, every project would have to carry out some basic umbrella processes like configuration management, SQA, etc., albeit that the mechanism and tools for carrying out these could vary from project to project. If the organisational processes have been defined with care, they should form the basis from' which the specific processes for any project could be tailored by using a suitable mix and match approach (refer to the inset titled, A non-software example of pYjocess tailoring or customisation). During the project planning stage, the project manager takes stock of the existing repertoire of organisational processes and tailors the processes to suit his project. The tailoring or customisation consists of the following steps:


Identifying and using certain processes/ as they are/ without any

modifications: There are some organisational processes that would apply to all projects. Examples of these are processes that specify levels of approvals needed (based on expense categories and amounts), processes for standards to be followed (based on project type), processes for reviews, etc. These are usually non-negotiable processes that are mandated to be practiced, without any modifications, in all projects.

Adapting an existing process by making some minor changes to it to reflect its application in the case of a particular project: For example, an organisation- wide process may mandate the need for configuration management but a project specific process for the same purpose may specify some overrides for some of the details (like file naming conventions, back-up procedure, etc.) These processes are mandated in intent but some flexibility is available to the project groups for carrying out the actual implementation.

Dropping some of the processes that are not applicable to the project (exemption): There may be some optional processes that a project manager may find inapplicable to his specific project. For example, if a project planning process stipulates that travel must be planned for (and lays out the processes to finalise the travel plans) and a particular project does not need any travel, the project manager may choose to drop that part of the project planning process.

Adding entirely new processes found necessary for a project (that do not already exist): There are times when the existing organisational processes are not sufficient to execute a new project. Such a situation may arise when the project is on a new area, not worked on before, or when a new business model evolves. In such cases, the project manager, in conjunction with the process quality group, should arrive at new processes that document the changes he needs to carry out the project.

Recognising that each project is unique and allowing the project manager to tailor the processes to suit a new project gets a tremendous buy-in from the manager to adhere to the processes (as he is actually defining what he will follow). This flexibility should be tempered with a certain amount of caution on some key issues like:


A Non-software Example of Process Tailoring or Customisation For those of you that are connoisseurs of good food and cooking, have you seen how Indian dishes are cooked and what their attributes are? Firstly, each dish is fairly unique in its taste; each dish is also very unique in the quantity and proportion of ingredients or spices used. But one thing common to all dishes is that fundamentally, they all have the same set of ingredients or spices. The organisation-wide processes are in a sense like the spices in Indian cooking andthe various projects are like the dishes produced! Each project (dish) is fairly unique but the basic processes (spices) used are fundamentally (in most cases) the same. The adaptation of the organisational processes to specific projects is akin to mixing the spices for a dish. True, each project will have some very project specific processes. These are like the rare esoteric spices used occasion- ally. But to say that every project needs completely new processes to be invented is like asking the chef to go the supermarket for every dish that has to be made! Not giving exemption on key processes: While putting together the processes for any project, certain fundamental processes cannot be left out. For example, no project can be allowed to completely bypass configuration management. Each project may choose to use a different tool for configuration management' and hence the operational procedures may be different for each project but the spirit of configuration management embodied by the organisational processes cannot be overridden. Keeping close tabs on the processes that get exempted most often: The reason for anointing a process as an organisation-wide process is that it is used very often. But if certain processes are waived very often, then chances are that this process needs _______________________________ 2 One must also add that while it is nice to give the flexibility for each group to choose its own

configuration management tool, it makes a lot of economic and operational sense to stand- ardise the entire organisation on a single tool.

178 Managing Global Software Projects to get re-written or even scrapped. For instance, suppose the organisation has a purchasing procedure which states that, "normally all purchases over $10,000 must be approved by the CEO but if the CEO is not available, the location manager can approve the purchase." If in such a case you find that most of the purchases actually end up being approved by the location manager, then it is time to re-write the processes to say that the location manager's approval is sufficient. The moral of the story here is that if we are not going by the written rule most of the time, it is either not OK to do things the way we do (in which case we need to correct our behaviour) or it is OK to do things as we do them from a practical sense (in which case there is no use in having a theoretical process that no one follows).

Examining new processes specifically introduced for each project: When a project introduces a new process, the quality group should examine the new process in the context of the existing processes and see if any of them can be "tweaked" slightly to accommodate it. In practice, most of this new process may be covered by some of the existing processes. Identifying this similarity at the outset would save a lot of process maintenance headaches in the future. Also, being able to map it to the existing processes (even if with some tweaking) would help in bringing about some consistency across the organisation.

Ensuring that the processes follow the spirit of quality rather than insisting on strict bureaucratic conformance: Suppose the organisational process mandates that a project manager gets an approval from the customer for any changes, the project manager should have the flexibility to decide whether the approval should be through em ail or on paper. Just because all the existing projects get paper documents with the approvals, it would not be appropriate to refuse to accept email approvals.

THE "BY WHOM" PART OF THE PROJECT MANAGEMENT PLAN: ASSIGNING RESOURCES

11.5 Once the milestones and the WBS units are arrived at, the BY WHOM part of the project planning would almost fall in place. The primary gov- erning factor to determine the BY WHOM part is the availability of appropriate skill sets and experience. The criteria that are applied in the choice of who would perform what function are:

-----=-----~- 179 Project Planning and Tracking

Achieving clarity of roles and responsibilities: The first basic principle in the BY WHOM part of project planning is that there should be a very clear understanding among all concerned as to who is doing what, what are their assigned roles, their responsibilities, and where should the lines be drawn. This has to be communicated clearly to one and all so that there is a unified and focused approach towards the targets set by the WHAT part of project planning.

Using the right experience levels: While choosing the people to work on specific tasks, it is important to strike a balance between minimising the learning curve (and hence the project deliveries) and providing new learning opportunities to keep the people motivated. Therefore, choosing people with the right experience levels for participating in the project tasks is very important.

Aligning work assignments with the team members' interests and aspirations: It would be highly beneficial for the team morale if the work assigned to its team members is based on not only the competencies of the employees but also takes into account their aspirations and future interests. This will minimise the chances of straight jacketing an employee to a particular type of work. For example, if an employee is given the same kind of work day in and day out just because he has been successful in that particular area of work in the past, he may start losing interest and become less productive in the long run. While business realities of resource availability and targets usually do drive resource allocations, it is desirable to align the allocations to employee aspirations as far as it is possible.

Achieving a fair distribution of work content: For the team to stay motivated, there should be a fair balance of work across the team. The work quantity and work type should be distributed equitably across the team. This is required to increase the overall utilisation of the team without unduly skewing the work load towards a select few.

Prioritising the scarce resources to provide the maximum bang for the buck: There are bound to be a few resources that are scarce and are shared across multiple projects. For example, in a new technology area, there may be very few competent people who have understood and can articulate its significance. In such cases, the BY WHOM part would have to be judiciously employed in asking for such resources. The management team of the organisation would then have to do some aggregate planning of such scarce resources. The project team should have some contingency plans if the most optimal resource is not available as a result of demand for that resource from other higher priority projects.


Considering the availability of resources with appropriate skill sets, the BY WHOM part transforms the effort estimates made in the WHAT COST part to schedule estimates. This information is also derived by the sync points described in the WHEN part.

PUTTING IT ALL TOGETHER: THE SOFTWARE PROJECT MANAGEMENT PLAN

11.6 The project plan, also called the Software Project Management Plan or SPMP in the literature, is the repository of all the WHAT-WHAT COST- WHEN-HaW-BY WHOM issues discussed above. The IEEE standards provide one example of what a SPMP should contain. A typical template for a SPMP is given in the next page. Some of the things to watch out for in order to ensure that the plan is useful are:

Keeping the SPMP current: The plan is not something that should be construed as "Write Once Read Many Times" nor as "Write Once Read Never" kind of document! It should reflect the reality of the situation at any given point of time. Any changes or exposure to risks or similar events should cause the plan to be updated. The plan should never become a static document that is just meant to be filed away.

Ensuring that all team members and the management have a common understanding of the project plan: The project plan is intended to be a common guide for all those who need to know the relevant details of the project. For the management, it gives a larger picture of the plan and the actuals, potential risks, their impact on the business outcome and the mitigation strategies. For the project manager, it gives an overall picture of the resources being utilised for the project, future needs of resources, task allocation to individual members, risks and contingency plans. For the individual team members, it gives them specific work allocations on a daily basis.

Making sure that the SPMP goes through proper configuration control: As the SPMP is the guiding map for all the parties involved, it is important that everyone gets to see the most current version of the plan at any given point of time. This means that extra care has to be taken in ensuring proper configuration management of the plan. A very common practice is that people print the plan and pin it up in their work area. In such cases, it is important that they reprint the plan every time it changes. It is very important that people do not work on different (and obsolete) versions of the plan; with each one of them shooting for different targets.

-----=-----~- 181 Project Planning and Tracking

Avoiding duplication of unnecessary information in the SPMP: Having said that everyone should have a common understanding of the SPMP and that all the relevant information about a project be available in the SPMP, people find it is tempting to make the plan really bulky with all the information possible in that one single document. This will only increase the chances of out-of-date information filtering into the SPMP. An effective approach would be to use the SPMP as an anchor that contains pointers to its relevant information in its appropriate locations rather than duplicating this information in the SPMP document. CONTENTS OF A TYPICAL SPMP • The "What" Part

Project scope and deliverables Features Success measures of the project Work breakdown structures

• The "What Cost" Part What the product should do: Features and aspects planned in order of priority What the product does not do: Features and aspects not intended Resource constraints and stipulations Infrastructure needs

• The "How" Part Processes to be followed Processes to be customised Organisation-wide processes not followed (with reasons) Infrastructure / interface processes Basic quality processes - umbrella activities (Risk analysis, SCM, SQA, etc.) and

how they are carried out • The "By Whom" Part

People resource allocation Roles and responsibilities Staffing plans Escalation and reporting mechanisms

• The "When" Part External factors Schedules and milestones Dependencies

182 Managing Global Software Projects ACTIVITIES SPECIFIC TO PROJECT TRACKING 11.7 The objective of Project Tracking is to ensure that the project is progress- ing as per the plan and if there are any differences, to plan the appropriate mid-course corrections. This section focuses on some of the effective management techniques for project tracking in a geographically distributed team. The specific actions or events that increase the effectiveness of project tracking include:

Status reporting Communication SPMP updates

The theme common to all these is effective information dissemination to ensure

that the right people get the right information at the right time.

Status Reports A status report, that tracks the progress of the project, is given on a periodic basis (daily / weekly / fortnightly, etc.) against a pre-determined plan for that period. It is one of the means by which each level in an organisation is kept appraised of the progress of the project by the level below. The key issues for effective status reporting are:

What should be the level of detail in a status report? Who should get the reports? What should be done with the status reports? What should be the periodicity of the status reports?

What Should be the level of Detail in a Status Report? The status report is, in general, likely to be read and used by those at the higher level in the management hierarchy. Thus the information to be given in the report should have some degree of abstraction and aggregation. One of the common mistakes that the project managers make is to clutter the status report by unnecessarily going into the depth of all the technical problems and then providing ingenious solutions for such problems (even down to the lines of the code!). Such details are unlikely to add value to the report. We view periodic status reports as a means of giving early warning signals if something is going awry. In other words, it is a way of tracking planned progress versus the actual progress.


Viewing "Planned" Activities and the" Actually Done" Activities as two axes, we would get four quadrants (Fig. 11.3). Let us discuss each one of them.

The Planned and Done quadrant (Q3) indicates activities that seem to be going on track. This conclusion is based on the assumption that the plan indeed reflects progress towards the eventual goal of the project.

The Planned and NOT Done (Q2) quadrant probably indicates slippage. As James Brooks says in [BROO-7S], "Slippage occurs one day at a time." It is important to look at the tasks of this quadrant carefully and perform some root cause analysis of why the tasks were not accomplished.

Some of the questions about activities that are planned and NOT done include:

Did the time allocated for activities not done get used up by unplanned activities (those in Q4). This would probably indicate interruptions (and unplanned work).

Were the activities not taken up at all or are they partially complete? If it is the latter it probably indicates poor size / effort estimation.

Did any activities not get completed because of resource constraints? This probably indicates poor resource planning.

Did any activities not get completed because of non completion of some preevious activities on which this activity is dependent? This would indicate

inappropriate WBS units and schedules. . The NOT Planned and NOT Done quadrant (Ql) seems to be the most innocuous. In theory, this quadrant should not contain anything (or alternatively could contain infinitely many things!) as these pertain to activities not planned. But if there are activities that need to be done and they have never been planned for, it is a sign of trouble ahead. Using Stephen Covey's terms, such activities could represent "Im- portant but not Urgent" activities. So long as no activities are getting postponed, there is no harm in this quadrant being empty.

Based on the above discussion, we suggest a very simple format for status reporting that works very effectively in distributed teams. This format is given in the template below. In addition to having information about the four quadrants, the report also has, at the very beginning, a section called Red Alerts. These Red Alerts are matters that require immediate attention. These are the urgent items that have to be acted upon by the recipient of the status report within a given time frame; failing which there would be serious repercussions. It is recommended that this section be placed right at the beginning of a status report to attract immediate attention.


A SIMPLE AND EFFECTIVE STATUS REPORT FORMAT

STATUS REPORT FOR THE PERIOD < FROM DATE > TO < TO DATE >

REPORTED BY: <REPORTING PERSON>

RED ALERT

ACTIVITIES PLANNED AND ACHIEVED FOR THIS PERIOD

ACTIVITIES PLANNED FOR THIS PERIOD BUT NOT ACHEVED, WITH REASONS

ACTIVITIES NOT PLANNED FOR THIS PERIOD BUT CARRIED OUT

ACTIVITIES PLANNED FOR THE NEXT PERIOD

Who Should Get the Status Reports?

This would depend on the organisational structure and also on how critical the project is. It is important to ensure that the information presented in the status reports is not of an ambiguous nature and that it reaches the right people without any delay.


The status reports generally go to the direct manager of the person responsible for writing these reports. During the project initiation phase, one of the points taken up is the escalation procedure. If certain items during a given status reporting period require escalation, then it is appropriate that the status report (or part thereof that pertains to the escalation) be addressed to the levels concerned with the escalation. There may also be critical projects or parts thereof that are in critical phases, that require everyone in the organisation-from the senior management to the project team members - to be in sync. For example, if the project is close to the final date of delivery, it is very likely that everyone (including the senior management) would be interested in its current status. In such a case, the "passing of the report" from one level to another sequentially, with the report slowly bubbling up from the team members, through the organisation hierarchy, to the senior management should not happen. It is also important to resist the temptation to copy all the status reports (as an "fyi") at all the levels of the management "to be safe". This will have two adverse effects: first, the higher levels will be flooded with unnecessary reports they would not know what to do with; second, when there is a real escalation which needs their attention and action, that would get lost, with all the previous "fyi" status reports providing a red herring.

What Should Be Done with the Status Reports? Status reports should be put to two types of uses, the first being immediate corrective action/ status accounting. The project manager looks at the status reports, ob- serves the deviation from the plan and does any immediate fine tuning that is required. For instance, suppose he had estimated that the project would be complete by December 2000-going by the assumption that the required hardware would come in by May 2000-and it is already the second week of August. The hardware has still not arrived. In such a case he should review whether he can compensate for the loss of time in getting hardware and revise the final date of completion of the project if necessary. The second use-and perhaps that which most project managers fail to implement-is an aggregate analysis of the status reports. When there are several Status Reports collected over a period of time, one should go through them to observe patterns. Some of the analyses that should be done by looking at the past several status reports are:


Are there a fair number of activities that are consistently in the "Planned but not done" quadrant? If this quadrant consistently has a fair to large number of activities, then it most likely is a pointer to poor planning.

Are there some specific activities that consistently get into the "planned but not done" quadrant? Even if there are not a large number of activities but some specific activities that make it to this quadrant consistently, it indicates that these specific activities are not being planned properly. One root cause for this could be that these activities are "Important but not Urgent" (i.e., they get overridden by interruptions) in which case the project manager should consciously place them high on the priorities list to get them done. Another possible cause could be that these activities are simply under-estimated. In such a case, the project manager should re-evaluate these activities to arrive at a realistic estimate and re-draw the plan accordingly. A third possibility is that these activities are neither important nor urgent and hence they need not be planned at all.

Can you pin-point the "planned and not done" activities to the short- comings of any particular individual(s)? It is possible that these people do not have the required training in their specific areas of work. Or else it could simply be some cases of ineptitude tha~ may have to be weeded out.

Are there any Red Alerts that appear repeatedly and continually in the status reports over several reporting periods? This is an indication of false alarms (if the project is moving forward at a reasonable pace) or else of some serious omissions by the recipient of the status report, in which case it is perhaps time to escalate these matters one level up.

Are there any Red Alerts that crop up intermittently in the status reports of various periods? If so, this points to some quick fix patches or solutions being put together, which in the long run leads to an unstable or poor quality product. It is time to bite the bullet and go for a permanent solution.

What is the frequency of interruptions that take place every week and does it follow a trend here? If there are too many interruptions, then again it points to an Urgency syndrome. Also, if the interruptions are taking place with some periodicity, it would be worthwhile getting at its root cause. For example, if the project manager finds that immediately after the release of a new product, the maintenance overhead (or incoming bug rate) shows a steep increase, and the development team is unable to devote any time to the new releases development, then it would makes sense to beef up the maintenance staffing for the team immediately after a release.


Are there any activities that were never planned for (and therefore never got done) and one has regrets about not having planned them? These may never show up in the status reports but it would be worth, the project manager's while to reflect on. One example that falls under this category is continuous skill upgradation. The team members might have indicated that they would like to get trained on some new technology. Because of project delivery pressures, the project manager may never be able to plan for this activity but if he keeps postponing it indefinitely (and it never shows up on the planning horizon), then he stands the risk of having people with obsolete skills, even people frustrated at the lack of learning opportunities.

What are the type of activities that were always planned for and that got done? This analysis may reveal some best practices by a specific group or individual that may be well be worth duplicating by other groups or individuals.

What Should he the Periodicity of the Status Reports? The periodicity of the status reports varies with the duration of the project. In general, there are two factors that drive the frequency of status reporting: project duration and project criticality.

The first is the duration of the project. If it is a short duration project (say a few weeks), then the status reports should be produced more often. As we mentioned earlier, Status Reports are the means of doing health checks on the progress of the project and effecting any mid-course corrections. In a project of short duration, frequent health checks would result in faster responsiveness to change. On the other hand, in a long duration project-say a project spanning a few months to a year-a weekly or fortnightly status report would be appropriate.

The second dimension that affects the periodicity of the status reports is the criticality of the project. Certain projects are critical in the sense that there is a big stake involved in the outcome of these projects and the management has to have accurate and up-to-the-minute information all the time. Armed with this information, the management is geared to re-deploy resources from other projects should the need arise. Thus in these critical' projects, it is important for the progress to be reported very frequently so as to enable the management to make commitments and to garner resources accordingly. Such status reports may also require greater detail than the ordinary status reports.

Before we move on, a few more points on the frequency of status reports: Firstly, there is no pre-determined frequency of status reports for the entire duration of the


project. If a project enters a critical phase at any time, the frequency of the reports does increase in order to counter any adverse outcome. Second, there could be hier- archies of status reports. As one moves up the ladder, the level of detail decreases. It would of course be ideal if all these people, irrespective of their hierarchial levels, take the information from a single reliable source in an automated fashion. Thirdly, status reporting is just one form of communication. It does not eliminate the need for other forms of communication like group meetings, informal hall-way talks, em ails, etc.

Common Pitfalls in Status Reporting

Making status reports just because ISO / CMM asks us to do so! Status reports are not evils that a project manager has to do just because ISO / CMM stipulates them! The project manager should start off by acknowledging the value addition brought in by status reporting so that he can follow the same in the right spirit and not just view it as an unnecessary burden from the bureaucracy.

Just for the purpose of filing them away! You often see that the offices of most project managers will have nice files labelled "Status Reports - project XYZ" in which they meticulously file the reports they get every week! Or, in this era of email folders, they file away the reports in separate email folders. Regardless of the me- dium of storage, most status reports are simply stored and never retrieved or checked! Status reports are not meant to be just stored. They are valuable information that needs to be analysed and acted upon. If the project manager does not aggregate analysis and take corrective action as suggested in an earlier section, then the status reports have lost their purpose.

Reports at irregular intervals or only when things go wrong. Most project managers believe in the dictum "No news is good news"! This is a serious mistake! With- out constant communication, it is very likely that the management and the project team would go out of sync. Also, when reporting is resorted to only when things go wrong, the team should be prepared for bad news. From a morale perspective, it is very important that any achievements in the Planned and Done quadrant be highlighted for the benefit of the team as well as the management.

Too much detail: Remember that the recipient of the status reports is more interested in the final outcome or what has been achieved versus what was planned. Spare him the boring details of your heroic adventures in debugging in the status reports! Strike a balance between giving too much detail and cryptic one liners to the effect, "Things are under control-leave me alone and I will deliver!"

189 Project Planning and Tracking Not highlighting "Red Alerts": Red alerts require immediate attention of the recipients of the status reports and the higher management. A common mistake that is made is to hide away such red alerts somewhere in the middle of the status reports. In doing so, there is an imminent danger of the recipient of these reports completely missing out the red alert item.

Other Methods of Communication

One-to-ones: One of the main challenges that the project manager has to face is ensuring that any concerns the team members have are addressed in a timely and satisfactory manner. To meet this challenge, the project manager should plan to have a weekly one-to-one with each of his team members. This one-to-one meeting should not be just work related (i.e., talking about the deliverables, deadlines, etc.) but should also focus on any constraints / dissatisfaction/ problems that the team member is facing. To what extent should the non-work related discussions take place in a one-to-one situation would depend upon the culture and practices of the prevailing environment as well as the familiarity between the team member and the project manager. Group meetings: It is not sufficient that each individual knows what he has to do and whether or not his concerns are addressed. In project teams, there is a lot of inter-dependency between the works of the various team members and there are potential conflicts between their interests. A periodic meeting of the entire group to get them all on the same page is essential. The periodicity of the group meetings (like the status reports) depends on the nature, duration and criticality of the project. But a rule of thumb is that there should be a group meeting at least once a month. Periodic conferencing among the teams in various locations: One of the biggest challenges of a geographically distributed project team is that people do not get to see each other physically very often. The effectiveness of communication within the team increases when the team members have met each other, have had the opportunity to observe each other's body language, gestures, and have made eye contact. The geographically distributed teams are somewhat handicapped is this respect as they miss out on these very important non-verbal communication modes. As an alternative, periodic video conferencing between the teams in various locations serves to minimise the impact of this handicap. If video-conferencing is not available or possible, at least an audio conference call should be arranged periodically (If you can't put a face to the email id, at least put a voice to it!).

These conferences are held not just for the sake of the- teams getting to know each other. In a global scenario, there are bound to be dependencies across the teams.

190 Managing Global Software Projects The conference calls should clearly establish action items, responsibilities, and timelines for carrying out these action items. Because these meetings are possibly the only forum where the teams are (virtually) in the same room, dependencies, important issues, and action items must be discussed candidly. Another purpose served by these conferences is that they provide a platform for sharing the problems faced by the groups and for working out solutions. This will help the other groups to pro actively address such problems and reduce the need for reinventing the wheel by each team.

It is extremely important that when such calls are made, the minutes of each call be documented clearly and circulated to all the participants. The minutes should clearly specify the action items (who-when-what). Also, each conference call should start off by reviewing the action items from the previous calls and close them as necessary. Non-work related outings: The reader would have observed that the common theme of the above means of communication (one-to-one / group meetings / inter- location conferencing) is strengthening the bond between team members and making them gel. Yet another very powerful way to accomplish this bonding is to have non-work related outings like picnics or offsites. A project manager, should allocate some budget for this! An outing does not have to be to some exotic, far away place. So long as it provides sufficient time and opportunity for interaction, it would have served the purpose. By organising group games (like cricket or volleyball) and ensuring that people from various sub-groups mix well, one can increase the bonding and co-operation between the team members. When such group outings are planned, is it best to avoid activities like watching long movies as they only serve to isolate the team members and inhibit communication. Periodic SPMP Updates Another effective way of communication and project tracking is to keep the SPMP updated. Any change would be significant if it affects the schedule or the cost or features of a project / product. As these are precisely the attributes tracked and recorded in the SPMP, keeping the SPMP current and making sure that everyone has access to only its latest copy serves as a powerful and effective way of project tracking and communication.

Updating the SPMP for every change that takes place in the product/project environment or conditions may be impractical and time consuming. Not updating it at all would lead to inconsistency in its use by different team members. We need a midway strategy between the two extremes. Some effective strategies for keeping the SPMP reasonably current include: .

191 Project Planning and Tracking Updating the SPMP at a definite time interval; for example, on a weekly basis.

This can be an activity like status reporting. Of course, the periodicity of the update would depend on the project duration, criticality, etc.

Updating the SPMP whenever the deliveries are expected to slip by a given percentage or by a given number of calendar days.

Updating the SPMP whenever the key personnel in the project change. This is likely to have additional impact on schedules and cost (because of recruiting, training, etc.)

Specifying in the SPMP certain user defined conditions or events under which the SPMP should be updated and updating the SPMP when such events do occur. For example, you may specify in the SPMP that needs to be updated after the key milestones are completed.

INTERFACES TO THE PROCESS DATABASE 11.8

Table 11.1 Process Database Interface for Project Planning and Tracking

Entity Description

Experience gained from similar projects in the past

This information is used to learn from the experience of others in terms of constraints faced, resources needed, processes adapted, etc.

Changes to any of the needs from infrastructure groups

This information is input into the database. The extent of change is a measure of (in)accuracy of the initial estimates; also used by the infrastructure groups to fine-tune their aggregation and optimisation.

SPMP

This is an input into the database. The SPMP covers all the aspects of project planning. As discussed earlier, the SPMP is kept current and consistent. The SPMP of a project is in turn used by other similar projects that are initiated later.

Status Reports

This is input into the database. They are analysed to draw conclusions and take any corrective action .

Meeting minutes The minutes of all the meetings and the action items thereof are input. These can be used to track the action items to completion.


CONCLUSION Project planning and project tracking is a continuous activity that takes place throughout the project life cycle. The plan is a guide to the progress of the project and should not be perceived as something cast in stone that cannot be changed. All that we are trying to do in planning and tracking is to ensure that pro-active planning is done for anticipating and detecting changes that can result in controlled reaction when such changes do happen. The effectiveness of anticipating and planning for such changes comes by experience and by taking into consideration the learnings from the previous projects of similar type. Such learnings are captured during the Project Closure phase which is discussed in detail in the next chapter.

REFERENCES

Project Planning and Tracking are Level 2 KP As in the Software CMM and are covered in [HUMP-86], [PAUL-93-1] and [PAUL-93-2]. [IEEE-94] provides standard templates for project planning and other activities that exhaustively cover all aspects of a SPMP. [GLAB-97] also addresses the overall issues pertaining to a project plan. [FAIR-97] presents various methods of arriving at Work Breakdown Structures. [BROO-7S] is a classic that uncovers some of the common challenges in project planning and tracking. Project Management Institute (PM!) is a source of useful project management literature and can be accessed at www.pmi.org.

PROBLEMS/QUESTIONS

1. We have listed five pieces of the puzzle for project planning. Which of the five pieces would you start with? Discuss why the pieces are inter-related as claimed at the beginning of this chapter.

2. In the text, we identified different types of logical components for WBS units as functional components, life cycle components and geography based components. Give examples for each of these logical components, going by your experience. ]

3. Other than the classification given above, what means of identifying logical components have you used in your projects? How do they fit the characteristics of WBS units defined in the text?

4. In the text, we have mentioned that at the beginning of development, a certain amount of parallelism would be possible, but later, some synchronisation would be required. Give some examples of such synchronisation points in a project.

5. Consider the features of the project / product you are currently working on. Try to classify the features on the basis of "essential" /"nice to have" /"frills". Make sure

193 Project Planning and Tracking you are taking the market / customer viewpoint rather than your own development viewpoint.

6. Identify the differences between internal milestones and external dependencies. Assume there are no external dependencies for a project. Should the dates in internal milestones be relative or absolute? .

7. Identify which of the following milestones are outcome based and which are activity based. If anyone is outcome based, suggest reasonable changes to make it outcome based (a) Testing shall be completed on 29-Jan-2001

(b) One representative from the project group should attend the inter-group meeting on 13-March-2001

(c) The product should be released to the market on 30-Apr-2001 after achieving a code coverage factor of 90%

(d) Reviews should be done. (e) All reviews should be complete by 30-June-200l covering the design document

and each of the critical files identified during the design phase. 8. We have mentioned in the text, "milestones should be conveyed consistently to all

the team members". Are there instances when you would not do this? 9. In deciding the allocation of people for specific tasks (the BY WHOM part), a project

manager identified one of his team members who has been very good in testing and finding defects and has done this very well for the last two years. Should the project manager automatically assign the testing job to this person in the new project as well? Under what circumstances would he not assign testing to this person?

10. There are certain jobs that are considered cool (e.g., Java programming) and some others that no one wants to do (e.g., testing). How would you, as a project manager, distribute the load among all and get all the jobs done?

11. Place the following activities reported in a status report in the appropriate quadrant as described in the chapter. (a) Wanted to complete coding of module xyz.c and completed it (b) Attended two unexpected bugs from customers (c) The review of module abc.c had to be postponed for the third time

12.Which of the following would you consider as red alerts and under what conditions? (a) The hardware has not arrived even though it is two weeks after the scheduled delivery date (b) Even three months after the release of the product, the rate of the incoming bugs of the

product has not reduced. This has caused us to deploy all the resources just for maintenance and we are not able to attend to the development of new releases.


(c) One of the team members went on a scheduled vacation for a day. (d) Five of the team members did not come to work last Sunday.

(e) Our satellite link failed for two hours last week-end. 13. Under what circumstances would you copy a status report to multiple levels of management? 14. Under what circumstances would you copy a status report, that you send to your manager, to your staff as well? 15. Analyse the past few weeks of your current work and classify the activities in the four quadrants mentioned in the text. What patterns did you find on applying the questions given in Section 11.7. 16. Is it appropriate to call project planning and tracking as in-stream activities? What characteristics do they share with the umbrella activities? What are the differences?

Chapter - 12

Project Closure

"The wisest mind has yet something to learn. "

George Santayana

When does Project Closure happen? Why should we explicitly do a closure? - One possible closure process - Issues discussed during closure - Metrics for the closure- Interfaces to process database.

WHEN DOES PROJECT CLOSURE HAPPEN?

12.0 Closure refers to the conclusion of a project or some logical part of the project. As discussed, software product development takes place typically in versions or releases. The release of a given version can be taken as a closure of the development project for that version and also as the beginning of the maintenance phase for that version. When a version is in the maintenance phase, problems/bugs get reported and fixed. How do we define a closure in such a case? The final closure would be when the version is made obsolete. Such a final closure would not provide opportunities for capturing the learning in a timely manner. Hence there could be some intermediate closures.

WHY SHOULD WE EXPLICITLY DO A CLOSURE?

12.1 One of the fundamental requirements of software development is to achieve continuous improvement. This is needed to stay competitive. How do we achieve continuous improvement? The first step is to learn from our past experiences. For each project that is done, there are two deliverables: One is the actual product or service that the project was intended to produce for some customers; the other is the learning process / the knowledge


acquired through executing the project by the organisation. If we continue to execute projects that do not contribute to organisationallearning, then we would very soon reach a point of stagnation.

AN EFFECTIVE CLOSURE PROCESS 12.2 Who should participate in the closure process? Ideally, the entire team working on the project should participate in the closure. This should include the project teams from different locations as well as the infrastructure providers (e.g., training, travel, finance, etc.). When a team is geographically distributed, it would be ideal to have a video conference so that the teams in various locations can see each other. If that is not possible, at least a simple telephone conference call is a must. The objective of having everyone in one (virtual) room is to discuss the issues that concern all the groups. This would minimise the chances of anyone pointing a finger at groups that are not represented in the room.

The closure process starts off with some planning and culminates in a closure meeting. For a closure process to be effective:

The meeting should have a point of focus and this focus should be on learning. The discussion should be on issues and should not deviate towards accusing people / personalities

Each member should come prepared, for even if one member is not prepared, chances are that the meeting will dissipate into meaningless accusations or unproductive small talk

Each member should get an opportunity to voice his views. Generally, meetings tend to be dominated by one or two individuals who steal all the air time. This should be avoided by careful mediation.

The suggested process to ensure that learning is maximised from the closure is:

1. The project manager is the driver for the closure. He intimates the date of the meeting well in advance to all concerned, that is, any or all of the team members (and at least a part of the management team in other locations) as well as some select representatives of the infrastructure groups.

2. The project manager asks each member to come prepared on a certain item on the agenda. There are two ways to distribute the agenda across members: Vertical distribution: The process of learning is divided into several areas

and each member is asked to come prepared on a specific area. For example, the configuration controller of the project is asked to present the issues associated with SeM, the quality assurance person of the project

197 Project Closure has to present the SQA issues, etc. Thus each person works on a given topic. This is likely to give an in-depth knowledge of the issues. (The specific questions given in the next section are examples of a vertical distribution)

Horizontal distribution: Each member is asked to introspect in the entire project with no boundaries. This approach gives different perspectives on the same issue.

In practice, the distribution is a combination of the horizontal and vertical distributions, i.e., there may be some specific views sought from certain specialists and general views would be sought from everyone on certain matters.

3. The project manager provides a framework to each member which is to be used for preparing the presentation. Such a framework ensures the consistency of the presentation and accelerates the process of understanding. For example, a simple (and a very effective) framework is: List three things that you think we did very well in this project/ area and

that we need to replicate in future List three things that you think we did not do right and that we should

consciously avoid repeating in future List three factors that you think are constraints we are facing and that are

keeping us from achieving more. How do you think we should overcome these constraints?

4. By making each member come prepared to the closure meeting, the project manager has elicited a certain amount of commitment from the team. This is the first step towards a successful meeting. 4. In the meeting, the project manager drives the show, calling each member to

present his views and allows time for a healthy debate on each issue. He takes care that the issues do not become personal and ensures that resolutions and consensus are arrived at.

5. He documents the proceedings of the closure meeting and sends them to the senior management, the process quality team, and to the participants of the meeting.

6. The senior management team utilises and collates the several closure reports to measure and achieve organisation-wide continuous improvement.

7. The senior management also looks for patterns across all the closure reports to identify common organisation-wide problems and tries to resolve such problems.

8. The process team analyses the contents of all the closure reports to identify common processes and the possibility of generalising and abstracting organisation-wide processes.


ISSUES THAT GET DISCUSSED DURING CLOSURE 12.3 As the closure is a means of feeding back the knowledge acquired from a project into the organisational knowledge repository, the closure process strives to get answers for some of the following questions: What were the goals that we set out to achieve? How successful were we in achieving them? This should be the first thing to introspect on. The first deliverable of any project is ensuring customer satisfaction by meeting all his requirements. Some of the parameters in evaluating this satisfaction are whether the desired features were delivered on time, while conforming to quality standards and in compliance with the budgetary and other constraints.

How effective were the in-process metrics? Did the in-process metrics truly reflect the end goals? How easy was it to collect and analyse them? Can any improvement be made in either redefining the in-process metrics or in the modes of collection and analysis?

If there were instances of over-achievement or under-achievement, what were their root causes? It is important to do this analysis for both under-achievement and over-achievement. Was the under-achievement actually a case of unrealistic expectations or poor planning in the first place? Was the over-achievement at the expense of something else (e.g., did you deliver the product one week ahead of time but did not test it, thereby leaving a lot of bugs behind)? Was over-achievement possible because of some innovative new methods? If so, can those methods be institutionalised?

Was our estimation of size in the right ball park? If the size of the final work product (measured in LOC or Function Points or whatever size measure originally agreed upon) was found to be radically different from what was originally estimated, then it probably implies that an inappropriate size estimation method (or inappropriate parameters) was used. Alternatively, it may be a case of some special causes that were different in this project. The root cause of the size variation must be found out and the estimation procedures corrected for future use.

Was our estimation of effort correct? If the effort that is actually expended on the project is substantially disproportionate to the estimated effort, then we should examine the means by which the efforts were originally estimated. Was the size estimate itself wrong? If the size estimate was right, did the translation of size into effort not work? What were the productivity factors that were used? Why are they different in this project? One important point to note is that when such an analysis is done, some project managers confuse schedule for effort. "We completed all the

199 Project Closure milestones on time and hence we did not have an over-run" is a common argument, one will find. But the important point is that while meeting the deadlines and milestones, did the engineers consistently put in 15 hour work days? If so, it is still an indication of under-estimation. Either the organisation is going to face employee burn-out or (if the organisation is billing in Time and Materials basis) service is given away free. It is important to compare the actual effort and not just calender days.

What did we "accidentally" do right that we could legitimise? When we execute a project, there are times when we tryout new things consciously or unconsciously. Some of these experiments or things done accidentally turn out to be great successes. For example, in a particular project, you might have tried re-distributing some of the responsibilities to different people and that might have worked wondrs for retention and motivation. Closure is the time you look back on the successes and try to formalise or institutionalise them.

What did we gain from the system or environment? It is very easy for a project group to take all the credit for things that go right and blame the others for things that go wrong! But in reality, every project group gains to some extent by the existing environment or systems or procedures. By examining the specific gains from these factors, better bridges are built with the external groups.

What are the mistakes that we need not have made as they were under our control (and that would not be made the next time round)? All of us do make mistakes; some of them are under our control and some are not. It is important to identify the ones that are under our control and ensure that we do not repeat such mistakes. This can be achieved through a combination of self discipline, external monitoring procedures and enabling tools.

What were the factors in the environment that we would like to change? What would be the impact if such changes are made (both in cost and benefit terms)? The external environment or the processes that drive our work are not cast in stone. They should adapt to changing needs. As we learn from a project, there may be a need to change the organisational structure, operating procedures or infrastructure. Each of these involves costs and may have some benefits. The closure process should initiate some soul searching in respect of making the above changes.

Was our estimation of the hardware requirement correct? Sometimes people working on software projects play it safe by ordering hardware configurations which are much higher than the actual requirements; at other times, software expands to fill up all of hardware resources. During closure time, some analysis should be done to check if hardware sizing was appropriate.


Would the use of any tools have made our life easier? The objective should be to cut out unproductive time spent on mundane things. During project closure, any experience on the selection and use of appropriate tools should be explored. The functionality offered by the tools used currently (if any) should be evaluated against what else would have been nice to have. Appropriate recommendations can then be made to either enhance existing tools or procure new ones.

Was the use of communication channels appropriate? How often were the meetings held? Were they viewed as overheads by the team? While communication and processes are vitally important for project success, if the team members feel that these are being overdone (or bureaucratic) then they are sure to backfire. It is important to have a healthy balance between flexibility and structured communication and processes.

What was the employee satisfaction in carrying out this project? Did the project provide learning opportunities for the employees? Was there attrition? Was this attrition restricted to this project? Ultimately, the organisational goals and individual satisfaction should be aligned for the success to be sustainable.

How many of the originally anticipated risks became realities? Was the impact as severe as originally estimated? This information is needed so that future projects perform a more realistic risk analysis.

Was the distribution of work done fairly among the geographically distributed teams? Was there appropriate load balancing? That is, was everyone kept equally busy? Was there appropriate mix of work for all the teams (i.e, did the teams get different things to do instead of being allocated just a single type of work)? Did the distribution of work cause unnecessary communication overheads?

What changes/adaptations did we have to make to the organisational processes to make them applicable to this project? In the HOW part of project planning, we discussed the need to tailor organisation-wide processes to a project. During the closure stage, the effectiveness of such tailoring is discussed. Some of the questions that come up: How many of the changes (to the processes) Were really needed? How similar are these changes to the ones made to the processes for other projects? Which processes were found to be overheads, i.e. not adding value? Which new processes were added for this project?

Did we get and use customer feedback appropriately? What channels did the customer have to give feedback? Were these easy to use? Were these utilised by the customers? Have we acted on the customer feedback? Have we given feedback to

201 Project Closure

the customers regarding what has been done with their inputs? Any means of improving this communication channel? METRICS FOR PROJECT CLOSURE 12.4 The primary objectives of the closure are: evaluating the effectiveness of the original project goals and providing learning to improve the system. Thus the metrics of closure are pretty much on the lines of the questions we had asked in the previous section. Note that these metrics are not so much of the project closure process per se but are the metrics that should be captured during project closure.

Table 12.1 Metrics for Project Closure Metric Significance

Size variance How much did the estimated size of the work product vary from its actual size? How does this compare with the size variance of similar projects? This will indicate some special causes.

Effort variance How much did the estimated effort on the project vary from the actual effort? How does this compare with the effort variance of similar projects? This will indicate some special causes.

Schedule variance How much did the estimated schedule on the project vary from the actual schedule? How does this compare with the schedule variance of similar projects? This will indicate some special causes.

Number of changes made to processes

Process changes could be any of the following: • Change in the methods of estimation of size / effort • Change in the organisation structure • Change in the operational procedures • Change in work load distribution It is important to study the effect of such changes in future projects

Software tools enhancements

If new tooling is suggested, chances are that this would lead to higher productivity. However, it is important to avoid the "Cool Tool Syndrome" by which tools are made just to satisfy the cravings of enthusiastic coders and the processes are force fitted to the tool.

Employee satisfaction

• Can be estimated by formal and informal surveys • One measure is attrition in the project as a ratio of average attrition in the organisation. If the ratio is closer to one, then this project is an average project. If it is > I, then, it means that people are less satisfied in this project. If it is < I, then people seem to be content with the project. Examine the root cause in each case and apply the findings in future projects

202 Managing Global Software Projects INTERFACES TO THE PROCESS DATABASE 12.5 Table 12.2 Interfaces to Process Database for Project Closure Entity Description The Project Closure meeting minutes

This information is used by other projects during initiation to benefit from any lessons learnt in terms of constraints faced, resources needed, processes adapted, etc.

Metrics for project closure discussed in the previous section(e.g., the variances, process changes,employee satisfaction)

This information is input during the project closure phase and is analysed by the management team to continuously improve estimation methodologies and for better work distribution.

CONCLUSION

Continuous improvement entails, firstly, taking the best practices found in pockets and insti- tutionalising them and secondly, understanding the past mistakes and ensuring that we do not repeat them. Project closure provides a formal framework to achieve this. By combining the information captured at the project closure stage and using it along with the information captured through the duration of the project (and recorded in the process database), continuous improvement is facilitated and becomes institutionalised. Such an institutionalised and conscious attempt is likely to result in tangible benefits. PROBLEMS/QUESTIONS 1. Why should we have a formal closure of a project? 2. In sales situations, when a sale is closed-either successfully or unsuccessfully-a quick introspection is done (at least by the sales person). What do you think are the issues a sales person would consider in such an introspection? Compare such an introspection with a project closure as discussed in the text. 3. Take a project of about 18 months' duration, which comprises of three modules. Each module follows the life cycle of requirements-design-development-testing, before it is passed on to the customer. The modules are taken up one after the other (i.e.,

203 Project Closure

sequentially, rather than simultaneously). At what point of time you would have formal project closures?) In your discussion, you can define "project" in whatever way that makes sense.

4. The scenario in the same as in Problem 3 but the three modules are undertaken simultaneously. Discuss at what point of time you would have formal project closures.

5. How would a project closure in a geographically distributed team be different from a project closure when the team is from a single location?

6. Give some examples of the kind of patterns that the Senior Management can infer from project closure reports of several projects.

7. An audit in an organisation revealed that there were twenty project closures over a period of nine months. But there was no resultant change in the development process or the methodology. There was also no communication from the Senior Management or the quality group. What do you think would be the reaction of the developers/ auditors?

8. Look back on the last two projects you were involved in and answer the following questions: (a) What were the similarities between the two projects? (b) What were the differences?

(c) What were the lessons learnt from the first project and were you able to apply these to the second project? If so, how did you benefit by doing this?

(d) Was there anything that you tried to replicate in the second project that actually did not help at all (i.e., the wrong learnings or the "second systems effect")?

9. Apply the questions in Section 12.3 to the last two projects you carried out. What gleaning did you get? Would the answers to these questions, in any way, change how you would carry out these projects if you had the opportunity to start all over again?

Engineering Activities

Part IV

Chapter - 13

Engineering Activities in Project Life Cycle

"All things are created twice; there is a mental or first creation, and a physical or

second creation to all things. ". Stephen Covey

In Parts II and III of this book, we have viewed the activities during a software project either as umbrella activities or in-stream activities. The umbrella activities described in Part II and the in-stream activities described in Part III are just internal activities which act as enablers in developing the product in an effective and a predictable way. The eventual goal of a software project is to let the customer have the software product that satisfies his needs. In Part IV, we will go through the actual engineering activities that capture the customer requirements and transform them through a design into the final software product.

The engineering activities that enable the realisation of a plan into a software product start with the identification of what should constitute the software product and how that product would relate to the system as a whole, which could comprise manual systems, legacy systems, etc. This step, called requirements gathering, is covered in Chapter 14.

In order that the software development organisation and the customer get an accurate idea of the effort, schedule, and costs involved in developing the software product, estimates are worked out. As discussed in Chapter 4, estimation is done in three stages: size estimation, effort estimation and schedule estimation. All these translate into cost estimates. The process of estimation and the various factors to be considered during estimation are covered in Chapter 15.

Requirements specify what needs to be done. Design translates this what into how. In most projects-especially short cycle projects-design is intricately interwoven with development. Design and Development are covered in Chapter 16.

208 Managing Global Software Projects During the development stage, the product should also be tested to detect any defects. Even though testing may go on concurrently with development, the skill sets needed, challenges faced, and the issues to be resolved in testing are so unique that we have made testing a separate phase and have discussed this phase at length in Chapter 17. When a product is released to the customers and they start using it, they will uncover the need for changes required in the product. Such changes may arise out of changing customer needs or because of errors in identifying requirements, errors in design or development or inadequate testing. Regardless of the cause, changes to the product become unavoidable and hence the product needs to be maintained. Maintenance activities and the management issues thereof are covered in Chapter 18. The reader will notice that unlike in the case of the in-stream activities, we have not drawn a diagram that shows the relationships between the various engineering activities. The reason for this is that the relationship between these engineering activities and the feedback mechanism used between them depends largely on the life cycle model that is followed for the project. This in turn is decided by the type of project, as discussed in Chapter 3. Hence, while describing each of the engineering activities, we have confined ourselves to discussing the details of what happens in each activity rather than describing how the information flows across activities. Also, in keeping with the emphasis on the management aspects of a project, rather than on software engineering aspects, our discussion is centered on what needs to be done .. We have consciously not focused on the theory of "why" behind the "what". A minor clarification of the terminology used is also in order: We use the terms customer and software development organisation in the discussions. By customer (or customer organisation), we refer to the organisation whose need is being met by the software product being developed. This term can be applied directly to the case of developing bespoke software for a specific customer. It is important to note that the term customer is also applicable - with some adaptations - for the case of development of general purpose software used by multiple customers, even though the product is not targeted towards a specific customer. By software development organisation, we refer to the organisation that fulfils the need of the customer. The software development organisation encompasses the marketing, development, testing and support functions and is not intended to be confined to the development function alone. Another term that is used synonymously with software development organisation is vendor.

Chapter – 14

Software Requirements Gathering

"It is more important to do the right things than to do things right.”

• Stephen Covey

Inputs and start criteria for requirements gathering- Dimensions of requirements gathering-Steps that happen during requirements gathering-Outputs and quality records for requirements gathering- Skill sets needed during requirement gathering- Differences in shrink wrapped software-Common challenges during requirements phase- Metrics for requirements gathering.

INPUTS AND START CRITERIA FOR REQUIREMENTS GATHERING 14.0 Most projects start with a systems requirement study, which encompasses software as well as the systems that make up the environment (hardware, manual processes, etc.). For a more holistic understanding of 'the systems an initial scope is drawn out, which describes, at a very high level what needs to be accomplished. This initial scope acts as an input to the requirements gathering phase. At the time the high level scope is arrived at, complete details of what needs to be done mayor may not be available. With the necessary information available, the customer and the organisation bidding for the project draw up a contract which stipulates the commitments from either side. Before the contract is signed, each organisation should review the scope as per the contract review processes so as to ensure that they are not making commitments they cannot meet.

This approved high level scope leads to the identification of the software components that need to be developed. Understanding the details of the software compo-

210 Managing Global Software Projects nents is called software requirements gathering, which we refer to simply as requirements gathering in this chapter. During the requirements gathering phase, the software development organisation understands what is needed from the product to satisfy the needs of the customer, without necessarily getting into the details of how the needs are to be satisfied. DIMENSIONS OF REQUIREMENTS GATHERING 14.1 We view requirements gathering as a holistic approach to maximising customer satisfaction at the end of the project and not in the narrow context of a technical process just to capture the functionality requirements of a given system. Viewed in this broader context and as illustrated in Fig. 14.1, requirements management is made up of four dimensions:

Responsibilities Current system needs Targets Ongoing needs Responsibilities: Commitments on Either Side Requirements form the basis for the success of further activities in a project. If the requirements are not captured properly-no matter how good the subsequent steps

211 Software Requirements Gathering (of design, development, etc.) are-we would not be able to build the system that would actually satisfy the user. Commitment to getting this step right is the first dimension to be addressed. The enablers that increase the chances of achieving success in this respect are:

Identifying! single points of contact and sign-off authorities Identifying and establishing service level agreements for resolving issues Identifying change control norms Identifying any statutory compliance issues

What is it that constitutes the "right requirements"? Every person in the cus-

tomer organisation would have his own interpretation of what is right. In order to ensure that we capture the right requirements from the right people, how do we tell who are the "right" people? Ideally, we should start with a single, ultimate point of contact in the customer organisation for stating and arbitrating the requirements. This single point of contact should be nominated by the senior management of the customer organisation and should be officially notified to the rest of the organisation. Typically, this single point of contact is the Head, Information Systems or the Chief Information Officer so that a sense of legitimacy and authority is brought to the table.

What does this single point of contact do? He presents the big picture: This single point of contact knows the complete requirements of the organisation and articulates these needs. He presents the 20,000 foot level view of the system to be developed vis-a-vis the organisational needs. He also knows what the various components of the system are and how they fit together. Nominates other contacts for more details: Each of the components (or modules) has its own levels of detail and intricacies. The single point of contact nominates the module owners who can give specific details of these individual components. For example, for an invoicing system, the single point of contact would be aware that there are modules like customer management, discounting, inventory interfacing, etc., but the specific details of what kind of discounting schemes are practiced would only be known to the owner of the discounting module. Acts as a tie-breaker in the case of conflicts: When multiple components are involved, it is possible that they will have conflicting requirements. For example, the requirement of one module may dictate a minimum memory configuration of 64MB to run Throughout this chapter "identifying" mostly refers to "identifying, agreeing upon and documenting" .

212 Managing Global Software Projects whereas the maximum intended configuration could be only 32MB for pricing poses. Should the design of the component be altered (perhaps sacrificing peri ance) or should the original intentions be changed? These types of decisions invo not just technology issues but also market issues. The single point of contact acts a tie-breaker and an arbitrator in issues. His ruling is final. Prioritises the various requirements: The single point of contact eventually deci which requirements should take precedence. This prioritisation will determine the order of deployment of resources.

The single point of contact in the customer organisation has his counterpart (the Project Manager) in the organisation that is developing the software. This project manager is the conduit for resource allocation and negotiations. His commitments should be viewed as official by the software development organisation.

It may not be possible for either of the single points of contact to get into all the details of all the components. For example, if the system to be developed is an Inte- grated Human Resources System, the single point of contact should be able to state at a high level that the system should take care of personnel management, payroll and training. The owners of each of these modules could be the HR, finance, and training departments respectively. Expanding on the concept of module owners further, there should be a sign-off authority for each of the modules. The module owners should have the final say on the requirements for their modules-barring, of course, the final override which has to be provided by the single point of contact.

During the process of gathering requirements, two things are guaranteed. First, there are bound to be certain unclear or conflicting issues that need clarification from the customer. Second, even if the requirements are agreed upon initially, they are found to change later on. Service Level Agreements address the response time to queries for resolving any conflicts. Since requirements eventually translate into costs and schedules, it is important to describe the conditions under which these would remain valid. Such service level agreements (SLA) include response to queries like, "how long would the single point of contact take to resolve conflicts?".

An unavoidable reality in any software system is the change in requirements. Change is unavoidable and cannot be wished away. Rather, change has to be anticipated and managed by appropriate change-control norms. Change-control addresses procedures to request, identify, evaluate changes in requirements. Dur- ing the requirements phase, when the system definition is still evolving, changes will take place almost continually. Using the sign-off authorities and single point of

213 Software Requirements Gathering

contact, such changes can be aggregated and consolidated. But the more challenging task is to manage the scenario after the requirements are frozen and the system design and development gets under way. Making changes in the requirements, at this stage is very expensive and needs to be controlled and managed. As such changes will affect costs and schedule, it is important to identify, during the commitments dimension, what type of changes can be requested, how does one decide whether a particular change is worth making and what is the cost involved. Basi- cally, at this stage, the requirements gathering team is laying the criteria for the necessity-appropriateness-impact framework discussed in Chapter 6.

A customer organisation may have statutory processes that may have to be followed. This could be because the organisation is (for example) auditable under ISO- 9001 or because of statutory requirements of the government. Such compliance requirements are not compromisable and should be identified upfront. They form the foundation of the entire requirements management process.

Current System Requirements The next dimension of requirements management is the gathering of the actual basic needs which should be satisfied by the software product. The needs are classified into: Functionality Requirements: The functionality part of the requirements addresses issues Iike.what is expected from the system and how the system would satisfy the business needs of the customer. Some of the aspects covered under this head are: What are the modules (or sub-components) that make up the system?

What are the inputs and outputs of each module? What is the business logic in each module that transforms the inputs into

outputs? What is the persistent data that is maintained by the system? Are there any external industry standards that the product should adhere to?

What are the interfaces between the modules? What are the external interfaces that the product should present? What is the tie-up of this system to manual systems or other legacy systems?

Often times, these functionality requirements translate into prioritised feature

lists which identify the various features required in the product and the relative priorities for each of these features. These also enable the size, effort and schedule to be estimated more accurately.

214 Managing Global Software Projects Performance Requirements: Functionality provides qualitative description of what the system should do. Performance requirements stipulate the traffic that an application is expected to satisfy. Some of the parameters to be gathered in performance requirements are: Data storage requirements Maximum number of users expected on the system Peak load that can be expected on the system in terms of transactions

Throughputs that the system must satisfy Expected response time for transactions Growth rate in future for any of the above

Performance requirements are tough to quantify especially for applications based on the Internet. We will revisit this in Chapter 20. Availability needs: Availability needs are about the up-time expected of the various components. Some of the factors that up-time expectations dictate include: Amount of redundancy to be built into the system (both at hardware and

software levels) Sophistication of the underlying tools like databases Operational issues like scheduling of back-ups and the resultant demands on

speed of such operations Security: Security determines who can have access to which parts of the system (and at what times). Security requirements have to be identified early in the requirements phase because they have ramifications on the actual system design. Some of the issues addressed by security requirements are: Who are the authorised users of the system?

How are they authenticated? What access rights do each of the users have on, various business components (like modules, inputs, outputs, etc.)? ' Who is authorised to administer these securijy rights?

Environmental definition: This part of the requirements management specifies any constraints with regard to the hardware and software platforms that the system should run on. As the choice of the hardware / software platform greatly influences the design and further development, as well as the eventual performance of the systems and also (to some extent) dictates the skill sets needed, it is necessary to define these upfront.


Targets Success measures: Success measures denote the criteria under which the project can be deemed successful. There are some targets that can be negotiated and compromised on and some that have to be absolutely met because of business realities. What can and cannot be compromised should be identified at the requirements phase itself. For example, Are there any drop-dead dates on completion? For example, for a product to

be released by the christmas shopping season, these is a clear and non- compromisable drop dead date.

Is there a limit on the dollar amount that can be spent on the project? Is there a restriction on the number of people you can deploy on the project?

Knowing what the non negotiable parameters are enables a project manager to

manipulate other parameters to achieve the desired results. Acceptance criteria: When a system is developed, how can one conclude that it meets the needs of the customer? Acceptance test criteria is meant to serve this purpose and it is characterised by the following factors: It is specified early in the development cycle (during the requirements phase) It is independent of implementation as it reflects the raw requirements It is set forth by the customer, to reflect the real life use of the product It uses the data from the customer's environment and not the test data

generated by the software development organisation It covers all aspects of requirements (i.e., functionality, performance, security,

'availability, and environment) We will revisit acceptance testing in Chapter 17.

Ongoing Needs When requirements for a software product are drawn up during the requirements management phase, it is important to consider the non-software aspects of the product that the customer would need for successful deployment of the product. These include: Documentation: Every product requires documentation and the extent to which it is needed depends on the complexity of the product and what has been agreed upon. Some examples of the kind of documentation required for a product are:


User manuals Design and internals documentation Installation guides On-line help

It is important to identify the documentation requirements upfront as these would entail additional efforts and the use of specialised resources. Training: Once a product is developed, its users may need to be trained in how to use it. There could be different levels of training for different people: the users may need training on the modules they would be using (data entry forms, menus, reports etc); the system administrators on providing security, back-up, restore, etc. on the system; if the product is going to be handed over to the customer for further maintenance, the developers in the customer organisation may have to be trained on the actual programs and on how to maintain them. Thus, the extent to which training is needed adds to the work that needs to be done for the project. Ongoing Support: Once the system is deployed in the customer site, there would be a need for ongoing support. Some of the questions that need to be answered in this area include: What constitutes a requirements change and how to handle it? For how often are code fixes needed? For how long should the product be maintained? What are the things that cannot be changed?

The information gathered at this stage serves as input to planning the resoures needed for the maintenance phase (discussed in Chapter 18). STEPS TO BE FOLLOWED DURING REQUIREMENTS GATHERING 14.2 Under the various dimensions discussed in the previous section, the activities that take place during the requirements management are:

1. The customer and the development organisation identify the single points of contact on either side who are vested with the authority to make commitments and act on behalf of their respective organisations.

2. These two individuals, along with their teams as necessary, have meetings and interviews wherein they discuss the various requirements along the dimensions suggested in the previous section. These meetings and interviews

217 Software Requirements Gathering are often minuted and circulated to the participants to ensure that there is a proper understanding of the discussions. 3. The software development organisation analyses the requirements for connsistency and completeness. In case any clarifications are needed, they approach the appropriate points of contact in the customer organisation and get the issues resolved. 4. The development organisation captures the discussions in the form of a requirements specification document. 5. The people in the customer organisation review the requirements specification document to ensure consistency and completeness. In case of changes, they negotiate with the appropriate people in the software development organisation to ensure that both parties have consistent, complete and unambiguous understanding of the requirements. 6. The single point of contact and/ or the senior management on the customer side sign off the requirements specifications document. Simple as this process may sound, there may be several iterations before the for- sign-off can be effected because of the various challenges described in section 14.6. Some of the key questions to ask during the requirements phase is summarised in the checklist below. CHECKLIST OF THE QUESTIONS DURING REQUIREMENTS PHASE Commitment Is the single point of contact in the customer/product development

organisation identified? Are the individual modules and the owners of these modules identified? Are the service levels of responsibilities (e.g., response time to questions)

identified? Are the statutory compliance requirements identified? Are the change control procedures and norms identified?

Functionality Is a prioritised features list worked out? Are the inputs and outputs for each module identified? Is the business logic that transforms inputs into outputs identified? Is the persistent data that is to be stored by the system identified? Are the interfaces needed between the modules identified?


Are the external interfaces that the product should present to other systems (legacy systems/manual systems) identified?

Are there any external standards the product must adhere to? Performance Are the maximum number of concurrent users in the system identified?

Are the data volume requirements identified? Are the peak and average work loads identified? Are the throughput levels demanded by the business identified? Are the expected response times for the various transactions identified? Are the growth rates for these parameters identified?

Administrative Needs

Are the availability requirements (e.g., 24x7) identified? Are the security requirements identified (e.g., roles, access privileges, approval

limits)? Are the issues of back-up / restore (frequency, storage etc) identified?

Environment

Are the intended supported environments (hardware and software) identified? Are there any non-negotiable constraints on the environment (e.g., "it should run

under 2MB RAM")? Are these identified and consistent?

Documentation, Training and Support

Are the necessary user, administrator, and internal documents that are needed

identified? Is the training plan for the products identified? Are the ongoing support requirements identified?

Acceptance Criteria

Are the criteria for acceptance of the product by the customer identified? Are the acceptance test data identified? Have the non-negotiable parts of the constraints (e.g., drop-dead dates,

total cost, etc.) been identified?

219 Software Requirements Gathering OUTPUTS AND QUALITY RECORDS FROM THE REQUIREMENTS PHASE 14.3 The primary output from the requirements gathering process is the Re- quirements Specifications Document. This document captures all the information that is finally agreed upon by the customer and the development organisation. The content of this document covers all the points we have discussed in the previous section.

There are various formats possible for the requirements specifications document. Rather than present our own formats, we refer the reader to the ones in the literature. The checklist given above, together with the templates, would provide the reader with the basic tools necessary to document the requirements, which he can adapt to the specific needs of the situation.

The main quality records that need to be captured during the requirements gathering phase include:

Minutes of the various meetings held to discuss requirements Any correspondence carried out to clarify or resolve conflicts in the

requirements Change requests and their impact, signed off by the appropriate authority

These quality records ensure that the right requirements are captured from the

right people and that change in requirements is handled in a controlled way.

SKILL SETS REQUIRED DURING THE REQUIREMENTS PHASE 14.4 The requirements gathering phase is characterized by a very high customer visibility and interaction. There is a need for communication at a much higher level than in other phases, compounded with a high degree of fluidity. Based on all these factors, some of the essential skill sets needed for someone leading or participating in the requirements gathering phase include:

1. Ability to look at the requirements from the customer's point of view: The person involved in gathering the requirements should put himself in the shoes of the customer and look at the requirements from his viewpoint. This will enable the right perspective to be captured and will also increase the rapport with the customer.


2. Domain expertise: It would be very useful if the person gathering the requirements has some understanding of the domain of application. This will not only ensure a better understanding of the customer needs (satisfying the first point discussed above) but will also enable him to build a rapport with the customer.

3. Technology awareness: Before accepting that the requirements can be satisfied, a quick feasibility check usually helps. Thus, a certain amount of technology awareness is needed for feasibility testing.

4. Strong inter-personal skills: Requirements may have to be gathered from different types of people at different levels. The person involved in this gathering process should be able to extract the information he needs from all these people and he would therefore, require very strong inter-personal skills.

5. Strong negotiation skills: In a lot of cases, requirements start off by being closer to wish lists! Feasibility and reality checks are not fully thought out at the beginning. The software development organisation should find it viable to develop the product that meets the customer's requirements, else it may not be able to sustain the business. The person from the development organisation performing the requirements gathering must be able to convince the customer to prioritise his requirements within the constraints of time, money, and the people available. This requires very strong negotiating skills.

6. Ability to tolerate ambiguity: With the high level of fluidity and change, things are not cast in stone during the requirements phase. A person participating in the requirements gathering phase must have a high tolerance to ambiguity and be able to react very fast to changes.

7. Strong communication skills: In addition to all the above points, strong communication skill is an essential ingredient for success. This includes both written and spoken communication.

DIFFERENCES FOR A SHRINK-WRAPPED SOFTWARE

14.5 In the above discussion, we have delineated the customer from the organisation that produces the software. How does this model apply in the case of shrink-wrapped software (i.e., general purpose software)?

In the case of shrink-wrapped software, there is no single customer who can specify the requirements. The responsibility of identifying, collating and prioritising the requirements of multiple customers is assigned to the Product Man- - --

221 Software Requirements Gathering ager within the software development organisations. What are the skill sets that constitute a successful product manager? In addition to all the skill sets listed in the previous section, the product manager should also possess the following attributes:

1. He should be market savvy. He should have sufficient leads into the market to be able to assess the actual requirements of the various organisations.

2. He should be able to differentiate the customer's wants from the customer's needs.

3. He should be able to generalise from the requirements he gathers which are the most common requirements and be able to prioritise which are the non- negotiable requirements and which ones can be deferred/ avoided. He should be able to spell out the bang for the buck requirements.

4. He should be able to articulate the business needs of the product to the developers. In other words, he should be able to map the customer requirements to product features.

CHALLENGES DURING THE REQUIREMENTS MANAGEMENT PHASE 14.6 Incomplete and changing requirements: The requirements gathered at the start of a project are often incomplete. The question arises whether one should wait for all the requirements to be frozen before embarking on the design or to proceed with the design with incomplete (and evolving) requirements. In the context of software projects, especially with the speed and alacrity demanded by projects in the Internet era, it is an accepted fact that requirements will change. Thus, the challenge lies in being able to track and control change to requirements. The inability to handle change in a controlled manner often causes the undoing of a project. Conflicting requirements: In a complex system involving several users, conflicting requirements should be expected and planned for. When these conflicts are detected-either during the requirements phase or as the need for changes is felt- they have to be brought to the notice of the single point of contact in the customer organisation so that they can be resolved in manner most acceptable to the customer. Stated and implied requirements: We discussed in Chapter 7 about stated and implied requirements. During the .equirements management phase, the goal should be not to leave any of the requirements as implied. One should be more objective

222 Managing Global Software Projects and measure the success of a project against stated requirements. But it is not always possible to translate all the implied requirements into stated requirements, for example, the specification of user interface. The user may state user friendliness as a requirement from the system. But user friendliness is never quantifiable. What is friendly to one user may not necessarily be friendly to another. Even if the user interface (in terms of screen layout, report layout etc.) is signed off by the user during the requirements phase, he could come back with a request for changes when he starts using the syste-m. A delicate balance between being flexible for changes and being pragmatic about the real-life use of systems is required to handle cases like this. Technology changing the customer's perception of what constitutes a "requirement": With the continuing advances in technology, the user's perception of what should constitute an actual requirement changes quickly. Based on the fads that exist in the industry at any point of time, he may demand that such fads be supported in his system. At the same time, he may not be aware of the costs and impli- cation of incorporating these unnecessary features in the system nor of the essential features that he would be missing out on if these fads are to be supported. The challenging task for the person doing the requirements analysis is to be able to distinguish between the user's real needs and his wants; educate him on the non- applicability of new fads to the system being built and help him prioritise the real needs. The "Geek" effect of over-engineering requirements based on technology: Most people involved in gathering requirements come from a technical background. Hence there is a tendency to over-engineer the requirements, based on that which is possible. While it is important to "wow" the customer with new ideas and possibilities he may not have thought about, it is equally important not to over-engineer the requirements and suffer from "feature creep", i.e. engineers and the development team dictating what the customer's requirements are rather than letting the customer specify his actual needs. Confusing the "how" with the "what": During the requirements phase, only the "what" should be captured. Again, as the people involved in this phase usually come from a development background, they often look at the requirements from the point of view of design (and even implementation). Thus the "how" gets con- fused with the "what". This sometimes even causes the requirements to be captured incorrectly. Unwillingness to sign-off on requirements: Some customers may be unwilling to sign off requirements to allow themselves the room for further negotiations down the line. While this is not a desirable situation, it is nevertheless a reality to be dealt with.

223 Software Requirements Gathering METRICS FOR THE REQUIREMENTS PHASE 14.7 The main metrics to be captured during the requirements gathering phase would be to reflect whether we have captured and documented the right requirements. Ideally, if we have captured the requirements right and the requirements do not change at all, then things could be cast in stone for the subsequent phases. But in real life, requirements do change with time and there are communication gaps that inhibit capturing the requirements perfectly. Thus the primary metric for the success of requirements gathering is requirements stability-a measure of how stable the requirements are. As mentioned above, the stability (or lack thereof) can come either from real changes or from misunderstanding of the actual requirement. Rather than give mathematical formulae for measuring requirements stability, we present a series of questions (or a framework) that would help characterise the stability better. Table 14.1 Metrics for Requirements Phase Question

Interpretations

How many times did new requirements/changes come up after an initial agreement but before the requirements got frozen?

Frequent flip-flop after initial agreement indicates that communication needs to be honed up; either the initial agreement was not documented properly or there was no formal initial agreement

How many new requirements / changes were made after the initial freeze of the requirements specification document?

Too many changes after the requirements get frozen result in re-work and indicate unclear documentation and poor communication

How significant were the additions/ changes?

1. If the changes are primarily for screen layouts, report layouts, etc, it indicates incomplete documentation or nit-picking nature of the customer!

2. If the changes are in the processing logic, it indicates incomplete information capture or rapid changes in business

3. If complete new transactions and business processes are introduced, it very likely points to a less than thorough gathering of requirements

How often did the priorities for features change after the requirements were frozen ?

Frequent changes in priorities indicate an unclear awareness of what is needed.

(Contd.)


Question

Interpretations

How often did the fundamental "non-negotiable" requirements change after they were frozen?

If some of the requirements that initially started off as "non-negotiable" got compromised, it indicates poor estimation or unclear expectations. The former can be reduced by using better estimation techniques and setting more realistic expectations; the latter requires that there should be a greater clarity from the customer as to what is needed.

CONCLUSION

Capturing the requirements sets the scene for the software product to be designed, devel tested and deployed. In the next chapter, we will consider design and development as one and discuss the same in detail. REFERENCES Requirements Management is a Level 2 KP A in the Software CMM and is covered in [HUMP-86j [P AUL-93-1] and [P AUL-93-2]. [IEEE-94] provides standard templates for effective requirements management. [GAUS-89] provides an interesting framework (in terms of questions) to gather requirements. Quality Function Deployment (QFD) and Facilitated Application Specification Techniques (FAST) are two of the models that also provide ways to address the communication aspects involved in requirements gathering. These are discussed in [BOSS-91] and [ZAHN-90j respectively. [LEFF-99] discusses various skills, tips, techniques and tools. PROBLEMS/QUESTIONS

1. What are the pros and cons of having the CEO of the customer organisation as a single point of contact for requirements?

2. How would the availability needs contribute to project cost? How would they contribute to project schedule?

3. Under what circumstances would environmental constraints be identified at the requirements gathering phase itself?

4. Give an example of a real drop-dead date on which there can be no compromise if the project has to be successful.

5. Who should specify the acceptance criteria for a project and why? 6. Why should the requirements gathering meetings be minuted? Suggest a template to

effectively minute such meetings.


How do the activities during requirements gathering change with

(a) Projects with rapidly changing needs (b) Different life cycle models used

8. Discuss the pros and cons of having the requirements gathering done by someone with no domain expertise in the area of the system being developed.

9. Why does a "technology fad" become a "requirement", from the customer's viewpoint? Give some examples.

10. Look up the literature to identify various definitions and metrics for the stability of the requirements.

11. One of the abilities specified in CMM Requirements Management KP A is "members of the software engineering group and other software related groups are trained to perform their requirements management activities". In your experience, (and based on what is written in the text), what training would be included? Also, what are some examples of "other groups"?

Chapter – 15

Estimation

"Forecasting is difficult especially about the future." Victor Borge

Estimation - what, why and when - Three phases of estimation - Estimation methodology - Formal models for size estimation - Translating size into effect estimate - Translating effort estimates into schedule estimates - Common challenges during estimation - Metrics for estimation processes.

WHAT IS ESTIMATION?

15.0 We all do estimation for most of the activities in real life. Planning for the time it would take to drive to a destination, budgeting money for buying a house, estimating the number of guests to a wedding, are all examples of estimating. Some attributes of real life estimations are: Estimation is for a future event: You estimate the time you will require to visit a particular place on a particular day in the future; you do not estimate how long it took you yesterday, for that is already known and is history! Estimation is almost always done with incomplete information: As estimation is done for a future event, it is obvious that there is no absolute certainty in it; things could go wrong at the time the actual event takes place. For example, when you estimate travel time for visiting a particular place, there is no way of knowing about the traffic jams or accidents that could take place at that specific hour. Each estimate is based on certain assumptions: For example, when you estimate the time it would take for driving to your destination, that estimate is based on assumptions such as the time of travel, the route, traffic conditions, etc. Assump- tions are either implicit or explicit. Each estimation has to be understood in the context of the assumptions made. Hence it is better to state all implicit assumptions explicitly.

227 Estimation Estimation is done for the specific purpose of predicting the demands on certain resources: In every situation, you are ascertaining the quantum of a certain resource that is important to you. The resource could be time, money, hardware required, etc. But you should be clear about what resource you are estimating. Taking all of the above into account, we can conclude that

Estimation is a process of expectation setting which forms the basis of quantifying the resources required to accomplish certain goals, based on certain clearly stated assumptions.

WHEN AND WHY IS ESTIMATION DONE? 15.1 Take the case of a bespoke software developed by an organisation (called the vendor) specifically for a particular customer. Initially, the customer states his requirement. The user's initial requirements generally comprise a wish list of features he expects from the software product than the actual requirements per se. Certain features are more important than others. Through the process of a detailed requirement analysis, the vendor and the customer get a better understanding of these requirements. By working out an estimate they are able to arrive at (at least approximately) the cost and the time frame involved in developing the software product of their choice. This helps the customer prioritise his needs and features and fit them into his budget of cost and time frame. From the vendor perspective, estimation provides sanity checks to ensure whether it makes sense to get into this product development engagement. For a vendor to be in business, he should maintain a good track record of meeting his commitments. Estimation provides a means of making commitments-backed by objective data- that the vendor is confident of meeting. Thus, estimation in this case is seen as a pre- requisite to contractual commitment from either side to develop and deliver the software product that complies with the given requirements at a specific cost, in a specified time frame.

The situation is not very different when it comes to the development of shrink- wrapped software. Initially, the product marketing team comes up with a statement of the features required in the product. When. the development team estimates the effort and schedule needed for producing the product, the marketing team is forced to prioritise the requirements within the resource constraints. If the product marketing team feels that the effort and schedule estimates provided will not meet the market demands, the feasibility of increasing the resources is explored before a final plan is arrived at. Thus estimation can be seen as a process that takes place before the detailed requirements and the resource constraints are signed off by the development and the product marketing teams.

228 Managing Global Software Projects Estimation, like risk analysis or project tracking, is done on a continual basis. The

initial estimates are arrived at by using the minimal or incomplete data. As the project progresses, the information becomes more definitive. This leads to the estimates being revised appropriately. THE THREE PHASES OF ESTIMATION As discussed in Chapter 4, for a software project, estimation comprises three phases-size, effort, and schedule estimate. Figure 15.1 illustrates these three phases in detail.

Size estimate is a measure of the size of the final work product. It gives a measure of the ground to be covered to achieve the end result. Effort estimate is the effort in

229 Estimation

person months (or person days or years) to produce the work product. A primary driver for effort estimate is the organisational productivity data. Schedule estimate is the calendar time it would take to accomplish the effort, taking into account the resource constraints of an organisation and the extent of parallelism that can be derived.

Eventually, both the customer and the organisation are interested in the cost of the project in its dollar value. Cost estimate in dollar value is given by

Cost estimate = # of person months * $ value per person month

The size, effort and schedule estimates get translated into cost estimates. The

purpose of going through the size, effort and schedule estimates is to increase the confidence levels in the final dollar value of the cost estimate as there are three intermediate sanity check points (in the three estimates). The three level estimation also provides a framework for balancing one resource against another. For example, if time to market is critical, then more people can be deployed (when feasible) at an extra cost to get the product completed faster. Similarly (as depicted in Fig. 15.1), if the effort estimate (which directly translates into the cost estimate) is not acceptable to the customer, it forces him to re-prioritise his requirements and go into a fresh round of estimations with the organisation.

A Non-software Example of the Utility of the Three Phases of Estimation When the author started to write this book, the "project" started off with a high level statement (from the author and the publisher) of interest in writing a book on Global Software Project Management. In order to proceed further, both the author and the publisher needed more specific information; like what are the chapters, how many pages, who will be the audience, how long would it take to complete, etc. As a first step, a Chapter Outline was drawn. This served two purposes: First it gave an overview of the contents and enabled making a decision about whether this book had a marketing appeal. Second, it gave the first size estimate of the book. We knew there were approximately twenty chapters in the book, which was a better quantification than saying, "there is a book on Global Software Project Management"!

(Contd,)


As the next step, we needed to refine the initial size estimate. A few of the chapters were taken and actually written as initial sample chapters. This enabled us to get an idea of approximate pages per chapter and thus an approximate count of the total number of pages. This again was a more refined size estimate than the previous estimate of "Approximately 20 chapters". A contingency factor was applied while estimating the total size to account for the chapters having varying sizes. While writing the initial chapters, (which you may call prototyping), the author kept track of the time taken for writing the chapters. The task of writing was done in multiple sessions and for each session, information on the duration of the session and the number of pages written during that session was recorded. This "Productivity Database" gave an insight into the practicality of writing the book and how long it would take to actually complete it. A contingency factor was added to the productivity factors to account for variation in time taken to write the different chapters. Since there was only one author for this book, the effort estimate translated directly into schedule estimate. That the book project got completed in time is a reflection of the value of the estimation principles! Table 15.1 gives a comparison of the three estimates on their various attributes. Sometimes, effort and schedule estimates are used interchangeably by mistake; hence it is important to understand the significance of each and how they relate to one another,

Table 15.1 Attributes of Size, Effort and Schedule Estimates

Attribute Size estimate Effort estimate Schedule estimate

What it measures Actual ground to be covered

Effort it would take to cover this ground

Time it would take to cover the ground

Unit of measure KLOC, Function Points, etc .

Person months ; can be further refined by the person months per type of resource

)e.g., designer months , developer months, etc (.

Calendar months

Primary drivers Complexity of the product; features to be covered

Productivity data Resource constraints, parallelism possible

)Contd(.

231 Estimation

Attribute Size estimate Effort estimate Schedule estimate

Dependencies

Ideally should depend only on the customer requirements

Would depend on the customer requirement, organisational productivity and reuse opportunities.

Would depend on size and effort estimate factors and also on internal scheduling issues.

Customer use

To validate the organisation's understanding of the requirements.

To compare different vendors for cost as costs are usually tied directly to effort

To compare different vendors for delivery dates

Organisation use

To draw parallels from earlier similar projects and validate feasibility

To arrive at demands on specific types of resources

To schedule the resources and come up with a consolidated resource utilisation plan

Where most applicable and relevant

New development similar to the ones already completed



Where likely to be of less use

Maintenance functions

Maintenance functions

Single threaded functions like testing or machine intensive functions; in these cases effort estimate almost directly translates into schedule estimates

In addition to the size, effort and schedule estimation, one other contributor to the total cost of the project is hardware / software resource cost. The project manager has to ascertain the required hardware configuration (RAM, disk, processor, network capacity, etc.) as well as the supporting software products needed (OS, Database, tools, compilers, etc.). Hardware costs and software licensing costs add to the cost of the project. We do not discuss the methods of estimating these costs in this book.

ESTIMATION METHODOLOGY 15.3 We mentioned earlier that estimation is based on incomplete information. If so, how does one actually estimate? The first possibility is to use past experience. One can talk to people who have done similar projects in the past within the organisation or scan the literature to check the experiences of the people on similar projects. Such experiences can then be extrapolated for the current project.

232 Managing Global Software Projects The main chall:nge .in this approach is, how does one define similar project? No two

project are identical but they have some similarity in parts. A refinement of this model IS the following "Divide and Conquer" approach.

1. The project is decomposed into smaller and more manageable com that can have similarities to the existing components.

2. The requirements of these smaller components are studied in more de This approach is almost identical to the Work Breakdown Structure discussed in Chapter 11.

3. When a project is broken down into components, these components can fall into one of the following three categories: Components that are identical to the already developed components:

Falling into this category are components like screen handlers, error handlers, etc. Such components can simply be re-used and do not need to be re-developed.

Components that can be adapted from the already developed components with slight modifications: When a complex project is broken down into smaller, manageable components, identification of similar functions becomes possible. The existing versions of such components would require some re-work but it is much less as compared to the work involved in developing these components from scratch.

Component that are completely new and need to be built from scratch: These are the areas that would normally require a substantial chunk of effort.

4. The estimates for each of the above three categories of components are worked out separately. For the components that are in the first category (Le., that can be re-used directly), there is no impact-we already know the size; the effort involved is not much either. For the second category of components-those that can be adapted from existing ones with minor modifications -the new, adapted component can be estimated to be a certain percentage of the original component based on the amount of modifications identified. For the components that are entirely new, very rough estimates are made initially, based' either on the previous experiences or by further decomposing these components into smaller sub-components which then could have parallels to the existing components. 5. Each of these three estimates are given some contingency factors which are essential, for inspite of applying the divide and conquer approach and using the historical data, each project has some unknowns that have to be accounted

233 Estimation

for. How does one estimate the contingency factors? While there are no hard and fast rules, one could follow some general guidelines: Apply a higher contingency factor for estimates during the early stages of

evolution. As you refine the estimates in the later stages of the factors, gradually reduce the contingencies.

For projects exploring new areas, apply a higher contingency factor. For projects involving skill sets that are either difficult to find or in hot

demand, apply a higher contingency factor. This will allow for planning for hiring, training, attrition, etc.

For components that are entirely new and have to be built from scratch, apply a higher contingency factor.

6. An aggregate estimate of the project is then put together by adding the estimates of its individual components.

Note that we have used the word estimate ill a generic sense in the above discus-

sion. As the underlying principle behind this methodology is a common sense "divide and conquer" approach, this process is applicable to size, effort and schedule estimates.

Another variant of the above methodology is to replace Step 4 above with prototyping of subsets of the key components and extrapolate the total estimate based on the data gathered from the prototypes of the subsets.

FORMAL MODELS FOR SIZE ESllMTION 5.4 There are a number of formal models for size estimation found in the literature. We present below a very high level overview of two of the models-Lines of Code (LOC)l and Function Points. The References and Bibliography section at the end of the book provides more pointers to other formal models and methods.

Lines of Code In a software project, the eventual product is built by lines of code in a programming language. The lines of code is a possible measure for the size of the product. It seems a very natural choice too. Several reasons favour usage of lines of code as a size measure for a software product: ______________________________________

1 We use the term LaC synonymously with the term KLOC which stands for Kilo Lines of Code, i.e.

1000 Lines of Code.

234 Managing Global Software Projects Easily understood: Lines of code is an easy to understand measure. There is very little ambiguity (save in the cases discussed below).

Easily measurable, amenable to automation: Lines of code are easy to measure; there are a number of tools available in the market to measure the lines of code.

Because of these advantages, lines of code continues to be a widely used size measure. But it has some problems as well:

Language dependencies: The number of lines of code for a given function has a high degree of dependency on the programming language used. For the same function, COBOL will have a lot more lines of code than a more compact language like C. Thus the lines of code has to be used in the context of the language used. Further- more, when non procedural languages and CASE tools are used, lines of code has no meaning at all as very little code is actually written (code is mostly generated).

Need for some common ground rules: Lines of code can be defined in various ways: Programming languages allow program statements to span multiple lines. Thus the lines of code for a given statement can vary. Furthermore, code also includes comment lines. Thus, in order to have a consistent unit of measure, lines of code must actually not include comment lines and should have some norms about the number of lines per statement.

Applicability to the entire life cycle: Code gets produced only at the coding/ development phase of the project. Coding encompasses only a small portion of the project. Lines of code does not capture the size of the project with respect to capturing requirements, designing and such up-stream activities. Moreover, the number of lines of code does not have a direct relationship to the complexity of requirement. Thus, the LOC as a size estimate may not accurately reflect the size of the entire project but only the size of the code per se.

Penalises compactness: If size measure is used as a measure of complexity (and a measure to estimate effort and costs), it penalises optimisation and compactness. When a programmer optimises the code, the lines of code reduces and thus is made to appear less complex than a sub-optimal implementation of the same functionality. Thus the productivity data appears unnecessarily skewed. Furthermore, if the customer is billed on the lines of code, then he is made to pay an unfair price for an inefficient implementation.

The need to have a Size Measure other than the LOC stems from the need for a measure that would reflect the size of work that spans all life cycle activities and is language independent. Function Points, discussed next, provide a solution.

235 Estimation Function Points Function Points were originally proposed by Albrecht [ALBE-79] to capture the functional complexity of an application. The application features are divided into functions under the heads of inputs, outputs, interfaces, external data files and enquir- ies. Relative weights are given to each of these features to reflect their relative complexity. For example, inquiries and inputs are less complex than data files. Inter- faces and outputs fall in between. The weighted average of functions (number of functions of each type multiplied by the weight for that function type) gives an initial estimate of their size or complexity.

The function point method also identifies fourteen external influence factors like the transaction rate, distributed processing, multiple sites, etc. Based on the application, a weight between 0 and 5 is given for each of these factors. The initial estimate of size arrived at previously is adjusted with the influence factors to arrive at a final function point size for the application.

Further research in function points has produced guidelines and formulae to translate function points into lines of code, based upon the language to be used. This will further quantify the size estimate for the application.

The function point method is very popular. There is a wealth of information that is available on the Internet on the function point method and its uses. This method presents several advantages: Captures application complexity: Identification of functions and their classification (Input, Output, etc.) is a measure of the inherent application complexity. Re- gardless of which programming language or database one is using, it is obvious that queries are simpler to write than input-output oriented programs. Represents environmental complexity: Function point captures the influence of fourteen environmental factors. Thus the reality of the actual deployment environment (and the consequent impact on the development part) is captured. This is a more realistic representation of the size of the project. Independent of programming language: As the complexity of functionality is captured in terms of inputs, outputs, files, interfaces and environment, the size measure is independent of any programming language.

The function point method of estimating size also has some disadvantages:


Does not apply to all project types: Function point analysis is applicable only when new applications are developed wherein the applications have the pattern of input I output or file based activities. The applicability of this model to projects in the systems programming arena which are characterised by internal data structure ma- nipulations, is limited. Subjectivity in factors: The accuracy of the estimate is determined by the actual value of weights used for the various factors. The subjectivity in determining these factors leaves the accuracy of the estimates very much dependent on the capability of the person making the estimates. Needs specialised expertise: Identifying and counting function points and assigning weights requires more training than counting the lines of code.

TRANSLATING SIZE ESTIMATE INTO EFFORT ESTIMATE

15.5 The next step after obtaining a size estimate is to translate it into an effort estimate. Generally, the size estimate has a direct correlation to effort estimate in cases of new development. In activities like maintenance, there is very little correlation between the size and the effort estimates. A fix for a tricky (non-reproducible) bug at the end may be just a couple of lines of code but the debugging process could take several days. But in most cases, there are some common factors which are the drivers for translating the size estimate into an effort estimate.

The first factor that contributes to estimating effort for a given size is the history of productivity of the organisation while working on similar components or projects. In the previous part of the book covering in-stream activities, we discussed the Process I Project database which contains all the project planning and execution information. By querying the information from the process I project databases, the productivity information can be obtained. For example, when the information about LOC/ day productivity of a team on a particular project is available from the Process Database, and the LOC size estimate for the current project is made, effort estimation for the current project can be found by simply dividing the size estimate by the productivity factor.

If the same team that worked on similar projects earlier is re-deployed for the new project, then the above method of using the productivity data as it is would be appropriate. But a new project may have a different team composition. New people

237 Estimation who are not familiar with the problem domain or the technology area could have joined the team. Effort and time have to be accounted for training, making the new team familiar with the environment, and getting the team upto the required speed. Besides, a new team always needs some time before it can gel with the others and attain high productivity. Until that time, communication overheads and team building time has also to be accounted for. Hence, the productivity data (from records) must be modified to account for these factors before it is used. It is important to record in the process database the productivity figures used in each project, the assumptions made to arrive at the factors and the reference projects used to arrive at the original estimates.

The productivity data should also be re-evaluated if new tools have been introduced for the project. New tools require some training time initially but in the long run, they could reduce the overall effort needed as compared to the case when no tools are available. To cite an example, suppose we had records of productivity data on which we could do twenty tests per day using manual testing and then the organisation introduced an automated testing tool for a new project. The old productivity data of twenty tests per day should then not be used the way it is. One would expect that the number of tests that can be run per day would increase substantially with the introduction of the new tool. Again, it is important to record the impact of such tools in the process database so that an effective cost-benefit analysis can be done.

One common mistake made while translating the size estimate into an effort estimate (or when calculating productivity figures) is that no provision is made for the time needed for support activities. In addition to the actual design or development or testing, the team members have to attend meetings, fill up status reports, attend training programs, take vacations, travel, etc. This time for support activities has also to be accounted for as these are essential for the success of the project.

TRANSLATING EFFORT ESTIMATES INTO SCHEDULE ESTIMATES The next step is to move from the effort estimate to the schedule estimate. The schedule estimate provides the answer to "when can we deliver what?" There are some primary drivers that enable translation of an effort estimate into a schedule estimate: Hard deadline limits: Each project normally has drop-dead dates. These are deadlines that cannot be compromised. They are dictated by competitive forces

238 Managing Global Software Projects (e.g., releasing the product before a competitor releases his product), external events (e.g., need to demonstrate the product in a trade show, or to release it for Christmas) or simply by the dictates of the boss! (e.g. President Kennedy saying, "By the end of the decade, man shall be on the moon"). The translation of an effort estimate into a schedule estimate and the consequent demands made on resources (e.g., number of people) should be based on meeting the hard deadlines.

Number of people available and number of people needed: The team size and skill sets needed do vary with each phase of the project. In the early stages, there is a smaller number of designers and senior level people; the team size peaks when the project is about half way through and the major development and testing are going on in full swing with the middle and junior level people. Again, towards the end of the project, the team size decreases to just a few people who see to the ongoing maintenance. The translation of effort into a schedule estimate should also take into account the number of people needed at each phase, the number of people available, and the hiring plans for new people coming on board. One common mistake is to believe that the schedule can be accelerated by putting more people at work. Brooks [BROO-7S] discusses this misconception and its effects.

Hardware constraints: The schedule estimate must also take into account any hardware or environmental constraints that the team may have. For example, if the budget is only for ten workstations, then it does not make sense to employ a large number of people to accelerate the project, unless of course they can be given workstations. Other avenues, like working in shifts, should be explored to overcome these constraints.

Internal and external dependencies: As discussed in Chapter 11, each schedule has internal as well as external dependencies. Internal dependencies are caused by the time sequence in which the components have to be developed. This time sequencing is a consequence of the dependency that exists between the components. For example, for a data entry tool, the terminal access module (the component that performs input-output on the terminal) may be a pre-requisite for the modules that display the screens or accept the user data. External dependencies are caused by events beyond the direct control of the project manager. For example, the project cannot start without the hardware being delivered by the hardware vendor. While per- fanning schedule estirnates, such internal and external dependencies should be taken into account.

239 Estimation COMMON CHALLENGES DURING ESTIMATION 15.7 Expectation setting and the ever rising bar! As we discussed at the beginning of this chapter, estimation is a way of expectation setting. If the estimates are acceptable to the customer, then the progress of the project is measured not just against its absolute standards but also against the expectations set by the estimates. Once the actual resources taken match or beat these expectations, the next level of expectations gets set, requiring continuous improvement by raising the bar even higher. Experience level of the estimator: The effectiveness of estimation is highly dependent on the experience level of the project manager (or the person who is doing the estimates). Even with the best of models and data available, eventually the effi- cacy of an estimate is dependent on proper decomposition and identifying existing modules that are either reusable or are similar to the ones needed. This ability has a direct correlation to the experience level of the project manager. "Second System effect": Brooks [BROO-7S] describes a behaviour pattern called "Second System effect" which has applicability to estimation. This theory postu- lates that when one goes from the first project to the next, there is a tendency to stereotype the second project to. make it look like the first one, to expect the same problems in the second project as those faced in the first one and, in effect, "over apply" the learnings from the first project. While we said that experience of the project manager has a big role to play in the accuracy of estimates, one should be cautious about the setting in of the "Second System effect". Over attachment to a particular estimation model: Formal models like function points are great tools but one should realise that they have their domains of applicability and non-applicability. When a particular model works well a few times for a project manager, he has a tendency to force fit every project estimation into the model. The project manager should first question the applicability of a particular model to the project on hand and if it is not applicable, be flexible to adapt this model to the current needs or even to use a different model for estimating. Changing requirements and evolving technology: An estimate is applicable. for the requirements as understood at the point of time the estimates were mad~. It is a fact of life that requirements do change over time. Consequently, the estimates also would undergo some change. The project manager should revisit the estimates every time the requirements change and re-validate them. The changing technol-

240 Managing Global Software Projects ogy brings in an additional dimension to this re-estimation process. Changes in technology are taking place at neck-breaking speeds. The components that you had planned to write from scratch may become available off the shelf during the time you are developing the product; external standards may change; certain technologies may become completely obsolete and you may be forced to learn and use new technologies. All these factors should trigger a revisit to the estimates made earlier.

Tracking and refining estimates rather than being fixated: During a project execution, unexpected events may take place and these may cause estimates to slip. If we can't avoid the slip in estimates, the next best thing is to be aware of the slip and initiate corrective action as soon as possible. The project manager should not treat estimates as a "one time documentation". Just as in risk monitoring and project tracking, the project manager should always have his antennae up for any slippages and re-validate the initial estimates.

Fear of estimation data being used for performance appraisal: This is similar to the concerns expressed in the use of metrics in Chapter 5. Inputs to estimation-like productivity figures, experience levels, etc. should be used only for estimation purposes. This data should not be used to compare individual productivity or to determine an individual's performance levels. It should not act as inputs to the appraisal and reward system of employees. There should be a clear commitment from the management and demonstration of the fact that estimation and metrics do not figure in the appraisal/reward systems.

"I don't have the time to estimate!" syndrome: At times, we hear project managers making this statement. If the project manager is not able to use some means of estimation, then how can his delivery commitments be anything more than mere hope or speculation?! The purpose of making and docuinenting estimation is to be able to achieve a confidence level in a justifiable, objective and quantitative manner. Saying "I don't have time to estimate" is akin to not reading a map and driving to an unknown destination with commitment to being there at a fixed time!

"Here is a deadline, that is all I care!" syndrome: Market forces drive deadlines in most projects. There are certain drop-dead dates for projects that are not negotiable and that are dictated by external forces. In such cases, is there any point in estimating anything at all? Our contention is that estimation adds even more value in such cases. When there are drop-dead dates, the project manager has to be absolutely sure of the commitments he makes. Furthermore, if the date is sanct and cannot be modified, by justifiably estimating the effort involved in meeting the date, the

241 Estimation Project Manager will be in a better negotiating position to ask for more resources- people resources, machine resources, budgetary allocations, etc. METRICS FOR THE ESTIMATION PROCESSES 15.8 For any type of estimate, the metric to determine its effectiveness is the variance. At the end of the project (or at logical milestones within the project duration), the actual values of the resources that were estimated are captured. The actuals are compared against the estimates to find out the accuracy of estimates. Variance is defined as:

Variance = (Planned - Actual)/Planned * 100 For example, Effort variance = (Planned effort - Actual effort)/Planned effort * 100

Size variance = (Planned size - Actual size)/Planned size * 100

Schedule variance = (Planned duration - Actual duration) / Planned duration * 100

Another useful metric for the effectiveness of estimates is the number of times

these estimates have been used on future projects and their results. If an estimate is found to be useful in future project components, then it indicates some amount of repeatability and similarity across these components.

REFERENCES

[PAUL-93-1], [PAUL-93-2] and [HUMP-86] discuss the size-effort-schedule estimate continuum. [BOEH-81] describes in detail some of the common estimation methodologies. Albrecht proposed the original Function Point model. Some of the early treatises on this are [ALBE-79] and[ALBE- 83]. Significant work has been done in this area and can be found in UONE-86], [JONE-91] and [IFPU-94]. [BROO-7S] discusses some common pitfalls in estimation (including the second system effect). There are a number of estimation methods that we have not discussed in this text. One of the most popular models is the COCOMO Model discussed in [BOEH-81]. This had a revision called COCOMO II, details of which can be found in the website http://sunset.usc.edu/ research!cocomosuite/index.html Wideband Delphi is another popular estimation method that attempts to formalise the experience levels of the-estimators.


PROBLEMS/QUESTIONS 1. An existing legacy system in Cobol is to be converted to use a relational database

management system and the associated 4GL tools. How would you perform size estimation for this?

2. Your project is in the maintenance mode, fixing bugs in products. What size estimates would you apply for this?

3. Your group is developing test scripts for a systems software product. What size estimates would you use for this project?

4. Does the choice of size estimation model depend on the life cycle model chosen? 5. In the text, we have mentioned that function points are not applicable to all types of

projects. List some project types to which function points are not applicable. 6. Look up the literature for other methods of size estimates, for example feature points,

COCOMO, COCOMO II. 7. We have specified organisational productivity data as the only other input to effort

estimation (other than the output from size estimate): What data, other than the organisational productivity data would you need? When would the use of organisational productivity data be inappropriate?

8. How would you perform an effort estimate for a project that is completely different from any of the projects done so far in an organisation?

9. Would the size estimate for a product differ based on whether the team is geographically distributed or not? What about effort and shedule as estimates? 10.What is the relationship of schedule estimation to the project portfolio discussed in

Chapter 2? 11. Take the last two projects you managed: How did you carry out the three types of estimation?

Chapter - 16 Design and Development Phases "First I 'see' the ball where I want to finish, nice and white and sitting up high on the bright green grass ... Then I 'see' the ball going there &its path, trajectory and hape, even its behaviour on landing ... the next scene shows me making the kind of swing that will turn the previous images into reality." Jack Nicklaus in "Golf My Way" Some differences in our chosen approach-Evolving an architecture/blueprint- Design for re-usability - Technology choices/constraints - Design to standards - Design for portability-User interface issues-Design for testability-Design for diagnosability - Design for maintainability - Design for installability - Inter-operability design-Challenge of design and development-Skill sets for design and development- Metrics for design and development phases

SOME DIFFERENCES IN OUR CHOSEN APPROACH 16.0 Design constitutes the conceptualisation of how the user's requirements will finally be realised and it is at this stage that the first visualisation of the product takes place. Development is the actual realisation (by use of software development tools) of the design. In a traditional software engineering life cycle paradigm, design and development are two distinct phases. From the project management perspective, we have chosen to combine the two into a single chapter. There are a few reasons for this. Design and development phases (if one were to take them separately) end up with a significant amount of overlap- ping and back-and-forth communication. Even though the intent is that design should be frozen before development can begin, in practice, one finds the design- develop-change design-redevelop iteration to be very common in software. Requirements gathering is usually done by a different team and hence formal sepa-

244 Managing Global Software Projects ration between requirements and design becomes somewhat natural. In contrast, design and development responsibilities are usually shared by the same team and hence the lines of communication are not always as formal. Furthermore, most people who start as pure developers see design as a career path and hence they have similar skill sets, attitude, etc. We have therefore from a project management perspective, decided to combine design and development into a single chapter. Unless we are referring to some of the specific activities that are indeed unique to either phase, we would be using the terms designer / developer (or design / develop) synonymously in the discussions in this chapter.

The second difference that we have chosen in our approach is on the categorisation of design issues into specific heads from a project management perspective. Design and development are probably the most "technical" activities in a software product life cycle. There are decisions to be made as to which design methodology to use, what algorithms to choose, what data structures to deploy and the implementation trade-offs of the various options. Detailed coverage of these technical issues can be found in most software engineering text books. Instead of focusing on the technical details of these issues, our focus has consciously been directed at addressing what high level issues should design and development address to make project management of the overall life cycle more effective and to reduce the burden on the subsequent phases of a product life cycle. We consider some of the specific and important attributes of what a designer / developer should look for from the above project management perspective.

SALIENT FEATURES OF DESIGN

16.1 From a project management perspective, the salient attributes of design one needs to address are:

1. Evolving an architecture/blueprint 2. Design for re-usability 3. Technology choices/ constraints 4. Design to standards 5. Design for portability 6. User interface issues 7. Design for testability 8. Design for diagnosability 9. Design for maintainability

10. Design for installability 11. Inter-operability design

In the subsequent sections, we will go into the details of each of the above issues. EVOLVING AN ARCHITECTURE/BLUEPRINT 345

245 Design and Development Phases To simplify the process of the realisation of requirements, the architecture of a system identifies the various units of the system. These units can be viewed as building blocks for constructing the system. How are these building blocks different from the modules or components identified during the requirements gathering phase? The latter represents the basic units of requirements with respect to what needs to be done from a user's perspective. The architectural design step takes the view of the implementers and asks, "what parts do I need in order to realise the requirements in the most optimal way"?

The architecture also identifies how these basic building blocks communicate (interface) with one another and what the inputs and outputs of each are. This part of architecture can be viewed as the way in which the various parts fit together to form the whole.

If one were to use an object oriented paradigm, then the building blocks described here can be viewed as the basic objects that make up the system, complete with their own data and methods, realising a particular function to be accomplished. These objects represent the modules at the design level.

Let us illustrate the importance of an architecture/blueprint with a non- software example. We will take the example of building our dream house. How do we go about it? We start with the basic requirements-our location choice, area desired, whether we need a garden or not and of course, most importantly, the budget!

With these requirements in place, we first identify the area of the real estate needed in the given location. If the budget affordable does not match the availability, then we either adjust the budget or change the location. This forms the starting point for the design.

The first step in the design is identifying a plan or an architecture to build the house. This puts in place some of the requirements-where the garden would be, where the various rooms would be, ete. In addition, this plan would also identify some of the details that will go into realising these requirements-for example, what kind of beams and structures are required to support the building, what kind of internal plumbing is needed, how and where the electrical wiring should


be, and what should be the ratings on the wires, etc. Would these infrastructure or implementation related details be spelt out in the requirements? Probably not. It is the job of the architectural designer to specify this. In fact, there would be more than one architectural designer-a specialist in electricity, a specialist in plumbing, a specialist in structural design, etc. (just as in building a software system, the architecture may span operating systems, databases, user interfaces, etc. each requiring its own architect). An important expectation from the architectural design is that all the pieces - structures, plumbing, electricity, etc. - all work together and meet the user's initial requirements.

It is only when the architectural plan gets approved by the customer (and of course all the government authorities) that the actual construction can take place. This construction is akin to the actual development and the subsequent phases.

The only difference between constructing a building and constructing a software product is that after the architectural plan is finalised the construction usually follows the design strictly and there are very few occasions where the design is changed radically. In contrast, in the case of software products, it is indeed very common to find that the design changes after the development starts! What does an Architecture/Blueprint Achieve from the Project Management Perspective?

The main purpose of putting together an architecture is that it acts as a road map for the actual implementation itself. There should be sufficient information (with sufficient clarity) for a developer to be able to actually carry out the implementation. In general, there should not be a need for the developer to go back to the requirements document to see what he needs to do. All that information should have been ab- stracted in the architecture itself. Viewed from this angle, architecture acts as a bridge between requirements and implementation. A second advantage that an architecture design brings to project management is that it enables early identification of dependencies. For example, when the building blocks are identified, some of them would have to be available early in the project for the project to proceed. This early identification of dependencies helps the project team in arriving at an initial sequence of activities. As the project advances through design, these initial dependencies get translated into work breakdown structures, discussed in Chapter 11. Thus the architecture serves as the basis to performing preliminary scheduling estimation and costing.

247 Design and Development Phases

DESIGN FOR REUSABILITY 16.3 In the context of the rapidly shrinking product life cycle times, it is important to be able to re-use any of the existing software assets to any extent possible. To make a software component re-usable does not happen by accident. It happens by design. While designing any software component or module, the designer should consciously keep re-use in mind. This means asking the following questions:

1. Can I achieve the' functionality that I am trying to achieve by using an off-the- shelf component that serves exactly the same purpose?

2. Can I achieve this functionality by adapting an existing off-the-shelf component that achieves something similar (though not exactly identical)?

3. If this functionality that I want to achieve is not possible with any of the existing components, can I foresee any future re-use for this? If so, what generalisations are needed?

The building blocks identified during the architecture serve as a good starting point to attempt re-use. A good architecture should make the building blocks as re- usable as possible. One challenge in developing re-usable components is the possible trade-off one has to make between performance and re-use. To make a building block re-usable across multiple instances, some generalisations would have to be made. Such generalisations, when translated to implementation, would have some associated run-time costs. Only when the performance is not unduly compromised for the sake of re-use, does re-use become viable.

How does a designer identify the re-use opportunities? The key to this lies in the existence of a systematic and consistent documentation of design and the presence of a repository that stores every detail of the functionality, input and outputs of the various building blocks as well as an intelligent search mechanism to query the repository to identify possible candidates that can be re-used in a given context. Some of the CASE tools that exist in the market provide such functionality.

TECHNOLOGY CHOICES / CONSTRAINTS

16.4 In the design phase, we are moving into the "how" of realising the user's needs as identified during the requirements gathering phase. Thus, the design and the development phases are intricately tied to the choice of the target hardware and software platform on which the product is sup-


posed to run, as well as the technology environment under which-the product is to be developed. During the design phase, any technology, hardware, and software issues should be identified and documented. Some of the technology assumptions (like the environment, minimum and maximum configuration, etc.) are already stated during the requirements gathering phase. During the design phase, we should drill into the details of these requirements. Some of the detailed choices that need to be made during the design stage are:

Choice of the enabling system software, versions, etc. (e.g., compilers, Integrated Development Environment (IDE), profilers, etc.)

Choice of infrastructure software (databases, application servers, etc.) Choice of utility tools (back-up, diagnostics, etc.) Make vs buy decisions for some of the components: For example, for

generating reports, there may be report generation software available off the shelf but may not be affordable from a cost perspective or an overkill from a functionality perspective. The decision of whether to buy this off the shelf product or to write the reports from scratch would be important for design and development as it has a bearing on the effort, cost, and schedule as well as the actual work that needs to be done.

DESIGN TO STANDARDS 16.5 A significant trend in the computing industry over the past few years has been the movement towards open standards. In the earlier days, most of computing was based on proprietary platforms and technology. This caused too much dependency on a particular vendor's software or hardware, thus locking the customer in a technology which did not allow him to harness the advances in technology available from other vendors. This resulted in a transition to standards based, open computing that characterises today's environment. Standards are usually not determined by one vendor but by consortiums that have customer participation.

Standards come in two forms--external standards and internal standards. Exter- nal standards characterise external product behaviour. It could be compliance to a published language syntax and semantics (e.g., SQL), compatibility to a set of call level interfaces (e.g., JDBC), adherence to a common protocol (e.g., W AP) or reflect- ing a standard user interface (e.g., Motif). In all the cases, some of the common attributes of external standards are:


They are not proprietary They are published by an authorised consortium Compliance or adherence is objectively determined by successful passing of

certain pre-defined tests

Decision to adhere to external standards is often made at the requirements stage. Sometimes, this decision can be deferred to the design stage. As external functionality is at stake here, the decision as to whether to comply to external standards (and if so, which ones) cannot be postponed beyond the design stage. This decision has also got to be made pretty early during the design phase as it has bearings on the choice of technology, skill sets, etc.

Compliance to standards brings in a lot of benefits. From the customer's perspective, he can objectively have an apples-to-apples comparison between the two products that comply with the same standards. From the development organisation's perspective, it is a lot easier to find people skilled in standard areas than in non- standard areas. This availability of skill sets is one of the biggest benefits that standards have brought to the table from a management perspective.

One of the challenges encountered during the design stage is that if a product were to comply with the external standards of product behaviour, what USP (Unique Selling Proposition) can the product bring to the table? External standards usually specify the behaviour and not the implementation. Even while complying with the external standards of behaviour, a product should be able to optirnise the implementation, add new features that are not covered in the standards that enhance the usability of the product without infringing or compromising on the external standards-based behaviour.

To summarise, during the design phase, the designer should decide as to which external standards should be complied with and shape the design to provide for better implementation. External standards-just like documented processes - do not preclude creativity and innovation, they only increase the predictability in the external behaviour of a product.

The other type of standards that have to be decided upon during the design phase are internal standards. Internal standards determine what mechanisms are to be followed internally to deliver the product. We have already seen one type of internal standards-the documented processes-in Chapter 4. Documented processes in an organisation specify what logistics are to be followed during development, how do we hire and train people, how do we design, how do we identify, and resolve

250 Managing Global Software Projects problems, etc. There are other types of internal standards that need to be nailed down during the design phase itself: These include coding standards, documentation standards, testing standards, etc. The ways in which the internal standards differ from external standards are:

They are usually proprietary in nature They pertain to methods of realisation of the product rather than the product

per se Customers would normally not get to know the internal standards followed

by the development organisation.

The decision on the use of specific internal standards is not a requirements gathering stage decision as the customer is agnostic about the internal standards. It is necessary to finalise these standards before the actual development work starts. Hence, decision on internal standards to be followed is clearly a design time decision. From the point of view of the development organisation, internal standards ensure consistency and serve as the first level of insurance against employee turnover. When consistent internal standards are followed, it is easier to get employees upto the required speed faster, provide more job rotation and skill acquisition opportunities which are likely to result in greater employee satisfaction and employee retention.

DESIGN FOR PORTABILITY

16.6 During the requirements gathering phase, the specific hardware and software platforms that a product is supposed to run on are usually specified. If a software product is to run on multiple platforms, then portability should be kept as a design criteria and the product must be designed accordingly. Some of the principles that can be followed for designing for portability are:

Separating out generic functionality and platform specific functionality: For any product that runs on multiple platforms, there would be some generic functionality that is inherently a function of the product and is independent of the platform, and there would be platform specific functionality. The generic functionality relates to the core business logic and algorithms that dictate the actual function the product was supposed to achieve. Suppose you were to develop a payroll package. The business logic that governs payments, withholdings (deductions), tax rates, etc. are completely independent of the platform on which the product is going to run. If you plan

251 Design and Development Phases to deploy this payroll package against different databases, then the part of the product that interfaces with the different databases becomes the platform specific functionality. For example, different databases may have different schemas or variations in the SQL syntax. The platform specific functionality glues the generic functionality to the specific idiosyncrasies of the platform. The more the generic functionality, the clearer the demarcation between the generic functionality and the platform-specific functionality, the more portable the product becomes, and the easier it is to manage the timeliness and effectiveness of the product on all the platforms. Laying down standard means of communication between generic and platform specific functionality: The expected behaviour of specific platform implementa- tions should be documented by unambiguous programmatic interfaces. The input and output parameters, the types of completion criteria and error conditions should be specified externally at the generic level. The platform specific code should merely be an implementation to satisfy this external interface. It is in the implementation that platform specific optimisations can be exploited to get better performance but such optimisations should not be at the cost of violating the documented interfaces and input/ outputs. Using portable development environments: Today's software development environments come with some in-built advantages of platform independence. In the early 80s, the C language provided a means of developing portable code while not losing the closeness to the lower layers of the machine (needed to gain performance). Today, the development environment is even more conducive to producing portable code-thanks to the advent of a versatile, portable network-centric language like Java, open interchange standards like XML, and the availability of Inte- grated Development Environments (IDEs) that facilitate the process of design, development and debugging under one single umbrella. USER INTERFACE ISSUES

16.7 User friendliness is probably one of the most misunderstood and ill-defined phrases in software! With the plethora of user interface standards for various platforms, each one is claimed to be more natural and user friendly than the others. The advent of web sites and the ease with which colour, images and such graphical widgets can be incorporated into web pages (thanks to the advent of WYSIWIG creation tools), the question of what is a good user interface becomes even more arguable.


There is significant information in the literature about user interface design and what constitutes good user interface design but this is an area where a lot of subjectivity still remains. All that we would like to do in this section is just to give some general tips and suggest some common sense approaches.

Different types of users like different types of user interfaces: Different types of users have different interpretations for user friendliness. A programmer or a developer feels at home with complicated commands with options, flags, etc. Such com- mand line interfaces will be completely alien to an end user who would prefer navigation by menus, screens, etc. People who use laptops may prefer to use keyboard shortcuts. Thus a product designer should consider supporting different types of user interfaces and should also try to identify the different classes of programs which are likely to have different types of users. For example, a backup program or a program designed for use by a system administrator can be designed with a different type of user interface from a set of programs designed for use by the end users.

Consistency of platform look-and-feel: Each platform has a set of user interface standards. This was pioneered by Macintosh in the early days of Graphical User Interfaces (GUIS).l This has been followed later on by GUI standards for Motif, Win- dows, etc. When such platform standards are institutionalised, agreed upon, and adhered to by the existing software for that platform, any new software is also expected to adhere to the same standards. This should be finalised during the design phase so that the developers can acquire skills in these standards.

Context sensitive online help: Ideally a user should not get lost while using a system. If he does, the system should be able to provide him a meaningful context sensitive help to guide him to correct himself, rather than give a generic help message (or worse still, completely irrelevant and confusing message!). Designing context sensitive help requires documentation skill sets that are not the forte of developers. Hence, this has to be planned for and designed upfront.

Context sensitive options display: As an extension to the idea of context sensitive help, at any point of time, in a menu-driven system, only those options that are relevant and applicable at that time should be highlighted and enabled. For example, when all the files of a word processing application are closed, the option to close an open file should not be enabled.

Personalisation: A user would like to see what he wants, when he wants it. To present him with general purpose screens giving a lot of options that he does not

________________________________________________

1 In fact even in non GUI days of IBM block mode terminals, there were user interface standards like the conventional meaning assigned to program function (PF) keys; for example PF3 was to exit a screen. .

253 Design and Development Phases want, ends up in confusing the user. The user interface should be customisable with mass personalisation as a goal, especially in the context of the Internet. DESIGN FOR TESTABILITY 16.8 We will be discussing testing (as the next phase of the software life cycle) in the next chapter. Design and development should make it easier for testing to be carried out in a meaningful way. How does one draw-up such a design for testability?

Identification of test data to ensure that the design reflects the requirements precisely and that development reflects the design: During that requirements gathering phase, a set of acceptance tests are decided and agreed upon by the customer and the vendor. The customer views the system as a black box that should produce the desired outputs with the data specified in the acceptance test data. In addition,

it is also important to ensure that design faithfully reflects the requirements and that the next phase (development) faithfully reflects design. For this, the design must be testable. Taking the view that design is an architectural model that encap- sulates the requirements, one should be able to map the requirements to representa- tions in the architecture that can be tested. Similarly, the architectural model captured in the design should be testable with the implementation carried out in development.

Modularisation with dear specification of inputs and outputs: Once the architecture of the product is evolved and individual modules identified, it is essential to ensure that each module achieves its stated objectives. Hence during the design phase, the specific inputs and outputs of each module should be stated explicitly. This establishes the work flow across the entire system, thus making it possible to test the different scenarios.

Specification of limiting conditions and the action on limiting conditions: During design and development, a set of boundary or limit conditions would arise. Exam- ples of such limit conditions are, how many concurrent users should be allowed to log on? or how much cache should be allocated to store the most recently used information? When such limiting conditions are present, the action to take when the limits are reached or exceeded should be clearly documented during the design phase.

254 Managing Global Software Projects Error conditions and how they are handled: The design should handle error conditions appropriately and give meaningful error messages that enable the user to identify and correct the root cause of the error. The usability of a system depends not just on how it handles the correct conditions but also on how it handles error conditions. DESIGN FOR DIAGNOSABILITY 16.9 Any software product that is used by the customers is likely to have some bugs or anamolies that need to be fixed. When problems are encountered, the symptoms are usually what the user sees while the root cause is what needs to be fixed. In other words, a user encounters an error at an execution point. The execution point can be in a number of end user situations like while entering data into a screen or running a batch program or while running a report, etc. All that the user can make out is that a failure or an abnormal behaviour was displayed when he was executing his user function at a particular execution point. The real root cause of the observed failure actually would exist in some source point which is the start of the error condition that causes a domino effect and manifests itself as an observed abnormal behaviour at the execution point. The real challenge for the developers is to be able to quickly trace back to the source point (where the root cause of the problem started) from the execution point (where the error manifested itself). We call this ability to do the execution point-to-source mapping as designing for diagnosability. Given that any product or a version spends considerable time in the maintenance mode (where defects have to be diag- nosed and fixed), designing for effective diagnosability will make the project more cost effective. What are the design techniques that one can follow to enhance diagnosability?

Providing enough "foot prints": When a problem manifests itself, there must be enough foot prints to find out what actually caused the problem. The foot print- also called the context-should consist, at the minimum, the following:

Which modules got called in what sequence What were the parameters passed from one module to the next What were the return values from each called module to the caller module

The foot prints or the context should be easily locatable in some standard location.2 Recording and retrieval of foot prints must follow some standards that are

_________________________________

2 Most operating systems refer to this as a stack trace.

255 Design and Development Phases consistent in the hardware and software environment that the product is running on. This is especially important when a number of components or products inter- operate and an error at a source point of a component or product gets propagated and manifests itself as symptom at an execution point in another component or product.

Making the context self contained: The entire context should be self contained in the sense that no extraneous information should be needed to derive the context. One very common way that this simple condition is violated is the use of global variables in programming languages. Some of the information on the context of the sequence of modules being called and the results thereof gets stored in global variables or in multiple inconsistent (and undocumented) data structures. This results in undesirable and unpredictable side effects that make the tracing from the execution point to the source point more difficult.

Having self identifying data structures: One of the common design and development problems is not taking care of boundary conditions. For example, not checking the limits of an array and letting it overflow into the other memory locations or an infinite loop wiping out the contents of memory locations that contain data structures that point to other data structures. When such pointers get over-written because of a program malfunction, tracing from the execution point to source point becomes extremely difficult. One of the common ways to detect such over written data structures is the use of eye catchers. Each data structure has a few bytes at the beginning that contains a literal string that describe what this structure represents. When looking at the location which is supposed to contain a given data structure, it is first ensured that the eye catcher is intact. If it is, it means that the data structure is probably intact. If not, it probably means that some module has overstepped its bounds and the data structure is corrupted. A simple check like this would go a long way in simplifying diagnosability.

Providing "validatable redundancy" in data structures: Data structures represent the state of a program at any given instant. Even though redundancy in data is traditionally said to lead to inconsistency (because of the need to maintain multiple copies), when used judiciously, redundancy in data structures may actually help in recovery from errors. The practice of audit trail illustrates this concept: Whenever a transaction gets executed, an audit trail that logs the before and after images of a particular record gets created. In case of any data corruption, the audit trail records can be examined and compared against the actual transactions to locate the exact point where the corruption took place.

256 Managing Global Software Projects DESIGN FOR MAINTAINABILITY 16.10 Diagnosability, as we discussed, refers to tracing the root cause from the symptoms. Maintainability encompasses diagnosability and covers much more. Having traced the root cause, how do we fix the problem? 'What are some of the steps that can be taken pro-actively to minimise the time for fix? What are some of the management controls one can exercise to minimise the need for maintenance and when such need does arise, minimise the time needed for maintenance. Presented below are some of the design principles (which we call Design for Maintainability) that address these questions.

Module level accountability: Earlier in this chapter, we discussed the concept of building blocks at the design level by which the design is conceived in units of well defined building blocks or design level modules. A given module may be called by any number of other modules. But when a change is required in a given module to satisfy the needs of the module, such a change should be addressed to and made only by the owner of the called module. In other words, there should be a clear single point of accountability for a module. While this would require a little more communication and co-ordination among the design and development staff, this scheme of module level accountability will result in a product that is more easily maintainable.

No spaghetti code or spaghetti design! The separation between the modules should be clean with well defined interfaces. The only communication between the modules should be through the pre-defined interfaces of input and output parameters. By ensuring this separation during the design phase, the maintainability of the product will be enhanced significantly. One of the easy ways in which this simple dictum is violated is the introduction of spaghetti design. In a spaghetti design, a module is not self contained but has dependencies on other modules that are not necessarily through clean, published interfaces. Because of such a design, the dependency among modules increases. This causes a tighter coupling between the modules. Thus a change in one module gets accompanied by changes in other modules to keep this functioning intact. Such a tightly coupled design causes a double whammy from a maintenance view point: First of all, such a coupling can be eliminated by a simpler modular design. Secondly, in such tightly coupled designs, the amount of physical change that needs to be done (in terms of number of modules to change) for a given logical (or functional) change is much higher than in the case of a modular, loosely coupled design.

257 Design and Development Phases Take the case of a module (written in C) that is supposed to be a general purpose utility to manipulate a stack. To be usable, the stack routine should be able to: Handle stacks of any size Handle stacks of various data types Perform common stack operations like create, push, pop, destroy Detect and handle error conditions like underflow and overflow

A clean way of accomplishing this stack utility is to provide a stack object that is characterised by common attributes (like maximum allowed stack length, length of one element, a start address of the stack) and provides a set of methods (like create, push, pop, destroy) with published interfaces. For example, the parameters for the push could be a pointer to the stack object representing the stack to be pushed into and the value to be pushed. If the push is unsuccessful, then such a condition can be returned as a return value from the push routine.

Simple as this may sound, this principle of well separated interfaces can be easily violated! One common way this is violated is the use of global variables in a programming language like C. In the above example of the push routine, an unclean way of writing the code would be to store the return code in some global variable to be checked by the caller. Such use of global variables and other similar unclean interfaces produces undesirable and unpredictable side effects that are difficult to debug and maintain.

______________________________________________________

Proper documentation: It is a fact that people who actually do the initial design and development seldom end up maintaining the code. When a person who does maintenance is not aware of the big picture of design and the original development, such maintenance is likely to result in increased maintenance overheads. Proper and ongoing documentation is a means of reducing this risk. Two types of documentation that would help in minimising such sub-optimal maintenance are cross-reference documentation and change history recording. Cross reference documentation refers to documenting which modules are called by a given module. When this particular information about all the modules is stored and analysed, one can easily infer which modules would call a given module. Thus, this documentation enables a person making a change to gauge the effect this change would have on other modules. Change history documentation is done by any person making the actual changes to keep track of what changes were made, by whom, for what purpose, and when these changes were made. This serves as the audit trail to track down the changes. We present below a sample template for this documentation.

258 Managing Global Software Projects TEMPLATE FOR MODULE DOCUMENTATION COVERING CROSS REFERENCE DOCUMENT AND CHANGE HOSTORY RECORDING Module identifier : Module name : Module description : Module owner : Module input parameters : Module output parameters : Module logic specifications : CROSS REFERENCE DOCUMENTATION Called modules : CHANGES CHANGED BY CHANGE DATE CHANGE DESCRIPTION

259 Design and Development Phases DESIGN FOR INSTAllABILITY 16.11 The user forms his first impression of the product when he tries to install it. Hence a proper design for easy installation will have a lasting impact on the user's mind and will go a long way in enhancing customer loyalty. Some of the design and development aspects that should be taken into consideration on installation are: It should conform to a standard look-and-feel: Each platform has a standard way of installation that sets the expectations of a user with respect to what he a user would be wanting to see. For example, the Windows platform, Macintosh platform, etc. each have their own installation standards. When a product installation is being designed, it is important to factor conformance to the installation standards of the platform. Should be consistent in the presentation and processing format: The installation program should not only conform to the platform look-and-feel but should also be consistent within itself. For example, the shapes, size and colours of buttons and other GUI widgets should be consistent, the order of the buttons (e.g., YES/NO/ CANCEL) should be consistent, etc. Should be easy to install and should ideally require no documentation: The installation should be designed to be highly intuitive and common sense oriented. The language and style used for communicating with the user should be simple, con- cise, to-the-point and unambiguous. The best installation is the one which requires no documentation and in fact, no action from the user! Where documentation is necessary, it should be completely in sync with the actual installation: If there is a need to use the documentation during installation, then what is found in the documentation should be exactly the same as what the user actually sees on the screen during installation. If there are variable fields or parameters being displayed on the screen and on the document, the allowed differences in the documentation vis-a-vis the actual screens should be clearly specified. Any differences there in are likely to confuse the users further and make the installation process more error-prone. Should assume intelligent, context sensitive defaults: One of the most irritating aspects of an installation is when the installation program asks questions for which it already has the answers-more so when a question has only one answer which the installation program could easily infer by examining the environment. The hall- mark of a good installation design is the ability to present the user with an intelligent set of defaults that are most appropriate for the given environment. One important corollary of redundant questions is that an installation should definitely not ask the same question more than once!


INTER-OPERABILITY DESIGN 16.12 No software product works in a vacuum. It has to co-exist and inter- operate with other software products or even with older versions of the same product. The design of a new product or a new version of an existing product should address some important questions on co-existence like:

How is the inter-operability of the multiple systems achieved? Inter-operability of different products means that there must be a way to share and exchange data across two systems. Also, one product must be able to use the services of another. Such data or services sharing (also called interface sharing) cannot happen by accident. This has to be planned for during the design phase itself. To enable data interchange, the design should take care of:

Providing data structures that take care of what data needs to go in and out

Marshalling input and output data to account for differences in data formats and requirements across systems

Handling the machine specific issues of data stored in various systems (like byte ordering, character sets, etc.)

How can data be migrated from one system to another? In addition to inter-operability of different products, there are often requirements for data migration from one system to another. Such a need would arise when the system has several heterogeneous products that do not inter-operate directly. For example, when separate products are used for capturing the operational data and for decision support queries, data would have to be migrated from the operational system to the decision support system.

How can the more recent version of the software access data be created in older versions? Any organisation will have a significant amount of data that is created on a production system using the software products that it already has been using. When a new version of a product is introduced, it should be able to access the existing legacy data created by the older versions, preferably as it is. This is called downward compatibility. New versions of products that are not downward compatible to the previous versions involve significantly high migration costs.

Is there a call level compatibility across different versions? So far, we have looked at inter-operability and co-existence from a data perspective. But in today's world of componentised software development, a product is built using re-usable components. Furthermore, a product can call upon services of another product. Let us take


a very simple example. A software product from the client's side may invoke certain operating system calls to perform some screen operations. If a new version of the operating system is released, it is important not to alter the behaviour of the call interface so that the existing applications can continue to run unchanged even with the new operating system routines. To provide this call level downward compatibility without constraining on the introduction of new functionality, most systems that provide such call level interfaces provide a compatibility mode of operation that enables older applications to run unchanged while allowing new applications to exploit the new functionality.

CHALLENGES DURING DESIGN AND DEVELOPMENT PHASES

16.13 The design and development phases are the domain of people who come from a technology background. There are some common patterns that can be viewed as challenges, as a result of the background that these personnel come from.

"I don't need design, I am in RAD mode!": Developers usually graduate to be designers. They see design as a natural career path. But as they move on to being designers, they still tend to carry some of their old passions-the urge to jump into code and development! This jumping into development (euphemism for coding!) comes at a price-and the price is skipping design. This mistake is sometimes even legitimised by, "We are following the RAD life cycle model"! One of the important challenges for the management is to guard against the urge to go into development prematurely with an incomplete design.

"That cool one line change!": People who do the actual development are familiar with-and even possessive of-the code they write. While being attached to the code, they tend to be somewhat myopic of the overall function the code is supposed to serve. Sometimes they introduce "cool one line changes" that, in their mind provide a cool new feature or a great new optimisation. One should be careful of such uncontrolled "cool new things" as they could end up producing new features that are either unwanted or come at the expense of other essential features or they produce unknown side effects. It is essential to have code and design review mechanisms to ensure that there is no such feature creep.

Design change control and need for feedback: The requirements gathering phase is characterised by significant amount of communication with the customer. This


communication acts as a natural correction mechanism to make sure that the customer's needs are taken care of. The design and development phases are by nature relatively inward looking and tend to have lesser customer interaction. Change control-the process of evaluating a change request for its necessity, appropriateness, and impact-becomes all the more critical and essential in the design than in any other phase. It would also be a good idea to have, in the design change review team, a representative from the requirements gathering phase. This will ensure a better translation of requirements into design.

Anticipating future growth: Any design should anticipate future growth-growth with respect to length of fields (e.g., key fields like account numbers), storage requirements (e.g., allocating sufficient space for indexes, data storage, etc.), and transaction volumes (e.g., providing network bandwidth). Most design tends to optimise current needs while not taking a thorough and analytical look at future needs. (A classic example of the consequences of not planning for future growth is the infamous Y2K problem!) To make matters more complicated, for systems deployed over the Internet, such estimation may not even be possible. The designer should consciously ensure that future growth in each of the dimensions described here is accounted for in the system design.

Keeping documentation current through changes: It is believed that developers do not particularly like documentation! A design document or a source file that is not kept current with the development and changes is a big landmine that could pose problems in the later phases like the maintenance phase. Furthermore, even during development, if the design and code documentation are not kept in sync with the code, and the developer changes mid-stream, there is a significant scope for erroneous interpretation of design to produce a wrong implementation. Not keeping the design and code documentation current and trying to do development is as frustrating as trying to navigate on roads of Bangalore with a map of San Francisco!

SKILL SETS FOR DESIGN AND DEVELOPMENT

16.14 Developers are the ones who actually implement the code. Most software people start off their career as developers.' The academic founda- tions they get from their schools and colleges usually make them adept at whatever the current technologies are. This mastery and in-depth _____________________

3 By the term" developer" we mean people who write any form of code. This includes testers, people who perform maintenance functions, etc.

263 Design and Development Phases knowledge of the relevant technologies is an essential skill set for successful developers. But this is just necessary not sufficient.

Since the technologies change very fast, the challenge lies in not just knowing everything they need to know about the most current technologies but also in being adaptable to learning new technologies. This requires an open mind and a positive attitude. It is as important to be trainable as it is to be trained.

One of the common traits seen in developers, especially early in their career, is an excessive affinity to a specific language and/or a specific platform. During the late 80s, when a student came out of school, his main aspiration was to work on 'C'. Then in the early 90s, 'C++' was the "in thing". In interviews, people would say, "I want to work only on C++ not on C!". When the Java wave struck in the second half of 90s, the new aspirants would want to work only on Java!

An important attitude change to be imbibed in developers is their ability to understand that language or a platform is an enabler to achieve an end goal. There are common attributes in all technologies, platforms and languages that need to be carried forward without undue bias to any specific language or platform. One of the characteristics of computer science education in most schools and universities is that it encourages individual development and does not give very many opportunities for team based development. Software development in the real world is seldom done by one man armies. Also, unlike the training in most academic institutions, the main success criteria in an industry setting is team success rather than individual success. In order to realise the team success, each team member is required to play multi-faceted roles. Such diversity in work and the ability to work in teams are both essential aspects of skill sets needed for developers. As these are seldom taught in schools and universities, they should be imbibed in the training programs in the industry.

Another aspect of training that the developers who come out of school need to undergo is the willingness to adhere to organisational processes and cultivate some work discipline. Concepts like configuration management, estimation, metrics and

264 Managing Global Software Projects quality assurance are important discipline-related practices that need to be culti- vated in developers.

As we mentioned earlier in this chapter, developers view design as the next pro- gression in career. How do developers become designers and what new skill sets do they need?

The first is to be able to think at an architectural level. This requires the abstraction capability to identify common building blocks for the system, the willingness to source the building blocks as necessary from existing re-usable components and the ability to develop new components and put them together with re-usable components.

A second major requirement is that when a developer turns a designer, he should be able to get the development work done by other developers. He should not just take somebody else's detailed specifications and turn them into a programming language code but should also be able to generate such specifications from the requirements gathered. This calls for a different type of skill that is not found in all the developers. It also calls for a combination of being able to understand technology and the product and to communicate the same effectively. Thus, communication becomes an essential required skill for successful designers.

Developers tend to be somewhat isolated from the customers. But when they take on the mantle of design, there would be a need for some amount of interaction with the customer and the need to be able to look at things from the customer requirement perspective instead of just the code perspective. To most developers, this is a paradigm shift and a chasm difficult to cross. METRICS FOR DESIGN AND DEVELOPMENT PHASES 16.15 Software literature discusses a good number of metrics to evaluate the engineering effectiveness of the design and development phases. Metrics exists for cohesion, coupling, complexity, interfaces, etc. From a project management perspective, all these engineering metrics should eventually boil down to two major factors:

1. How well does design/ development reflect the requirement? 2. How often did the design change because subsequent phases could not move

ahead using the current design?

265 Design and Development Phases The first factor refers to how well the design reflects the requirements. Every feature or item captured during the requirements should be accounted for realisation during the design phase (and carried forward to development). It is also equally important to ensure that there are no design features that do not have corresponding requirements.

The second factor measures the adequacy of design for the subsequent phases (like testing and maintenance) and the changes that had to be made to the design because it was found inadequate or not realisable in the subsequent phases.

During the design phase, certain data structures and algorithms are chosen. The code development then proceeds with this design. Let us suppose that during development and testing, the algorithms and/ or the data structures were found not feasible (not realisable through the technologies or languages chosen) or inefficient (too resource intensive under the chosen configurations), then the design would have to be redone to accommodate the realities of development. Here the slips in design are detected only during the development phase and the feedback from development causes the design to change which results in wasted effort and development re-work.

The quality of design could have an impact on more than just the development phase. It could well extend into the maintenance phase. As we discussed in the section on Design for Maintaintability, bad design could have a telling effect on the maintenance costs of a product. The factors discussed in that section act as drivers to evaluate the quality of design.

CONCLUSION

Design and development are the ideal phases where a software team likes to spend most of its e as these are closest to technology. What we have attempted in this chapter is to provide a amework that enables the designer not to just look at the technology aspects but also consider other aspects that would have a far reaching impact on the total cost of product development, This total cost includes the cost of testing and maintenance, which we cover in the next two chapters.

REFERENCES

The architectural aspects of software can be found in [SHAW-95] and [BASS-98]. [GAMM-95] discusses reusability. [BOOC-94] is a classic in object oriented analysis and design. [SHNE-97]

266 Managing Global Software Projects presents some of the user interface issue. [PRES-97] covers a lot of ground on various aspects of design.

PROBLEMS/QUESTIONS

1. We have combined design and development into a single chapter. Give some reasons as to why this is not appropriate.

2. Identify some differences between design and development in terms of (a) Processes used (b) Technologies and tools used ( c) Skill sets needed

3. What would be the undesirable outcome of not identifying a blueprint/ architecture as the first step of design?

4. In order to achieve re-usability, you should have a repository that specifies the characteristics of modules. Develop a checklist of attributes of such a repository.

5. In case of the following software tools/requirements, applying the "Make or Buy" decision in each of these, state whether you are more likely to make the software or buy it: (a) An underlying relational database management system for the product (b) Organisation-specific price computation program for an invoicing system

(c) A problem tracking system that helps an organisation to prioritise and track the problems reported by customers.

(d) Income tax calculations as per the Government of India regulations 6. List some of the disadvantages of complying with external standards for the

emerging technologies. As an example, discuss your design and management strategy if you are developing an application for the Mobile marketplace and you have to choose between W AP and iMode-two competing standards.

7. Discuss some of the differences between internal standards and external standards.

8. You are managing the design and development of a portable application. Your engineer / designer comes and tells you "I am using Java. Hence, my application will automatically be portable". Would you agree? Justify your answer.

9. What are some of the differences in GUI design when an application is to be deployed over the Internet?

10. Revisit the design for testability after you read the chapter on 'Testing' and ascertain what actions you would take at the design / development time.

11. While designing for diagnosability, we have mentioned that there should be footprints to trace from execution point back to the source point. Discuss some cases where this may not be possible.

267 Design and Development Phases 12. Revisit the Design for Installability section after reading the chapter on the effect of

the Internet (in particular, the section about deployment models). How does the Internet change the design for the installability criteria discussed in this chapter?

13. Look tip the literature for some of the software engineering metrics for design (like cohesion, coupling, etc.) and discuss what effect these have on project management.

Chapter - 17

Project Management in the Testing Phase

"The most important considerations in software testing are in the issues of economies and human psychology."

Glenford J. Myers

What is testing? - Activities that make up testing- Test scheduling and types of tests- People issues in testing-Management structures for testing in global teams-Metrics for testing.

INTRODUCTION

17.0 In Chapter 7, we discussed various methods of ensuring the quality of a product. We distinguished Quality Assurance (as a means of pro actively avoiding defects before the product is built) from Quality Control (as a means of detecting defects after the product is built). In this chapter, we will discuss Testing, one of the common quality control methods.

WHAT IS TESTING?

17.1 The eventual goal of a software project is to have zero defects in the end product that goes out to customers. The defects in the final product normally creep in by means of defects from various phases. For example, defects can come from improper identification of requirements or incorrect translation of requirements into design or through erroneous coding. Mecha- nisms like design reviews can catch the defects in the initial phases. Testing refers to activities that are carried out to ensure that the final software product meets the requirements that the product is intended to satisfy. Some of the attributes of testing are:

269 Project Management in the Testing Phase

Testing is done on a product that has already been built. It is not a desk check

like an inspection or a code review. Testing is done to detect the presence of defects in the product, not to prove

that the product is defect free. Tests are divided into physical units called the test scripts (or test cases). Each

test script exercises the built product in a pre-defined manner to produce an actual result . Each test script also has a pre-defined expected result that specifies the result of executing the test is if the product behaved according to its original intent / requirements.

The actual result is compared against the pre-defined expected result. If the expected and the actual results match, the test is said to have been a success and if they don't match, the test is considered a failure.

When a test failure is encountered, the product and the expected results are examined to analyse the reasons for this failure and accordingly, appropriate changes are made in the product, and the tests are re-run to ensure that they succeed. It could also be that the expected results arrived at initially were wrong, in which case they are changed and the test is then deemed successful. Also, the expected results are updated to reflect the new changes.

270 Managing Global Software Projects WHAT ARE THE ACTIVITIES THAT MAKE UP TESTING? Testing includes the following activities:

• Test specification • Test design

Test development Test registration Test execution Test maintenance

In the following sections, we will go into the details of each of these activities. Test Specification It this step, what needs to be tested is finalised and documented. This can also be viewed as "requirements specifications" for the testing activity. Some of the questions that get answered during this phase are:

Which hardware configurations should be used for testing the product? The software product is eventually designed to run on certain hardware platforms. In this step, the specific hardware platforms on which the product should be tested are identified and documented. From a project planning perspective, this leads to estimating the cost of hardware needed for testing and also the time needed for the testing activities. If there are more platforms on which the product needs to be tested, the test development and test execution costs would also increase.

Are there any cut-off configurations under which the product must be tested? There may be some "minimum" configurations the product is expected (or documented) to run on (for example should run under 256 MB of RAM). During the requirements stage, such configurations would have been specified. During test specification, it is important to re-visit these minimal configurations to ensure that tests are designed for them.

Which software environments should the product be tested under? Typically, product development takes place in specific software environments-for example, the specific versions of the operating system, compilers, databases, and other utili- ties. But when the product is deployed in a customer location, the software environment may not be exactly identical to the environment under which the product was developed. The operating system or any of the other environmental software might have had patches applied to them. These changes may cause the software product

271 Project Management in the Testing Phase under test to behave differently in the deployment environments than it did on the development platform. Hence while testing, it is very important to capture and document the software environment under which the tests are to be developed and executed. This will help in narrowing down the time of resolution should a problem-that did not show up during development-appear at the customer site. What are the most common scenarios that need to be tested? A software product can be exercised by the user in several different scenarios that the software developer might not have visualised. It is just impossible to test the product under all the different scenarios. Hence a careful and judicious choice must be made of the scenarios to test under that is representative of the most common ways of exercising the product. During test specifications, the choice of which scenarios are to be tested have to be documented after discussions with a cross section of the typical users. What are the criteria for test completion? During the test specification stage, the criteria for test completion should also be documented. Some examples of completion criteria are "achieving code coverage of (say) 95%" or "exercising entry to (say) 80% of the routines". There may also be hard deadlines for the product to reach the market. Such deadlines can also be specified here and they-along with criteria like code coverage-would act as drivers for estimating the resources needed for testing. Test Design Having decided what to test at a high level during the previous step, the details of the layout, tooling and standards required for test development are designed in this step. Some of the questions taken up at this stage are: For each of the scenarios identified as important at the test specification stage, can we drill into details of what needs to be tested (the test cases) and what should be the expected output for each such test case? For example, suppose it is decided during the test specification stage that limit tests have to be done for the permissible number of users who could concurrently be logged in, then during the test design phase, questions like "how many users should be tested?" are answered. Are we planning to use a tool for test automation or are the tests going to be run manually? Once the tests are developed, they have to be run multiple times, typically, once each time a new version of the product is built. This makes test execution repetitive and labour-intensive. Using a test automation tool alleviates the problem. Most of the commonly used tools provide mechanisms to capture or "record" tests

272 Managing Global Software Projects and the outputs, and then play the tests to verify that the produced output and expected outputs match. But the decision to use a test automation tool is not a post- facto decision that is taken after the tests are developed. This decision has to be taken during the test design stage itself as it has ramifications on the cost, effort, and the technology to be used for test development.

What kind of structure or standards are to be used for development of tests? Most test automation tools come with their set of recommended standards and structures. Standards cover coding standards (on how the tests are coded to facilitate functionality and re-usability), documentation standards (how the tests, their function, and their changes are documented) , structure standards (directory structure of storage) and other means of translating the test design into test cases.

Test Development

This step is akin to the coding part of development. During this activity, tests are actually written. The specific activities differ depending on whether an automated tool is used or whether the testing is manual.

Test Automation

One of the biggest complaints about testing is that it is considered a manual activity. This is especially true of testing of the GUI based applications wherein a fair amount of manual operations are involved. One way to alleviate this problem is the use of test automation tools. Such tools provide mechanisms to

Capture or record the user inputs Invoke the right parts of the product (or the environment) in an automated

way, based on the user inputs Specify responses the product should produce ("Expected Results" from

Fig. 17.1). Compare actual results and expected results.

The actions of the user and the system are coded in a way that allows the test automation tool to run the tests automatically with minimal human intervention.

Test automation poses several interesting challenges:

The complexity of test automation increases with an increase in user interaction and also when there is an increase in "GUI-ness" of the application. This is because

273 Project Management in the Testing Phase capturing user inputs and expected screen outputs becomes tricky. Such input/ output undergoes minor changes from one release to another and hence the verification of validity of observed (actual) outputs becomes difficult. One of the ways in which test automation tools can overcome this problem is to capture logical screen inputs and outputs instead of physical screen inputs and outputs.

The complexity of test automation increases with an increase in the number of platforms on which the product is supposed to run. This is because even if an application behaviour is logically identical across platforms, the look-and-feel of the CUI controls is different on different platforms and hence the re-use of expected results across platforms becomes almost impossible. This problem can be overcome by using a generic testing framework that works across various platforms.

Most tests have some environment dependency in capturing expected results. For example, the expected output may contain the current system date, terminal id or similar environment dependent variables. The comparison of expected results with observed results should not flag such environmental differences as errors. The comparison software should have the intelligence to represent such differences and be able to avoid flagging these as errors.

When an automated tool is used for testing, test writing comprises the following steps:

1. Training the test engineers on the automated testing tools to be used. Most testing tools have special languages in which-the tests have to be represented. Each tool also has specific ways of capturing inputs and-outputs of a test and validating the results.

2. Coding the tests in the language that the tool would understand, that would result in test scripts.

3. Running the test under reference conditions. This step would ensure that the test runs and that the documented expected output is indeed consistent with what was originally expected.

4. Capturing the inputs and outputs in this run and ensuring that this matches with the standard expected behaviour for future runs.

5. Registering (baselining) the test script / the input output capture into the configuration management system.

So, at this stage, the test scripts are available and the standard expected inputs and outputs are calibrated to be the actual expected inputs/ outputs.

274 Managing Global Software Projects Manual Testing

When the testing is manual, test writing refers to writing detailed instructions on what to test and how to test it. Also, test development in this case requires very clear and unambiguous documentation. An example of how to document a manual test case is given in the next page. It covers how to carry out a deadlock detection test properly while two users access a table in an Inventory application. Some salient points that should be kept in mind while documenting tests for manual execution are:

Do not assume the tester will have an in-depth knowledge of the application: The tester may not know the details of the application he is testing. For example, the statement, "check if the item has reached its re-order quantity level" may be very obvious to the developer of an Inventory application but may not make sense to someone who is new to the application domain and is testing the application.

Do not assume that the tester is proficient with the details and syntax of the underlying software: For example, if an application is built on top of a relational DBMS supporting SQL, it may not be sufficient to tell the tester, "subtract quantity ordered from quantity on hand for the product" . You would have to give an explicit SQL syntax which the tester would have to key in.

Do be specific and detail oriented: When the instructions are documented, they should follow the specific syntax and the punctuation that the tester should type in. When a CUI application is being tested, the instructions should go into details of where the mouse should be placed, what kind of cursor the tester would see, what he should do (mouse click, double click, tabbing across choices, etc.) and what would be the result of such an action.

Do not assume that all the environment is set up and is ready for testing: It is very likely that a test would require some set-up to be done. In the example given in the inset, the required table (PART) has to be created and populated with necessary rows (Item 100 and 200). It is the test developer's responsibility to ensure that specific instructions for doing the set-up are provided. It is also a good idea to drop the existing environment and recreate it to remove any undesirable side effects of data left over by the previous test runs.

Do run the test on an environment distinct from the one in which the test development was carried out before registering / baselining the test: When a test developer develops the tests, he is usually running then in his test environment which may not match the virgin environment in which the tests are supposed to run. For

275 Project Management in the Testing Phase example. there may be specific environment variables set up in the test developer's environment which may not exist in the live test environment. Thus before base lining the tests, it is important to validate them in a separate environment. Do have someone else run the tests by just following your test documentation: The person running the tests routinely may not have access to the test developer while running the tests. Hence it is useful to have someone else test out the test documentation. Do clean up after your test is over: Eventually, all the tests have to be run one after the other to test out the complete product functionality. Hence every test should clean up after it-i.e., drop the unnecessary data, unset any environment variables, etc. An Example of Test Case Documentation

System/product: Inventory system

Test case purpose: Deadlock detection

Test case author: [email protected] Test change history: 10 Nov 2000 Jdoe Creation 15 Nov 2000 Jdoe Added SQL examples Test description: To check out proper detection of a deadlock scenario

Test requirements: Need two simultaneous sessions: administrative privileges for setting up the test but normal privileges for running the

tests. Test set-up: Have your database administrator do the following: /I create a table ITEM" by the SQL statements

drop table ITEMS; create table ITEMS (item_code number, qty number); insert into ITEMS values (100, 10); insert into ITEMS values (200,20); Also have the database administrator create two userid's testuserl and testuser2 with passwords XYZI and XYZ2; and have him grant update privileges on ITEMS table to these newly created userid's


Detailed instructions for test case Step no.

What should the tester do How should the system respond

1 From Session # I, Invoke the query tool for the database, login to testuser1 with password XYZ1

Display the message "Connected"

2

Try updating Item table from Session # 1 with Item code =100 by executing the SQL statement update items set qty = 1000 where item_code =100;

Display the message "Record updated"

3 From Session #2, Invoke the query tool for the database, login to testuser2 with password XYZ2

Display the message "Connected"

4

Try updating Item table from Session # 2 with Item code =200 by executing the SQL statement update items set qty = 2000 where item_code =200;

Display the message "Record updated"

5

From the query tool already under execution in Session # I, try updating the item_code 200 row by: update items set qty = 4000 where item_code =200;

The tool would wait with no response as the row 200 is in use ("locked") by the transaction from Session # 2.

6

From the query tool already under execution in Session # 2, try updating the item_code 100 row by: update items set qty = 4000 where item_code =100;

The system is now about to enter a deadlock because Session # 1 transaction is waiting for Session # 2 to release the lock on Item Code 200 while Session # 2 is waiting for Session # 1 to release the lock on Item Code 100. You should see a message "Deadlock detected"

Test Registration

The tests have to be run multiple times for each build of the product. Whenever a product is tested, it is necessary that the correct versions of the tests be run, just as it is the correct versions of the products that have to be used. Hence tests need to go through proper configuration management. When we say "tests", we refer to the entire set that characterises a test-the test specification, the test scripts, the test documentation the test inputs that are captured and the expected test outputs that are produced.

Test Execution This activity refers to the actual execution of tests against a given build of the product. This step is repeated several times, usually every time the product is built. The

277 Project Management in the Testing Phase objectives of test execution are to detect any old defects that have re-surfaced and to report any new defects. (Such a test run is called regression run-see Section 17.3.6.) If automated tools are used for executing the tests, such test execution can be piggybacked on the activity of building the product. If the test execution is manual, then it can be triggered by a formal communication to the testing team upon successful completion of a given version of the product. Test Maintenance Over time, a product evolves with its new versions. New features are introduced. Some features keep getting enhanced while some other become obsolete. In addition, testing technology itself can evolve with more automation and tools. Because of all these changes, the tests and / or the expected results need to be maintained. The existing tests may need to be changed to reflect changes in product behaviour. For example, the error message that a product gives under certain conditions may change with new versions of products. This would require new versions of expected results to be created. Existing tests may also need to be scrapped as some of the features may be de- supported in newer releases. For example, if a given version of an Operating System supports a particular type of a device, the tests for that version of the OS should include communication with that type of device. In the future versions, support for that type of device may be discontinued (as it might be replaced by another device). In such an event, it does not make sense to run the tests for the de-supported device. Any new product version would have new features. It is important that as new features get added to the product, new tests for those features also get added to the test suites. When we look back at the activities that make up testing, we can see that there are quite a few similarities between code development and test development. Product requirements get finalised first; similarly, what needs to be tested gets

finalised first.


Test development is a means of translating the test design into executable tests, just as Program development is a means of representing the design/ algorithms in a programming language, eventually complied into an executable code.

Test code, just like the program code, needs to go through proper configuration management

Tests get debugged just as code gets debugged. Debugging a test involves ensuring that the tests are coded and executed in the right way to produce the right expected results.

Tests need to be maintained and kept current with changing requirements, just like code is kept current with changes in requirements/design.

_________________________

TEST SCHEDULING AND TYPES OF TESTS

17.3 When do the testing activities start and when do they end? Is testing a separate and distinct phase of product development? To answer these questions, let us first recapitulate the intent of any product development activity, which is to avoid product defects and in case product defects do creep in, to minimise the time delay between the point of injection and the point of correction ot'the defect. Testing being a means of uncovering the defects in the final product (as in quality control), it is important that the defects in the products be detected reasonably close to the point of injection and not at the end of the development phase. Thus testing is an activity that should run parallel with development so that defects can be detected and corrected early in the cycle. But the kind of testing that needs to be done would depend upon the level or position that a product is in. In this section, we will discuss the different types of tests that are done at different points of product development life cycle. Each of these test types may require different skill sets, different profiles, and the responsibility of the test activities would rest with different people. The different types of testing done during a product life cycle are:

White box testing Black box testing Integration testing System testing Installation testing Regression testing Acceptance testing

279 Project Management in the Testing Phase We will cover each one of the above in the following contexts:

Why and how is this type of testing is done? Who is responsible for this type of tests and what are the required skill sets? What are some of the common challenges in this type of tests?

17.3.1 White Box Testing

Why and How is White Box Testing Done?

Using program design specifications, the programmer produces the source code that in turn gets transformed into an executable code (by the use of compilers or other similar software). The product accomplishes different functionality or options by executing different paths through the code. In white box testing, the program is run with various test data that exercise as many of the various paths in the source program as possible, thereby testing as much of the functionality as possible. White box testing requires knowledge of (and access to) the source code of the product. Either the developer (or someone else who can understand the source code) looks at it and identifies the various paths through the program code and designs test cases to cover as many of these paths as possible. The test data is generated so that a majority of the paths are covered. Some means of widening the coverage of different paths through the program are:

Tests that exercise the multiple conditions in a boolean expression in various combinations.

Tests that exercise the THEN and ELSE parts of conditional statements. Tests that are within the various CASE conditions of a multi-way decision

statement like the SWITCH statement in C. Tests that take a loop construct from 0 to the maximum value expected in the

loop variable. Tests that exercise various error conditions by giving erroneous data. Tests that check the combinations of correct and incorrect values for input

parameters.

The rationale behind white box texting is that if we cover as many of the code paths as possible through test cases and in each case, the product behaves as was expected, then the product is working in accordance with what the code was supposed to achieve.

280 Managing Global Software Projects White Box Testing: Responsibilities and Skill Sets

White box testing clearly requires an in-depth understanding of the source code and the paths thereof. Thus the people who design white box tests should be totally familiar with the programming language used during development. The test designer should also be familiar with the logic of the product, like what are the allowed inputs to a program, what are the expected outputs and behaviour at the program level. In addition, because the source code itself changes very often, the test developer must be aware of what the changes in the various paths are so that he can modify the tests as needed to get adequate path coverage.

Given all the above factors, it becomes clear that the design of white box tests are best done by the author of the program himself as he is familiar with the programming language, program logic and the various paths within a program. Also, as the intent is to detect any defects as soon as possible, it is also advisable that the developer himself executes the white box tests before baselining the code.

Common Challenges In White Box Testing

Simple as it may sound, white box testing does present some interesting challenges.

Developer's unwillingness to develop/run tests: Developers in general prefer writing new code to test development or repeated test execution. They are also under pressure to produce new features/versions. Hence they are usually unwilling to design and run tests.

Common human limitations in finding defects in one's own work: A programmer who writes his code has a biased view of his own way of writing. Human nature is such that it is very tough for one to find defects in one's own work. Furthermore, as testing is meant to uncover defects in one's own product, not many people want to admit that their work has defects! Hence by nature, there is an inherent reluctance on the part of the developer to test his own code.

Combinatorial explosion of possible paths and time constraints: The number of paths that exist in a program are potentially infinite. Testing all these paths would be a huge drain on time. The challenge lies in testing a reasonable subset of this large number of paths.

Relating common usage paths to code paths and prioritising: If a developer looks at the code as a set of paths he has to exercise / traverse, he would not be able to visualise the common usage patterns of a typical user, nor would he be able to understand which paths are critical show stoppers if they don't work. Understand- - --


ing the most commonly used paths or relative criticality of paths requires looking at the product from an external perspective and making sure that test cases are designed for such paths. To bridge this important gap in white box testing we have the black box testing.

17.3.2 Black Box Testing

Why and How is Black Box Testing Done?

As mentioned at the end of the previous section, the primary disadvantage of the white box testing is that it is based on the knowledge of the program code from the developer's perspective but not on product functionality from the user perspective. Black box testing looks at the product as a black box which is supposed to behave as per the specifications originally laid down and attempts to identify, from an external perspective, any deviations from the expected behaviour of the product. As black box testing looks at the product from an external perspective, there are multiple approaches possible to design black box tests. Presented below is one approach that is usually quite effective:

1. From the requirements specifications, the product is broken down into its salient features or logical modules. In fact, a well laid out requirements specification would already have identified the distinct features of the product. A feature is realised by a collection of source files but since black box testing consciously avoids looking at the program source, the test designer is allowed to look only at the external behaviour of the product and not at the implementation in the source files.

2. For each feature, tests are designed for functionality, usability, limits, error handling and interfaces.

Functionality testing: This type of tests exercises the basic functionality of the product from an external perspective. Some typical functionality tests are:

Tests to ensure that proper input data is accepted . Tests to ensure that the internal calculations and transformations result in

appropriate intermediate results . Tests to ensure that the external outputs match what is expected in terms of

content and layout.

282 Managing Global Software Projects Usability testing: Some examples of usability testing are:

Does the user interface match the CUI standards of the platform? Is there consistency in the user interface across product(s)? Does the navigation match what is documented? Is there consistency in the reports - both in content and format?

Limit testing: A product feature may have in-built hard limits that are independent of the environment it is running on. Some examples of such limits are the maximum size of a particular data item, maximum logical size of a file, maximum number of concurrent users on the system, etc. Limit testing refers to creating tests to verify:

that the system is able to handle the values within and including these limits properly.

that the system is able to handle the exceeding of such limits in a graceful manner, i.e. by displaying an error message rather than a system crash or some similar catastrophic outcome.

Error handling tests: It is important to validate product behaviour not only for correct data but also for incorrect data. The system should handle error conditions gracefully and in a user friendly manner. Some of the error checking tests that need to be done include:

Testing data inputs of wrong type or format. Testing data inputs of wrong size (covered in limits tests above). Testing inconsistent data combinations. Testing that the right message is displayed for the appropriate error

condition. Testing that error messages are not given for non-error situations.

Interfaces testing: Each module (feature) should talk to the other modules (features) through well defined interfaces. Interface testing is done to ensure that proper interfaces are passed across modules. Interfaces can be external, (like files) or internal, (like internal data structures). Since all the modules may not be available at the same time for testing, it is important to document clearly what the interfaces are so that such interface test data can be generated manually and the tests carried out. Black Box Testing: Responsibilities and Skill Sets

Black box testing requires an in-depth understanding of the requirements and the external functionality of a feature. Thus the people who design black box tests need


not be totally familiar with the programming language used during development. The test designer should be able to visualise how the feature would be used by the users, what the commonly used functionality are, and what would be the expected behaviour under various scenarios. Hence the black box tests development team is usually different from the people who actually develop the code.

Common Challenges in Black Box Testing

Ambiguous or unclear expected behaviour: The success of black box testing is dictated by how well the external behaviour of the product is understood. When the development cycles are short, it is often the case that the requirement or design specifications leave some loose ends in terms of the expected product behaviour. It could also be that all the possible usage scenarios are not envisaged or documented. Hence the tester may have his own view of "what is the correct behaviour", which may be distinct from what the product was originally intended to do. One way to remove the resultant subjectivity in testing is to tighten the Requirement and De- sign to describe unambiguously the expected behaviour in various scenarios.

Black box testers viewed as adversaries to development: Because of skill sets required and the nature of black box testing, the black box testing group is kept separate from the development group. As the testing group is distinct and their job is to find defects in the products produced by the developers, there is a possibility of the two groups viewing each other as adversaries. Some ways of tackling this feeling are discussed later in the chapter.

Relating common usage patterns and prioritising: When the product usage is viewed from an external perspective, myriad potential usage patterns are possible. If one were to test all the possible scenarios, it would be prohibitively expensive and time consuming. The challenge (as in white box testing) lies in visualisaing the common usage patterns, prioritising them and ensuring that they are tested.

17.3.3 Integration Testing

Why and How is Integration Testing Done?

Black box testing tests the functionality and external behaviour of an individual module or a feature. A product works as a whole by interaction between the various modules / features. Integration testing is done to test if the individual parts work together as one single unit.


One of the steps we had listed in black box testing was interface testing-making sure that each module or feature produced the right interfaces to be used by other modules or features. We also mentioned that since all the interfaces may not be available at the same time, interface data may have to be generated manually for testing purposes. When we come to integration testing, the modules that are to be integrated are available for testing. Thus the manual test data that was used to test the interfaces is replaced by that which is generated automatically from the various modules and can be used for testing how the modules would actually interact.

There are various sequences in which the modules can be integrated and tested. A couple of important drivers for deciding the order of integration and testing are:

Availability of modules to be integrated: Each module goes through its development schedules. If a module becomes available for testing, it would be expedient to test it with other modules that are ready, which will optimise the time needed to do the integration testing. This will be dictated by the availability of WBS units and milestones during the project planning phase.

Modules with maximum impact: Among the modules that are available, integrating those with the maximum impact (i.e., those that interface with maximum number of modules) earlier will detect the integration errors earlier.

In contrast to the above staggered approaches to integration testing, one can also consider doing a Big Bang integration testing wherein all the modules are put together and tested in the end. This may simulate the real life use of the product by the customer better but would be successful only if the planning and organisation of interfaces is done with a high degree of perfection. Since the number of interfaces and integration points are very high in a typical real-life software product, an unplanned integration testing is very likely to lead to wasted resources by not testing the most typical integration points.

Integration Testing: Responsibilities and Skill Sets

The type of skills that an integration test development team has are very similar to those of the black box test development team. Both have good product knowledge from an external perspective and both know the basic modules / features within the product. The one difference in the responsibilities arises from the dependencies that exist across modules. Hence the need to communicate across different groups and the soft skills required is generally higher for integration test team than for the black box team. Also, because of the multi-group dependencies, the integration test team may have a different reporting structure then that of the black box team. We will cover this in Section 17.5.

285 Project Management in the Testing Phase Common Challenges In Integration Testing

Visualising integration tests: Integration testing takes the testing one step closer to the actual product usage. Truly successful integration testing calls for a sound knowledge of how the various parts should fit into the whole. This requires someone who understands the external product functionality as well as the internal units of integration. To find this combination of skill sets is not easy.

Schedule conflicts because of availability: Once a module reaches a certain stage of completion, it would require some other modules in order to proceed. But because of scheduling conflicts, these other modules might not be available. Thus integration testing may come to a standstill. In order to avoid this situation, one may have to, at times, proceed further with development and defer integration testing.

Assigning responsibilities to problem areas: During white box or black box testing, when a problem or an anomaly is observed, there is no controversy about assigning responsibility to fix the problem since the unit being tested is self contained. But in integration testing, we are taking modules developed by different groups and putting them together for testing. When a problem comes up, it is sometimes very difficult to pin-point where the problem lies and who should take the corrective action. If the interfaces are perfectly defined, there would be no such controver- sies. But in real life specifications, there are always unanticipated scenarios and un- defined interface values. In this case, there has to be some mechanism of assigning responsibility of fixing the problems that get exposed.

Communication: In white box and black box testing, the testing is carried out pretty close to the point of development as there are very few external dependencies. Inte- gration testing depends on the availability of several modules. Hence, triggering the start of integration testing and ensuring smooth progress and defect resolution is dictated by very good and well defined communication channels across the various groups.

17.3.4 System Testing

Why and How is System Testing Done?

Like integration testing, system testing is aimed at exercising the product as a whole. And unlike integration testing, the focus during system testing is on stress- ing the system under extreme conditions and ensuring that if there is any failure, it is well managed. Some of the aspects of system testing are:


Load testing: This subjects the product to a very abnormal work load and ensures that there are no adverse effects. Some examples of load tests are: testing with a high number of concurrent users and ensuring that the system does not break; flooding the system with excessive input requests; trying to pump in more data than what the network bandwidth or other similar physical limits can handle, etc.

Configuration testing: Every product should have the specifications of the hardware configurations that it runs under. Configuration testing is a means of running the software product under various combinations of these configurations. For example, if the product is certified to run with a minimum memory of 16MB, then the tests must ensure that the product does run in a machine with 16MB memory.

Integrity testing: Regardless of the things that go wrong in the environment, the product should not compromise the integrity of the data it handles. For example, there should be adequate protection and recovery from events like power failure, media crashes, etc. Integrity testing is aimed at testing features like recovery, authentication, etc.

Inter-operability testing: In today's componentised world, a product would be expected to inter-operate with other products, whether from the same vendor or from different vendors. While doing Inter-operability testing, the approach should be to specify which versions of which products should inter- operate with each other and test such combinations. Inter-operability testing usually becomes increasingly complex as the product matures (as there would be more versions to test inter-operability) and increasingly expensive too because of the number of combinations possible.

System Testing: Responsibilities and Skill Sets

The skill sets of system testing encompass and transcend the skill sets of integration testing. The added requirement is that in tests like load testing, the person developing and running the tests must be throughly familiar with the nuts and bolts of the underlying system software. For example, load testing has a significant dependence on the hardware configuration and system tuning. Such skill sets are fairly niche and difficult to come by.

Common Challenges in System Testing

Defining realistic scenarios: Defining what constitutes realistic scenarios is a very complex task. For a general purpose software-because each customer's system could be different -what constitutes a good system test for one customer may be

287 Project Management in the Testing Phase inappropriate for another customer. Even for a bespoke product, the usage patterns vary from time to time.

Unique mix of skill sets needed: As discussed in the previous section, system testing requires a delicate combination of visualising the 20,000 foot level view of how an end product would be used along with the nuts and bolts of how to exploit the best features of the underlying system. This is a fairly specialised skill set.

Resources needed to perform tests: Most of the system tests described above test the system under extreme conditions. Tests like performance tests require high end hardware configurations that are expensive to acquire.

Reproducibility: Most problems that show up during system testing do so because of a complex combination of factors from the product, the software environment and the hardware configuration. Thus, most "problems" found during the integration testing tend to be difficult to reproduce and resolve.

Problem Identification: A natural consequence of the difficulty to reproduce results in the system tests is that problem analysis and responsibility allocation becomes a more serious issue than in the case of integration testing. Does the problem lie in the product or in the environment? Which should be corrected? These are difficult questions with no easy answers.

17.3.5 Installation Testing

So far we have been concentrating on various features and the behaviour of a product. But before the product can be used on a customer site, it has to be installed successfully. Installation tests are are done to ensure that the product is packaged correctly and can be installed successfully using the instructions given in the installation documentation. The steps that are followed for carrying out the installation tests are:

1. Packaging: Once the product features are tested, the product needs to be packaged for use by the customers. Packaging can be the creation of a master copy in a media like a CD or the creation and publishing of a location (ftp site / URL) from where the user can download/install the product. The packaging has to be easy to use, customisable and conforming to any platform or product standards.

2. Documenting: Accompanying the product would be some documentation about how to install the package. Such installation documentation should

288 Managing Global Software Projects contain screen captures of the various screens that would come up during installation, specify various options possible and the actions in each of these options and lead the user to successfully install the product in his environment from the media.

3. Installing: The person performing the installation tests should get the media and the documentation listed above, follow the instructions given in the documentation and ensures that

The screen shots and the defaults shown in the documentation are accurate

There is a match between the documentation and the actual behaviour of options chosen, installation flow, and the results observed

If erroneous inputs are given, the installation system handles the errors gracefully and gives appropriate error messages.

No extraneous or repetitive information is sought from the user unnecessarily.

4. Verifying: Every installation packaging should have some means of verifying that the installation has been completed successfully. After installation, a "self test" suite should be designed and run. Such a self test should have clear success criteria.

17.3.6 Regression Testing

So far, we have seen a number of different types of tests that need to be run at different points of time during product development. As discussed earlier in this chapter, product development goes in iterations of built-test-fix. It is obvious that from one cycle to the next, the older defects should not re-surface.

Let us illustrate this with an example: During a given build and test cycle, defects Dl, D2 and D3 are discovered. The root cause is found, the necessary corrections made, and the tests are re-run during that cycle. It is confirmed that the defects are fixed. During the next build cycle, new defects D4 and D5 are found on the testing. These defects are corrected and the tests are re-run. Now there is a chance that the fixes for D4 or D5 may break the fix made for Dl/D2/D3. Such a re-appearance of an earlier defect is termed as a regress. In the example above, if the tests for fixes of Dl/D2/D3 are also run at the end of the second cycle, then a regress of Dl/D2/D3 would have been captured.

Regression tests are then defined as those tests that are run to verify that problems do not resurface (or regress).

289 Project Management in the Testing Phase What tests should constitute regression tests? At the minimum, regression tests

comprise:

tests that test out key product functionality tests that exercise those product areas that are historically defect prone tests for defects fixed in the last few cycles

Regression tests are usually designed to run automatically after each time a prod-

uct is built. This reduces the tedium of running the tests repeatedly. Just like in any other forms of testing discussed above, the choice of what to test (and include in regression tests) should be done judiciously, balancing the knowledge of the internal code and design with the common external usage scenarios. As regression tests are run every time the product is built, it is important to keep the size of these tests within manageable limits so that they can be completed in reasonable time. Hence someone in the organisation should be assigned the responsibility of periodically looking at the list of regression tests and keeping them updated by deleting unwanted tests and by adding tests for the new features. 17.3.7 Acceptance Testing When a product is designed for use by a specific customer, it is usually required to pass certain tests that the customer considers representative of his typical environment. During the time that the initial requirements are arrived at (when the contract is signed), a set of acceptance tests would be specified by the customer. The performance of a product would be considered satisfactory (by the customer) only if it has passed the acceptance tests. Such acceptance tests typically require the product to be tried using specific data provided by the customer. Moreover, it should also produce the specific outputs that the customer expects to see. In addition to such functionality based tests, the acceptance tests may also include performance tests that test the system under load from a number of users, delivering a minimum response time or throughput.

PEOPLE ISSUES IN TESTING 17.4 Out of all the life cycle activities in software development, the one activity that faces the

highest number of people related issues is testing. The most common manifestation of such people issues is that generally employees do not want to be in the role of a tester. There is a perception

290 Managing Global Software Projects that testing is a mundane job and does not require any special skills. Given a choice, most people prefer to be in development rather than in testing. There are several reasons for this misconception:

1. Testing is not formally taught in many of the institutions. 2. Testing as a branch has not received the same amount of publicity and

attention as design in terms of working groups and forums. 3. Management attention tends to be biased towards developers 4. Management sometimes does not "walk the talk" when it comes to acting on

defects uncovered by the testing team 5. People not seeing a career in testing, view testing as a stepping stone to

graduating to development.

Common Symptoms Seen in Managing Testing

While managing testing teams, there are some common themes that are seen among the testing teams:

“I will do testing to start with but can you move me to a Java programming project in the next six months?"

Most people do not perceive there is a career in testing, whereas they do feel that there is a career in "development", which is equated to coding. It is important for the management to provide role models who make a career in testing "Testing is just data entry"

This misconception is carried over from the earlier days of testing where one had to do manual testing. With the advent of test automation tools, this is no longer true. Testing can focus more on test design than test execution

Such comments can get aggravated by comments like the following from management: “Let us put our best engineers in development and assign testing to rookies"

It is important that management exhibit their commitment towards the testing function by assigning some of the best engineers for testing and by rotating people between development and testing functions. "Let us do all the testing after development"

291 Project Management in the Testing Phase It is very important to start testing functions as early as possible in the product life cycle. Test specifications can be evolved right from the requirement or design stages; test development can run in parallel with product development to enable early beginning to testing. "Let us do whatever testing we can do in the next two weeks, before the release" Testing should not always be constrained by time. The end criteria for testing should not be just "oh it is time for the release!" but that a given amount of code coverage or bug fixes is achieved.

How does one contend with such perceptions? A few simple principles can be adopted by the organisation's senior management as well as the project manager to attract and retain people who want to do testing:

1. Treat the developers and testers on par in terms of recognition, compensation, etc. 1. Demonstrate that the testing team is equally important: for example, if the

testing team uncovers serious defects in the product, ensure that the developers do fix the defects rather than just going ahead and releasing the product.

2. Do not assign all the best engineers to development; assign some to testing as well.

3. Design and show a career path for the discipline of testing 4. Rotate people between development and testing so that the developers

understand the fact that testing is challenging 5. Invest in skill development of the testers. A key part in the success of a tester's

job is soft skills. This includes: developing better attitude and pride in testing among testers and

developers being able to communicate the defects with the sole intent of getting the

product defect free. not projecting oneself as being an adversary to the developer.

MANAGEMENT STRUCTURES FOR TESTING IN GLOBAL TEAMS

How do you organise the testing and development teams to minimise conflicts and deliver a time bound, high quality product? We present below some possible organisational structures--initially starting with

292 Managing Global Software Projects generic structures and then bringing into the picture the new possibilities as dem- onstrated in the case of geographically distributed teams.

In the above model (Fig. 17.2), there is one project manager who manages both the development and the testing functions. By making the testing and development teams a part of one physical team reporting to a single manager, this model presents some advantages:

=> The project manager can multiplex the development resources with testing resources. A typical product development cycle is front loaded with the need for development resources and rear loaded with the need for testing resources. With all the resources in one basket, there are opportunities for better load balancing and resource utilisation. => The chances of conflicts between the testing and development teams are reduced because the teams have many opportunities for interaction. The team work can further be enhanced by job rotation and multiplexing of testers and developers.

However, this model also has some problems that one should watch out for:

Entrusting operational responsibilities for both development and testing to the same manager opens the doors to potential conflicts. It is easy to gloss over some of the defects to meet the deliveries. Also, when testing and development are done by the same set of people, it is possible that different

293 Project Management in the Testing Phase perspectives would not come into the picture. Testing degenerates to proving that the product works rather than finding defects in the product. Testing and development require somewhat complimentary skill sets. It is

not always possible to make a developer do the testing. Dedicated Testing Team Model

In this model (Fig. 17.3), the testing team reports directly to the next level of senior management. Thus the conflicts between operational delivery responsibilities and testing responsibilities are avoided.

There are some finer variations possible in this model: The testing team can further be broken down into sub-teams and each sub-team assigned the responsibility of a particular product. Alternatively, the entire testing team can be considered as one set of resources who are assigned the testing of different products on a need basis.

This model has two primary disadvantages: First, because of the direct reporting line of the testing team to the senior management, there is a greater chance of the testing team perceiving the development team as an adversary or vice versa. Sec- ond, there is very little opportunity for diversity in work: testers do the testing and developers the developing. This lack of diversity could eventually end up in reduced motivation.

294 Managing Global Software Projects Testing Teams in Geographically Distributed Product Teams Geographically distributed product teams present some more opportunities for organisation structures and for maximising the quality and optimising the resources.

One way to divide the product between different locations is to break it into different components and give the complete component responsibility on specific components to each location.

Each component is like a mini-project in itself. Thus the model is very similar to the integrated testing team model presented above; with each location manager managing a self contained mini-project, spanning both development and testing.

One possible variation to the above model is to let one location test the parts of the product developed in another location. This cross-location testing, illustrated in Fig. 17.5, offers some very significant advantages:

Operational responsibilities in testing and development are distributed Because both locations get involved in all the product components, there is a

wider distribution of product knowledge.


The primary disadvantage of this model is the excessive need for communication. When the development and testing teams are co-located, there are more avenues for face-to-face interaction and communication. In addition to enhancing team work, such interaction leads to speedier resolution of issues and hence a better throughput.

The final variation in the case of global teams is the concept of creating testing

competency centers by designating a particular location for testing. This is very similar to the dedicated testing team model discussed above. The added advantage that geographic distribution brings about is the exploitation of time difference. Prod- ucts developed during day time in one location can be tested during the subsequent hours in another location, thereby fully exploiting all 24 hours.

Hybrid Models There are various combinations possible from the above basic models. One of them is assigning white box testing to the developers themselves, while the black box testing team is a separate team under the project manager and the integration testing team reports directly to the next level of senior management. The advantage of

296 Managing Global Software Projects this model is that it places sections of the testing organisation as close as possible to the right level in the development organisation. Thus it facilitates early detection of defects at as close as possible to their point of injection.

METRICS FOR TESTI NG PHASE

17.6 The primary purpose of testing is to uncover the presence of defects and thereafter, to feed this information back into the system in an effort to minimise recurrence of the defects. Under this definition, some of the metrics possible and their significance are given in Table 17.1.

Table 17.1 Metrics for the Testing Phase

Metric Significance

Code coverage The greater the code coverage, the fewer are the chances of the existence of untested pieces of code. Hence the chances of deviations from their expected behaviour are also lower.

Number of defects that get caught after the testing phase

The purpose of testing is to detect the presence of defects. Thus post-testing defects indicate possible improvement areas in testing. Also, if problems get detected after the testing phase, then the chances are that the customers are encountering the problems. This adds to the direct and indirect costs (refer Chapter 7)

Rate of re-appearance of problems

Is an indication of the effectiveness of the regression tests. If a particular set of problems keeps re-appearing in different versions, it means that the regression tests have not been

planned properly.

CONCLUSION

As can be seen from the above discussions, testing is an area which provides the project manager with some of the most complex management challenges. After testing, the product goes out to the customers and enters the maintenance phase. This phase is discussed in the next chapter.

REFERENCES

[MYER-79] is a classic on testing, test types, testing methodologies, etc., with specific examples. In particular, the principles of testing covered in Chapter 2 of the above book provide valuable

297 Project Management in the Testing Phase insights from a project management perspective. [HUMP-86] and [PRES-97] provide comprehensive coverage of testing fro~ both the engineering and management perspective. [DEMA-87] contains interesting anecdotal information about testing (e.g., "the Black Team")

We discussed test automation in the text. The Silk set of products from Segue (www.segue.com). Load Runner and other products from Mercury (www.mercuryinteractive.com). Visual Test Suite by Rational (www.rational.com) are some of the examples of popular test automation tools.

PROBLEMS/QUESTIONS 1. Throughout this chapter, we have only discussed testing of code. How do some of

these principles apply to testing other kinds of deliverables in a product, e.g., external documentation?

2. What is the earliest point in time in a project when the test specification activity can start? Does the answer depend on the type of tests being specified?

3. Discuss some of the differences in the profiles and skill sets of test engineers versus development engineers

4. In the text, we discussed the similarities between test development and code development. Point out some of the differences between the two activities. Also point out the differences in skill for the two functions.

5. Take the standard method of opening a file through the "File" menu on your favourite word processor. How many different ways are there to choose the file to be opened? Be sure to take into account the mouse, keyboard short cuts, etc.

6. Assume that the multiple ways of opening a file in a word processor are also applicable to your favourite spreadsheet program that you are developing. How would you structure the testing team and the test specifications in this case?

7. Assume that you have to test a CUI product. Your organisation cannot afford a CUI test automation tool. What kind of challenges can you expect? What kind of skill sets would you require to form your testing team?

8. What kind of misconceptions deter people from joining a testing job? How would you combat such misconceptions?

9. The following defects were found in a product. Identify which type of testing would have uncovered the defects?

(a) The product is a set of APIs. New versions of the APIs are supposed not to break existing programs using the existing APIs. A particular version caused some existing programs to fail.

(b) A defect carne up in Release 4.3 of a product, got fixed in Release 4.4 but resurfaced in Release 4.5

298 Managing Global Software Projects (c) A database is designed to support 40 fields per file. The program breaks when presented with a 35 field file. (d) A field is supposed to accept only numeric values. When a non-numeric data was entered, the entire system crashed. (e) The user followed the instructions in the Installation manual exactly but the product did not install properly.

10. What type of defects would not get uncovered by testing? How would you minimise the chances of such defects creeping into the product?

11. Assuming testing as a process, (a) What completion criteria would you use to put to end the testing phase of a product? (b) What quality records are appropriate for the testing process? (c) Would the answer to the above two questions differ for different types of tests discussed in the text?

12. The literature on testing distinguishes two types of coverage-code coverage and path coverage. For example, in the following IF- THEN-ELSE code segment, test

data that exercises the THEN part would have a code coverage of 90% but a path coverage of 50%. The idea is that the THEN and the ELSE paths are considered the logical units that would get exercised as individual units. Discuss the merits and demerits of such path coverage metrics. if <Cond-1>

Stmtl; Stmt2; Stmt3; Stmt4; Stmt5; Stmt6; Stmt7; Stmt8; Stmt9; else Stmt10;

Chapter – 18

Project Managementinthe Maintenance Phase

"The FAA required commercial carriers to keep extraordinarily detailed maintenance records .... All this paperwork meant that every one of the aircraft's million parts could be traced back to its origin. "

• Micheal Crichton in "Air Frame"

Activities - Management issues - Configuration management-Skill sets for people- Estimating size, effort and people-Advantages of using geographically distributed teams-Metrics

INTRODUCTION

18.0 The maintenance phase for any given version of the product starts after that version is released to the market. When the product is released to the market and the customers start using it, it is possible (and even to be expected) that they would find its behaviour different from what they had originally anticipated. The customer's expectations with regard to the product behaviour can be based on his own perceptions or can arise from the actual defects in the product in that it does not meet the stated requirements. When such discrepancies are observed, customers would start asking for changes to the product so that the observed behaviour matches the expected behaviour.

The maintenance phase deals with the process of evaluating the customer's product change request; ascertaining its applicability; making the necessary changes to the product; testing that the requested change is implemented and that no existing functionality regresses; and finally, delivering the change to the affected user(s). The changes that are made are to remove any defects in the product and to make it comply fully with the requirements initially targeted.


The maintenance phase precedes the Obsolescence phase, during which the prod-

uct is completely "de-supported", i.e., no fixes are provided. Normally, after product obsolescence, customers migrate to the next version of the product.

ACTIVITIES DURING THE MAINTENANCE PHASE

18.1 The maintenance phase activities comprise the following major activities: • Problem reporting

Problem resolution Solution distribution Proactive defect prevention

Central to all the above activities is a Problem Repository. The problem repository is a database that contains all the information about all the problems that were encountered or reported. Each problem record in the repository is identified by a unique identifier. Some of the salient points stored about each problem include: the customer who reported the problem; the platform and environment under which the problem arises; the specific version number of the product(s); a detailed description of the problem; a test case to reproduce the problem (and to test the fix); some information on the root cause of the problem; the fixes made and the location from where the fixes can be taken. Not all the information gets filled at the same time; for example, the fix information gets updated after the fix is made. Also, not all the information is accessible to everyone. For example, the specific details of what was fixed should not be made available to anyone outside of the development team.

In the following sections, we will go into details of what happens during each of the above activities.

Problem Reporting

Once a product' is released in the market-place, customers start using it. When they encounter some difference between the product behaviour and their understanding of what the behaviour of the product should have been, they perceive this as a problem. They then seek to get this problem resolved. Figure 18.1 gives the process flow during this stage.

________________________________

1 Throughout this discussion, we are using the word "product": what is actually implied is "a given version of product".

The first step is to apprise the organisation (that supplied the product) of the problem. The customer contacts the supplier (the organisation that developed/ supplied the software product). Such a contact (called the Support Call) is usually on the phone. It can also be through an email or the Internet. Normally, each organisation has a separate Customer Support Group / Call Center (that is different from the Product Development group) chartered to take these incoming calls and be the first point of contact for the customers. The objective of this initial contact is gathering preliminary information to help solve the customer's problem. During the initial conversation, a Support Analyst (i.e., a member of the customer support group) talks to the customer. He first ascertains that the caller or the customer is authorised to make the call-for example, does he have a valid license for the product, is he an authorised person in the organisation, etc. He then tries to get as much information on the problem as possible. Some specific questions he could ask are: What is the product that is giving the problem? What is the environment (e.g., hardware/ software platform)?


What was the scenario under which the problem showed up? That is, a description of what the customer was doing when he encountered the problem.

Is the problem consistent and reproducible at will or is it sporadic / seemingly random?

The support analyst uses this information to gauge whether the problem that the user is encountering is indeed a real problem or a misunderstanding on the part of the user as to how the product should work. If the problem turns out to be a user error, the support analyst informs the user of the corrective action needed on the user's part. He also updates the problem repository with the information about the problem that was reported and the solution given. Over time, the number of such user error call closures should be analysed by the management. It is likely to point to some unclear documentation or perhaps a need for a change in the product behaviour. (See the following section on Proactive Defect Prevention.)

If the support analyst is not convinced that the problem is a user error (or if he is not able to convince the user that this is not a user error), then this could point to a likely defect in the product. The next thing that the support analyst does is to see if this kind of a problem has been encountered before. For this, he accesses the problem repository. If he finds that a similar problem has been reported and if a fix is available, he initiates the process of solution distribution (described in in subsequent sections) to ensure that the customer gets the fix. If the problem is known but has no fix (i.e., a Known Problem), then he advises the customer accordingly and provides any workaround that is possible. The Problem repository is updated with the information about the customer reporting this problem. This update is necessary to prioritise the fixing of these known problems.

If a problem with the current symptoms has not been reported earlier in the problem repository, then it is a new problem. The support analyst next evaluates the criticality of the problem, which is determined by the impact that the problem has on the customer's business. Not all problems are equally critical. For example, a problem that completely stalls the invoicing from a company is obviously a show stopper, while a problem of improper field alignment in a report is not that serious. The support analyst creates a new problem record in the problem repository and lets the customer know a reference number (typically the identifier of the problem from the repository). Along with all the other details of the problem repository, the criticality of the problem (also called the severity or priority) is also recorded. This acts as a major input in enabling prioritisation of problems which need to be fixed first.

Fig. 18.2 Activities in problem resolution

At this stage, it is clear that the problem is a new one that currently does not have a fix. Now the action shifts to the product development organisation. Here, the problem is looked into, the root cause located and a fix is provided. In order to do this, the development organisation takes the following action:

1. Analyses the problem to understand the criticality of the impact. The development organisation needs some way to prioritise the incoming problems and decide which ones to work on first and which ones to defer. One of the factors that is used in this decision making is the impact of the problem, characterised by the problem criticality entered by the support analyst. Typically, problems which are show stoppers are the ones that take precedence.

2. Assigns a particular developer as single point of responsibility to track the progress of resolution.


3. The assigned developer tries to reproduce the problem as per the description in the problem repository or by using the test cases supplied. The first step in problem reproduction is to reproduce the exact environment under which the customer reported his problem.

4. If the problem can be reproduced in the development environment, then the developer does the following:

analyses the root cause of the problem and maps this to the exact source files that need to be changed.

tries making the changes, checks if the reported problem is fixed, and that nothing else is broken

follows the necessary processes needed to formally effect this change into the configuration management system (as discussed in Chapter 6). These cover change a:uthorisation, review, execution, test, re-baselining, etc.

5. If the problem cannot be reproduced in the development environment, then the developer works with the support analyst (and the customer, if necessary) to resolve the situation. Some of the possible techniques that can be used are:

Walking the customer through the problem scenario over the phone and providing diagnostic information

Dialing into the customer site and running the diagnostics remotely Visiting the customer site and running the diagnostics on site 6. The problem repository is kept current and up-to-date on the status of the

problem and any issues thereof.

At this stage, the product development organisation has identified what the problem is, has made the fix to the source code and re-built the product. The fix is ready to be distributed to the affected customer(s). That takes us to the solution distribution activity.

Solution Distribution

When should the fix be sent to the customer? Should it be sent as soon as it is made and the product re-built? The answer to this question depends on the severity of the problem. If the problem is a show stopper for the customer, then it would make sense for the fix to be disseminated immediately. If it is not a show stopper, then such immediate dissemination may not be of advantage either to the customer or the supplier. From the customer's point of view, installing fixes for minor problems one at a time is more time consuming than accumulating multiple minor fixes and installing them in one go. From the product development organisation's perspec-

305 Project Managementinthe Maintenance Phase tive, distributing multiple small fixes not only cuts into the resources but also introduces multiple configurations to support.

In order to minimise the problem of distributing multiple fixes and keeping track of multiple customer configurations, a common practice is to accumulate multiple fixes into a patch for an intermediate release. Such intermediate releases are often scheduled at a pre-defined frequency. These releases are usually cumulative, i.e., the fixes made in one release are available in future releases as well.

Regardless of which mode of distribution is chosen, the problem repository is updated with information about when and how the fix would be available for use by customers. The support analyst(s) who interact with the customers, (who reported the problem) are intimated of the fix so that this information is passed on to the customers.

Another question that comes up with regard to fix distribution is whether the customer who reported the problem should be the only one to get the fix or should the other customers, who are likely to encounter the same problem, also get the fix? The answer to this again depends upon the severity of the problem. If the problem is very severe and there is a high likelihood of other customers being affected by it, then it makes sense to distribute the fix pro-actively to those customers as well.

Proactive Defect Prevention

So far, we have seen the reactive maintenance- i.e., carrying out maintenance to fix problems after the problems surface. The information about the problem occurrences that is collected in the problem repository can also be used effectively for pro-active defect prevention. When such defect prevention activities are undertaken, the load on the maintenance team decreases and this freed bandwidth can be used for developing new products and features that increase the revenue generating possibilities for the organisation. Some of the ways of achieving this defect prevention are:

Analysing common user errors and updating documentation as necessary: When a number of defects get classified as user errors, it is likely that the product documentation is not very clear. A relatively higher number for such occurrences of user errors should trigger an examination of all the documentation associated with the product-the manuals as well as anyon-line help-to ensure that any misleading or ambiguous statements are cleared.

306 Managing Global Software Projects Analysing common user errors and changing the product as necessary: When a number of defects get classified as user errors, it is also possible that it is not the documentation that is unclear but the initial understanding of the product requirements is unclear. A relatively higher number for such occurrences of user errors could necssitate the changing of the designed behaviour of the product to match its expected behaviour as anticipated by the user.

Publishing common user errors and work-arounds on a bulletin board or a web site: When a user encounters an error, he can look up this bulletin board or the web site and correct his error immediately. This would save the customer the time to call the support analyst and having to relate his problem. This self service model would also save the organisation costs associated with support.

Performing root cause analysis of problem areas and cleaning up the code of such areas: When problems keep coming up repeatedly up the same areas, it is indicative of a "spaghetti code" caused by periodic maintenance by different people. When more than a threshold number of bugs are fixed on a given part of the product, it may be advisable to take another look at the entire code (or even design) of that part and re-write or re-architect it. Beefing up regression tests with tests for critical/oft-appearing bugs: When certain areas are identified as defect prone, it would be a good idea to subject them to more extensive regression tests. By incorporating the reproducible test cases of com- -monly occurring bugs or high impact bugs into regression tests, these problems are caught in-house rather than by external customers.

MANAGEMENT ISSUES DURING THE MAINTENANCE PHASE

18.2 The above work-flow is an over-simplified description of how a problem proceeds from the problem identification stage to its resolution stage. Nevertheless, it captures all the major sub-phases in the maintenance phase. In this section, we discuss some of the common practical management issues that are encountered during the maintenance phase.

Incomplete information from the customers: When a problem is reported by customers, it is possible that not all the complete or relevant information is supplied to diagnose the problem. This is especially true if the caller is an end user and not necessarily technology savvy. Problem reports like "the system died on me" or "the system is so s ... lllll .... ooo .. w!" are generally the ways the customers/users vent

307 Project Managementinthe Maintenance Phase their frustrations. The support analyst should use his soft skills to skim the emo- tions and get to the root of the problem. One of the most effective ways to achieve this is to use a checklist of minimum information that is required to be gathered from a customer. A sample of such a cheklist is given below. SAMPLE CHECKLIST OF INFORMATION TO BE GATHERED FOR PROBLEM ANALYSIS Product (s) used:

Version Number (s):

Hardware Details

RAM

Disk space:

Drivers/Devices:

Software environment Details:

OS/Verstion

Any supporting software version (database, application, etc.)

Network drivers and similar software

Problem Description:

Is the problem reproducible?

During the problem occurrence what other software is running?

How critical is the problem?: For any customer, his problem is very important and urgent! Even if it were just a formatting error on a report, the customer may be justifiably agitated by any discrepancies. But to be fair to all the customers, problems that have very serious business impact should be fixed with a higher sense of urgency than the problems that have a cosmetic or peripheral impact. Hence an objective prioritisation of incoming problems is needed. If a software system is not operational then it takes the highest priority. Problems with somewhat messy work- arounds and those with reasonable work-arounds assume reducing priorities.

Problems that do not reproduce: It is not uncommon for a problem to corne up sporadically (or even consistently) at a customer's site but does not happen at all in a development environment. Some of the problems may show up only with large loads or system sizes or when a combination of third party products work together. It may not always be feasible to recreate the same environment at a development

308 Managing Global Software Projects site. Some of the possible ways to overcome this hurdle are to dial into the customer's system or to send development staff to the customer site for some on-site diagnostics. Whose problem is it?: Most of today's software is componentized, i.e., when a software product is running, different people own different parts of the code. Some of the parts (or components) are likely to be owned by different groups of an organisation and you may also be invoking the services of products from a different company (a classic example of this is that most software products end up calling operating system services). In such a componentized world, how do you ascertain whose problem it is and who needs to change what? Should a component that provides a service be changed or should a client using the services be changed? If the change is required from a third party company, whose responsibility is it to ensure that the customer's problem eventually gets fixed? These are some of the questions to which there are no easy answers.

Who gets the fixes?: If a problem is reported by a customer, should he be' the only one to get the fix or should the fix be distributed pro-actively to all the customers? This question requires the development organisation to visualise the customers' scenario for any likelihood of the problem becoming widespread. If so, they should seriously consider ensuring that other customers are aware of the problem/ fix.

How to distribute the fixes?: There can be two different models for fix distribution-one, a "push model", wherein the development organisation pushes the fixes to the customers, i.e., the customers get the software distribution without their explicitly asking for the specific fixes. Such a distribution can be on a physical ~edium like a CD or through email or Internet. In the "Pull model", the fixes for all the problems lie in a repository (typically a web site) and the customers pull the fixes they want based on the symptoms/problems that they encounter.

Developers unwilling to do maintenance: Maintenance is probably second only to testing on areas that people do not want to work in! The reason for this reluctance is that engineers generally (and wrongly) believe that designing and developing new software demands more originality and creativity than "changing someone else's code". Some of the solutions to this problem include job rotation and giving complete ownership of maintaining and enhancing components to a team. The former approach gives some variety to employees and the latter makes them completely responsible for a given component and motivates them to produce defect-free and quality components upfront so that they do not have to spend more time on maintenance.

309 Project Managementinthe Maintenance Phase Balancing maintenance with new development: Whether an organisation has different groups for development and maintenance or the work is multiplexed by the same group, the fact remains that the more time that goes into maintenance, the lesser are the cycles available in writing new products or new features. It is not possible to ignore maintenance workbecause timely bug fixes are a necessary condition to keep the customer loyalty. At the same time, maintenance is usually not revenue generating. This requires some judicious and delicate balance of resources. By having metrics on the periodicity of occurrence of problems and the customer's expectations on acceptable time frame norms for getting the fixes, it is possible to estimate the resources needed for maintenance. Once these resources are allocated, there should be a conscious attempt to reduce them without compromising on quality and customer satisfaction. The cardinal rule for achieving this is, "prevention is better than cure" and evolving processes to minimise the occurrence of defects in the first place.

Regressions and chain maintenance: While maintenance is not directly revenue generating, having to fix the same problem multiple times repeatedly is even worse. It is extremely important that when problems are fixed, the previous problems do not re-surface. The key to achieving this is to use effective configuration management. Some of the SCM issues that are particularly applicable to the maintenance phase are discussed in the next section.

CONFIGURATION MANAGEMENT DURING THE MAINTENANCE PHASE

18.3 During the initial development phase, the only users of the products are the developers themselves. Thus, there is almost a direct a mapping between the changes made to the source files and the final products or programs. The problem becomes more complex once the product is released and customers start using it, some of the reasons being:

Customer's environment is not directly under the control of the development organisation: The customer might have customised the program or the screens to suit his needs. He may have deleted or changed some files that could potentially affect the behaviour of the product. Furthermore, he may be using different environment software (e.g., operating system) or a different hardware configuration. Thus during the maintenance phase, one may have to detect problems in an environment that does not necessarily conform to the configuration management procedures of the development organisation.


Fixes have some inherent dependencies: Each fix may have co-requisite fixes (i.e., a set of fixes must be installed together as one unit) and pre-requisite fixes (i.e., those fixes that must be installed before the current fix can be applied). It is important that the tool to install the fixes at the customer site support these mechanisms.

A way to identify the configuration in a customer site: As each customer may have installed fixes on a selective basis, it is important to be able to get immediate information as to what fixes are installed at the customer site. This information is necessary to detect co-requisite / pre-requisite fixes at the customer site as well as to reproduce the proper environment at the development site to reproduce any problems.

Mapping the customer environment to source environment: Customers have executable files whereas the fixes on the source files are made by the developers. The configuration of the source files is controlled by the SCM system at the development organisation whereas the executables at the customer site are not under this system.i Somehow, the SCM system should allow some kind of footprints to trace the genesis of an executable file to its component sources. It is in this context that the principles of Design for Diagnosability and Maintainability discussed earlier in the book became very significant.

Regression testing for fixes: The SCM system at the development site includes not only the source files but also the test cases and test results of the product. When a fix is made, it is important to do at least three things: First, to design a test case to test the occurrence of the problem and than to test that the fix does indeed address the problem. Second, re-baseline the changes by checking in the changes made to accomplish the fixes. Third, update the configuration repository and the test running procedures to include a new test to test the new fix. This will ensure that the bug does not regress again (i.e., it does not re-appear, or if it does re-appear, it should get caught).

SKILL SETS FOR PEOPLE IN THE MAINTENANCE PHASE

18.4 We had introduced a new role of the Support Analyst while describing the activities in the maintenance phase. The support analyst (also called the Customer Support Representative) is the customer's interface to getting the problems reported and resolved. Why can't the developers be

______________________________________

2 Some of the operating systems allow direct change of the executable without changing source files and remaking the executable files by the standard compile-link procedures. Such direct changes make the issue even more complex.

311 Project Managementinthe Maintenance Phase

the first point of contact for customers to get their problems resolved? There are several reasons: The developers have priorities of developing new products / versions and

hence may not be available to give uninterrupted attention to the customers when the customers initially call.

The customers call only when they have a problem. As the developers own the product code, there is a possibility that there may be a bias in looking at the problem that the customer reports.

The primary strength a developer needs to have is understanding the innards of development; but when talking to customers, (especially those encountering problems), what is required is good communication-the ability to objectively talk to an angry customer, without taking personal affront or a defensive attitude.

Given all these factors, there are certain key skill sets one should look for in support analysts:

Strong understanding of the product external functionality Good communication abilities to talk to the customer and get specific details Ability to take a balanced, objective view of the problem: both from the

customer's viewpoint and from the product viewpoint Ability to identify patterns and abstract test cases out of the customer's

problem descriptions Good follow-through attitude, making sure that everybody is kept in sync.

As can be inferred from the above, it is obvious that for a support analyst, focus on soft skills is vital to job success. .

The development staff performing maintenance functions, face the added chal-

lenge of (almost always) having to understand somebody else's code. Also, while normal product development works according to a pre-defined plan, maintenance is a reactive activity. It is not easy to predict when the problems will come up. Hence the maintenance engineer may be subjected to a more unpredictable workload. The ability to be flexible and to respond quickly to situations becomes vital to success.

ESTIMATING SIZE, EFFORT, AND PEOPLE RESOURCES FOR THE MAINTENANCE PHASE 18.5 In most other phases of product development, there is a reasonable correlation between size, effort, and schedule estimates. In case of the maintenance phase, however, the correlation between the three is not predictable.


To cite an example, suppose a very tricky, non-reproducible bug is reported by the customer. The development organisation may have to spend a lot of effort in trying to debug the problem. Such an effort could include travel to customer locations, multiple attempts to reproduce the problem, and long hours of debugging using multiple diagnostic tools. But at the end of it all, the fix may turn out to be just a one line fix. Even though the size of the eventual fix is small, the effort put in is disproportionate. Going one step further, unlike in development activities where there are possibilities for parallelism and thus minimising the time, maintenance often tends to be a single- threaded activity. This means that for a small sized fix, the schedule for getting the fix completed could be much more extended as compared to what would normally have been the case in development activity.

In addition, as we discussed at the end of the last section, maintenance is a reactive activity. The work-load is not pre-planned. Also, the work-load would not be distributed in a controlled manner. There would be periods when it would be extremely high and there would be lean periods. Also, it is not easy to predict when the work-load would be high or low. Thus, in the maintenance phase, the key questions are not how do we estimate size, effort and schedule but:

how do we predict the inflow of work? how do we then estimate the staffing resources?

I There are several factors that can be taken into consideration for answering the above two questions:

Historical data on the arrival and resolution rates of bugs: The problem repository captures all information about the frequency with which the problems (bugs) arrive and the time it takes for the problems to get fixed. Let us illustrate this with an example. Suppose on an average, 100 bugs are reported over a month and each bug, on an average, takes 2 person days to resolve; there would be an overall effort of 200 person days. Thus, we should at least plan for having 200 person days of bandwidth available in the maintenance team.

Customer expectations: There may be customer expectations on Service Levels- for example, there may be a mandate that mission-critical problems be fixed within a day. By analysing historical data, one may be able to see patterns in problem- prone areas and provide resources to ensure that mission-critical problems in these areas are covered.

Seasonal variations: There are usually more bugs reported during certain months than they are in the other months. For example, the end of the year statutory reports

313 Project Managementinthe Maintenance Phase get run only during a particular month, when the part of the product in question gets exercised. Hence, the problems in a particular area, if any, will show up only during that month. Another example: ecommerce sites have a very high traffic during the Christmas season and the support organisation must be geared up to meet this increased workload. Even though these problems may come up only once a year, when they do, they are of the mission-critical. Thus one would have to make sure that notwithstanding the average problem arrival/resolution rates, resources are provided to satisfactorily handle these seasonal variations.

Release schedules: It is often the case that the number of problems reported in a' product is high soon after a new product version is released and as the product stabilises and the problems get fixed, the inflow of bugs reduces. It is also possible that during the early stages of a product usage by the customers, the type of problems that may come up are less predictable. Because of all these factors, the maintenance load can be expected to be high during the period immediately following a release.

ADVANTAGES OF USING GEOGRAPHICAllY DISTRIBUTED TEAMS FOR THE MAINTENANCE PHASE

18.6 For mission-critical problems, round the clock coverage would be required. This is where global teams would be very valuable. One can staff up teams in different geographic locations and make use of the time difference to distribute the workload so as to ease the pressure on engineers. For example, if a part of the team is in the US and part in India, the US engineers can work on a problem during the day and if the problem is not resolved at the end of their day, they can pass it to an engineer in India where the work day has just started. For this method to be successful, one would obviously have to take into consideration the accountability factor and would also need a very well defined communication model between the teams.

METRICS FOR THE MAINTENANCE PHASE

18.7 The primary goals of the maintenance phase are: minimising the impact of problems on customers while at the same time balancing the maintenance workload with the development of new features and products. Some of the metrics to this end, and their significance is given as follows.


Table 18.1 Metrics for the Maintenance Phase

Metric Significance Arrival rate of problems (also measured by Mean Time Between Failures)

If the arrival rate of problems is high, this points to inherent instability in the quality of the design, development and testing processes.

Percentage of problems classified as not a problem

A higher percentage indicates unclear or inaccurate documentation. A better control of documentation could reduce the unnecessary call overheads. A higher percentage could also indicate that the requirements were not captured properly.

Problem occurrence classified by area, product or platform

Performing this classification identifies high risk development areas. For example, if you were to find that in an operating system development project, more bugs are filed in the communications module than in the other modules like file systems, it may point to the need for deploying additional resources or changing the processes or algorithms used in the communications module.

Problem occurrence classified by the severity of the impact

If a majority of the problems reported are of the high impact category, it either means that the product is completely unusable or the method of classification / prioritisation is not appropriate The corrective action could either be the complete overhaul of the development and testing process / tools (if the prognosis is indeed that the problems are high impact) or a more objective categorisation of the incoming problems based on impact

Mean Time To Repair, i.e., average time taken to fix a problem

This is an indication of the effectiveness of implementation. Alacrity in this step usually indicates responsiveness in execution.

Number of times that we needed to go back to the customer with requests for more information and the amount of time this interaction took

This is an indication of completeness of information given by the customer and also an indication of how comprehensive the problem information gathering process is. If it is found that there is a lot of going back-and-forth to the customer, it would be worthwhile to devise checklists detailing the kind of information that must be captured for each problem type. A similar situation applies to third party problems as well.

Amount of time spent on the problem getting shuttled among internal groups

In a component based development model, where different parts of an organisation work on a product, the customer must see one face of the organisation. Too much of internal re-assignments would cause loss of credibility with the customer

Rate of re-appearance of problems

This is an indication of the effectiveness of the configuration management and the regression testing mechanisms.

315 Project Managementinthe Maintenance Phase

CONCLUSION

This concludes all the in-stream activities in project management. In the next part, we will take up some of the emerging trends in project management.

PROBLEMS/QUESTIONS 1. Assume that you have a small number of staff supporting maintenance functions and

new development functions. How would you schedule and prioritise the work among the staff?

2. Compare and contrast the skill sets for people performing functions of design/ development, maintenance and testing

3. In the text, we have made a reference to a problem repository. Propose a possible schema for this repository to address the types of functions that we have described in the text.

4. Discuss some of the challenges that can be expected in reproducing a problem at the development site. From a project management perspective, how would you tackle a situation where a problem occurs intermittently and cannot be reproduced at will?

5. In the text, we discussed two types of mechanisms to distribute fixes to the customers. One is to distribute individual fixes and the other to accumulate multiple fixes into patches and distribute the patches on a periodic basis. Discuss the pros and cons of each of these approaches.

6. One of the issues we have not addressed in the text is that of the training needed for the support analysts. When should the support analysts be trained on the product? What kind of training should be imparted to them?

7. Answer the above question for people doing maintenance, assuming that maintenance is done by a group that is separate from the group that actually developed the product.

8. Discuss what interfaces and organisational information exchange should take place between the testing team, development' team, support team and the maintenance team to reduce the defects in the product.

9. An organisation prioritises incoming bugs as 1/2/3/4-1 being the most severe and 4 the least severe-from the point of view of impact on the customer. It is also usually the case that the priority 3 or priority 4 bugs are easier to locate/ fix than priority 1 or priority 2 bugs. Bug reports for a particular month showed the following details. What do you infer from this data? What corrections does the organisation need? In this context, what would be the metrics that you would suggest for the bug fixing activity?


Bug # Priority Filed Date Date Started Diagnosis Date given a fix

123 4 1 Mar 2001 5 Mar 2001 6 Mar 2001 124 2 2 Mar 2001 4 Mar 2001 8 Mar 2001 125 3 2 Mar 2001 2 Mar 2001 3 Mar 2001 126 1 2 Mar 2001 4 Mar 2001 7 Mar 2001 127 1 4 Mar 2001 4 Mar 2001 8 May 2001 128 3 4 Mar 2001 4 Mar 2001 5 Mar 2001 129 4 10 Mar 2001 10 Mar 2001 11 Mar 2001 130 2 10 Mar 2001 14 Mar 2001 16 Mar 2001 131 3 12 Mar 2001 12 Mar 2001 15 Mar 2001

Emerging Trends

Part V

Chapter - 19

Globalisation Issues in Project

Management

“There will be two kinds of CEOs who will exist in the next five years: those who think globally and those who are unemployed."

Peter Drucker

Evolution of globalisation - Challenges in building global teams - Models for the execution of global projects-Some effective management techniques

EVOLUTION OF GLOBAlISATION

19.0 Throughout the book, we have been discussing details of how we actually manage global teams in the context of specific activities like SCM, project tracking, etc. In this chapter, we will look at how globalisation has evolved over the years and some of the common challenges in managing geographically distributed (global) software project teams. We also look at some of the models and techniques that have been proven effective in combating such challenges.

Just a step back in history; the software industry has always had an element of globalisation for well over three decades. This is because of the acute shortage of talent that is required for the industry. Countries like India have been significant players in this field since a long time. We can see the global distribution of software industry go through four distinct phases:

Purely local: In the early days-perhaps till about the mid seventies-the action was primarily where the markets were. The dominant markets were in the US and Europe (and to a lesser extent, in Japan). Software was still a "geek" profession- very niche, very specialised. In fact very few universities / schools even in US had a dedicated "Computer Science Department". The "computers" curriculum in most

320 Managing Global Software Projects other countries was primarily theoretical. Added to that, the cost and maintenance overheads of the large systems of those days made it extremely difficult, if not impossible, for most countries to afford these computers to provide practical hands-on training experience. Also, "software projects" as a concept was very rare: large "software projects" were mostly done as a part of hardware vendors offering their boxes.

Because of all these factors, software project teams were normally confined to a single location. Also, because of the paucity of trained manpower in many countries, software remained an industry which had very few players.

Global, on-shore: During the mid to late seventies, the need for competent software professionals started exploding. This was because of the heavy application backlog that resulted from hard-to-use, complex software environments and languages that made software development and maintenance unwieldy and time consuming. The quality of training and availability of software professionals in countries like India improved during this time. The strategy adopted for keeping the application backlog under control during this time was to get people on-shore. A set of people who were trained in the basics of programming and software were moved from other countries to the location of the project. They underwent any required project-specific training, were made a part of the project team and worked at the site of the project itself.

Global, off-shore: During the eighties, development environments like Relational Database Management Systems, Fourth Generation Languages and easy to use software tools became available. At the same time, with the advent of inexpensive PCs and Unix servers, hardware became affordable - both from the cost and the maintenance perspective - in many countries This meant that it was no longer necessary to go through the expensive process of locating all the staff where the project was located. So the model evolved to one of off-shore development. Typically, some senior level people spent some time at the customer location (where the project was to be eventually deployed), understood the requirements, scoped and partitioned the work and moved the actual development of some logical and fairly independent portions of work to other locations where trained manpower was available and the costs were lower. The key to the success of this model rested on the possibility of the work getting partitioned into independent units and in minimising the need for communication between these partitioned units.

Global, distributed: The reduced hardware costs enabled transition to Global, off- shore model. But it was increasingly difficult to separate the project into watertight compartments or independent units. Communication and the costs of integration of systems that were developed by multiple distributed teams increased. The main factor that propelled software development to the next level of "Global, Distrib-

321 Globalisation Issues in Project Management uted" was the improved communication technology and the advent of the Internet. Suddenly, the physical location of the team hardly mattered. With the Internet, everyone was as good as being next door! Communication costs came down; changes made by one team were made instantly available across the globe and hence integration defects were either avoided or detected early. The virtual, distributed global teams became truly viable.

Table 19.1 summa rises the key aspects of the various stages of evolution of global teams

Our discussions in the rest of this chapter would be focused on the "Global, distributed" model.

Table 19.1 Evolution of the Global Teams Model Approximate

Period Major features Success

enablers Driversto move to next levels

Purely local <mid seventies • Most activity confined only to a few countries • Trained people and projects co-located

• The only choice available then! • Did not provide

enough opportunities for creation of talent pools across the globe • Application backlog

Global, on site mid-seven-ties to mid-eighties

• Participation by people from multiple countries but all work on site • Exploits availabi-lity of (semi-) trained manpower from across the globe

• Sourcing and utilising talent from multiple countries

Still based on hard- to-use environments, not allevi- ating huge application backlogs

Increased travel costs

Governmental issues (e.g. visas)

Global off-shore mid-eighties to

mid- nineties Initial work

partitioning done onsite

Subsequent "nuts and bolts" development work done in multiple locations across the globe

Availability of productivity software and inexpensive hardware

Lower travel costs

Exploits the cost advantages of different countries

Work partitioning issues

Increased human communication needs

(Contd.)


Model Approximate Period

Major features Success enablers

Driversto move to next levels

Global, distributed

Mid nineties and beyond

Virtual teams across the globe

Teams across the globe work as a single team with different possible work allocation/ management structures technologies

Exploiting time zone differences to increase throughput

Utilising talent pool from across the globe

Availability of enabling Internet technology

Increased expectations from customers!

Communication Bandwidth

CHALLENGES IN BUILDING GLOBAL TEAMS 19.1 Building and running a team that is geographically distributed presents some very interesting and formidable challenges. Some of these are: Cultural differences: Each country has its own cultural practices and heritage. What is considered the norm in one country can be a strange practice (or sometimes even taboo) in other countries. To understand such cultural idiosyncrasies, travel by key team members to different locations would help. With the advent of the Internet, a significant part of these cultural issues of different countries are available on popular country-specific portals. The teams would benefit by making an extra effort to understand the cultural issues. Communication issues: As discussed earlier in this book, geographically distributed teams are at a serious disadvantage as they do not often get the opportunity for face-to-face communication. Hence they lose out on a significant amount of communication that takes place through non-verbal means-this includes gestures, eye contact, voice modulation, etc. With the absence of such reinforcing channels, communication is heavily dependent on the written channels-like emails. Because of the difference in usage of language in different countries, the written word might not convey the true intent of the sender of the message. Hence it is important to plan for opportunities for travel, video or audio conferencing, so that the different teams can build a rapport. Time zone issues: As we discussed in the maintenance phase; the time difference between different locations can be an advantage as well as a disadvantage. It can be

323 Globalisation Issues in Project Management an advantage because the work can be passed on "with the sun". For instance, when a problem or a bug is being worked on during the daytime in the US and is not resolved by the end of the business day, it can be passed on to competent staff in India (whose business day starts at that time). But the flip side in this case is that when one team wants to communicate with the other team, there are strong chances of either side being woken up from sleep at unearthly hours! Hiring and retention: Globalisation has spread an awareness among people with regard to the compensation levels in various countries. The buying power of all the currencies is not the same. In addition, the saving potential in different countries also varies. Because of these differences in the economies and currencies, people are always looking for relocation to countries with stronger currencies and better sav- ings potential. Two other factors make this global marketplace for jobs more threat- ening for organisations from the point of view of hiring and retention. Firstly, there is a global shortage of trained manpower. Hence these trained people are in demand everywhere all the time. Furthermore, when the teams in different geographi- callocations are working on the same (or similar) work content, the location with better economy and opportunities stands at an advantage in terms of attracting not only trained people but also people who have worked on almost exactly the same type of projects elsewhere. Issues of compensation and equity have to be addressed to improve hiring and retention in other locations. Training: In most cases, it is very likely that the experts who can offer training are confined to one location. It is important to make sure that this expertise is made available in other locations as well. Unless the people in all the locations are given consistently high quality training, they are not likely to produce consistent quality of work. One of the ways of accomplishing high quality training includes institu- tionalising a train the trainer program wherein the expert gives an extensive and thorough training to other trainers. Another way to make sure that all the locations get the same high quality training is to use e-Learning (covered in the next chapter).

MODELS FOR THE EXECUTION OF GLOBAL PROJECTS 19.2 Because of the various challenges described above, it is very important to understand the different types of models under which the global project teams operate. We briefly discussed this in Chapter 11 in the context of identifying and allocating work breakdown structure units. In this section, we will go into the details of the three models that are commonly used when executing projects with geographically distributed teams and study the applicability, advantages and disadvantages of each of these models. We have, to some

324 Managing Global Software Projects extent, simplified the discussion below by assuming that there are only two teams / locations. It is easy to use these models for multiple teams /locations as well.

Resource Model

In the Resource Model, one of the teams is identified as the primary team. The primary team directs and allocates work for the other team (called the extended team). The extended team acts as a resource to the primary team. Some of the attributes of this model are:

The primary team dictates all aspects of work allocation The extended team executes the work allocated to them The extended team reports to the primary team The local manager of the extended team is more in charge of the

administrative aspects than the work allocation aspects .

This model enables the primary team to exercise direct control over the project. In highly critical projects, such a control may be very useful and also necessary. The resource model is also very useful in situations where the allocated work units are easy to execute with minimal communication between the primary and extended teams. For example, if the specifications for programs are written rigorously and unambiguously, coding of these programs can be handed over to an extended team. Similarly, the testing of well documented multiple test scenarios can be successfully completed using a resource model.

In this model, it is clear that the two teams are not peers-one has a direct reporting relationship with the other. This could lead to difficulties is establishing a strong bonding between the two teams (especially when the opportunities for communication are less). The resource model is a double edged sword; a danger to watch out for is in the primary team doing micro management of the members of the extended

325 Globalisation Issues in Project Management team. If the primary team does not understand their strengths, restrictions or local conditions, it may end up allocating unreal work allocation units which may in turn jeopardise the success of the project. For example, if the work allocation to individual members of the extended team is done directly by the primary team, it may be difficult to work around realities like vacations, employee sick days, etc. To guard against this micro management of the extended team and to make the job of its local manager a little more value-adding, a slightly different adaptation of the resource model is used. The extended team is considered a resource that would get a chunk of the work done. The responsibility of getting the chunk falls on the shoulders of the local manager of the extended team. He may also do some local work allocation and monitoring in addition to his administrative management responsibilities.

Life Cycle Model

In this model, different teams have specialisation and responsibility in different life cycle phases. For example, the responsibility for finalising requirements may lie with the team which is closest to the customers / market, because the most logical place to do the requirement study is where the major market is. A given location may have developed and established competence in certain key technology areas. So, when opportunities for design / development in these areas corne up, it makes sense to assign this responsibility to locations with established and proven competence.

The primary benefit of this model sterns from the fact that each location is being called upon to do what it is good at doing. This ties in well with the concept of II core competence" that has gained acceptance in the management practice. There is a sense of ownership for each life cycle activity that augurs well for the success of the entire project.


One risk element to watch out for in this model is the tendency of a team to become prisoner of its own success and be straight-jacketed or labelled for a given life cycle activity. The model may make the jobs allocated to each of the teams somewhat-routine and this may come in the way of the various team members' aspirations to learn new things and to acquire expertise in other areas. The second challenge that this model presents, is that there are certain life cycle activities that everyone wants to do (e.g., design) and other activities that people prefer not to do (e.g., testing). But all these activities have to be done-and done well-for the success of the final product. It is important to ensure that the teams that are competent in areas like testing are kept motivated. This brings us to a third model called the Integrated Team Model, discussed below.

Iterrated Team Model

This represents the true "Global, distributed" model. The teams in different locations work in close unison through all the life cycle phases as peers. As a result, they generally gel better, thus overcoming the primary disadvantage of the resource model. Because no team is confined to anyone aspect or a life cycle phase, they get the opportunity to do different kinds of work, thus overcoming the problem of straight-jacketing as the case of the life cycle model. Thus this model seems to be the best of all models.

But there is a price to be paid for this. The teams have to have a good level of understanding to make this model work. The fact that they have to work in close unison leads to an increased demand for better and more frequent communication between them. The success of this model depends upon the different teams being more or less on par with one another in terms of competencies and capabilities.

The situations in which this model would be applicable are when teams have a very good understanding with one another and the skills required are distributed across the locations. This model also calls for a high level of maturity and a disci-

327 Globalisation Issues in Project Management plined and structured way of working. Generally when two teams in different parts of the world start collaborating for the first time, it is recommended that they do not start with this integrated team model. They should start with either the resource model or the life cycle model and make a transition to the integrated team model once they reach a certain level or comfort. In this sense, the integrated team model can be viewed as the highest level of collaboration between the geographically distributed teams. Comparison of the Three Models We conclude the discussion on the three models by drawing a correlation between two important variables-motivation levels and team satisfaction on one hand and the need for well defined processes and communication on the other. The qualitative results are shown in Fig. 19.4.

In the resource model, the process or communication is as simple as the primary team telling the extended team, this is what needs to be done. If the model is applied in the right profile of projects, the need for communication between the

328 Managing Global Software Projects teams is relatively less. Also, as the work units are fairly well defined and well understood, the processes are already laid out and hence the need for extensive processes for co-ordination and work direction is minimal. Generally, in the resource model, the satisfaction levels of the extended team are relatively low because the sense of "ownership" rests with the primary team.

When we move to the life cycle model, the need for communication between the teams increases because each life cycle phase has to get the right inputs from the previous phase (and pass on the right outputs to the next phase). As discussed in Chapter 7 on software quality assurance, it is highly desirable that defects in any phase be detected and corrected in that phase itself instead of being passed on to the subsequent phases. Hence the need for communication and well defined processes increases in the life cycle model.

What happens to team satisfaction in the life cycle model? This depends upon two factors: the phase of the life cycle that a team gets involved in and the frequency with which they participate in that phase. Generally, the up-stream life cycle phases tend to produce higher satisfaction levels of the team because the common perception is that these activities have more uncertainties and hence present more scope for innovation and challenge. If the same phase is covered repeatedly by a team, the satisfaction levels could wane out, even if it happens to be an up-stream phase.

Finally, when we move to the integrated team model, the need for communication is extremely high because there is no clear cut separation between either the life cycle phases or the teams. The need for proper division of work from one location to another is also high as there are no compartments of work between the locations.

Because of the varied work that each team gets to do and its involvement in the entire life cycle, the sense of ownership and bonding increases in this model. This results in greater team satisfaction.

It is important that the teams have a clear understanding of what model they are working on so that their expectations are set right. For example, if a team believes they are working on an integrated team model while in reality the other team is actually viewing this team as a resource, there would b~ conflicts in work allocation and project decisions. This is bound to adversely affect the project outcome.

As a final note, none of the above models are cast in stone exclusively for a project. For the same project, at different points of time, different models may be adopted. One may start off with a resource model and eventually move over to an integrated team model after a good rapport has been established between the teams.

329 Globalisation Issues in Project Management SOME EFFECTIVE MANAGEMENT TECHNIQUES FOR MANAGING GLOBAL TEAMS 19.3 When working on global teams, certain common practices have been found to be effective. The common thread in all the practices is to increase the communication and bonding between the team members and to ensure a sense of fairness and equality across all teams.

Expectation setting and clarity of role: Clarity in spelling out the expectations from the various team members up-front enables them to produce better quality of work. In particular, each team should know whether they are resources or peers to other teams. This will minimise the conflicts as to who should do the work allocation, what type of work should each member do, etc.

Travel opportunities: As stressed often in this book, face-to-face interaction of the key project team members is important during the early part of the project as well as on an ongoing basis. It goes a long way in improving the chances of success of the project. Travel is no doubt an expensive proposition but ensuring that there is a reasonable exchange of personnel across the various geographic locations is essential to the success of the project. Because of the nature of software projects, such travel opportunities present themselves naturally-for example, certain software is illegal to export outside of the US and when there is a need to work on such components, travel is mandated. Similarly, for training or discussions, travel is useful. The management team should budget for and exploit such natural travel opportunities.

Planning periodic communication: When the entire team for a project is co-located in one building, there are ample informal opportunities for communication-like hallway chats, cafeteria chats, etc. Geographically distributed teams do not have this luxury. Hence it is important to plan for establishing avenues of communication on a periodic basis. Conference calls, off-sites and video conferences should happen in a pre-planned and pre-scheduled manner. It is very tempting to plan for communication only when the need to do so is felt, but in a geographically distributed team, such an approach often ends up with too little communication too late and this can result in an adverse impact on the project.

Non-work related outings: The bonding between the teams increases in outings that are not directly related to the actual project work. For example, going on an occasional group picnic, especially when visitors have come from other locations, and some informal sports activity during such outings goes a long way in enhancing the personal bonding between the team members. In addition, when such an

330 Managing Global Software Projects outing is planned with visitors from other locations, it helps them to get a better grasp on the cultural aspects of the host country.

Consistent policies: It is very important to have consistent policies across the teams in different locations. Consistent policies refer to policies of travel and use of infrastructure. For example, if two teams in different locations are working on the same , project, it is important to ensure that they have similar hardware configurations. The travel and related administrative procedures should also be consistently implemented to avoid any feeling of discrimination among the team members.

Involvement in peer-to-peer activities: Involvement of the teams in peer-to-peer activities across different locations is another way of acknowledging equality of the groups. For example, when a review or an inspection is taking place as a part of the SQA activities of the project, it would be useful if the review team is comprised of members from the different locations instead of from just one location. Such an approach will not only give the members a sense of equity and fairness, but will also provide them with extra opportunities and avenues for communication with members of various other locations.

CONCLUSION

The evolution of global teams is still in its infancy and one can expect Significant changes as the management and business models become better understood and the technology continues to make rapid strides as it has been doing over the last few years. We believe there are likely to be two key drivers in taking the collaborative work of the global teams to its next evolutionary phase. The first is the advances in the Internet technology that favours such collaboration and the second is the evolution of process models that define collaborative work better, address people issues and work towards customer satisfaction. These two drivers are addressed in the next two chapters.

PROBLEMS/QUESTIONS

1. What were some of the factors that caused a transition to the off-shore model of project teams? What would be the criteria for choosing the countries in which to do offshore development?

2. Would all countries that succeeded in off-shore model be successful in the distributed model of development? Justify your answer.

331 Globalisation Issues in Project Management

3. Analyse your interactions with members from another location and identify the areas where you feel you could have done better had you known about some of the cultural differences of the members of the other location.

4. Form a cross-cultural group and discuss the impact of the following on communication and co-operation

(a) Language differences

(b) Style differences (e.g., being very open versus being somewhat shy) (c) Stereotyping and making assumptions about a given culture

(d) Protocol issues

5. Discuss how time zone difference can be exploited effectively for business success. Identify project scenarios where time zone differences actually prove to be a handicap rather than a benefit

6. Discuss the impact of globalisation on the following issues:

(a) World-wide market for jobs: An aspirant can post his resume on the web and get considered for placement anywhere in the world

(b) Global stock options as a part of the compensation.

(c) Team members geographically distributed across two locations getting different salaries for the same job function (based on the location)

7. Let us assume that the aircraft technology has become extremely advanced and it is possible to physically commute from Bangalore to California in under three hours. How would the project management / team models discussed in the text change?

8. Which of the project team models discussed in the text would you choose in each of the following cases?

(a) There is a requirement for data entry operators (e.g., medical transcription) on a large scale. Data originates in one location only and the cost of data entry operators is substantially lower in another location.

(b) You have found that abundant talent is available in India on Java technologies. You want to minimise the programming time by hiring the best talent for Java programming.

(c) You need to provide a 24-hour coverage of product support utili sing the time difference.

(d) You are designing a product for the global market. There are design experts in each geography (e.g., Asia, Europe, etc.) who know the specific requirements of that area.

Chapter - 20

Impact of the Internet Project Management

"Since it arrived on the scene as a full-fledged cultural and social phenomenon in late

1994, the Internet and the World Wide Web have come to dominate all aspects of the future of technology and, by extension, the future of business. rr

• Jeff Papows

Effect of Internet on Project Management-training time planning-software distribution and deployment changes-Internet's role in enhancing communication- managing projects for the Internet-characteristics of applications for the Internet- effect on project management activities-unknown customer and requirements manage-ment - configuration management issues -design and development issues - unique challenges -of performance testing- "Word of Mouse" and need to do it right first time- maintenance phase changes

INTRODUCTION 20.0 It has become almost a cliche that the Internet is changing everything and is having an all-pervasive effect on everything we do in life-be it commerce, learning or our social life. In this chapter, we discuss two effects of the Internet phenomenon: First, how does the Internet change the way we plan and run a project? Second, given that most of the software projects in the next few years would be for the Internet space, what special considerations should we be aware of for managing such projects? We will look at all the activities discussed in the earlier chapters and see what impact the Internet has on each one of them.

333 Impact of the Internet on Project Management

THE EFFECT OF INTERNET ON PROJECT MANAGEMENT

20.1 Two of the main characteristics of the Internet economy are (a) Neck-breaking speed at which technology is evolving: The hardware infrastructure as well as the Internet software are making advances at a very rapid pace. Let us take the wireless access to the Internet as an example. In just under a year, there

have been at least three competing standards, and over 15 million users accessing information on the Internet using their mobile devices. As was stated in Alice in Wonderland, one has to keep running even to stay in the same position!

(b) Drastic reduction in product cycle times: To cope up with the rapid changes in technology, product cycle times-the time gap that spans a project from the conceptualisation stage through product development and finally to product obsolescence-has come down drastically. This has forced software developers to seriously consider using reusable components rather than starting all development from scratch.

There are at least three significant effects of this race for time on project management (even if the project is not for producing an Internet product). These are:

Reduction in training time of employees through the use of technology and

e-Leaming Reduction in software distribution costs and time Reduction in time needed for dissemination of accurate information

As can be seen, the common theme in the above points is the cutting down of the cycle times of projects in order to remain competitive. Let us see each of these in detail in the following sections.

Training Time Planning One important factor to keep in mind while planning a project is the time it would take to ensure that the employees are fully trained for their job. There are a few reasons why this is important. Firstly, technology is changing fast and there is a need to stay current and competitive. Secondly, employees constantly aspire to learn new things and to become more productive. The opportunity to learn new things is one of the key motivators for employees to stay in an organisation. In this era when hardware is becoming a commodity, the real competitive advantage for

334 Managing Global Software Projects an organisation rests with having well trained, motivated employees. Thus it is obvious that planning for training is very important to the short term needs of a project and the long term needs of an organisation.

But planning for training in the pre-Internet days was not easy owing to several factors:

Training used to be a discrete event that was held on certain pre-determined dates. The project manager and the employees had to adjust their schedules and plans to be able to attend the training. This in turn had an adverse impact on project deliveries and deadlines. On the other hand, when the project went through a slack period and the employees were free to take the training, such training was not available. Hence there was an impact on scheduling of training.

There were only a few qualified trainers. These people were not easily available. There were scheduling and cost implications that were difficult to overcome. The compromise solution was either a "Train the trainer" program or that the training be given by someone who is not the most desirable choice for trainer. Either of these approaches meant compromising on the quality of training of employees.

Most of the good training programs were being conducted in different parts of the world. In order to get the best training available, travel costs had to be incurred. The project manager and the employee had not only to contend with scheduling for the actual training, but also to budget for the time and cost of travel. Thus this increased the cost of training (in addition to, of course, the inconvenience).

With the advent of the Internet has come e-Learning, which overcomes the disadvantages mentioned above. The model for e-Learning is as follows:

1. A competent and capable (and preferably the best) trainer is identified for a program

2. The training is offered once by this competent and capable trainer. The offered training is captured and stored on the Internet-or the organisation's Intranet-in a Learning Management System

3. Such a "stored training" could consist of the instructional material (like slides) as well as multimedia material (such as as video of the class)

4. The employees take the training as and when they need it and as and when they have the time.


5. In order to ensure that the employees' questions are answered and all doubts clarified, the original instructor (or someone qualified) is made available either in a chat room or via email. 6. The above e-Leaming is supplemented by the necessary conventional training

mechanisms like classroom training, use of books, etc.

The above model of e-Learning addresses the concern areas expressed earlier. As the "course offering" is a one time activity, the most competent instructors can be obtained with fewer logistics problems. As the training is taken by employees at times convenient to them, scheduling and conflicts with project deliveries are overcome. This also provides an added advantage of enabling employees to take the training at their own speed. If they are familiar with certain modules or portions, they can skip these parts and finish their training faster. Finally, as the training requires no travel, the costs are reduced.

As we move forward in the Internet era, the "Just in time", "Just what is needed" e-Learning paradigm would simplify the organisations' and project managers' efforts in planning their training requirements. By enabling employees to come up to the required speed faster with consistent high quality training at a lower cost, organisations would benefit from improvement in productivity, timeliness and quality of project deliveries. The net result would be an increase in customer satisfaction.

Software Distribution And Deployment Changes

In the pre-Internet days, software had to be distributed to the customers through some media. The distribution media has changed over the years from tapes to floppies to CDs. But in each of these cases, the project manager had to account in his plan the delay between the actual completion of the project and the software reaching the customer. The typical steps involved would be:

1. The software product organisation makes the product available on a "master media" from which copies can be made.

2. The customer would be notified of the availability of the software 3. The customer would place an order for the software with the software organisation 4. The software would be copied into an appropriate media after ensuring that the customer has met all the pre-requisite conditions (licensing, legalities, payment, etc.)


5. The media is shipped to the customer 6. The customer receives and installs the product.

In this model, there was significant cost incurred and time spent on media repli- cation, shipping etc, as illustrated in Fig. 20.1(a). Furthermore, since the software had to be installed at the customer site, the customer required expensive hardware and system administrators.

With the advent of the Internet, the software distribution model moved to web based deployment. The new model is based on self service. The software is placed on a web site for downloading by any interested and authorised customer. He logs on to the published web site, enters the necessary information, downloads the software, installs it and starts using the software. This method of deployment eliminated duplication and shipping costs (Fig. 20.1(b». It also reduced the time lag between development being completed and the software being available to the customer.


Going one step further, Application Service Providers (ASP) even obviate the

need for downloading software. With the advent of the hosted model, the software changes are placed on the ASP site and made available to the users directly. This significantly cuts down the cost and time of deployment. It also reduces the complexity of the hardware and personnel required at the customer site. (Fig. 20.1(c))

Internet has enabled reducing the overall product delivery time by cutting down on transit time and costs. There are two side effects caused by this reduction in delivery and deployment time: First, the pressure to reduce the time required for other life cycle activities (like design, development, etc) also builds up. Because products get consumed quicker, they have to be produced quicker also to maintain an equilibrium. Second, because of the ease of deployment, more customers are likely to get on to the software faster. Thus the demands made on the quality of the product-both Quality of Conformance and Quality of Design - increase significantly. Problems are expensive and sometimes impossible to fix. The extra demand on the quality is likely to increase the cost of the SQA activities and the project manager must budget and plan for this increase.

Internet's Role In Enhancing Communication

We have mentioned repeatedly, that the success of a project is largely influenced by the effectiveness of communication among the terms.

Internet has opened up several new avenues to facilitate this. Some of these avenues are:

Sharing a common repository of geographically distributed project information: In the pre-Internet days, when project information was distributed across different machines, systems, and databases, getting a common view by aggregating information from these multiple sources was very difficult. The current Internet technologies have provided mechanisms and standards for effective sharing of information across the disparate sources. For example, information on a single web page can come from multiple databases in different locations. The ease with which such distributed information can be aggregated and presented makes consistent information sharing a reality.

Better and less expensive means of communication: Communication comes in two flavours-synchronous and asynchronous. Typically, in the case of discussions / negotiations, synchronous communication (when both the communicating parties are present online at the same time) is more effective than asynchronous communi-

338 Managing Global Software Projects cation. In the pre-Internet days, the only means of synchronous communication was through using a telephone or in a face to face meeting. Both these were pretty expensive. The current Internet technologies have facilities like chat or instant messaging or Internet Telephony, which are cutting the costs of long distance telephony and yet providing the benefits of synchronous communication.

Ability to access information anytime, anywhere: In the pre-Internet days, one required special purpose software and special environments to look at project infor- matioh. For example, if one had to look at his email, he needed to be logged into the organisation's intranet before logging into the emaiL This made on the move information dissemination very difficult. Today, most airports and public places provide Internet access and it is possible to access information with very low overheads in set-up, infrastructure, settings, etc. Added to this, the Internet is spreading its wings to mobile devices like cellular phones, palmtops, etc. This is bound to increase the effectiveness of communication of project information and enable more informed decision making for projects and thus more effective project management. The successful management of a project has a strong correlation to ensuring effective communication among the team members. As can be seen in the above discussion, the Internet has provided avenues that enhance the effectiveness of communication. When harnessed properly, the Internet acts as a great facilitator in project management and very significant benefits can be derived through the appropriate and judicious use of the Internet tools and technologies. MANAGING PROJECTS FOR THE INTERNET 20.2

Characteristics Of Applications For The Internet

As the Internet is becoming an integral part of our lives, it is obvious that almost any future software project will be for use over the Internet. In this section, we describe some of the characteristics of applications for the Internet, and the impact these characteristics have on the management of projects for these internet applications.


The evolution of an organisation's presence on the Internet generally goes

through three distinct phases:

First, an organisation provides non-interactive web sites. This calls for no more than a simple page design. The organisation can choose to use the Internet to display an online catalog. It can also give product and pricing information online. This phase of web presence is just a conduit for customers to get to know a point of contact in the organisation (like an email id). With the evolution of technology over the last few years, this stage is almost trivial. With the sophistication in the facilities offered by the various web sites, this kind of static web presence is far from sufficient in today's context. Most of today's Internet applications go far beyond static web pages.

In the next phase of evolution, the organisation opens the doors to customers for transactions over the Internet. For example, the customers can place orders for products over the Internet. Such orders get into the normal order processing system of the organisation and get fulfilled by the normal "brick and mortar" system of deliveries. This is the first exposure a customer gets to the applications in an organisation. Such applications on the Internet are called "B2C", which stands for, Business to Consumers. As the end customers are using the applications, the applications have to be robust and easy to use. Also, the bricks and mortars infrastructure should meet the order fulfilment commitments. Otherwise, the customers would not return to the site. Moreover, bad reputation spreads faster on the Internet and the organisation would start losing its customer base at a very rapid rate.

In the final phase of evolution, the customer's application seamlessly integrates with that of its suppliers and customers. The suppliers know which goods the organisation needs and at what time and interface with the bricks and mortars infrastructure to get the goods delivered. Similarly, the customers of the organisation gain an automatic window into the organisation's ordering system and place orders for what they want. There is a tight link between the logistics at the organisation's end that cover transportation, billing, payment, etc. to that of the customer. All the interaction and communication is over the Internet. The entire supply chain is fairly transparent. This type of application over the Internet is called "B2B", which stands for, Business to Business. In this case, not only should the organisation's software products be robust but there must also be interoperability between the systems across the value chain. Furthermore, the operational processes of the supplier, the organisation and customers also become highly visible and any of the kinks in the operational systems have to be ironed out.


The next phase of evolution in progress is the concept of exchanges. During this

phase, there is no real organisation-specific software. Everyone "comes in to" a common market place called exchange. There are usually industry specific exchanges- for example, airline exchange, automobile industry exchange, retail exchange, etc. All the requirements of various organisations are registered into the exchange. There is a process of bidding, auctioning and reverse auctioning that happens before a deal is struck. In this case, the exchange software has to be powerful enough to handle the needs of multiple players; robust enough to withstand volume of transactions and yet be natural enough for organisations to be able to use it.

In addition to organisations that are transforming themselves for an Internet presence, there are also other types of players in the Internet arena. These include Internet Service Providers (ISPs) who provide basic Internet access; Application Service Providers (ASPs) who provide users with readymade infrastructure to run the applications they want (which is discussed earlier in hosted development); Por- tals which provide a single point of entry to all that a user may want to see (be it weather, sports, stock prices, news, etc.) and Content providers (who actually provide the contents pointed to by the various portals).

Most of the typical applications for the Internet (described above) are characterised by the following common attributes:

341 Impact of the Internet on Project Management Very simple deployment model: The front end is a simple browser; Generally, there is no client side installations to be made. The data is maintained on one or more Data Servers. All the application logic is centrally maintained on Application Serv- ers. The application may even be hosted - i.e., the customer would not have to perform any installations on his system but use the applications that are already on the system provided by the ASP. Thus the entire deployment model is extremely simplified. There are no time consuming upgrades on multiple systems.

Need for mass customisation: In the pre-Internet applications, customisation of applications was expensive and time consuming. Each user saw pretty much the same application in the same style. That was sufficient when the users were known. But, for using the Internet applications, when the users are manifold and are not known, customisation is almost a tablestake for survival. In fact, the expectation is not just customisation but mass customisation. Each user sees exactly what he wants to see; no more, no less. Furthermore, the specific information he would like to see could vary with time of the day or place from where he is executing the application.

Self service: The Internet Deployment and Application model takes the users to a self service mode of operation. Be it placing orders over the Internet or taking e- Learning training or downloading maintenance patches, each customer goes by his own time table and his own schedule. Thus there is no predictability of traffic. Also, the system cannot afford to have any down-time or outage as customers could come in at any time from any part of the world.

Convergence of media: Current Internet technologies have brought about the convergence of the computer, communication, entertainment, and even mobile devices. The same application may have to be viewed on a PC or a TV or on a mobile phone. Thus, while designing the application, its suitability to the different media has to be taken into account. Alternatively, tools to automatically detect which device is using the application and automatically render the application for that device need to be used.

Importance of standards: Because of the openness of the Internet, use of proprietary technology is almost passe in the Internet era. Conformance to open standards is made necessary by the heavy use of componentisation. In most of the areas, the emerging and competing standards make it difficult to know which standards to comply with!

In the following sections, we will discuss the impact these characteristics have on Project Management activities.

342 Managing Global Software Projects EFFECT ON PROJECT MANAGEMENT ACTIVITIES The Unknown Custromer And Requirements Management

When custom, bespoke software was developed for a specific customer, the customer was known and so were most of his requirements. Even if there were some requirements that were not implemented correctly, communication was easier and there was less scope for conflicting requirements.

When customer-specific software gave way to shrink-wrapped, general purpose software, things became slightly more tricky: The software that was developed satisfied most of the common needs of most customers, even if it did not match the needs of any particular customer 100%. Thus, the possibility of conflicts between the requirements among various customers arose for the first time in the case of shrink-wrapped software. This increased the importance of Requirements Manage- ment. Before starting on the product development, the target market and the requirements that would be (and would not be) satisfied had to be clearly spelt out. The decision by a customer to tryout a general purpose software was taken by the customer after a fairly extensive process. Trying out new products was an expensive proposition with fairly significant entry barriers (of set up, installation and training) and an even greater exit barrier (of data migration and application migration). Although a product could seldom meet a customer's need 100%, the high entry and exit barriers ensured that the really interested customers did take on the product and did not make a premature exit from using the product.

When a product is developed for the Internet, customers in the far flung corners of the world, who the software manufacturer had not even dreamed would be customers, could overnight become customers. They could also use the product in entirely new ways. To make the situation even more interesting, customers who do not like the product features could simply switch to another product without giving any feedback to the software manufacturer as to what to change/ enhance. To use a cliche, "the competition is just a click away" and there are very few entry and exit barriers for customers and prospects to try out new products.

Thus, when a product is designed for the Internet, requirements management assumes a much higher level of significance. People planning the product features


should be absolutely sure that the right requirements are fed into the product even though they would not be able to predict who will use the product and for what purpose. Effective ways of gathering, managing, and prioritising requirements using techniques like surveys, meetings with interested prospects, and looking at what is already available on the web, assumes special significance and importance in the case of products for the Internet space.

Configuration Management Issues

For a non-Internet product, Configuration Management is usually confined to controlling and tracking the files and objects that are used for building the product. For the Internet products, there could be other types of information that needs to be subject to formal configuration management procedures.

One of these is the content in a site. Any updates to the contents of the site should go through proper configuration management procedures (like change request, authorisation, etc.). A site may be liable for the content that is accessed through that site. It would be useful-and even necessary-to have a process to ensure the validity of the content and provide appropriate audit trails.

As we discussed earlier, Internet applications are characterised by mass customisation. Each user may select his set of services to use, his set of options and preferences. For example, one user may choose to use the Stock Ticker and weather services; with the ticker showing values of symbols ORCL, CSCO, INFY and SIFY and the weather services showing the weather for San Francisco, Bangalore, London and Singapore. He may wish to see the tickers in graph format. Another user may choose other combinations of services, options and preferences. One can see that each of these individual configurations is distinct and information about such configurations also needs to be managed. While this may not be "Configuration Management" in the sense of the term that we defined in Chapter 6, one can see that the management of these user preferences is important for the user's acceptance of the product.

Design and Development Issues

As we discussed earlier, the Internet deployed applications have very tight time-to- market considerations. Some of the design and development issues that assume extra importance in the development of Internet products are:

344 Managing Global Software Projects Componentisation: The products should use effective componentisation. This would enable achieving better parallelism in the Work Breakdown Structure. In addition, componentisation would facilitate the identification of re-usable components.

Re-use: Design should consciously keep in mind and evaluate the re-use possibilities. Setting up a library of re-usable components with documentation on the functions and interfaces provided by the components would facilitate identifying and promoting re-use.

Conformance to external standards: Because of componentisation and re-use, a product would have to inter-operate with components which conform to industry standards. This would also mean that the inter-operability considerations would have to be documented accurately during the requirements/ design phase and tests designed during the test phase to ensure that proper interfaces are used.

The Unique Challenges of Performance Testing

In addition to the functionality of requirements discussed in the previous sections, the Internet based products present one other interesting challenge. Not only do the product developers not know what the customers would eventually need in terms of functionality but they also do not know how many concurrent users would use the product. An Internet based product could become a prisoner of its own success: A product or a site comes up; some initial users take a liking to the site and the functionality; reputation spreads fast; quickly the site becomes popular; more users try this site; the site and the infrastructure are unable to handle the traffic; users start dropping off; the site goes out of business.

What steps can a project manager take to stop this downward spiral?

1. Making some realistic estimates about the possible traffic load: Making such estimates is very different from the traditional pre-Internet products where the maximum traffic can be predicted based upon the physical number of terminals / users connected to the machine. This adds complexity to the test planning phase of the project.

2. Testing the product simulating maximum traffic conditions and ensuring the system stands up to the load: This step means that the verification and validation phase has to be planned more thoroughly for functionality testing as well as performance / stress testing.

345 Impact of the Internet on Project Management 3. Providing infrastructure to ensure system performance: Infrastructure

covers hardware infrastructure (like CPU power, memory, disk space, network hardware like routers, bandwidth, etc.), software infrastructure (a well tuned system and database, performance monitoring tools that predict and spot potential bottlenecks, performance enhancement tools like cache managers, etc.) and support infrastructure (linking the application to logistics, having well trained operators and support staff, etc.). All these require specialised skills, involve extra costs and hence need to be factored in the project planning and tracking.

4. Constantly monitoring the traffic patterns and being able to add new infrastructure on the fly: This has implications on costs as well as choice of tools. The extra hardware costs have to be factored in the cost of the project. Also, the software tools chosen must be able to exploit the new hardware and deliver better performance. For example, to improve performance upgrading to a multi-processor hardware will not help if the underlying software cannot exploit the multiple processors and achieve parallelism.

The Need To Do It Right First Time: The "Word Of Mouse" Spreads Faster Than The Word Of Mouth!

In the case of pre-Internet software products, when the product had defects, one had a second chance to fix them by issuing patches. For the Internet products, it is almost impossible to get this second chance. First, because of the low entry and exit costs, the customer can just exit from the product he is using and move over to another product offering a similar functionality. Second, as mentioned earlier, in the Internet space, reputation spreads very fast! A product defect gets noticed almost immediately because there are so many users. When a product defect does get noticed, the news about this spreads even faster to the far flung corners of the world because of the presence of online communities, chat rooms and email. Hence the need to get the product right the very first time becomes critical in the case of the Internet products. Stated differently, software quality assurance activities which provide means of defect prevention, assume greater significance for the Internet products.

Activities like inspection, reviews, etc. should be carried out very thoroughly. Both the breadth and the depth of coverage of these SQA activities should increase. Any new functionality that gets introduced should go through extensive review as

346 Managing Global Software Projects well as testing. Any modifications to existing functionality should be reviewed and tested to ensure compatibility to current systems.

The challenge lies in containing the SQA activities in the rapidly shrinking life cycle times. Some possible strategies to meet these challenges are:

Use of well-defined processes. Use of checklists and templates that are always kept updated. Use of automation Practicing re-use of proven components Adherence to industry standards

Maintenance Phase Changes

There are two transformations that the Internet brings about on the activities during the maintenance phase of a product.

Call center -7 Web center support model: In the call center model described in Chapter 18, typically the customer makes a phone call to the call center and talks to the support analyst. This invariably forces the communication to be synchronous, i.e., there is a need for human intervention at the time of taking the call. Most of the initial interactions are routine questions about the environment and the basic problem description. Moving this communication from a synchronous model to the asynchronous model opens the doors for automation and parallellism. An automated tool that front ends on the web can

(a) Prompt the user with all necessary information on the problem (b) Validate that all the required information is provided (c) Check the problem repository for matching symptoms (d) Advise the customer of any possible fixes if the problem is a known problem (e) Track the progress if the problem is a new problem

Centralised support -7 Distributed support: The move from the synchronous model to the asynchronous model of communication makes customer support a back office function. Thus the customer support group can be located at any place on the globe that offers the best talent pool and is cost-effective. In fact, the customer support groups can be divided and placed at different centers in the world to effectively exploit the geographic time difference and provide 24-hour coverage.

Fix distribution -7 Self service model: In the pre-Internet days, to get a fix, each customer had to get the media and install it. This involved shipping and logistics.

347 Impact of the Internet on Project Management With the Internet, the fixes are simply hosted in a web site. The download and installation procedures are fairly standardised and hence the maintenance and application of fixes can become a self service activity for the customer.

REFERENCES [P APO-98] is one of the books that discusses some of the transformations that some businesses are undergoing because of the Internet. The site www.masie. com contains useful pointer about e-Iearning. [BARR-20Dl] discusses the impact of the Internet and some of the 'life cycle activities.

PROBlEMS/QUESTIONS 1. Discuss some of the advantages and disadvantages of the hosted model of

deployment from the point of view of project management. 2. One of the prevailing trends is the "software as service" or "pay per use" model of deployment. In other words, software services are hosted and managed centrally; the user picks what he wants and pays for what he wants when he uses it. Discuss some of the project management challenges in managing the development and deployment of such system. 3. Is "e-Learning" nothing more than courses hosted on the Internet? Would this be sufficient? What gaps do you foresee when web based education is used without combining it with other traditional methods of learning? 4. In the text, we have described how the Internet enhances communication. Describe some of the means by which the Internet actually reduces the effectiveness of communication. How would you guard against such adverse effects of the internet? 5. Describe the impact of the following on the specified umbrella activities / in-stream

activities / engineering activities (a) Effect of the need of mass customisation on configuration management (b) Effect of convergence of media on testing activity (c) Effect of rapid change (and obsolescence) of technology on maintenance

6. Describe some of the situations where you would use synchronous communication and where you would use asynchronous communication.

7. How is performance testing for web based applications different from client server applications?

Chapter - 21 People Focused Process Models

"If you find yourself concentrating on the technology rather than the sociology, you're like the vaudeville character who loses his keys on a dark street and looks for them on the adjacent street because, as he explains 'The light is better there'.”

• Tom DeMarco and Tim lister Growing emphasis on people centric models-P-CMM, People Capability Maturity Model- Other people focused models in the literature- How does an organisation choose which models to use.

GROWING EMPHASIS ON PEOPLE CENTRIC MODELS 21.0 We started this book by presenting people, processes, and technology as the three dimensions of software project management. In Chapter 4, we discussed formal process models. The main purpose evolving such formal process models was to ensure the consistency and predictability in the results and the quality of deliverables from a software organisation. In the previous chapter, we discussed the impact of technology on project management. But in a knowledge based industry like software, people form a very vital dimension. This dimension is more often than not glossed over.

There are several important people related questions which need to be answered: How can we ensure consistency and predictability when the basic training offered to practitioners is not consistent (or sometimes non existent)?: In any other profession; an aspirant practitioner would have to go through rigorous and formal training on all essential and fundamental aspects first. During this training, he

349 People Focused Process Models would be under close observation by an expert. When he comes out of this rigorous and well defined training, he has good chances of achieving a predictable level of proficiency. But, in the software profession, the formalism in training has not reached the same level of rigour. Neither there is a consensus on what constitutes essential and fundamental aspects nor is there a consistent way of imparting the training. With such inconsistently trained people, how can we ever achieve consistency and predictability in product quality and deliverables?

How can we ensure consistency and predictability when there is a wide variation in the capabilities and performance of people? The demand for software professionals far outweighs the supply. Thus it is not always possible to hire a team of people with all equally proficient in their performance. Every team is bound to have some star performers-with a majority fitting into the average category. How does an organisation achieve predictability and consistency with varying proficiency levels of the people (when people are the most important raw material for a knowledge based industry)?

How can we ensure consistency and predictability when there is a high turnover rate of employees? Software industry suffers from much higher attrition rates than most other industries. Even if an organisation assembles a team of all star performers, how does it ensure that the experience and knowledge gained by the current team members are passed on to the new employees? Even if such a knowledge sharing program is proactively thought out, can the organisation survive the high turnover rate and still maintain the quality, consistency, and predictability of the deliverables?

How can we balance the individual's aspirations with organisation's goals? Quality and consistency can be achieved only when each individual feels committed to the goals. Each individual is different and has different aspirations that even vary with time. When there is a divergence between individual aspirations and the organisational goals, how can we ensure consistency and predictability of results?

The last few years have seen the evolution of process models that are people- centric. These people-centric process models provide guidelines and frameworks for harnessing the potential of software professionals and maximising the opportunities for achieving consistency and predictability of products. In this chapter, we briefly discuss one such model-People Capability Maturity Model (P-CMM). This model aligns with and complements the Capability Maturity Model discussed in Chapter 4. We also give pointers in the literature to other people-centric models.

350 Managing Global Software Projects PEOPLE CAPABILITY MATURITY MODEL (P-CMM) 21.1 People CMM was developed in the Software Engineering Institute and is documented in [CURT-95]. The Capability Maturity Model for Soft- ware (also called Software CMM) enabled organisations to streamline processes and practices. But it was soon realised that to fully enjoy the benefits of Software CMM, people related issues needed to be addressed. Some of the people related issues that hindered the full realisation of benefits of the processes were:

Inability to hire and retain skilled people in a consistent manner. Incomplete or inconsistent attention paid to communication, compensation

and career planning resulting in lack of commitment. . The skills and the competitive advantage of an organisation not being

institutionalised but simply being confined to a few individuals. Lack of bonding between team members and the consequent divergence

between personal ambition and organisational goals.

People CMM (P-CMM) provides a framework to guide organisations to hire and retain human assets and to institutionalise software development capability. The eventual target benefit is a cohesive organisation with a shared vision and a common purpose-a necessary condition for a high performing organisation.

The P-CMM follows a structure that is similar to Software CMM. Five levels of . maturity are identified. Each level is characterised by a set of Key Process Areas (KPAs). In order to be at a given level, all the Key Process Areas of all the preceding levels must be satisfied. Figure 21.1 depicts the five levels and the KPAs for each level.

We will now briefly discuss the various levels, their KP As and how they relate to the common practices.

At Level l -called the Initial level, the performance of the organisation is highly dependent on individuals and hence is inconsistent. There are no institutionalised procedures for most of the people related functions. Managers are not formally trained in people skills. Important job functions like interviewing, performance ap- praisals, etc., are performed in an ad-hoc manner. There is no conscious effort made to develop employees' skills. People do not see a synergy between their personal aspirations and the organisational goals.

Just as in the case of an organisation at the Software CMM Level I, an organisa-

tion at People CMM Level 1 need not necessarily be under-performing and nor should the managers of this organisation be perceived as people with no skills who are guiding the others. Since there is no conscious attempt made to institutionalise the good practices at this level, consistency cannot be guaranteed. The satisfaction level of an employee also suffers as it is largely determined by the personal initiative of his manager. In the long run, this uncertainty leads to varying levels of employee satisfaction and may prove to be detrimental to the organisation's morale.

Level 2-known as the Repeatable Level-establishes the common management practices and minimises or eliminates the obstacles that commonly come in the way of a productive work environment. First, the Work Environment provides guidelines on how to create and maintain a work environment that complies with all the laws and regulations, minimises distractions and provides employees with all the resources they need to carry out their work. Communication attempts to augment the physical work environment with healthy, across-the-board communication so that everyone works on a shared vision, and for a shared purpose; knowing exactly how their job fits into the organisational goals. Staffing ensures that the people with the right knowledge, skills and attitude get hired into the teams and that the se- lected candidates gel with rest of the team. Training imparts additional skills

352 Managing Global Software Projects when needed; Performance Management and Compensation-the means by which performance of individuals gets reviewed objectively and gets rewarded in a fair and commensurate manner-completes the KP As of the Repeatable Level.

At Leve13-called the Defined Level-the organisation identifies the core competencies required to conduct its business and puts in place plans to adapt and develop the workforce practices so that the employees are able to acquire the core competencies. Knowledge and Skills Management takes the first step of ascertaining the core competencies required to satisfy the current business needs as well as the anticipated future needs. These core competencies are mapped to the knowledge and skills profiles. Workforce Planning and Competency Development develop the long and short term plans for acquiring, tracking and improving the competencies required. As individuals develop their competencies in synergy with the organisational needs, they should also see a career path for themselves that would motivate them to stay and grow with the organisation. Career Development accomplishes this important personalisation. With the alignment of individual career plans and organisational core competency development, the stage is set for Compe- tency Based Practices which directs the workplace practices (at least in part) to be based on developing the knowledge and skills of its workforce. The organisation experiences a Participatory Culture which lays the foundation for building a high performance team.

Level 4-the Managed Level-effects the transformation to quantitative management of knowledge, skills and competencies. Mentoring spreads the experience gained by the experts to the rest of the workforce in a structured and focused manner. In addition to knowledge transfer, mentoring also increases the bonding between people within the organisation. This is further augmented by formal Team Building and Team Based Practices. Organisational Competency Management sets and tracks the measurable goals for growth in the organisation's core competencies and skills. With all these practices, there is a strong correlation between the knowledge, skills and performance of an individual, the group in which he works, and the entire organisation. Organisational Performance Alignment quantitatively assesses the effectiveness of workforce practices in achieving this alignment.

When an organisation achieves the Managed Level, workforce practices are consistent. They are based on competencies and are quantitatively defined. There is clear focus and synergy at all levels. The stage is now set to achieve continuous improvement and to reach Level 5-called the Optimising Level. This involves Per- sonal Competency Development at an individual level and an organisation-wide

353 People Focused Process Models

Continuous Workforce Innovation. Coaching is one of the means of achieving this continuous improvement.

Advantages Of P-CMM

Just as in Software CMM, P-CMM embodies common sense practices into a formalism that is easy to adopt. In any organisation, it is likely that some of the workforce practices that the P-CMM addresses are already being followed, albeit in pockets and perhaps unconsciously. What the P-CMM provides is a way to identify and institutionalise the best practices. Furthermore, the P-CMM embodies the practices of successful organisations. Applying this wealth of knowledge would allow an organisation to jump-start a sound human resource base.

Challenges In P-CMM

P-CMM is relatively new (as compared to Software CMM). Hence the experiences to share are fewer in case of P-CMM. But this is changing rapidly as more and more organisations are discovering the value in formal people practices.

One of the challenges that may be faced in developing organisation-wide competency-based practices is the rapid change in technologies. As the technology changes and the demand for shorter cycle time increases, defining the competencies required to succeed becomes difficult.

Another challenge lies in the area of compensation and performance management when the teams are geographically distributed. Compensation levels are different in different countries and this may lead to the perception of lack of parity or equity across the teams.

No doubt the P-CMM attempts to retain employees by creating a bonding between them and the organisation, but the fact remains that the software industry probably suffers the highest attrition rate among all industries.

Just like the Software CMM, P-CMM requires commitment from the individuals to make it a success. The employees have to take the initiative to develop their competency, skills and knowledge. The framework itself cannot ensure this commitment.


OTHER PEOPLE-FOCUSED MODELS IN THE LITERATURE

21.2 P-CMM brings the focus on people at an organisationallevel. There are other models which take this people-focus to the more granular levels.

Personal Software Process (PSP) discussed in [HUMP-95] identifies those aspects of Software CMM that are applicable to individuals and packages subsets of these methods to enable gradual introduction of these in small programs in a classroom setting. PSP also provides tools and techniques to formally and rigorously practise these methods and to achieve targeted continuous improvement so that these best practices become habits that are hard to break. Team Soft- ware Process (TSP) discussed in [HUMP-2000] builds on PSP and institutionalises the processes at a team level. The rationale behind these models is that once the practising of the disciplined processes becomes a habit with individuals, it becomes "natural" to follow (and tougher to break) these disciplines.

HOW DOES AN ORGANISATION CHOOSE THE MODElS TO USE?

21.3 It may seem a daunting task to choose from so many different models- Software CMM, P-CMM, PSP, TSP, ISO-9001, etc. There are also a host of other models that we have not covered in this book. Some of the questions that a Project Manager (or an organisation) are likely to be faced with are:

Which model(s) do I use? What are the circumstances under which each model should be used? What are the cost-benefits trade-offs that I can expect from each model?

There are no easy answers to the above questions. But it would be useful to internal- ise and appreciate some basic facts:

The models just embody common sense practices: Whether it is the concept of planned staffing in the P-CMM or defect prevention in the Software CMM, they are all practices that appeal to one's common sense.

No one model is sufficient by itself: It is not possible for an organisation to address all the process issues by adapting a model like Software CMM or ISO-9001 while completely ignoring the people issues. Even if an organisation formally follows a model like P-CMM, it cannot afford to not follow the practices of Software CMM.

355 People Focused Process Models There is no specific order of precedence of the various models: It is not necessary that one should adopt the Software CMM before adopting the P-CMM or vice versa. The organisation c~n adopt whatever is most appropriate from each model.

In order to get the maximum benefit from the various models, the approach from the project management perspective could be:

Institutionalise the basic "hygiene factors": These are typically the practices at initial maturity levels. Until issues like project planning, proper staffing or measuring one's own productivity and defect rates become "natural", achieving higher levels of maturity would be very 'difficult.

Know where the organisation's maximum needs are: Once the basic issues like the work environment and project management are addressed, the most immediate needs of the organisation will become clear. These needs could be the documenting and following of the processes (because the projects are predictable and repeatable) or looking into problems caused by too much attrition (because people do not see a synergy between their career aspirations and the organisational goals). Addressing these areas of maximum need is likely to get a better bang-for-the-buck in the early stages and increase the buy-in for a process culture.

Adopt a model that best fulfils the identified needs and not just for certification: The goal should be to achieve continuous improvement in a planned and targeted way. Adopting to a particular model just to gain "certification" against that model is not likely to produce sustainable improvement.

Keep the options of using the other models open so as to identify, encour- age and institutionalise the best practices: Even though an organisation may choose to formally adhere to a particular model (like the Software CMM), it should not overlook some of the best practices offered by other models. As we discussed earlier, no one model is sufficient by itself to ensure the all round development of an organisation.

PROBLEMS/QUESTIONS 1. What issues would you face when you embrace the People CMM for a team that is geographically distributed? What are the solutions for some of those issues? As

examples, cover some of the following issues . Communication Work environment


Compensation Personal Competency Development

2. Study the details of the "Team Software Process" from the literature and present some of the salient benefits of TSP a comparison to other models

3. What kind of commitment is required from an individual to scale higher levels of maturity of P-CMM?

4. What commitment is needed from the management for individuals to be able to ascend the maturity levels on P-CMM? How does this differ from / is similar to the commitments required in the Software CMM?

REFERENCES People CMM is discussed in [CURT-95]. Other'models that are found in the literature include Personal Software Process which is discussed in [HUMP-95]. Team Software Process is discussed in [HUMP-2000]. [DEMA-87] covers some 'Of the common people issues faced in project management, albeit not under any formal process framework like the P-CMM.

Part-II Project Management Processes

Documents

stream activities project

project planning

project closure

project manager

project life cycle

project management perspective

project management processes

umbrella activities