Management Information Systems Assignment

cHAPTER

9 BIS project management

LEARNING OUTCOMES

After reading this chapter, you will be able to:

■ understand the main elements of the project management approach;

■ relate the concept of project management to the creation of BIS;

■ assess the significance of the different tasks of the project manager;

■ outline different techniques for project management.

MANAGEMENT ISSUES

Managers need to ensure that their BIS projects will be completed satisfactorily, whether they are directly responsible, or if the project management is delegated to another person in the organisation, or an external contractor. From a managerial perspective, this chapter addresses the following questions:

■ What are the success criteria for a BIS project?

■ What are the attributes of a successful project manager?

■ Which project management activities and techniques should be performed by the project manager for a successful outcome?

CHAPTER AT A GLANCE

MAIN TOPICS

■ The project management process 322

■ Steps in project management 326

■ A project management tool: network analysis 338

FOCUS ON . . .

■ A project management methodology: PRINCE2 334

CASE STUDIES

9.1 Putting an all-inclusive price tag on successful IT 320

9.2 Project management: lessons can be learned from successful delivery 324

M09_BOCI6455_05_SE_C09.indd 319 10/13/14 4:49 PM

Part 2 BUSINESS INFORMATION SYSTEMS DEVELOPMENT320

Projects are unique, one-time operations designed to accomplish a specific set of objectives in a limited timeframe. Examples of projects include a building construction or introducing a new service or product to the market. In this chapter we focus on providing the technical knowledge that is necessary to manage information systems projects. Large information systems projects like construction projects may consist of many activities and must therefore be carefully planned and coordinated if a project is to meet its objectives.

The three key objectives of project management are shown in Figure 9.1. The job of project managers is difficult since they are under pressure to increase the quality of the information system within the constraints of fixed costs, budget and resources. Often it is necessary to make a compromise between the features that are implemented and the time and resources available – if the business user wants a particular new feature, then the cost and duration will increase or other features will have to be omitted.

A major issue in IT project management is the determination of a realistic assessment of the costs and benefits of an IT project. This information is required when deciding whether to proceed with the project and for making a reasonable assessment of project success. This issue is discussed in Case Study 9.1.

While it is difficult to control and plan all aspects of a BIS development project, the chance of success can be increased by anticipating potential problems and by applying corrective strategies. The PRINCE2 methodology is reviewed since it is used to assist in the delivery of BIS projects to time, cost and quality objectives. Network analysis techniques are also reviewed in this chapter, since they can be used to assist project planning and control activities by enabling the effects of project changes to be analysed.

INTRODUCTION

Projects

Projects are unique, one-time operations designed to accomplish a specific set of objectives in a limited timeframe.

Figure 9.1 Three key elements of project management

Time

Quality/ features Cost

Project manager must negotiate for more time,

more people or fewer features

Failure to derive the expected benefits from IT systems is legendary. Yet organisations still fail to recognise or accept why this occurs and generally do little to address the root causes in any meaningful way.

The first place to look is the application of the Return on Investment (ROI) tool as the arbiter for benefits delivery and the subsequent plans for

Putting an all-inclusive price tag on successful IT By Ron Barker

CASE STUDy 9.1

implementing the systems. An ROI is required by most organisations, but the tool is often applied without fully understanding all of the cost components (full disclosure).

By definition, IT projects tend to focus on dealing with the technical issues. It is these that get measured as the cost side of the change – usually the cost

M09_BOCI6455_05_SE_C09.indd 320 10/13/14 4:49 PM

321ChaPter 9 BIS PROjEcT MANAgEMENT

of hardware and software with some allowance for training. Typically, costs are grossly underestimated (often by 40 per cent or more) by failing to consider precisely those factors that are needed to deliver the return.

ROI is a technical measure taking expected returns and expected costs to determine the worth of the investment. The key word is ‘expected’. The reality, of course, is that the ROI calculation is no more than a forecast, based upon someone’s view of the costs and benefits. Realising the benefits forecast is where the hard work arises, there is often a drastic underestimate of the efforts required to ‘make it happen’. The underestimates are generally in:

■ ensuring compliance with the business strategy; ■ aligning the people with the processes the business

is changing to; ■ ensuring that behaviours are commensurate with

the required new ways of working.

This assumes processes are being changed – otherwise where are the benefits coming from? Which means there is an implicit assumption that people somewhere will be doing something differently. It is the need to ensure and facilitate this change that generates a high proportion of the total project costs. By including these costs some projects start to appear unprofitable. This, of course, is generally not in the interests of any systems suppliers. It may, however, stop some projects from getting off the ground and avoid some of the overspending we have seen in the past. If the way things are done in the business is being changed then there is a need to understand what that change means. There is a range of implementation approaches taken by companies including:

■ simple ROI and the ‘stuff it at ‘em’ approach that follows the principles of ‘if we tell them what to do and give them a bit of training then they’ll make it work’;

■ a considered approach that defines real business need and vision but then fails to communicate this through to the ‘what’s in it for me’ messages and thereby does not connect with the users;

■ development of a system that involves some users early and is well communicated to staff, but is not properly aligned to the organisation’s strategy and owned by specific, accountable people in the business.

Quite often, once the decision to invest is made, technology projects are devolved to the IT department who are then responsible for overseeing through delivery and implementation. Often these technically focused people are poorly qualified to understand the business nuances and may not have the required communications skills. Over and above this, who looks at the changes required in human behaviour? Who is addressing the motivational issues that will get the right people doing the right things?

A framework can be proposed to improve chances of success. This is based around the simple model of People, Process and Technology (PPT) with the added element of environment or context (PPTE). Context is the first parameter to get right. How does the development proposed relate to the business strategy? What is the desired outcome for the development, in business benefit terms, so that we know what is to be delivered and why? After thinking through the application needs and functions, the next useful question is how is it to be delivered? This should be viewed as a problem that the business deals with rather than abdicating it to the IT group.

Costs can then be assessed in outline for the whole PPTE model. This may include some scenario planning work fully to appreciate the different ways that the system may work, and identify the best options, prior to getting the technologists involved. A full disclosure ROI can then be calculated that takes all benefits and PPTE costs into account. This should include all of the people costs for effective change, from ownership and visions through stakeholder buy-in, to positive, user-led adoption. Decisions to proceed are now likely to be better informed and can be done on all fronts of process, technology and people readiness, perhaps with the ‘go’ decision requiring people readiness to be assured.

Truer costs will be understood and the full implications of benefits will emerge. The business’s responsible project owner will now have a budget that allows them to plan from concept to execution with holistic consideration of all PPTE elements. This will give positive adoption of systems that are pulled through by users who expect what they get and get what they expect. They will ‘pull’ the system through rather than having it shoved at them.

Source: Barker, R. (2007) Putting an all-inclusive price tag on successful IT. Financial Times. 30 May. © The Financial Times Limited 2012. All Rights Reserved.

QUESTION

Discuss the difficulties in estimating the costs and benefits of an IT project.

M09_BOCI6455_05_SE_C09.indd 321 10/13/14 4:49 PM

Part 2 BUSINESS INFORMATION SYSTEMS DEVELOPMENT322

Project managers need to control projects, and to achieve this they tend to use frameworks based on previous projects they have managed. The systems development lifecycle (SDLC) or waterfall model (introduced in Chapter 7) provides such a framework. The majority of project plans will divide the project plan according to the SDLC phases.

Context: where in the SDLC does project planning occur?

By John Plummer

Projects equal pounds. Ever wondered what all those programme managers and project leaders do? Earn cash, it seems. According to project management training providers APM Group (www.apmgroup.co.uk) a quarter of the UK’s GDP comes from projects. A full-time job. Many companies reorganised over the past decade to chase the project pound, which has had a profound impact on staff. ‘Projects are no longer “something extra”,’ says the website www.chiefprojectofficer.com, ‘they are the way work gets done at an increasing number of companies, from small start-ups to the likes of Hewlett Packard.’ Get trained. As income from projects has grown, so too has the market in accredited project management qualifications. More companies are sending staff on courses such as Prince2 (www.prince2.org.uk), a project management methodology owned by the Office of Government Commerce. Define your objectives. Every project begins with a plan. When will we start? What do we need? Can we do it alone, or do we need help? How long will it take? What will it cost? ‘These are typical questions asked at the start of any project and the answers are the building blocks of project management,’ says the Prince2 website. Expect to change. Projects that don’t evolve are the likeliest to wither so no matter how good your initial plan is, expect it to change. If you’re running a project that has been outsourced to your company, consider inviting a customer on to the project team to keep them informed, involved in decisions and better motivated. The advantages. ‘Project management’ may sound as sexy as the words ‘Charles Kennedy lap-dancing’, but don’t be fooled. ‘One of the advantages of working in projects is that you never know what you will be doing in six months,’ says Andrew Delo at the project management advisers Provek (www.provek.co.uk). ‘If you like uncertainty, it is an exciting environment.’

