Control mechanisms in software development projects

control mechanisms are proposed or recommended in software development and to examine which type or types of control the mechanisms exercise. If different control mechanisms are required for projects with some outsourced or distributed work, then the proposed analysis should expose such differences.

When examining the different control mechanisms, it became apparent that it was not always possible to neatly classify some mechanisms as mainly “behaviour” or mainly “transformation”. In such cases the mechanism is included in both sections.

2.3.3.1 Output control mechanisms.

Output control mechanisms are intended either to specify the outcomes that must be achieved or to determine whether or not the outcomes have been achieved. Examples of output controls are;

• Project goals or objectives

• Project constraints such as budget or schedule • Functional requirements

• Milestones, often a combination of schedule and examinable intermediate products • Acceptance test specifications

• Contract terms and conditions

Of these, the most common practice in software development is that of determining project goals or objectives. The goals range from the very high level organizational goals through to specific project goals that might be sub-divided into business goals, political goals and technical goals (Lientz and Rea, 2003). Sometimes the goals or objectives are simply to act as constraints on the project (Project Management Institute, 2000) while other objectives are very specific and intended to be achieved by the project or as a side effect of the project (Lientz and Rea, 2003 p28). Lientz and Rea propose that since most projects are deployed into an existing situation, it is necessary to measure the current situation so that it can be determined whether or not the project made a difference and, if so, what difference (Lientz and Rea, 2003 p25).

Page 30

The project requirements are variously referred to as scope (Project Management Institute, 2000; Lientz and Rea, 2003), statement of work (Kerzner, 1998) or requirements (Cleland and Ireland, 2002). In the context of types of project control, the project or product requirements are a type of output control. They determine what the project is to achieve without concern for how it is to be achieved.

Despite the fact that most output control is exercised at either end of a project, project

milestones have the attributes of output controls (Kerzner, 1998; Project Management Institute, 2000; Cleland and Ireland, 2002; Lientz and Rea, 2003). By themselves they attest whether or not something has been achieved without concern for how it may have been achieved.

Where most of the mechanisms so far in this section are invoked during planning, acceptance testing applies toward the end of the project to test whether or not the requirements or goals have been met (Hughes and Cotterell, 1999; Project Management Institute, 2000).

When the project management texts specifically dealt with procurement, more output control practices were described. The PMBOK (Project Management Institute, 2000) has a specific procurement knowledge area, while Lientz and Rea (2003) specifically identify practices related to outsourcing. Both are notable for the number of output-based controls mentioned and

specifically described as relevant. The most commonly mentioned practice, used in software development as well as many other fields, is the request for proposal (RFP). Although the RFP is very similar to a requirements specification or scope of works, it is a specific type of control used in a specific context and with a widely agreed and understood meaning. As the PMBOK describes it, an RFP is a type of procurement document used to solicit proposals from

prospective sellers. A Scope of Works is one of the inputs to its development. 2.3.3.2 Behavior control mechanisms

Most of the control mechanisms described or identified in the project management texts can be classified as behaviour control mechanisms. Behaviour control mechanisms are intended to control the behaviour of project team members either by constraining how they perform tasks or by reporting on how they are performing tasks. Examples of behaviour controls are:

• Project schedule/project scheduling • Development methodology or processes • Change control procedures

Page 31

Project schedule

The most common practice in project planning is to develop a work breakdown structure (Kerzner, 1998; Hughes and Cotterell, 1999; Project Management Institute, 2000; Cleland and Ireland, 2002; Lientz and Rea, 2003). A work breakdown structure divides the whole task into manageable subtasks, then allocates responsibility for performing the subtask to an appropriate group. By itself, a work breakdown structure does not determine the sequence in which tasks must be performed. That is left to a schedule, which also records the resources required for each task, the task duration, interdependencies between tasks and the occasional milestone.

