THE INFOSYS DEVELOPMENT PROCESS

3.1 THE INFOSYS DEVELOPMENT PROCESS

During project planning, a project manager must decide what process should be used for engineering the software. This is a crucial issue because much of the engineering activity will be governed by this decision. It is like going on a long driving trip the planned route determines the course you will drive.

Several process models for software development exist. The most common ones include the waterfall model (a description of this model and its limitations can be found in Boehm's Software Engineering Economics ¹), iterative enhancement,² prototyping,³ and spiral.⁴ The most widely used model is the waterfall model, which organizes the phases in a linear sequence, although most implementations adapt this model to minimize its shortcomings.

At a macro level, a standard process can give the optimum organization of phases for a class of projects and makes a good starting point for process definition. However, a standard process cannot be suitable for all situations; the best process may be a variation on a standard process. Hence, to decide which process to use, the project manager must select the base process and also decide how it must be tailored to obtain a process that will suit the project. The rest of this section discusses the standard development process used at Infosys and explains how it is tailored by project managers.

3.1.1 The Standard Process

The standard development process used at Infosys resembles the waterfall model, although the traditional phases have been broken into smaller phases, or stages, to allow parallel execution of some phases. For example, planning for system testing is defined as a separate phase from system testing itself, a practice that allows teams to conduct the system test planning phase in parallel with coding, even though system testing takes place only after coding is finished.

The phases in the process include requirements analysis, high-level design, detailed design, build, unit testing, integration planning, integration, system test planning, system testing, documentation, acceptance and installation, and warranty support. Figure 3.1 depicts the phases and the dependencies between them. Details of the stages are omitted here, although they are described in my earlier book.⁵

Figure 3.1. The Infosys development process

The formal description of this process specifies the entry and exit criteria, inputs and outputs, participants, activities, and other information for each phase (stage). The process descriptions are generally brief, specifying the list of activities to be undertaken in that phase.

This overall process remains the same even for a project using an object-oriented approach, although some of the phases are done differently in such a project. The difference lies mostly in the analysis and design phases, although the guidelines and standards for some of the later phases are also different.

This basic process is also used by projects that do iterative development or prototyping or perform only some stages of the life cycle. In these situations this standard process is adjusted to suit the project. These adjustments are done through process tailoring, which is discussed next.

3.1.2 Process Tailoring

No defined process whether an organization's standard process or the process used in a previous project will apply to all situations and all projects. A defined process must be tailored to suit the needs of the current project.

Tailoring is the process of adjusting a previously defined process of an organization to obtain a process that is suitable for the particular business or technical needs of a project.^5,6 You can view tailoring as adding, deleting, or modifying the activities of a process so that the resulting process is better suited to achieving the project's goals.

Uncontrolled tailoring effectively implies creating a process from scratch. To allow effective reuse of previously defined processes, tailoring guidelines are provided. These guidelines define the conditions and the types of changes that should be made to a standard process. In essence, they define a set of permitted deviations to the standard process in the hope that the optimal process can be defined for a project. Figure 3.2 illustrates the role of tailoring guidelines.

Figure 3.2. Process tailoring

To illustrate the need for tailoring, let's take an activity in the build phase of the development process Do code review. Code review adds a great deal of value in many cases, but sometimes its added value is not commensurate with the effort required. Also, the review could be done by either a group (following the group review procedure) or by one person. The standard development process does not specify how code review should be performed. Tailoring guidelines can help a project manager by advising that the activity Do code review be performed only for certain types of programs (such as complex programs or external interfaces) and by suggesting the optimal form of the review (group review or one-person review).

The Infosys tailoring approach is similar to the table-based approach proposed by Ginsberg and Quinn,⁷ in which the project manager specifies the process element, the tailorable attribute, the options for each attribute, and the reasons for selecting a particular option. A project manager performs tailoring at two levels: summary and detailed.

Summary-Level Tailoring

In summary-level tailoring, depending on the project characteristics, the project manager applies overall guidelines for tailoring the standard process. That is, it provides some general rules regarding certain types of detailed activities. To perform this step, the project manager first identifies certain characteristics of the project. For development projects, the following characteristics are used for tailoring:

         Experience and skill level of the team and the project manager

         Peak team size

         Clarity of the requirements

         Project duration

         Application criticality

The experience level of the team is considered high if a majority of team members have more than two years of experience with the technology being deployed in the project; otherwise, it is considered low. Application criticality is considered high if the effect of the application on a customer's business or Infosys's business is significant; otherwise, it is low. Duration of the project is considered particularly short if the project must be delivered in less than three months.

Summary tailoring guidelines are provided for different values of these characteristics. The summary guidelines are generally review-related, effort-related, schedule-related, resources-related, or formality-related. Review-related guidelines typically specify when reviews should be done and what type of review should take place. Similarly, the effort-related guidelines suggest steps to be taken for the project that may affect the effort. These general guidelines set the context for detailed process tailoring and defining a suitable process for the project.

Detailed Tailoring

Detailed tailoring covers execution of activities, their review, and documentation needs. Tailoring guidelines may specify an activity as optional, in which case the project manager can decide whether or not to execute the activity. Similarly, preparation of some documents may be optional, in which case the project manager decides whether or not the project needs the document. For review, the general alternatives are Do group review, Do one-person review, or Do not review. In addition, a project manager may add some new activities or may repeat some activities.

When detailed tailoring is finished, the sequence of activities to be performed in the process for the project is defined. These definitions are then used to plan and schedule activities and form the basis of project execution. The tailoring performed is highlighted in the project plan, so the process definition and tailoring also are reviewed when the plan is reviewed.

3.1.3 Example: Tailoring for Short-Duration Projects

We illustrate the concept of tailoring by showing the summary-level tailoring for short-duration projects. Infosys observed that the duration of software projects has decreased over the years, and there is increased demand for projects of very short duration. Clearly, such projects require processes to be tailored to allow maximum parallelism and very tight project monitoring and control. The process tailoring depends on the clarity of the requirements, the experience level of the team or the project leader, the size of the team, and so on. Table 3.1 shows tailoring guidelines prepared by project managers of such projects for one combination of values.

Because the shortness of the schedule is the main characteristic, schedule-related guidelines suggest the use of a technique called timeboxing and mini-milestones. In timeboxing, several-week duration cycles are planned, and a working system is delivered after each cycle. To keep tight control on the timeboxes, mini-milestones milestones within the cycle are also set. At mini-milestones, a limited milestone analysis (see Chapter 11) is done. Most of the other guidelines are self-explanatory.

A project manager who must execute a short-duration project can use these guidelines to tailor the development process. For example, the project manager may plan to use iterative delivery with short iterations, perform limited milestone analysis but more frequently, define a change management process that defers most change requests to the next iteration, and so on. In addition, while performing detailed tailoring to define the project's process, the project manager may reduce the documentation for each cycle by, for example, reducing the scope of the templates used for reporting status.

Table 3.1. Tailoring Guidelines for a Short-Duration Project
Values	Summary Guidelines	Why?
Size of team >= 5, duration < 3 months, low requirements clarity, new technology, experienced project leader	Scheduling-related
	Plan for mini-milestones	Identifies problems very early and gives better control of project. Schedule-related risk is decreased because the visibility into the schedule is more frequent. Effort slippage is likely to be controlled early in the project.
	Try to timebox the deliverables	Schedule is potentially reduced because it ensures deliverable system at fixed intervals and discourages feature creep. Schedule-related risk is reduced.
	Effort-related
	Apply appropriate adjustment factors to base estimate as defined in estimation guidelines.	All project constraints are accommodated in effort estimate to project a realistic timeline.
	Give optimistic, pessimistic, and probable estimates.	Reduces risk related to improper estimation and "quick" commitments.
	Revise and renegotiate estimates at the end of design stage.
	Resource allocation-related
	Assign skilled resources for the tasks.          Get expert help for performance- related issues.	Productivity will improve. Schedule-related risk decreases. Rework and delays due to performance tuning are minimized.
	Formality-related
	Identify all stakeholders and their objectives and prioritize them.	Helps in focusing on clear objectives. Reduces schedule-related risk because the important success factors are identified, agreed to, and addressed.
	Regularly report status on risk mitigation activities to senior management.	Schedule-related risk is reduced because mitigation is done proactively.
	Define formal requirement change management process and educate team to strictly follow it.	Minimizes impact of requirement changes on the schedule.

The summary guidelines shown in Table 3.1 are for a project whose duration is less than three months, has a peak team size of more than five, is working with new technology, and has an experienced project leader. During detailed tailoring, the project manager chooses options based on the summary guidelines and suitability to the project. If, however, the tailoring guidelines are not sufficient to allow you to select the right process for the project, you may have to modify the process beyond what was allowed by the tailoring guidelines. Such deviations represent potential risks and hence are highlighted in the project management plan, which is reviewed and approved.