Source: Plummer, J. (2005) The key to … project planning. The Times, 26 May.

The key to . . . project planningMini case study

THE PROJECT MANAGEMENT PROCESS

When undertaking a BIS project, the project manager will be held responsible for delivery of the project to the traditional objectives of time, cost and quality. Many BIS have the attributes of a large-scale project in that they consume a relatively large amount of resources, take a long time to complete and involve interactions between different parts of the organisation. To manage a project of this size and complexity requires a good overview of the status of the project in order to keep track of progress and anticipate problems. The use of a structured project management process can greatly improve the performance of IS projects, which have become well known for their tendency to run over budget or be late as stated earlier. The ubiquity of projects and the challenge of project management is outlined in the mini case study ‘The key to … project planning’.

M09_BOCI6455_05_SE_C09.indd 322 10/13/14 4:49 PM

323ChaPter 9 BIS PROjEcT MANAgEMENT

An initial project plan will usually be developed at the initiation phase (Chapter 7). This will normally be a high-level analysis that does not involve the detailed identification of the tasks that need to occur as part of the project. It may produce estimates for the number of weeks involved in each phase, such as analysis and design, and for the modules of the system, such as data-entry and reporting modules. If the project receives the go-ahead, a more detailed project plan will be produced before or as the project starts. This will involve a much more detailed identification of all the tasks that need to occur. These will usually be measured to the nearest day or hour and can be used as the basis for controlling and managing the project. The detailed project plan will not be produced until after the project has commenced, for two reasons: 1. It is not practical to assess the detailed project plan until the project starts, since the cost

of producing a detailed project plan may be too high for it to be discarded if the project is infeasible.

2. A detailed project plan cannot be produced until the analysis phase has started, since estimates are usually based on the amount of work needed at the design and build phases of the project. This estimate can only be produced once the requirements for the system have been established at the analysis phase.

These points are often not appreciated and, we believe, are a significant reason for the failure of projects. Project managers are often asked to produce an estimate of the amount of time required to finish a project before the analysis phase, when insufficient information is at their disposal. Their answer should be:

I can give you an initial estimate and project plan based on similar projects of this scale at the initiation phase. I cannot give you a detailed, accurate project plan until the analysis is complete and the needs of the users and the business have been assessed. A detailed estimate can then be produced according to the amount of time it is likely to take to implement the users’ requirements.

Why do projects fail?

There has been a number of high-profile IT project failures in the UK public sector which underline the difficulties of IT project management. Despite these failures there are also a number of successes which generally receive less publicity. One reason for public-sector IT failures may be the sheer size and thus complexity of the projects. It is also difficult to compare performance with private-sector IT project performance as private companies are generally reluctant to disseminate knowledge regarding IT failures in order not to tarnish their reputation. Read Case Study 9.2 for more information on the success and failure of IT project management.

In general terms Lyytinen and Hirscheim (1987) researched the reasons for information systems projects failing. They identified five broad areas which still hold true today:

■ Technical failure stemming from poor technical quality – this is the responsibility of the organisation’s IS function.

■ Data failure due to (a) poor data design, processing errors and poor data management; and (b) poor user procedures and poor data quality control at the input stage. Responsibility for the former lies with the IS function, while that for the latter lies with the end-users themselves.

■ User failure to use the system to its maximum capability – may be due to an unwillingness to train staff or user management failure to allow their staff full involvement in the systems development process.

■ Organisational failure, where an individual system may work in its own right but fails to meet organisational needs as a whole (e.g. while a system might offer satisfactory

M09_BOCI6455_05_SE_C09.indd 323 10/13/14 4:49 PM

Part 2 BUSINESS INFORMATION SYSTEMS DEVELOPMENT324

operational information, it fails to provide usable management information). This results from senior management’s failure to align IS to overall organisational needs.

■ Failure in the business environment can stem from systems that are inappropriate to the market environment, failure in IS not being adaptable to a changing business environment (often rapid change occurs), or a system not coping with the volume and speed of the underlying business transactions.

It is apparent that a diverse range of problems can cause projects to fail, ranging from technical problems to people management problems.

It is the responsibility of the project manager to ensure that these types of problems do not occur, by anticipating them and then taking the necessary actions to resolve them. This will involve risk management techniques, described in Chapter 8. Case Study 9.2 shows the type of problems that occur, the reasons behind them and advice for new project managers on how to manage projects successfully.

The team behind Britain’s most high profile infrastructure project in recent times says there was no ‘magic ingredient’ in its successful delivery, but having £9.3bn available is likely to have helped.

The construction of the Olympic park in east London was widely hailed as a success long before the first athlete set foot in it last month.

While the fate of a few key venues is still unclear, there is a strong consensus on the park’s delivery. ‘On time and under budget’ is the most common appraisal batted around by politicians and Olympic organisers – though the latter description is not entirely accurate.

The success of the build has prompted some soul- searching about lessons that can be applied to future developments, partly to avoid repeats of projects that went wrong, such as Wembley Stadium.

‘In reputation terms [the Olympic project] was an opportunity, clearly,’ says Sir John Armitt, the man in charge of the body that built the park.

He says that the UK’s reputation for major construction and infrastructure developments has always been high, but admits that Wembley ‘didn’t go so well’.

The fact that the world was watching and judging as the Olympic park was erected on top of former industrial wasteland added more pressure to get it right. ‘The Olympic project is the most high profile project that you could imagine,’ he says.

Sir John says successful programme management starts from the client, in this case the Olympic Delivery

Project management: lessons can be learned from successful delivery By Vanessa Kortekaas

CASE STUDy 9.2

Authority, which he led. He says the ODA knew what it valued, balancing cost and quality, and made that clear to its suppliers.

‘If you talk to the suppliers on the Olympics what they will say is that the ODA was an intelligent client, and a consistent client in contractual terms,’ says Sir John. Consistency, he says, reinforced to suppliers what was expected of them.

The ODA oversaw the procurement of more than £6bn worth of contracts to deliver the Olympic park, and arguably its most important contract was with its delivery partner – CLM, a consortium that includes CH2M Hill.

But the creation and structure of the ODA itself was also key to the success of the project.

‘One of the weakest points of London’s bid originally was the sense that the UK, and London in particular, had such a range of agencies and bodies that would need to be corralled together to make anything happen,’ says Tim Jones, a partner at Freshfields law firm who was heavily involved in the negotiations that spawned the ODA.

The ODA served as a ‘single governmental interface’ with planning authority, he says, removing the need for time-consuming negotiations with various local bodies.

It also assumed power for some aspects of Olympic transport and security. ‘The ODA was where all those functions were really brought together,’ says Mr Jones. Having a delivery partner enabled the relatively small ODA to function efficiently, he adds.

M09_BOCI6455_05_SE_C09.indd 324 10/13/14 4:49 PM

325ChaPter 9 BIS PROjEcT MANAgEMENT

In order that a project is clearly defined and meets its objectives it is important to define the roles of the staff involved and how those roles are organised within a particular project. The principal roles encountered in a project are outlined below. Note that these roles may be known by other names or be undertaken by more than one person or roles may be combined and allocated to a single person, depending on the organisational context and the size of the project.

Project sponsor

The project sponsor role is to provide a justification of the project to senior management. The role includes defining project objectives and time, cost and quality performance measures. The role also involves obtaining finance and appointing a project manager. The project sponsor is accountable for the success or failure of the project in meeting its business objectives.

Project manager

Appointed by the project sponsor the project manager role is to provide day-to-day management and ensure project objectives are met. This involves selection and management of the project team, monitoring of the time, cost and quality performance measures and informing the project sponsor and senior management of progress. In larger projects the project manager may delegate certain areas of the project (e.g. programming) to team leaders for day-to-day management.