Frequently, there is a distinction between the project work breakdown structure and a project activity network. The distinction contrasts subdivision of the work into manageable packages with the relationships between the various tasks of the activity network (Kerzner, 1998 p671). By itself, the work breakdown structure does not impose any control on the project team, but the project schedule does. In most project management texts, a schedule is assumed to contain a work breakdown structure.

The project schedule is normally developed during project planning, which is where most of the project control is implemented (Kerzner, 1998; Hughes and Cotterell, 1999; Project

Management Institute, 2000; Cleland and Ireland, 2002; Lientz and Rea, 2003). This is in contrast to control such as project audits, which would normally be conducted in response to some trigger that occurred during the project (Cleland and Ireland, 2002 p388). The control mechanisms that are usually developed during project planning are neither wholly intended to make the transformation process explicit nor wholly intended to increase the visibility of team members’ project behaviour. For example, a project schedule that would typically be developed using a tool such as Microsoft Project not only lists all the project tasks, their sequence and interdependencies, durations and required resources but will usually also record milestones and provide a means by which the project progress may be measured. The schedule makes the transformation process explicit as well as increasing the visibility of behaviour during the project.

A project schedule controls the behaviour of the project team members by determining when they undertake specific tasks, the scope of those tasks and the relationship to those team members undertaking other tasks.

Software development methodology

While some general project management texts refer to organizational procedures (Kerzner, 1998; Hughes and Cotterell, 1999; Cleland and Ireland, 2002), the software development industry has developed a large number of software development methodologies. While some are proprietary, many are publicly available, often published in books. The objective of a methodology is to

Page 32

describe nearly everything that must be done in a successful software development (Henderson- Sellers et al., 2004), at least to some level of detail that balances the need to be specific with the need to allow for differing circumstances. It is a set of tools, methods and practices used to produce software (Humphrey, 1989).

Software development is usually divided into a series of processes that align with the differing skills used to produce different artefacts. For example, there is normally a project planning process that produces a project plan, a requirements elicitation process that produces a collection of requirements, a system design process that produces a system design and so on. Each process may be divided into a number of tasks that combine to produce the output or, in the case of ISO 12207, a number of responsibilities that collaborate to produce the outcomes (ISO 12207, 2002). Methodologies describe the transformation process in sufficient detail to ensure all necessary activities are performed with a minimum of repetition. They can also describe the flow of work products through the processes and activities so that it is evident how the tasks must be sequenced.

Some methodologies are very high level and intended only as a framework. ISO 12207 is very high level, serving only to define a number of processes relevant to software development and a small amount of detail about each process but deliberately not describing how the processes would be selected and assembled for a specific project. In turn, ISO 12207 serves as a framework for process assessment, to assess how well a specific organization performs a selection of processes (ISO 15504, 1998). The Capability Maturity Model (CMM) defines the software development processes even though its primary purpose is to assess those processes (Paulk et al., 1993). Other methodologies are more specific and describe how the various tasks are to be performed (1994b; Mazza et al., 1994a).

Whatever their origin, software development methodologies increase the explicitness of the transformation process as well as increasing the visibility of software development behaviour, which would influence the likelihood of adopting behaviour control.

Change control

Most project management texts list change control as one of the project control mechanisms (Thomsett, 1989; Hughes and Cotterell, 1999; Project Management Institute, 2000; Cleland and Ireland, 2002) making it one of the more commonly advocated control mechanisms. This technique acknowledges that there will be requests for changes in the project requirements or objectives but that the changes need to be controlled to avoid needless activity such as implementing the same change twice, redoing work to resolve conflicts among different changes or undoing work to resolve contradictory changes. Generally, there is some form of review of the requested changes, often by a committee, to decide which of them will be

Page 33

accepted and how they will be incorporated into the project plan (Thomsett, 1989). The

activities involved in change control serve to increase the visibility of behaviours.

Project status reports

The highest visibility of behaviours, in terms of most widespread communications, comes from the practice of project status reporting. Typically the project manager gathers relevant project information and distributes it to the project stakeholders. The exact contents of a project status report may vary considerably between different projects but will have a similar intent to that described by Thomsett (1989):