Project organisation

That sentiment is echoed in an ODA report on the project, which says having a delivery partner gave it ‘flexibility and agility’ and their partnership underpinned its success.

But not everything went to plan. Sir John says the impact of the financial crisis on delivering the athletes’ village was the ‘biggest challenge’ the ODA faced during the construction period.

Both the village and the media centre had to be bailed out by the government.

‘You couldn’t get a sensible financial package out of the banks, so the decision was made to use contingency money to fund [the village] and then sell the asset as soon as we could after… to recover the money,’ says Sir John.

Some £557m was recouped last year, when a Qatari- backed consortium bought half of the homes in the village and several plots of land in the Olympic park. Triathlon Homes had already paid £268m for 1,379 units, which are earmarked for affordable housing.

The contingency money that was drawn on for the village was available only because the Olympics budget was revised to £9.3bn in 2007, from an original estimate of £2.4bn. The ODA spent £6.8bn delivering the Olympic park.

The immovable deadline also drove the project. The opening ceremony was always going to happen on July 27, and frequent missions from the International Olympic Committee served as a potent reminder.

Cross-party support was another unique factor from which the build benefited. ‘You don’t always get that [support],’ admits Sir John.

It is unclear whether local authorities would be willing to yield some elements of power again, under different circumstances.

Mr Jones is hopeful but unsure. ‘They only agreed to do it that time because it was the Olympics and they all wanted this to happen,’ he says. ‘Maybe it is rather optimistic to suspect that you would get such support for another project, that people would actually surrender their power.’

Source: Kortekaas, V. (2012) Project management: lessons can be learned from successful delivery. Financial Times. 19 August. © The Financial Times Limited 2012. All Rights Reserved.

QUESTION

Discuss the delivery of the Olympic Park in terms of time, cost and quality performance objectives.

M09_BOCI6455_05_SE_C09.indd 325 10/13/14 4:49 PM

Part 2 BUSINESS INFORMATION SYSTEMS DEVELOPMENT326

Project user

The project user is the person or group of people who will be utilising the outcome of the information systems project. The user(s) should be involved in the definition and implementation of the system to ensure successful ongoing usage.

Other major roles that may be defined in the project include the following.

Quality manager

This role involves defining a plan containing procedures that ensure quality targets are met. Quality can be defined as ‘conformance to customer requirements’. Total quality management (TQM) attempts to establish a culture that supports quality. The European Foundation for Quality Management (EFQM) has provided a model that allows an organisation to quantify its progress towards a total quality business. For more information on quality management in relation to IS projects see Cadle and Yeates (2007).

Risk manager

All projects contain some risk that the investment made will not achieve the required business objectives. Risk management has become increasingly important in providing processes that attempt to reduce risk in complex and uncertain projects (see Chapter 8 for more details on risk management).

In many situations the project is organised by the main roles of project sponsor, project manager and project user. However, in complex or larger projects other organisational bodies may be encountered. A steering committee brings together a variety of interested people such as users, functional staff (e.g. finance, purchasing) and project managers in order that all stakeholder views are taken into consideration. At a lower level user groups may be instituted to represent the views of multiple potential users.

STEPS IN PROJECT MANAGEMENT

Before the planning process can commence, the project manager will need to determine not only the business aims of the project but also the constraints under which they must be achieved. Major constraints include the overall budget for project development, the timescale for project completion, staffing availability, and hardware and software requirements for system development and running of the live system. These questions form the framework for the project and it is important that they be addressed at the beginning of the project planning process. It is usual, however, to only prepare detailed plans of the early stages of the project at this point.

The project management process includes the following main elements:

■ estimate; ■ schedule/plan; ■ monitoring and control; ■ documentation.

Estimation

Estimation allows the project manager to plan for the resources required for project execution through establishing the number and size of tasks that need to be completed in the project. This is achieved by breaking down the project repeatedly into smaller tasks until

Estimation

Estimation allows the project manager to plan for the resources required for project execution through establishing the number and size of tasks that need to be completed in the project.

M09_BOCI6455_05_SE_C09.indd 326 10/13/14 4:49 PM

327ChaPter 9 BIS PROjEcT MANAgEMENT

a manageable chunk of one to two days’ work is defined. Each task is given its own cost, time and quality objectives. It is then essential that responsibility be assigned to achieving these objectives for each particular task. This procedure should produce a work breakdown structure (WBS) that shows the hierarchical relationship between the project tasks. It is an important part of estimation. Figure 9.2 shows how the work on producing a new accounting system might be broken down into different tasks. Work on systems projects is usually broken down according to the different modules of the system. In this example, three levels of the WBS are shown for the accounts receivable module down to its printing function. All the other five modules of the system would also have similar tasks.

At the start of the project in the initiation or startup phase, an overview project plan is drawn up estimating the resources required to carry out the project. It is then possible to compare overall project requirements with available resources.

Project constraints can be resource-constrained (limited by the type of people or hardware resources available) or time-constrained (limited by the deadline).

The next step, after the project has been given the go-ahead, is a more detailed estimate of the resources needed to undertake the tasks identified in the work break-down structure. If highly specialised resources are required (e.g. skilled analysts), then the project completion date may have to be set to ensure that these resources are not overloaded. This is a resource-constrained approach. Alternatively, there may be a need to complete a project in a specific timeframe (e.g. due date specified by customer). In this case, alternative resources (e.g. subcontractors) may have to be utilised to ensure timely project completion. This is a time-constrained approach. This information can then be used to plan what resources are required and what activities should be undertaken over the lifecycle of the project.

Effort time and elapsed time

When estimating the amount of time a task will take, it is important to distinguish between two different types of time that need to be estimated. Effort time is the total amount of work that needs to occur to complete a task. The elapsed time indicates how long in time (such as calendar days) the task will take (duration). Estimating starts by considering the amount of effort time that needs to be put in to complete each task. Effort time is then converted into

Work breakdown structure (WBS)

This is a breakdown of the project or a piece of work into its component parts (tasks).

Project constraints

Projects can be resource-constrained (limited by the type of people, monetary or hardware resources available) or time- constrained (limited by the deadline).

Figure 9.2 Work breakdown structure (WBS) for an accounting system

Accounting system

Control program

General ledger

Sales order

processing

Accounts receivable

Accounts payable

Print receipts

View all receipts

Data entry

Print option dialog

Send to printer

Print review

Effort and elapsed time

Effort time is the total amount of work that needs to occur to complete a task. The elapsed time indicates how long in time (such as calendar days) the task will take (duration).

M09_BOCI6455_05_SE_C09.indd 327 10/13/14 4:49 PM

Part 2 BUSINESS INFORMATION SYSTEMS DEVELOPMENT328

elapsed time, which indicates how long the task will take through real-time measures such as months or days. Effort time does not usually equal elapsed time, since if a task has more than one worker the elapsed time will be less than the effort time. Conversely, if workers on a task are also working on other projects, then they will not be available all the time and the elapsed time will be longer than the effort time. An additional factor is that different workers may have different speeds. A productive worker will need less elapsed time than an inexperienced worker. These constraints on elapsed time can be formalised in a simple equation:

Elapsed time = Effort times × Availability

%

× Work rate %

The equation indicates that if the availability or work rate of a worker is less than 100 per cent, the elapsed time will increase proportionally, since availability and work rate are the denominators on the right-hand side of the equation. The equation will need to be applied for each worker, who may have different availabilities and work rates. These factors can be entered into a project management package, but to understand the principles of estimation better the activity on project planning should be attempted (see Activity 9.1 below).

From the example in the activity, it can be seen that several stages are involved in estimation:

1. estimate effort time for average person to undertake task; 2. estimate different work rates and availability of staff; 3. allocate resources (staff) to task; 4. calculate elapsed time based on number of staff, availability and work rate; 5. schedule task in relation to other tasks.

Cadle and Yeates (2007) provide the following techniques for estimating the human resource and capacity requirements for the different stages of an IS project:

1. Estimating the feasibility study. This stage will not usually be estimated in detail, since it will occur at the same time as or before a detailed project estimate is produced. The feasibility stage consists of tasks such as interviewing, writing up interview information and report writing in order to assess the financial, technical and organisational acceptability of the project. The estimate will depend greatly on the nature of the project, but also on the skills and experience of the staff involved. Thus it is important to keep records of previous performance of personnel for this activity in order to improve the accuracy of future estimates.

2. Estimating analysis and design phases. The analysis phase will typically involve collection of information about the operation of current systems and the specification of requirements for the new system. This will lead to the functional requirements specification, defining the new system in terms of its business specification. The design phase will specify the new computer-based system in terms of its technical content. This will need to take into account organisational policies on design methodologies and hardware and software platforms. In order to produce an accurate estimate of the analysis and design phases, it is necessary to produce a detailed description of each task involved. As in the feasibility stage, time estimates will be improved if timings are available for previous projects undertaken.

3. Estimating build and implementation. This stage covers the time and resources needed for the coding, testing and installation of the application. The time taken to produce a program will depend mainly on the number of coding statements required and the complexity of the program. The complexity of the coding will generally increase with the size of the program and will also differ for the type of application. A lookup table can be derived from experience to give the estimated coding rate dependent on the

100 100

M09_BOCI6455_05_SE_C09.indd 328 10/13/14 4:49 PM

329ChaPter 9 BIS PROjEcT MANAgEMENT

complexity of the project for a particular development environment. This is discussed in more detail below.

Estimating tools

Statistical methods can be used when a project is large (and therefore complex) or novel. This allows the project team to replace a single estimate of duration with a range within which they are confident the real duration will lie. This is particularly useful for the early stage of the project when uncertainty is greatest. The PERT approach described later in this chapter allows optimistic, pessimistic and most likely times to be specified for each task – from these a probabilistic estimate of project completion time can be computed.

The most widely used economic model is the constructive cost model (COCOMO), described by Boehm (1981) and first proposed by staff working at US consultancy Doty Associates. The constructive cost model is used to estimate the amount of effort required to complete a project on the basis of the estimated number of lines of program code. Based on an analysis of software projects, the model attempts to predict the effort required to deliver a project based on input factors such as the skill level of staff. A simplified version of the model is:

WM = C × (KDSI)K × EAF

where WM = number of person months, C = one of three constant values dependent on development mode, KDSI = delivered source lines of code × 1000, K = one of three constant values dependent on development mode, EAF = effort adjustment factor.

The three development modes or project types are categorised as organic (small development teams working in a familiar environment), embedded (where constraints are made by existing hardware or software) and semi-detached, which lies somewhere between the two extremes of organic and embedded. In order to increase the accuracy of the model, more detailed versions of COCOMO incorporate cost drivers such as the attributes of the end product and the project environment. The detailed version of the model calculates the cost drivers for the product design, detailed design, coding and unit test, and integration and test phases separately.

These techniques may take a considerable amount of time to arrive at a reasonably accurate estimate of personnel time required. However, since the build phase will be a major part of the development budget, it is important to allocate time to undertake detailed estimation.

The COCOMO method derives the time estimates it produces from an estimate of the number of lines of programming code to be written. A method of estimating the number of lines of code was developed by Alan Albrecht of IBM (Albrecht and Gaffney, 1983). Function point analysis is based on counting the number of user functions the application will have. It is possible to do this in detail after the requirements for the application have been defined. The five user function categories are:

1. number of external input types; 2. number of external output types; 3. number of logical internal file types; 4. number of external interface file types; 5. external enquiry types.

Each of these types of input and output is then weighted according to its complexity and additional factors applied according to the complexity of processing. The function point estimate can be compared to the function point count of previous completed information systems to give an idea of the number of lines of code and length of time that are expected.

Constructive cost model (COCOMO)

A model used to estimate the amount of effort required to complete a project on the basis of the estimated number of lines of program code.

Function point analysis

A method of estimating the time it will take to build a system by counting up the number of functions and data inputs and outputs and then comparing to completed projects.

M09_BOCI6455_05_SE_C09.indd 329 10/13/14 4:49 PM

Part 2 BUSINESS INFORMATION SYSTEMS DEVELOPMENT330

Note that both the COCOMO and function point analysis techniques were developed before the widespread use of applications with graphical user interfaces, interactive development environments for ‘graphical programming’, rapid applications development (RAD) and client/server databases to store information. These new techniques have made it faster to develop applications and the original data sets and principles on which these models are based have been updated to account for this. In order to take account of developments in software and software development methodologies COCOMO II has been developed (Boehm et al., 2001).

Scheduling and planning

Scheduling is determining when project activities should be executed. The finished schedule is termed the project plan.

Resource allocation is part of scheduling. It involves assigning resources to each task. Once the activities have been identified and their resource requirements estimated, it is necessary to define their relationship to one another. There are some activities that can only begin when other activities have been completed. This is termed a serial relationship and is shown graphically in Figure 9.3.

The execution of other activities may be totally independent and thus they have a parallel relationship, as shown graphically in Figure 9.4. Here, after the design phase, three activities must occur in parallel before implementation can occur.

For most significant projects there will be a range of alternative schedules which may meet the project objectives.

For commercial projects, computer software will be used to assist in diagramming the relationship between activities and calculating network durations. From a critical path network and with the appropriate information, it is usually possible for the software automatically to generate Gantt charts, resource loading graphs and cost graphs, which are discussed later in the chapter. Project management software, such as Microsoft Project, can be used to assist in choosing the most feasible schedule by recalculating resource requirements and timings for each operation. The network analysis section of this chapter provides more information on project scheduling techniques.

Scheduling

Scheduling involves determining when project activities should be executed. The finished schedule is termed the project plan.

Resource allocation

This activity involves assigning a resource to each task.

Figure 9.3 Serial relationship of activities

CodeDesign Test

Figure 9.4 Parallel relationship of activities

Code

Write documentation

Design Test Procure

hardware

M09_BOCI6455_05_SE_C09.indd 330 10/13/14 4:49 PM

331ChaPter 9 BIS PROjEcT MANAgEMENT

The scenario You are required to construct a project plan for the following BIS development project. Your objective is to schedule the project to run in the shortest time possible. The plan should include all activities, the estimated, elapsed and effort time, and who is to perform each activity. In addition, it is necessary to indicate the sequence in which all the tasks will take place. The programs can be scheduled in any order, but for each program the design stage must come first, followed by the programming and finally the documentation.

Within the context of the exercise, you can assume that the detailed systems analysis has already been carried out and that it is now necessary to perform the design, programming and documentation activities. For the purposes of this exercise, we will not include the testing and implementation phases.

Present your project plan in the form of a Gantt chart (see Figure 9.10 later) showing each task, the sequence in which tasks will be performed, the estimated effort and elapsed time and the resource allocated to each task.

The activities There are five programs in the system. Each has a different level of difficulty:

■ Program 1 Difficult ■ Program 2 Easy ■ Program 3 Moderate ■ Program 4 Moderate ■ Program 5 Difficult

For each level of difficulty, the design, programming and documentation tasks take different amounts of effort time:

Design ■ Easy programs 1 day ■ Moderate programs 2 days ■ Difficult programs 4 days

Programming ■ Easy programs 1 day ■ Moderate programs 3 days ■ Difficult programs 6 days

Documentation ■ Easy programs 1 day ■ Moderate programs 2 days ■ Difficult programs 3 days

Resources In order to complete the project plan, you need to know what resources you have available. For each resource, there are two variables:

■ Work rate. This describes the speed at which the resource works (i.e. a work rate of 1.0 means that a task scheduled to take one day should only take one day to complete satisfactorily; a work rate of 1.5 means that a task scheduled for three days should only take two days etc.).

■ Availability. Each resource will be available for certain amounts of time during the week. 100% availability = 5 days per week, 50% availability = 2.5 days per week, etc.

In planning your project, work to units of half a day. For simplicity, any task which requires a fraction of half a day should be rounded up (e.g. 1.6 days should be rounded up to 2 days). Also, a resource can only be scheduled for one task at any one time!

Project planning exerciseActivity 9.1

➨

M09_BOCI6455_05_SE_C09.indd 331 10/13/14 4:49 PM

Part 2 BUSINESS INFORMATION SYSTEMS DEVELOPMENT332

Resource availability

System designer 1 (SD1) ■ Work rate 1.0 ■ Availability 100%

Systems designer 2 (SD2) ■ Work rate 1.5 ■ Availability 40%

Systems designer 3 (SD3) ■ Work rate 0.5 ■ Availability 50%