• The state of the project - is it still proceeding to plan or not? • If not, what is the revised situation and causes for the variation? • What actions have been taken by the team to solve any problems? • What alternative scenarios are available?

• What actions can be taken by senior management?

Similarly the distribution may vary considerably between projects. Different stakeholders may require different information. Senior managers may only require summary information while managers overseeing multiple projects may require more detail to determine the possible effects of one project on another.

2.3.3.3 Clan control mechanisms.

Clan control mechanisms are those that promote or increase shared values among the project team. Examples of clan control mechanisms are;

• Published project objectives • Team meetings

• Project web pages or other project management information system • Project kick-off meetings

While the project’s objectives would normally be regarded as an output control, publishing them so that all team members understand what the project is trying to achieve fits the definition of clan control.

More directly recognisable as a clan control technique is that of team building. Leintz and Rea (2003) devote a chapter to choosing the team and, within that, a section on building a team mentality. They believe that team building begins with a project kick-off meeting which all of the critical team members should attend. Since Leintz and Rea are concerned specifically with

Page 34

international projects where team members may be distributed around the globe, they do

acknowledge that a physical presence may be difficult and that attendance by video conference is an alternative. At the first meeting, argue Leintz and Rea, it is important to instil a common sense of purpose and goal. They go on to give a description of ways to instil a greater degree of team mentality. One of the suggested mechanisms is to take a collaborative approach to

planning the work, a sentiment echoed by Thomsett when he advocates team driven project management (Thomsett, 1989 p6). Leintz and Rea also recommend that the project manager take advantage of opportunities to draw distributed team members, persons or organizations, into the project ‘clan’ by visiting them through rotated project meetings, regular and frequent site visits and sharing tasks between ‘head office’ and the distributed team members.

Less obvious is the use of a project management information system to promote a common understanding of the project (Cleland and Ireland, 2002). While project reporting may not be intended solely to instil shared project values, it will have the effect of promoting a shared understanding of the project.

In a recent article, Thomsett argues that software development project teams are different from teams of twenty or thirty years ago (Thomsett, 2002b). In an earlier time, a team may have remained together for long periods that may have spanned more than a single project whereas now teams are likely to be composed of a mix of contractors, consultants and others from various organizations that have no common allegiance. Thomsett argues that commonly

advocated team forming mechanisms are likely to be irrelevant and the whole concept of “team” should be questioned. Nevertheless he goes on to suggest that virtual teams, although different, still need to form some sort of “teamness”, even if that is more of a commercial transaction of joining a team for a common commercial purpose, that of completing the project, rather than the more club-like teams of old that shared some social values over and above the commercial objectives of the project.

Carmel (1999) expresses similar sentiments about the loss of “teamness” when comparing co- located teams to globally distributed teams. Although Carmel’s perspective differs from that of Thomsett, both conclude that modern software development teams are less likely to form through social interaction than did the co-located, stable teams of some years ago. 2.3.3.4 Input control Mechanisms

Input control is exercised through recruitment and training, often to instil a particular mindset. Some examples of input control mechanisms are:

• Recruiting project team members • Project-specific training

Page 35

Project management texts pay some attention to selecting project team members but it is usually in the context of engaging contractors or outsourced suppliers. Hughes and Cotterell (1999) briefly deal with team selection whereas Leintz and Rea (2003) devote a chapter to setting up the project organization structure, of which a significant proportion deals with the importance of selecting the project leader or project manager.

Although recruitment and training are frequently covered in texts, it is in the context of ensuring that the team members possess the skills required by the project plan than as any form of project control.

2.3.4 Summary

Mechanisms of control within software development projects can be classified as output, behaviour, input and clan control mechanisms. Each have specific conditions that favour their use but more than one control can operate within the same project simultaneously.

In document in software development (Page 44-50)