Programmer 1 (P1) ■ Work rate 2.0 ■ Availability 40%

Programmer 2 (P2) ■ Work rate 1.0 ■ Availability 100%

Programmer 3 (P3) ■ Work rate 0.5 ■ Availability 60%

Technical author 1 (TAl) (to do the documentation) ■ Work rate 1.0 ■ Availability 60%

Technical author 2 (TA2) ■ Work rate 0.5 ■ Availability 100%

Technical author 3 (TA3) ■ Work rate 2.0 ■ Availability 40%

Tips

1. This exercise will be easier if you structure the information well. You could do this by producing three matrices for the design, programming and documentation tasks. Each of them should show across the columns three different tasks for easy, moderate and difficult programs. Each row should indicate how long the different types of workers will take to complete the task.

2. To calculate the length of elapsed time for each cell in the matrix, it is easiest to use this relationship:

Elapsed time = Effort times × Availability

%

× Work rate %

3. A calculator may help!

4. When drawing the Gantt chart, you may want to put your best people on the most difficult tasks, as you would on a real project.

100 100

M09_BOCI6455_05_SE_C09.indd 332 10/13/14 4:49 PM

333ChaPter 9 BIS PROjEcT MANAgEMENT

When a project is under way, its objectives of cost, time and quality in meeting targets must be closely monitored. Monitoring involves ensuring that the project is working to plan once it has started. This should occur daily for small-scale tasks or weekly for combined activities. Control or corrective action will occur if the performance measures deviate from plan. It is important to monitor and assess performance as the project progresses, in order that corrective action can be taken before it deviates from plan to any great extent. Milestones (events that need to happen on a particular date) are defined so that performance against objectives can be measured (e.g. end of analysis, production of first prototype).

Computer project management packages can be used to automate the collection of project progress data and production of progress reports.

Achieving time, cost and quality objectives

As stated earlier, the project should be managed to achieve the defined objectives of time, cost and quality. The time objective is met by ensuring that the project is monitored in terms of execution of tasks within time limits. Corrective action is taken if a variance between actual and planned time is observed. The cost objective is achieved by the use of human resource and computing resource budgets and, again, variation between estimated and actual expenditure is noted and necessary corrective action taken. To ensure that quality objectives are met it is necessary to develop a quality plan which contains a list of items deliverable to the customer. Each of these will have an associated quality standard and procedure for dealing with a variance from the required quality level defined in the quality plan.

Project structure and size

The type of project structure required will be dependent on the size of the team undertaking the project. Projects with up to six team members can simply report directly to a project leader at appropriate intervals during project execution. For larger projects requiring up to 20 team members, it is usual to implement an additional tier of management in the form of team leaders. The team leader could be responsible for either a phase of the development (e.g. analysis, design) or a type of work (e.g. applications development, systems development). For any structure it is important that the project leader ensures consistency across development phases or development areas as appropriate. For projects with more than 20 members, it is likely that additional management layers will be needed in order to ensure that no one person is involved in too much supervision.

Reporting project progress

The two main methods of reporting the progress of a project are by written reports and verbal reports at meetings of the project team. It is important that a formal statement of progress is made in written form, preferably in a standard report format, to ensure that everyone is aware of the current project situation. This is particularly important when changes to specifications are made during the project. In order to facilitate two-way communication between team members and team management, regular meetings should be arranged by the project manager. These meetings can increase the commitment of team members by allowing discussion of points of interest and dissemination of information on how each team’s effort is contributing to the overall progression of the project.

Monitoring and control

Monitoring and control

Monitoring involves ensuring the project is working to plan once it is started. control is taking corrective action if the project deviates from the plan.

M09_BOCI6455_05_SE_C09.indd 333 10/13/14 4:49 PM

Part 2 BUSINESS INFORMATION SYSTEMS DEVELOPMENT334

Ensuring adequate project documentation is a key aspect of the role of the project manager. Software development is a team effort and documentation is necessary to disseminate design information throughout the team. Good documentation reduces the expense of maintenance after project delivery. Also, when members of the team leave the department or organisation, the coding they have produced must be understandable to new project members. Often a development methodology will require documentation at stages during the project in a specific format. Thus documentation must be an identified task in the development effort and a standard document format should be used throughout the project (this may be a standard such as BS 5750 or ISO 9001).

Documents that may be required include the following:

■ Workplan/task list. For each team member a specified activity with start and finish dates and relevant coding standard should be defined.

■ Requirements specification. This should clearly specify the objectives and functions of the software.

■ Purchase requisition forms. Required if new software and hardware resources are needed from outside the organisation.

■ Staffing budget. A running total of personnel costs, including expenses and subsistence payments. These should show actual against predicted expenditure for control purposes.

■ Change control documents. To document any changes to the project specification during the project. A document is needed to highlight the effect on budgets and timescales of a change in software specifications.

Documentation

Project documentation

Documentation is essential to disseminate information during project execution and for reference during software maintenance.

A PROJECT MANAGEMENT METHODOLOGy: PRINCE2 FOCUS ON…

PRINCE2 (published in 1996) is a process-based project management methodology based on PRINCE (published in 1989), which stands for Projects in Controlled Environments. The development of PRINCE2 involved a consortium of 150 European organisations and is a de facto standard used by the UK government and widely used by the private sector, both in the UK and internationally. The PRINCE2 method for managing projects is designed to help you work out who should be involved and what they are responsible for. It also provides a set of processes to work through and explains what information you should be gathering along the way.

The key features of PRINCE2 are:

■ its focus on business justification; ■ a defined organisation structure for the project management team; ■ its product-based planning approach; ■ its emphasis on dividing the project into manageable and controllable stages; ■ its flexibility to be applied at a level appropriate to the project.

Thus the PRINCE2 methodology means managing the project in a logical organised way, following defined steps. The PRINCE2 methodology says that a project should have an:

■ organised and controlled start, i.e. organise and plan things properly before leaping in; ■ organised and controlled middle, i.e. when the project has started, make sure it continues

to be organised and controlled; ■ organised and controlled end, i.e. when you’ve got what you want and the project has

finished, tidy up the loose ends.

PRINCE2

A process-based project management methodology for effective IS project management.

M09_BOCI6455_05_SE_C09.indd 334 10/13/14 4:49 PM

335ChaPter 9 BIS PROjEcT MANAgEMENT

The PRINCE2 Process Model

In order to describe what a project should do when, PRINCE2 has a series of processes which cover all the activities needed on a project from starting up to closing down. The PRINCE2 Process Model (Figure 9.5) defines each process with its key inputs and outputs together with the specific objectives to be achieved and activities to be carried out.

Each element in the process model will now be described.

Directing a project

This process is aimed at the project board and involves the management and monitoring of the project via reports and controls from the startup of the project until its closure. Key processes for the project board are:

■ initiation (starting the project off on the right foot); ■ stage boundaries (commitment of more resources after checking results so far); ■ ad hoc direction (monitoring progress, providing advice and guidance, reacting to

exception situations); ■ project closure (confirming the project outcome and controlled close).

Starting up a project

This is a pre-project process designed to ensure that the prerequisites for initiating the project are in place. The work of the process is built around the production of three elements:

■ ensuring that the information required for the project team is available; ■ designing and appointing the project management team; ■ creating the initiation stage plan.

Initiating a project

The objectives of initiating a project include:

■ agree whether or not there is sufficient justification to proceed with the project; ■ establish a stable management basis on which to proceed; ■ document and confirm that an acceptable business case exists for the project; ■ agree to the commitment of resources for the first stage of the project.

Figure 9.5 PRINCE2 Process Model

Starting up a project

Initiating a project

Controlling a stage

Directing a project

Planning

Managing product delivery

Managing stage

boundaries

Closing a project

M09_BOCI6455_05_SE_C09.indd 335 10/13/14 4:49 PM

Part 2 BUSINESS INFORMATION SYSTEMS DEVELOPMENT336

Managing stage boundaries

This process provides the project board with key decision points on whether to continue with the project or not. The objectives of the process include:

■ assure the project board that all deliverables planned in the current stage plan have been completed as defined;

■ provide the information needed for the project board to assess the continuing viability of the project;

■ provide the project board with information needed to approve the current stage’s comple- tion and authorise the start of the next stage, together with its delegated tolerance level;

■ record any measurements or lessons which can help later stages of this project and/or other projects.

Controlling a stage

This process describes the monitoring and control activities of the project manager involved in ensuring that a stage stays on course and reacts to unexpected events. Throughout a stage there will be a cycle consisting of:

■ authorising work to be done; ■ gathering progress information about that work; ■ watching for changes; ■ reviewing the situation; ■ reporting; ■ taking any necessary corrective action.

Managing product delivery

The objective of this process is to ensure that planned products are created and delivered by:

■ making certain that work on products allocated to the team is effectively authorised and agreed accepting and checking work packages;

■ ensuring that the work is done; ■ assessing work progress and forecasts regularly; ■ ensuring that completed products meet quality criteria.

Closing a project

The purpose of this process is to execute a controlled close to the project. The process covers the project manager’s work to wrap up the project either at its end or at premature close. Most of the work is to prepare input to the project board to obtain its confirmation that the project may close. The objectives of closing a project therefore include:

■ check the extent to which the objectives or aims set out in the project initiation document (PID) have been met;

■ confirm the extent of the fulfilment of the project initiation document (pid) and the customer’s satisfaction with the deliverables;

■ make any recommendations for follow-on actions; ■ prepare an end project report; ■ notify the host organisation of the intention to disband the project organisation and

resources.

Planning

Planning is a repeatable process, and plays an important role in other processes, main ones being:

M09_BOCI6455_05_SE_C09.indd 336 10/13/14 4:49 PM

337ChaPter 9 BIS PROjEcT MANAgEMENT

■ planning an initiation stage ■ planning a project ■ planning a stage ■ producing an exception plan.

PRINCE2 organisation

The following are the main project management roles in PRINCE2.

Project manager

The project manager is responsible for organising and controlling the project. The project manager will select people to do the work on the project and will be responsible for making sure that the work is done properly and on time. The project manager also draws up the project plans that describe what the project team will actually be doing and when they expect to finish.

Customer, user and supplier

The person who is paying for the project is called the customer or executive. The person who is going to use the results or outcome of the project is called the user. On some projects the customer and user may be the same person. The person who provides the expertise to do the actual work on the project is called the supplier or specialist. All these people need to be organised and coordinated so that the project delivers the required outcome within budget, on time and to the appropriate quality.

Project board

Each PRINCE2 project will have a project board made up of the customer (or executive), someone who can represent the user side and someone to represent the supplier or specialist input. In PRINCE2 the people are called customer, senior user and senior supplier respectively. The project manager reports regularly to the project board, keeping them informed of progress and highlighting any problems they can foresee. The project board is responsible for providing the project manager with the necessary decisions for the project to proceed and to overcome any problems.

Project assurance

Providing an independent view of how the project is progressing is the job of project assurance. In PRINCE2, there are three views of assurance: business, user and specialist. Each view reflects the interests of the three project board members. Assurance is about checking that the project remains viable in terms of costs and benefits (business assurance), checking that the users’ requirements are being met (user assurance), and that the project is delivering a suitable solution (specialist or technical assurance). On some projects, the assurance is done by a separate team of people called the project assurance team, but the assurance job can be done by the individual members of the project board themselves.

Project management methodologies compared

In addition to PRINCE2 many other project management methodologies (as opposed to development process methodologies such as SSADM, JSD and STRADIS) exist, such as BPMM (www.bates.ca) and IDEAL (www.sei.cmu.edu/ideal). In addition, methodologies have been developed ‘in-house’ by companies for their own use or have been developed commercially and require a licence fee before more information is released.

M09_BOCI6455_05_SE_C09.indd 337 10/13/14 4:49 PM

Part 2 BUSINESS INFORMATION SYSTEMS DEVELOPMENT338

Critical path diagrams are used extensively during scheduling and monitoring to show the planned activities of a project and the dependencies between these activities. For example, network analysis will show that activity C can only take place when activity A and activity B have been completed. Once a network diagram has been constructed, it is possible to follow a sequence of activities, called a path, through the network from start to end. The length of time it takes to follow the path is the sum of all the durations of activities on that path. The path with the longest duration gives the project completion time. This is called the critical path because any change in duration in any activities on this path will cause the whole project duration to become shorter or longer. Activities not on the critical path will have a certain amount of slack time in which the activity can be delayed or the duration lengthened and not affect the overall project duration. The amount of slack time is the difference between the path duration the activity is on and the critical path duration. By definition, all activities on the critical path have zero slack. Note that there must be at least one critical path for each network and there may be several critical paths. The significance of the critical path is that if any node on the path finishes later than the earliest finish time, the overall network time will increase by the same amount, putting the project behind schedule. Thus any planning and control activities should focus on ensuring that tasks on the critical path remain within schedule.

Critical path network diagrams are sometimes called ‘PERT charts’, but the correct technical meaning of this term is detailed in a later section.

An important function of a company’s information systems manager is to review which methodologies should be employed to improve the quality of its systems development processes. Some methodologies may add a structure to a company process which improves its efficiency. Others may enforce restrictions which reduce the efficiency of the process and increase the cost and duration of the project.

You are a project manager in a company of 400 people. The company has a history of developing systems that meet the needs of the end-users well, but can sometimes be over six months late. The managing director has decided that the project will be conducted by internal IS development staff. Your role as the owner of the system in which the project will be implemented is to manage the project using other resources, such as the IS department, as you see fit.

QUESTION

From the information given in the preceding section and using any relevant books, decide whether to use a formal project methodology such as PRINCE2 or IDEAL or a different approach. Justify your answer, giving a brief evaluation of what you perceive as the advantages and disadvantages of the methodology.

An assessment of PRINCE2Activity 9.2

A PROJECT MANAGEMENT TOOL: NETWORK ANALySIS

Critical path

Activities on the critical path are termed critical activities. Any delay in these activities will cause a delay in the project completion time.

The critical path method (CPM)

Once the estimation stage has been completed, the project activities should have been identified, activity durations and resource requirement estimated and activity relationships identified. Based on this information, the critical path diagrams can be constructed using either the activity-on-arrow (AOA) approach or the activity-on-node (AON) approach. The issues involved in deciding which one to utilise will be discussed later. The following description of critical path analysis will use the AON method.

M09_BOCI6455_05_SE_C09.indd 338 10/13/14 4:49 PM

339ChaPter 9 BIS PROjEcT MANAgEMENT

The critical path method (CPM) uses critical path diagrams to show the relationships between activities in a project.

The activity-on-node (AON) method

In an activity-on-node network, the diagramming notation shown in Figure 9.6 is used. Each activity task is represented by a node with the format shown in the figure. Thus a completed network will consist of a number of nodes connected by lines, one for each task, between a start and an end node, as shown in Figure 9.7.

The diagram illustrates sequential activities such as from activity B to activity C and parallel activities such as activities D, F and G. Once the network diagram has been drawn using the activity relationships, the node information can be calculated, starting with the earliest start and finish times. These are calculated by working from left to right through the network, in the ‘forward pass’. Once the forward pass has been completed, it is possible to calculate the latest start and finish times for each task. This is achieved by moving right to left along the network, backward through time, in the ‘backward pass’. Finally, the slack or float value can be calculated for each node by taking the difference between the earliest start and latest start (or earliest finish and latest finish) times for each task. There should be at least one (there may be more than one) critical path running through the network where each task has a slack value of 0. In Figure 9.7 the critical path can be stated as running through the activities B, C, E, F and H. Any delay to these critical activities will increase the current project duration of 83. The critical path represents the sequence of activities that takes the longest time to complete and thus defines the shortest time that the project can complete in. Activities not on the critical path have a slack time, for example activity A has a slack time of 32, which represents how late the activity can be without effecting the overall project duration.

Critical path method (CPM)

critical path diagrams show the relationship between activities in a project.

Figure 9.6 Activity on node notation

DurationEarliest start Earliest finish

Slack/floatLatest start Latest finish

Activity number/letter Activity description

Figure 9.7 Activity on node network diagram

A 300 30

3232 62

B 150 15

00 15 C 3015 45

015 45

G 745 52

1762 69

E 1045 55

045 55 F 1455 69

055 69

D 1545 60

954 69

H 1469 83

069 83 END

083 83

083 83START 00 0

00 0

M09_BOCI6455_05_SE_C09.indd 339 10/13/14 4:49 PM

Part 2 BUSINESS INFORMATION SYSTEMS DEVELOPMENT340

The activity-on-arrow (AOA) method

The format for the activity-on-arrow method will now be described. The symbols used in this method are as shown in Figure 9.8.

Rather than considering the earliest and latest start and finish times of the activities directly, this method uses the earliest and latest event times, as below:

■ Earliest event time – determined by the earliest time at which any subsequent activity can start.

■ Latest event time – determined by the latest time at which any subsequent activity can start.

Thus for a single activity the format would be as shown in Figure 9.9. There has historically been a greater use of the activity-on-arrow (AOA) method, but

the activity-on-node (AON) method is now recognised as having a number of advantages, including the following:

■ Most project management computer software uses the AON approach. ■ AON diagrams do not need dummy activities to maintain the relationship logic. ■ AON diagrams have all the information on timings and identification within the node

box, leading to clearer diagrams.

Figure 9.8 Activity-on-arrow notation

Event label

Earliest event time

Latest event time

Activity label

Activity duration

Figure 9.9 Calculating event times for an activity-on-arrow network

A

25

10 0

0 20

25

25

Gantt charts

Show the duration of parallel and sequential activities in a project as horizontal bars on a chart.

Gantt charts

Although network diagrams are ideal for showing the relationship between project tasks, they do not provide a clear view of which tasks are being undertaken over time and particularly of how many tasks may be undertaken in parallel at any one time. Gantt charts are used to summarise the project plan by showing the duration of parallel and sequential activities in a project as horizontal ‘time bars’ on a chart. The Gantt chart provides an overview for the project managers to allow them to monitor project progress against planned progress and so provides a valuable information source for project control.

M09_BOCI6455_05_SE_C09.indd 340 10/13/14 4:49 PM

341ChaPter 9 BIS PROjEcT MANAgEMENT

Figure 9.10 shows a typical Gantt chart produced using Microsoft Project. Note that some phases such as ‘Phase 1 – software evaluation’ have subactivities such as ‘consult and set criteria’ and ‘evaluate alternatives – report’. Each of these subactivities has a certain number of days and a corresponding cost assigned to it. Milestones are activities that are planned to occur by a particular day, such as ‘Purchase hardware by 17/06’. These are shown as triangles. They are significant events in the life of the project, such as completion of a prototype.

To draw a Gantt chart manually or using a spreadsheet or drawing package, follow these steps:

1. Draw a grid with the tasks along the vertical axis and the timescale (for the whole project duration) along the horizontal axis.

2. Draw a horizontal bar across from the task identifier along the left of the chart, starting at the earliest start time and ending at the earliest finish time.

3. Indicate the slack amount by drawing a line from the earliest finish time to the latest finish time.

4. Repeat steps 2 and 3 for each task.

If the network analysis is being conducted using project management software, then the Gantt chart is automatically generated from information in the network analysis.

Milestone

This denotes a significant event in the project such as completion of a prototype.

Figure 9.10 Gantt chart showing activities and milestones

Capacity loading graphs

The basic network diagram assumes that all tasks can be undertaken when required by the earliest start times calculated from the node dependency relationships. However, resources required to undertake tasks are usually limited and the duration of an individual task or the

Source: Screenshot frame reprinted by permission from Microsoft corporation

M09_BOCI6455_05_SE_C09.indd 341 10/13/14 4:49 PM

Part 2 BUSINESS INFORMATION SYSTEMS DEVELOPMENT342

number of parallel tasks may be limited. In order to calculate the capacity requirements of a project over time, the capacity requirements associated with each task are indicated on the Gantt chart. From this, a capacity loading graph can be developed by projecting the loading figures on a time graph. The capacity loading graphs show the resources required to undertake activities in a project. If the network analysis is being conducted using project management software, then the capacity loading graph is automatically generated from information in the network analysis.

Capacity loading graphs

capacity loading graphs show the resources required to undertake activities in a project.

Project cost graphs

Show the financial cost of undertaking the project.

Project crashing

Refers to reducing the project duration by increasing spending on critical activities.

Project costs

The previous discussion has concentrated on the need to schedule and control activities in order to complete the entire project within a minimum timespan. However, there are situations in which the project cost is an important factor. If the costs of each project are known, then it is possible to produce a project cost graph which will show the amount of cost incurred over the life of the project. This is useful in showing any periods when a number of parallel tasks are incurring significant costs, leading to the need for additional cashflow at key times. In large projects it may be necessary to aggregate the costs of a number of activities, particularly if they are the responsibility of one department or subcontractor. As a control mechanism, the project manager can collect information on cost to date and percentage completion to date for each task to identify any cost above budget and take appropriate action without delay.

Trading time and cost: project crashing

Within any project there will be a number of time–cost trade-offs to consider. Most projects will have tasks that can be completed with an injection of additional resources, such as equipment or people. Reasons to reduce project completion time include:

■ to reduce high indirect costs associated with equipment; ■ to reduce new product development time to market; ■ to avoid penalties for late completion; ■ to gain incentives for early completion; ■ to release resources for other projects.

The use of additional resources to reduce project completion time is termed crashing the project. The idea is to reduce overall indirect project costs by increasing direct costs on a particular task. One of the most obvious ways of decreasing task duration is to allocate additional labour to a task. This can be either an additional team member or through overtime working. To enable a decision to be made on the potential benefits of crashing a task, the following information is required:

■ the normal task duration; ■ the crash task duration; ■ the cost of crashing the task to the crash task duration per unit time.

The process by which a task is chosen for crashing is by observing which task can be reduced for the required time for the lowest cost. As stated before, the overall project completion time is the sum of the task durations on the critical path. Thus it is always necessary to crash a task that is on the critical path. As the duration of tasks on the critical path is reduced, however, other paths in the network will also become critical. If this

M09_BOCI6455_05_SE_C09.indd 342 10/13/14 4:49 PM

343ChaPter 9 BIS PROjEcT MANAgEMENT

PERT replaces the fixed activity duration used in the CPM method with a statistical distribution which uses optimistic, pessimistic and most likely duration estimates.

The critical path method (CPM) described above was developed by the company Du Pont during the 1950s to manage plant construction. The PERT approach was formulated by the US Navy during the development of the Polaris submarine-launched ballistic missile system in the same decade (Sapolsky, 1972). The main difference between the approaches is the ability of PERT to take into consideration uncertainty in activity durations.

The PERT approach attempts to take into account the fact that most task durations are not fixed, by using a beta probability distribution to describe the variability inherent in the processes. The probabilistic approach involves three time estimates for each activity:

■ optimistic time – the task duration under the most optimistic conditions; ■ pessimistic time – the task duration under the most pessimistic conditions; ■ most likely time – the most likely task duration.

As stated, the beta distribution is used to describe the task duration variability. To derive the average or expected time for a task duration, the following equation is used:

Expected duration = Optimistic + (4 × Most likely) + Pessimistic

The combination of the expected time and standard deviation for the network path allows managers to compute probabilistic estimates of project completion times. A point to bear in mind with these estimates is that they only take into consideration the tasks on the critical path and discount the fact that slack on tasks on a non-critical path could delay the project. Therefore the probability that the project will be completed by a specified date is the probability that all paths will be completed by that date, which is the product of the probabilities for all the paths.

Project evaluation and review technique (PERT)

PERT

PERT replaces the fixed activity duration used in the cPM method with a statistical distribution which uses optimistic, pessimistic and most likely duration estimates.

6

Project network simulation

In order to use the PERT approach, it must be assumed that the paths of a project are independent and that the same tasks are not on more than one path. If a task is on more than one path and its actual completion time was much later than its expected time, it is obvious that the paths are not independent. If the network consists of these paths and they are near the critical path time, then the results will be invalid.

Simulation can be used to develop estimates of a project’s completion time by taking into account all the network paths. Probability distributions are constructed for each task, derived from estimates provided by such data collection methods as observation and historical data. A simulation then generates a random number within the probability distribution for each task. The critical path is determined and the project duration calculated. This procedure is repeated a number of times (possibly more than 100) until there are sufficient data to construct a frequency distribution of project times. This distribution can be used to make a probabilistic assessment of the actual project duration. If greater accuracy is required, the process can be repeated to generate additional project completion estimates which can be added to the frequency distribution.

happens, it will require the crashing process to be undertaken on all the paths that are critical at any one time.

M09_BOCI6455_05_SE_C09.indd 343 10/13/14 4:49 PM

344 Part 2 BUSINESS INFORMATION SYSTEMS DEVELOPMENT

The main benefit of using the network analysis approach is the requirement to use a structured analysis of the number and sequence of tasks contained within a project, so aiding understanding of resource requirements for project completion. It provides a number of useful graphical displays that assist understanding of such factors as project dependencies and resource loading, a reasonable estimate of the project duration and the tasks that must be completed on time to meet this duration (i.e. the critical path), and a control mechanism to monitor actual progress against planned progress on the Gantt chart. It also provides a means of estimating any decrease in overall project time by providing extra resources at any stage and can be used to provide cost estimates for different project scenarios.

Limitations to consider when using network analysis include remembering that its use is no substitute for good management judgement in such areas as prioritising and selecting suppliers and personnel for the project. Additionally, any errors in the network such as incorrect dependency relationships or the omission of tasks may invalidate the results. The tasks’ times are forecasts and are thus estimates that are subject to error. PERT and simulation techniques may reduce time estimation errors, but at the cost of greater complexity which may divert management time from more important issues. Also time estimates for tasks may be greater than necessary to provide managers with slack and ensure that they meet deadlines. Slack time that does exist may be ‘wasted’ by not starting activities until the last possible moment and thus delaying the project if they are not completed on time.

1. Projects are unique, one-time operations designed to accomplish a specific set of objectives in a limited timeframe with a limited budget and resources.

2. Major roles in project organisation include the project sponsor, the project manager and the project user. The project sponsor provides a justification of the project to senior management. The project manager role is to provide clearly defined goals and ensure that adequate resources are employed on the project. The project user who will be utilising the system should be involved in the definition and implementation of the system.

3. The main elements in the project management process include estimate, schedule and plan, monitoring and control, and documentation.

4. A work breakdown structure splits the overall project task into a number of more detailed activities in order to facilitate detailed estimation of resources required.

5. Projects can be resource-constrained (limited by resource) or time-constrained (limited by the deadline).

6. Scheduling involves producing a project plan which determines when activities should be executed.

7. Once under way a project can be monitored against the defined objectives of time, cost and quality.

8. Documentation is essential in reducing the expense of project maintenance.

9. PRINCE2 is an example of a project management methodology. An example of a systems development methodology is RAD.

10. Critical path analysis shows the activities undertaken during a project and the dependencies between them. The critical path is identified by making a forward and then a reverse pass through the network, calculating the earliest and latest activity start/finish times respectively.

11. Gantt charts provide an overview of what tasks are being undertaken over time. This allows the project manager to monitor project progress against planned progress.

SUMMARy

Benefits and limitations of the network analysis approach

M09_BOCI6455_05_SE_C09.indd 344 10/13/14 4:49 PM

345ChaPter 9 BIS PROjEcT MANAgEMENT

12. Capacity loading graphs provide an indication of the amount of resource needed for the project over time.

13. Cost graphs provide an indication of monetary expenditure over the project period.

14. Project crashing consists of reducing overall indirect project costs (e.g. by reducing the project duration) by increasing expenditure on a particular task.

15. To reduce the length of a project we need to know the critical path of the project and the cost of reducing individual activity times.

16. The PERT approach provides a method of integrating the variability of task durations into the network analysis.

1. What are the main elements of the project management process?

2. What are the main project aims of the PRINCE2 methodology?

3. What information is required for the construction of a critical path diagram?

4. What information do the Gantt chart and the PERT chart convey?

5. Define the term ‘critical path’.

6. What is the difference between effort time and elapsed time?

EXERCISES

Self-assessment exercises

Discussion questions

1. Draw a Gantt chart for the following AON network (Figure 9.11).

2. ‘One of the most difficult parts of project management is getting the estimates right.’ Discuss.

Figure 9.11 Activity-on-node network

2 7

A 300 3

332 62

B 150 1

00 15 C 3015 4

015 45

G 745 5

162 69

E 1045 5

045 55 F 1455 6

055 69

D 1545 6

954 69

H 1469 8

069 83 EN 083 83

083 83START 00 0

00 0

1. Explore the features of a project management computer package such as Microsoft Project. Evaluate its use in the project management process.

Essay questions

M09_BOCI6455_05_SE_C09.indd 345 10/13/14 4:49 PM

346

Albrecht, A.J. and Gaffney, J. (1983) ‘Software function, source lines of code and development effort prediction’, IEEE Transactions on Software Engineering, SE-9, 639–48

Boehm, B.W. (1981) Software Engineering Economics, Prentice-Hall, Englewood cliffs, Nj

Boehm, B.W., Abts, C., Winsor Brown, A., Chulani, S., Clark, B.K., Horowitz, E., Madachy, Cadle, J. and Yeates, D. (2007) Project Management for Information Systems, 5th edition, Financial Times Prentice Hall, Harlow

Lyytinen, K. and Hirscheim, R. (1987) ‘Information systems failures: a survey and classification of the empirical literature’, Oxford Surveys in IT, 4, 257–309

Sapolsky, H.M. (1972) The Polaris System Development: Bureaucratic and Programmatic Success in Government, Harvard University Press, Boston, MA

346

Examination questions

Part 2 BUSINESS INFORMATION SYSTEMS DEVELOPMENT

1. Evaluate the roles undertaken by people in a project organisation.

2. What are the main elements in the project management process?

3. Evaluate the use of the PRINCE2 project management methodology.

4. Explain the difference between portraying a project plan as a Gantt chart and as a PERT chart.

5. What is the importance of conducting monitoring and control when managing a project?

6. Why is it difficult and often impossible for a software project manager to balance the three constraints of time, budget and quality? You should relate your answer to two different aspects of the quality of the delivered information system.

7. What is the difference between elapsed time and effort time? How are the two factors related in terms of the availability and work rate of different staff? Describe this in words, or using an equation or an example.

References

Further reading

Brooks, F.P. (1995) The Mythical Man-Month: Essays on Software Engineering – Anniversary Edition, Addison-Wesley, Reading, MA.

Fenton, N.E. and Bieman, J. (2014) Software Metrics: A Rigorous and Practical Approach, 3rd edition, PWS Publishers, London.

Garmus, D. and Herron, D. (2000) Function Point Analysis: Measurement Practices for Successful Software Projects, Addison-Wesley, Upper Saddle River, Nj

Greasley, A. (2013) Operations Management, 3rd edition, john Wiley, chichester.

Hughes, B. and Cotterell, M. (2009) Software Project Management, 5th edition, Mcgraw-Hill, Maidenhead.

Kerzner, H. (2013) Project Management: A Systems Approach to Planning Scheduling and Controlling, 11th edition, john Wiley, New York.

2. Compare the different alternatives that are available for the critical path method of network analysis.

3. What is the most effective method of estimating the duration of an information systems development project?

M09_BOCI6455_05_SE_C09.indd 346 10/13/14 4:49 PM

347ChaPter 9 BIS PROjEcT MANAgEMENT

Web sites with further information on project management methodologies are as follows:

http://www.prince-officialsite.com/ PRINcE2 official site.

www.prince2.com website of ILX group who offer PRINcE2 training.

www.bates.ca BPMM.

www.sei.cmu.edu/ideal IDEAL.

www.pmi.org Project Management Institute.

https://at-web1.comp.glam.ac.uk/staff/dwfarthi/projman.htm Dave Farthing’s software project management web page has many links to project management resources.

Kerzner, H. (2013) Project Management Metrics, KPIs, and Dashboards: A Guide to Measuring and Monitoring Project Performance, 2nd edition, john Wiley, chichester.

Lock, D. (2013) Project Management, 10th edition, gower, Aldershot.

Maylor, H. (2010) Project Management, 4th edition, Financial Times Prentice Hall, Harlow.

Persse, J.R. (2007) Project Management Success with CMMI: Seven CMMI Process Areas, Prentice-Hall, Upper Saddle River, Nj.

Selby, R.W. (2007) Software Engineering: Barry W. Boehm’s Lifetime Contributions to Software Development, Management, and Research, Wiley-Interscience, Huboken, Nj.

Web links

M09_BOCI6455_05_SE_C09.indd 347 10/13/14 4:49 PM