1 PROJECTS AND PROJECT WORK
LEARNING OUTCOMES
When you have completed this chapter you should be able to demonstrate an understanding of the following:
• the definition of a project;
• the purpose of project planning and control;
• the typical activities in a system development life cycle;
• system and project life cycles;
• variations on the conventional project life cycle;
• transition strategies;
• the purpose and content of the business case;
• types of planning documents;
• post-implementation reviews.
1.1 PROJECTS
A project may be defined as a group of related activities carried out to achieve a specific objective. Examples of projects include building a bridge, making a film and re-organising a company. The outcome of a project is usually a new or modified system that creates benefits for an organisation, or, in the case of public sector projects, for society. Many IT projects implement new information technology (IT) applications within organisations. These are technical, but also involve changing the organisation in some way.
As well as business change projects, some IT-related projects generate new products, as in the case of computer games. These too would be expected to generate benefits for an organisation; in this case, new sales and increased income.
Difficult projects often involve innovation: a product different from anything before might be created; or new methods of delivery might be used. This differs from business as usual (BAU), where you are doing a routine job. A complication for IT specialists is that you often do a combination of BAU and project work.
A project comes about when one or more people have an idea about a desirable product or change. For this to become a project, a business case is needed showing that the value of the benefits of completing the project will be greater than the costs of implementing and operating the new (or revised) system that the project would create. This will not only need to consider business concerns, but also the technical difficulties of the project. This is underlined by the alternative name of feasibility study for the business case.
The project that emerges from a business case should have the following:
• A defined start point, which is when
▪ the exploration of the idea moves into an organised implementation;
▪ the idea obtains business backing and a project sponsor – an individual or group within an organisation who takes ownership of the project and ensures that it has the appropriate financial resources;
▪ a commitment is made to provide the necessary resources;
▪ responsibilities are defined;
▪ initial plans are produced.
• A set of objectives, which
▪ drive the actions of the organisation and project team towards a common goal;
▪ should be stated and understood at the start of the project;
▪ should be clear and unambiguous.
• A set of outputs or deliverables, which enable the objectives to be achieved.
• A date by which the objectives should be met and a budget setting the maximum allowable cost of the project.
• A unique purpose – routine activities are not projects.
• Benefits for the organisation which justify carrying out the project, and which are ideally measurable and greater than costs.
In some cases, the cost of the project is greater than the immediate benefits, but completion of the project enables other projects to be implemented that will reap the benefits – this is often the case with IT infrastructure projects. In this case, the work may be organised as a programme comprising several projects which together achieve the programme’s objectives.
1.2 SUCCESSFUL PROJECTS
To be successful, a project should:
• enable the stated objectives to be achieved;
• be delivered on time and within budget;
• deliver a system that performs to agreed specifications, including those relating to quality;
• satisfy the project sponsor and other interested parties. The term stakeholder refers to anyone who has an interest in the project; their role is discussed further in Section 8.3.
These are project objectives. The IT functions delivered, including both hardware and software, should enable the organisation to meet its business objectives. There will be other actions needed that do not involve IT development. For example, moving to web-based sales would require home delivery services to be negotiated. These business actions need to be part of the overall plan.
A new website supported by a new delivery service could enable an organisation to sell its products online to a wider market. However, while these project objectives might be achieved, the business objective of selling more products might be denied because of an external factor such as a general downturn in the market. The products that the project delivers are distinguished from its outcomes – how it actually changes the outside world.
Objectives are often called success criteria. If they are satisfied, then the project can be deemed a success. There could be several ways by which the success criteria might be achieved.
Well-defined success criteria are SMART (Specific, Measurable, Achievable, Resource-constrained and Time-constrained). For example, ‘increasing market share’ is too vague. ‘Creating an online booking system that will be used by at least 30 per cent of customers in its first year’ is more specific and measurable. As well as being specific and measurable, success criteria must be clearly achievable. If it is clear that they are not, people are likely to ignore them. Finally, part of the statement of objectives for a project will always define a deadline and an overall target cost.
In summary, the project must have a specified cost, a specified time/duration and meet a specified business requirement. These three specifications are closely linked. Any change to one will affect the others. The project objectives that relate to cost, time and the degree to which functional and quality requirements are satisfied (‘scope’) are often called the ‘project triangle’.
The project sponsor and users typically want a system with a broad scope – capable of a multitude of functions – to be delivered immediately and at low cost. Generally, this is not possible and the agreed project objectives will be a compromise between cost, time and scope.
If the scope of requirements strays outside this area of compromise, it will increase cost and/or delivery time. The costs of the project could therefore exceed the value of the benefits. Say the deadline for project completion has to be brought forward; to compensate, the scope could be reduced. This might well reduce the benefits of the project. Alternatively, more staff could be employed to work in parallel on the project, which would increase costs – and some project risks.
While this project book-keeping is important, the perceived value of the benefits of a project may in fact be quite subjective. The final judges of the success or failure of a project will be the project sponsor and the users of the products of the project. Sensitivity to their needs will be as important as the letter of any contract.
THE WATER HOLIDAY COMPANY INTEGRATION SCENARIO
The Water Holiday Company is a new business entity formed by the merger of two companies. One, Canal Dreams, had specialised in hiring out canal boats to holiday-makers in the UK. The other, Minotours, had chartered out yachts in the Aegean and Mediterranean seas as part of package holidays.
A marketing decision has been made to merge the websites for the two businesses, and the opportunity will be taken to extend access to online systems for making bookings and payments to smartphones. Whenever a sales transaction is made, there is a legal requirement to send the customer a follow-up email as confirmation. This email will be made into a vehicle for cross-selling, for example local car-hire.
A long-term goal is to centralise all Canal Dreams and Minotours operations (apart from boatyards and marinas) at a new, single green-field site. The objectives of these changes are: (i) to reduce staff by removing duplicated business functions across the two formerly separated companies; and (ii) to exploit the opportunities for entering new boat-hire-related markets, such as river cruising in continental Europe.
In order to meet these business objectives, the proposed system will need certain functionalities. For instance, it should allow the potential customer to check the availability of a particular kind of a boat moored at a particular locality at a time convenient to the prospective hirer. These functional requirements specify what the system will do and include quality requirements. For example, if it takes too long for the system to respond to a query, your prospective hirer may swap to a competing website.
Requirements will include not just those of the organisation but also those imposed by external bodies, such as legal requirements relating to distance selling. This is one example of the growing importance of organisations ensuring compliance with the regulatory authorities.
COMPLEMENTARY READING
Holt, J. and Newton, J. (eds) (2020) A Practical Guide to IT Law, 3rd edn. Swindon: BCS.
For a more detailed source on legal issues, see Murray, A. (2016) Information Technology Law: The law and society, 3rd edn. Oxford: Oxford University Press.
Each functional requirement carries a cost. There is also an overall project cost requirement. The potential additional income through extra bookings and staff savings in the Water Holiday Company example on the previous page might not be enough to meet the cost of implementing the system.
Boating holidays are a seasonal business and so implementation of system integration will need to be at a quiet time of the year before the bookings for the next season start to come in. This implies a certain deadline for system implementation.
1.3 PROJECT MANAGEMENT
Having established and agreed objectives, we can now move to planning. Having produced good plans, monitoring and effective control of the project will then be needed to fulfil the plans and achieve the agreed objectives. The project manager is someone with experience of overseeing implementation work and takes responsibility for controlling the work in accordance with the plans. There should also be someone who is the project sponsor and understands the business environment in which the new system is to be installed. The project manager interacts with the project sponsor to ensure business needs are met.
A successful project cannot be guaranteed, but the following will help to enable success:
• Clearly defined roles and responsibilities: these must be clearly defined, documented and agreed.
• Clear objectives and scope: managers who embark on projects without clearly establishing the scope of the expected deliverables, together with cost, time and quality objectives, are creating problems for the future. At the start of the project, there should be terms of reference, a project charter or some other document that defines the project objectives. More detailed requirements would be developed within this scope.
• Control: it is important to establish at the outset how best to control the work and how to exercise that control. This will be specified in a project management plan.
• Change procedures: ideally, the project manager would work in a world where there is no change or uncertainty. Unfortunately, it has to be recognised that there is uncertainty and that change will happen. Appropriate change procedures are needed to deal with it. Chapter 4 describes these.
• Reporting and communication: clear reporting of project progress and any problems allows remedial action to be taken quickly. Effective communication with all stakeholders can help avoid conflicts.
A project management method is a set of processes used to run a project in a controlled and predictable fashion. The design and development procedures by which the objectives of the project are satisfied – for example, the use of object-orientated analysis – constitute the development methods.
There are various project management methods. A well-known one in the UK is PRINCE2. In general, project management methods are applicable to a broad range of project types, whereas development methods are specific to projects with particular types of deliverables. This is because different deliverables require different development methods. Organising an office move, developing a software application and providing disaster recovery facilities are all projects needing their own methods of implementation, but all are controllable using the same project management processes. Different parts of a project often need different development methods, but the project management method will be common across it.
ACTIVITY 1.1
Assume that you are the manager of an office department that is going to be relocated to a building five miles away. Day-to-day management of the move will be delegated to one of your staff. What would be the main sequence of activities needed to plan and carry out the move? You want to leave as much of the detailed work as possible to your subordinates, but at which key points would you need to be involved to check progress?
Solution pointers for the activity can be found at the end of the chapter.
1.4 SYSTEM DEVELOPMENT LIFE CYCLE
Dividing a development method into a sequence of processes is a widely accepted practice. This allows systems to be designed and implemented using a methodical and logical approach. The number and names of these processes will vary from organisation to organisation. In some cases, stages will be combined or split.
With IT projects, there tends to be a divide between those that create new products and those that adapt existing applications and components. Generally speaking, the processes shown in Table 1.1 belong to the system development life cycles (SDLC) that apply to both types of IT project.
This suggests a particular sequence of processes. However, an application under development could be delivered in incremental segments (see Section 1.7.3). Thus, one software component could be coded while another was still being specified. The key point is that all these technical processes have to be dealt with somewhere within the project.
Each process creates one or more tangible products or deliverables. Delivery of the products of each process can act as a milestone at which we can judge the progress and continuing viability of the project.
You could well work in an environment where the concern is with implementing business change. Here the focus tends to be on identifying and adapting existing applications provided by vendors. Because the components already exist, the design and construction processes are not carried out. Instead, a selection process is devised consisting of methods of evaluating the suitability of candidate products. These could be services that are delivered via the cloud. The products to be used are then selected. Some element of customisation is usually needed to modify the product for local use. An acceptance test will almost certainly be carried out.
Table 1.1 Activities in SDLCs for Build versus Adapt projects
| Build | Adapt |
| Initiation | |
| Identification of the business case | |
| Project set-up | |
| Requirements elicitation and analysis | As for build, plus definition of selection criteria |
| Design | Identification of potential applications, services and suppliers |
| Construction | Evaluation and selection |
| Customisation | |
| Acceptance testing | |
| Transition to operation | |
| Review and maintenance |
It can be seen above that ‘build versus buy’ questions will have a major impact on the design of the system development life cycle for the project. This question is part of a broader set of questions that need to be answered about how exactly the desired outcomes of the project are to be met in practical terms. These practical activities and products can be referred to collectively as the ‘solution’. A major concern at this stage is establishing that the preferred solution will in practice lead to the business objectives being met.
Build versus buy
A basic software engineering principle is to avoid developing new functionality where existing tried and tested code already exists. The advantages of buying functionality are:
• It already exists, so it can be installed more quickly.
• It can be seen in action, so users can get a good idea of its quality.
• Existing users will have effectively tested it by reporting any defects, which will then have been removed by the supplier, so the functionality is likely to be more reliable.
• As there are many different organisations using the functionality, development costs will be shared and the cost of the application should be cheaper than if you had built it yourself.
• You do not have to employ software developers to build the new system, who may then become surplus to requirements.
• The vendor should supply updates to deal with statutory changes, so maintenance of the installed system will not be a responsibility of the host organisation.
However, there are disadvantages in buying existing applications, which may encourage the building of new software:
• Off-the-shelf software may not meet all the particular requirements of the host organisation. It could even have features you do not need, and this could confuse users.
• The organisation may have to change its business processes to fit in with the way in which the off-the-shelf application works.
• If you adopt an off-the-shelf application, you can be as good as your competitors who have the same system, but you cannot be better than them.
• Once you have adopted a particular off-the-shelf package, it may be difficult to change. Off-the-shelf software is often leased on an annual licence and if the vendor increases the licence fee, you may be trapped into having to pay it.
• If the vendor ceases to trade, this may put you in a difficult situation if you are dependent on vendor support for such things as training and updates to the system.
We will now look at the typical stages in an IT-related project life cycle.
1.4.1 Initiation
The first two processes – initiation and the identification of the business case – are, strictly speaking, not part of the project. Their purpose is to establish the justification for the project: an outcome could be a decision not to go ahead with the project.
The objective of project initiation is to decide the most appropriate way to respond to a request for some work to be done, while taking into account any business or technical strategies that the host organisation might have.
An organisation’s managers see a need that can only be satisfied by some form of project. The need might be a problem to be solved, something to add to an existing system or some new way of delivering value to the organisation. The initiation process checks that a problem or opportunity really exists and the change is desirable, and whether a project is the best way to implement the change. The result is a decision by the project sponsor on whether resources should be spent on further investigation of the feasibility of the proposal, including the business case for it. Terms of reference should be drawn up, outlining the scope of the proposal to be investigated and authorising staff to carry out the investigation. Staff carrying out the investigation need to have permission to gather information from those working in the areas affected, along with other stakeholders.
There are situations where an organisation’s business objectives are best achieved through a programme; that is, a number of different projects, each dealing with a different element of the project. In this case most of the initiation tasks for a component project will have already been done when the programme was initiated.
1.4.2 Identification of the business case
The business case, or feasibility study, assesses whether the proposed development is viable in terms of the balance of costs and benefits, the technical requirements and the organisation’s business objectives. The deliverable is a feasibility report which, among other things, presents the business with a range of options aimed at providing a solution.
Apart from the question of business viability – the benefits being greater than the costs – factors influencing the decision to adopt a particular option include:
• Budget constraints: the benefits may be greater than the estimated costs, but does the organisation have the resources to pay for the investment? If it does have the resources, is this the best project to spend them on?
• Technical constraints: can the proposed project be completed with the technology currently available? This will require the setting out of a technical strategy or ‘solution’ that provides practical steps for the achievement of the project’s objectives.
• Time constraints: can the proposed project be completed in the available time?
• Organisational constraints: can the organisation cope with the changes that the new development will demand?
One or more of these constraints may prevent a project from being developed any further. The content of the business case is discussed in more detail in Section 1.9.
In some cases, the business objectives can only be met by carrying out more than one project. For example, a new data centre may require a construction project for a new building, which is treated as a separate project from the installation of IT equipment. As noted earlier, these projects may be grouped into a programme.
1.4.3 Project set-up
Based on the recommendation of the feasibility or business case report, the organisation will decide whether to go ahead with the full project. At this point a group variously called the steering committee, project board or project management board is set up to oversee the project in the organisation’s interests. A project manager needs to be appointed and an initial project team set up to start work.
More detailed planning for the project takes place. Important decisions will be taken about how the declared project objectives are to be fulfilled. New terms of reference for the project to implement the new system, as opposed to simply investigating its feasibility, are drawn up.
1.4.4 Requirements elicitation and analysis
This phase defines the requirements of the new system in detail and identifies each business transaction. Some work on identifying requirements will already have been done when the business case was being identified. The elicitation or gathering of requirements could involve:
• interviewing users and their managers;
• examining documentation describing the current operations;
• analysing operational records created by the current system;
• observation of work practices;
• workshops – where groups of stakeholders and business analysts meet in intensive (often day-long) sessions, sometimes chaired by an independent facilitator, to identify and agree detailed requirements;
• questionnaire surveys.
In some cases, mock-ups or prototypes of parts of the new system could be used to help the users clarify their ideas about the requirements.
ACTIVITY 1.2
What kinds of people should the business analyst interview in the Water Holiday Company integration project in order to obtain the requirements for the new system?
Business analysis techniques, such as business process modelling or data analysis, will usually be applied to organise the raw data collected.
COMPLEMENTARY READING
Paul, D., Cadle, J., Eva, M., Rollason, C. and Hunsley, J. (2020) Business Analysis, 4th edn. Swindon: BCS.
At the end of this phase, a set of requirements is produced. This describes what the final system should be able to accomplish and lists all the major features of the end product. It forms the basis of the agreement between the customer for the new system and the developers.
We noted earlier in Section 1.2, that requirements include functional requirements (what the system is to do) and quality requirements (how well the system is to perform). Requirements can be prioritised, particularly where there is an overall cost requirement. There will also be trade-offs between quality requirements, where for example, security requirements are at the cost of ease of use.
At this point an outline of the test cases should be drafted, consisting of test transactions and the results expected from them. As will be seen, these will be used to check that the delivered system conforms to the requirements statement when acceptance testing is done.
1.4.5 Design
If it is decided to build a new system, rather than adopting existing functionality, then a design phase is needed. This activity translates the requirements for the automated parts of the system into a design specification of the computer processes and data stores that will be needed. It will also be driven by – and might modify – the solution/ technical strategy produced as part of the feasibility study/business case.
The identification of the inputs, outputs, business rules and information that the system will process is known as logical design. The physical design is concerned with the actual appearance of the input and output screens and the printed reports produced by the implemented system. Different physical designs could satisfy the same underlying logical design. The term user experience design (UXD) is used as the physical design of the screens needs to take account of the whole user experience of using the system. For example, steps should be taken to avoid situations where users are required to input information that is not readily available to them. This forces them to stop completing a transaction while they search for details required and then resume input. Where inputting is done by employees, interface design becomes job design.
Physical design in this phase is essentially concerned with the system as it will appear to the outside world. Further internal physical design of the software and data structures will take place in the next phase.
Where an existing application provided by a supplier is to be used, its design is already established. In this case, the issue is finding the package whose features most closely match the business requirements. The process must be planned by which available packages are to be evaluated and those which represent good value selected. Evaluation may involve trying out demonstration versions of the software, site visits to existing users of the software, and careful study of the suppliers’ documentation. In some cases, the existing software will need to be customised – that is, modified – to meet the organisation’s particular needs.
ACTIVITY 1.3
List some of the screens and other possible inputs and outputs that would need to be designed in the new integrated Water Holiday Company online booking system.
1.4.6 Construction
This process has the objective of designing, coding and testing software, and ensuring effective integration between different software components. For example, the new Water Holiday Company integrated booking system would need the development of a common application to record holiday bookings made by customers online. In the case of the Water Holiday Company integration, it is probable that one of the online booking systems used by one of the two companies to be merged could be used as the basis for the new integrated system. It is therefore likely that as well as new code being developed, existing code will be amended to deal with the enhancement.
Procedure manuals will also be produced and new hardware may have to be acquired. In the case of the Water Holiday Company, additional servers will be needed to deal with the increase in internet transactions. During this phase, the requirements statement will be re-examined to ensure that it is being followed to the letter. Normally any deviations have to be approved through a formal change procedure (see Chapter 4).
1.4.7 Using an external application
Sections 1.4.5 and 1.4.6 assume that a new integrated system is to be developed that may use some existing functionality. As noted at the beginning of Section 1.4, an alternative would be to look at the market to see if an existing application is available. After all, there are many businesses in the travel and tourism sector that handle bookings on a daily basis. If this option is followed, then among the activities that need planning would be:
• identification of potential applications and their suppliers;
• planning of how the evaluation of the offerings is to be carried out;
• the selection of the most suitable application;
• customisation, that is the setting of system and other parameters in the application to make it compatible with your method of working.
1.4.8 Acceptance testing
In Section 1.4.4, we suggested that test cases should be outlined at the requirements analysis stage that can be used to ensure that the requirements have been met. These can now be used to check the delivered system. This testing could be carried out by knowledgeable representatives of the users and IT support staff before its implementation as an operational system. It is inevitable during this stage that the user will uncover problems of which developers were unaware.
In the case of the Water Holiday Company integration, a problem with the introduction of smartphone access to bookings and payments is that users of the new facilities will be members of the public who the company does not currently know. Usability tests using external members of the public recruited for this purpose will be needed to test the customer-facing interfaces.
These acceptance-testing activities may overlap with the actual transition to the operational system. For example, some tests will need to be carried out on the system when it is actually installed on the equipment to be used in the final installation.
1.4.9 Implementation, installation and transition
Here the project reaches fruition. Hardware that has been purchased is delivered and installed. Software is installed, users trained and the initial content of databases set up. Apart from the technical aspects of the transition, such as the creation of a merged database, there is a general need to ready the organisation to take full advantage of the benefits of the new system, For example, in the case of the Water Holiday Company integration project, the general public need to be made aware of the new entity created by merging Canal Dreams and Minotours. There are various strategies for implementation; these are discussed later in Section 1.10.
1.4.10 Project closure
It is possible that a project could be abandoned during its development because its business case is no longer valid.
In the case of successful project completion, certain tasks will need to be done on closure, including:
• sign-off of acceptance documents by the project sponsor – this may be conditional on other key stakeholders giving approval first;
• handing over responsibility for maintenance and support to a permanent team;
• closing down accounts relating to the project;
• the project manager writing a lessons learnt report;
• releasing and re-allocating project resources, including the project team and the project manager;
• arranging publicity to tell the outside world about the project’s success.
1.4.11 Review and maintenance
At an agreed interval after the system has been made operational, a post-implementation review is carried out by a business analyst not involved in the original project. The review checks that the operational system is delivering the benefits envisaged in the original feasibility report. Changes sometimes result if the system does not fulfil its original requirements, but users could also identify new requirements. There could also be alterations in government regulations or in the way the organisation does business. These might become maintenance work, or be projects in their own right.
In the section on benefits management (Section 1.9) we will see that although the role of the project manager stops with the successful creation of the new system, the project sponsor who represents the business interests of the organisation will continue to have responsibility for ensuring the new system delivers benefits.
1.5 PROJECT MANAGEMENT AND THE DEVELOPMENT LIFE CYCLE
There is a need for management reviews at which the progress and direction of the project can be formally assessed.
Most projects contain elements of uncertainty, which make it difficult to meet all planned targets. This uncertainty is greatest at the beginning of the project, when little may be known about detailed requirements or any novel technologies, but gradually decreases as the project progresses. This makes it difficult in the early stages to plan later phases in detail. For example, it would be difficult at the outset for the Water Holiday Company to plan in detail the software code to be developed without a deeper understanding of the requirements of the new common booking system.
For the purposes of control there is a need to break the project into manageable units of work. These are variously called stages or phases. This is similar to dividing development into processes, except that it focuses on how best to manage the project. No two projects will be broken down identically because no single project structure can provide the best management control for all projects. In some cases – perhaps in smaller projects – two or more activities in the system development life cycle, such as design and construction, might be treated as one stage for management purposes. A larger project might split a single development activity into several management stages. For example, the construction phase might be broken into different management stages concerned with the construction of different parts of the system. At the start of a project, an initial overall plan of the work to be done will be presented with a detailed plan for the first stage. Detailed plans for each subsequent stage will be prepared as the start of it approaches.
The end of each stage is marked by a formal review, involving the project sponsor, which assesses the work completed and outstanding, and whether the business case is still valid. The review concludes with a formal sign-off of the current stage and the project sponsor’s approval of the plan for the next stage of the project.
1.6 ELEMENTS OF PROJECT MANAGEMENT
As well as consolidating or splitting up development processes in consultation with the project sponsor in order to facilitate their control, the project manager tailors project management procedures to improve control over the project. Although the overall project management process remains the same, the amount of effort needed for control varies. Small projects, for example, need less formal control.
The processes that need to be tailored include:
• planning and estimating;
• monitoring and control;
• issue management;
• change control;
• risk management;
• project organisation;
• business change and benefits management.
All of these will be described in greater detail in later sections of this book, but a brief overview will be useful at this point.
1.6.1 Planning and estimating
Good planning increases confidence within the project team. The aim is to detail the activities, the sequence in which they are carried out and the resources they need. The plan shows when activities are likely to start and finish and the estimated staff effort. An outline plan for the whole project is made initially, then a detailed plan is made for each stage nearer the start of the stage. Chapter 2 looks at planning and Chapter 6 looks at estimating in more detail.
1.6.2 Monitoring and control
Tracking and control ensures that the project meets its commitments in terms of deliverables, quality, time and cost by tracking the current state of the project against the plan and identifying any need to re-plan. Chapter 3 examines project control in more detail.
1.6.3 Issue management
During the course of a project, obstacles will be identified which could affect the project’s success. These problems may be outside the direct control of the project manager and need escalation, that is, reference to higher authorities. An example is where a promised external resource is not delivered when promised. Issues could lead to authorised changes to the project requirements – these have their own special procedures (see Section 1.6.4). The project manager should ensure that a system is in place for recording these issues, monitoring their status and starting any actions needed.
1.6.4 Change control
Any project can be subject to change. A change is often the result of a modification to requirements. Any requests for change should be made through a formal change management process. Failure to incorporate necessary changes reduces the benefit obtained from the project. However, accepting changes in an uncontrolled manner can cause problems that affect the cost, time scales and overall business case.
Chapter 4 examines change control and configuration management.
1.6.5 Risk management
All projects are subject to risk. If risks are not managed, they can have a detrimental effect. A suitable risk management process assesses and manages project risks.
Risks are different from issues. A risk is an unplanned occurrence that could happen, but has not yet done so. An issue is an unplanned occurrence which has already happened and which requires the project manager to request or initiate action.
Risk management identifies and quantifies risks before they happen, and plans and implements actions to eliminate risks or reduce their probability or impact. Risk management ensures that projects are only undertaken with a full understanding of the potential implications of the risks involved. Chapter 7 deals with risk in more detail.
1.6.6 Project assurance
When pressure mounts on a project to meet its deadline, it is tempting to ignore some of the checks and balances imposed by project standards and to focus exclusively on the work to be done. This lack of control can be dangerous and can lead to project failure. Project assurance is a set of procedures which ensures correct project control is maintained. This involves auditing by staff outside the project team.
1.6.7 Project organisation
A key factor in any project is effective project organisation, where the roles and responsibilities of all participants are clearly defined and understood. Chapter 8 explicitly addresses this topic.
1.6.8 Business change and stakeholder engagement
Changes to the IT used in an organisation often change the way the organisation works. IT can change people’s jobs. It can even cause staff to lose their jobs, and in other cases create new roles which need to be filled. The driver for IT change is to enable an organisation to generate new value and benefits.
Winning stakeholders’ support for a project is important for project success. Unless time has been spent communicating with stakeholders and making sure that users know exactly what to expect of the new system, the project could meet its formal requirements but still be seen as failing to provide benefits by its users.
The starting point for stakeholder engagement is the creation of a communication plan which identifies the key information stakeholders need about the project and when and how that information is to be conveyed. Chapter 8 on Project Organisation touches upon this topic.
1.7 DEVELOPMENT PROCESS MODELS
Section 1.4 identified the need for a well-defined, repeatable and predictable system development life cycle. A project’s life cycle is shaped by the products it delivers. Whatever the life cycle, it will be a set of activities each of which follows a particular method. For example, design and construction could adopt an Agile approach. Every activity in the process will have defined inputs and outputs contributing directly or indirectly to the deliverables to the customer.
Effective development methods are made up of an overall set of techniques and activities from which team members working on a new project of a particular type can select the most appropriate subset. The method should never require a task that does not produce something useful to the project.
The conventional system development life cycle for IT projects was described in Section 1.4. This has certain general characteristics that could apply to a number of different life cycles. However, it assumes that technical processes will vary according to the type of project. For example, as we have already seen, there are different project types (with differences in the types of processes carried out) where software is to be developed and where an existing software application is to be obtained from a vendor. In Section 1.5, it was noted that to make projects more manageable, the processes could be split up or sequenced in different ways. Here we look at some of the options for this.
1.7.1 Waterfall model
This waterfall model is anathema to many software developers. It is the basic phased model of a development cycle (see Figure 1.1). It is also known as the one-shot or once-through approach. The model takes its name from the way each phase cascades into the next. It is assumed that activities are normally done in a strict sequence, although there is some scope for reworking stages once they have been completed. Projects should produce a sequence of deliverables, such as the requirements statement, design documents and software structures, where the output from each phase is an input to the next.
This approach provides for feedback loops activated when there is a need to revisit an earlier stage to redesign, recode and so forth. It is possible to return to any previous phase, although this could well require extensive re-planning. The ideal is for quality control activities to be associated with each phase, so that once the deliverables of a phase have been signed off they should not need to be reworked.
This model is probably best used on projects where requirements have been clearly defined and agreed. Critics of the approach argue that most projects do not have clear requirements at the beginning. As the model relies upon having each phase completed and signed off, it can become bureaucratic and time-consuming. For example, remedying a failing found during acceptance testing might require the participation of staff involved with the requirements, design and construction phases. It works best where there are few changes to requirements during the development cycle, but whether changes will be needed will not be known before the project starts.
Another drawback is the amount of project documentation needed to pass information between stages and the effort needed to keep this up-to-date.
Despite these drawbacks, the approach provides convenient points when project sponsors can assess whether the project is still a valid investment.
Figure 1.1 The waterfall model
1.7.2 Incremental model
Although the incremental model (see Figure 1.2) is similar to the waterfall model, it involves the development and delivery of functionality in fragments or increments. Typically, global requirements are defined and an overall architecture designed. Then the product is developed in increments. After each increment is designed, developed and tested, it is system tested and then becomes operational, so that users get their new system in instalments. This approach works best when the requirements are relatively well-known. It can work well with larger projects, as these are effectively broken into a series of mini-projects, each delivering an increment.
The incremental model is often used in conjunction with timeboxes. The deadline for completion of the increment is fixed and the features to be delivered by the increment are ranked according to importance. The least important features may be dropped to ensure that the deadline is met. The dropped features can be implemented in a subsequent increment if they are still required.
Figure 1.2 An incremental model
1.7.3 Iterative model
This model (see Figure 1.3) is suited to situations in which the requirements are not clearly understood and where there is a need to begin development quickly to create a version of the product which will demonstrate its look and feel. It is also referred to as an evolutionary approach.
Early versions, or prototypes, of the system are created to help the customer identify and refine requirements and design features. The customer can make suggestions for possible changes to be incorporated into a further version of the software, which is then built and evaluated.
A possible drawback associated with this model is not knowing when to stop iterating. The iterative approach is potentially difficult to monitor and control.
The incremental and iterative models work well together. An application can be broken down into a number of increments, each of which can be implemented through a series of iterations. The Dynamic Systems Development Method (DSDM) is an approach that formalises the combined incremental/iterative approach.
1.7.4 Agile project practices
Conventional phased projects are sometimes seen as having excessively time-consuming lines of communications. For example, users of a new system could be consulted at the requirements phase, but then have to wait a considerable time while the system is designed, built and tested. It is often only then that discrepancies in understanding of the requirements are detected.
A response to the perceived limitations of the waterfall approach has been demand for the adoption of what are called Agile practices. These tend to be practices that reduce bureaucratic obstacles by encouraging intense, informal communication between project participants. Some of these work at the level of individual work teams. Scrum, for example, breaks a project into a number of increments (see Section 1.7.2) of about two-week duration called sprints. Within sprints, individual activities are broken into a series of small steps that are listed in a backlog. Each day the project team members report on their progress in implementing the items in the backlog in short ‘stand-up’ meetings. Other Agile approaches – such as Extreme Programming (XP) – focus on software development practices. XP, for example, calls for software developers to work together in pairs, so the coding decisions of one developer are always checked by the other as the code is entered at a workstation.
These strategies are only applicable to some types of projects. They may be useful in software development, as code is relatively easy to change, but not in large infrastructure projects – although this may be changing with the development of computer-aided design.
Agile practices focus on creating real-time communication between project stakeholders. Thus, a knowledgeable product owner may be designated who acts as the sole authority on user requirements, thus avoiding lengthy requirements gathering. User representatives may work directly with developers creating ‘user stories’ precisely mapped to delivered units of functionality, and at the same time design the test cases and expected results that will be used to validate them. As noted above, developers may work in pairs so that there is instant checking on work as it is executed.
This sensitivity to the exact needs of users leads to greater user satisfaction, but at the cost of demands on the time of users. Local satisfaction is sometimes balanced by overall reduction in organisational efficiency with increased costs for the maintenance of a variety of non-standard products carrying out similar functions.
A challenge comes when projects have to integrate activities that relate to different professional disciplines. Agile practices are likely to be applicable to only a small subset of these activities. A common overall project management system is needed to coordinate the efforts of a mixture of activities, some of which are Agile and some of which are conventionally organised. The Agile emphasis on fixed time and cost constraints helps this.
Regardless of the type of work, content managers of work packages need to be able to supply basic progress data to project management. Where Agile practices are involved, this may be easier to supply because work is more visible.
We will be returning to other relevant Agile practices in later chapters, particularly Chapter 5, which discusses quality issues.
1.8 PROJECT PLANS
The effective management of a project is based on a firm definition of project governance; that is, the principles, policies and frameworks by which a project is directed and managed. Among other things, this will set out who is accountable and responsible for each component of the project. Accountability refers to the management role which controls and reports on a particular activity within the project. The accountable person might well not be carrying out the work. Someone else who reports to the accountable person could have responsibility for the practical work. If there were external factors preventing work being completed as required, the responsible team member would need to consult the person accountable for the work. Thus, a manager might be made accountable for delivered software being correct. One way of ensuring correctness is by testing and the manager could allocate a system tester to have the responsibility of carrying out this task. If the tester finds that, for example, the testing is being delayed because of late changes to the functionality, they would need to refer to the manager for guidance. At the start of the project it might not be possible for all the accountable and responsible people to be personally named. Instead roles would be defined and then be allocated to actual people later in the project.
During the project set-up phase (see Section 1.4.3), a project plan is produced that consists of several different types of document, including activity networks and Gantt charts (see Chapter 2). It is used as the basis for the final decision by an organisation’s management to go ahead with the project, and as such is sometimes referred to as project initiation documentation (PID).
The PID is a set of documents that coordinate all project processes, bringing together all the planning documents used to manage and control the project. It is not cast in stone and will be amended as necessary during the lifetime of the project. The plan defines the project’s scope, schedule and cost, as well as the supporting processes related to risk, procurement, human resources, communication and quality.
1.8.1 Project initiation documentation (PID)
Different project management methods give this document different names, but in essence it serves as an agreement between the sponsors and the developers of the project. It has the following key elements:
• An introduction, which describes:
▪ the project background;
▪ the business justification for the project, including a brief summary of costs and benefits (see Section 1.9).
• Project goals, objectives and deliverables, including:
▪ project success and completion criteria;
▪ an outline of the technical strategy by which the goals will be achieved.
The following sections constitute the project management plan and explain how the project will be managed:
• A project organisation chart, which includes:
▪ the project sponsor;
▪ the project manager;
▪ major stakeholder representatives;
▪ the lead supplier representative(s), if appropriate.
The organisation chart shows the reporting relationships of all those with managerial responsibility for aspects of the project. It also identifies the members of any steering committee (or project board or project management board) established for the project.
Chapter 8 discusses some of the issues involved in project organisation.
• A management control section, which covers:
▪ the frequency, timing, recipients and format of progress reports;
▪ how the plan will be produced and maintained;
▪ what information will be monitored and recorded;
▪ how the information will be recorded;
▪ how packages of work will be signed off and reviews conducted, and who is authorised to sign off packages of work;
▪ the people accountable/responsible for authorising the commitment of resources;
▪ the people accountable/responsible for recording and assessing the impact of any changes;
▪ the people accountable/responsible for authorising different levels of change to goals, objectives, deliverables, costs or completion date.
Chapter 3 is devoted to monitoring and control.
The following constitute the initial project plan, which describes the activities to be undertaken to complete the project:
• A project structure section that describes how the project will be broken down into manageable portions of work, which will be administered as stages/phases.
• A list of project milestones, that is significant events in the project for which dates need to be clearly specified. Milestones are used to measure the progress of a project and can be the start or completion of a major project phase. Milestones are events that consume no resources in themselves, but enjoy a great deal of attention from management at a senior level. Management resources representing the project sponsors will be needed to review the state of the project before or after the milestone has been reached.
• A risks and assumptions section identifying high-level risks to the project and specific actions to reduce or eliminate each risk. It is useful to include in this section a list of assumptions made in producing the report.
See Chapter 7 for more on risk and its management.
• A communication plan that provides an overview of how the project will communicate with the wider business organisation, particularly with regard to changes needed in the business in order to make the implemented IT application effective.
See Chapter 8 for more on project communication,
• A report sign-off section.
The document should be signed off by staff who represent all areas and functions committing resources to the project and those who will be affected by the project. In so doing, they implicitly accept the assumptions listed. Final sign-off is given by the project sponsor. The project manager should not initiate any work that has not been explicitly or implicitly authorised in the project initiation document and signed off by the project sponsor.
1.8.2 Creating plans
The PID will contain an outline plan for the whole project and a more detailed one for the first stage. The detailed planning of later stages usually takes place closer to the beginning of those stages. This allows it to take account of the additional information gained during the progress of the project. Thus, plans are created at several levels:
• Projects, where the outline plan is approved by the project sponsor, supported by any steering group/project board.
• Stages, where the completion of any previous stage is signed off and the stage plan for the next stage is approved by the project sponsor.
• Work packages, which are the practical sets of activities that the project manager allocates to individuals or groups of developers under the guidance of a team leader or manager, who produces a detailed plan of how the work will be done.
The plan starts with a careful breakdown of the work to be done. The activities needed to carry out this work are identified plus the order in which they have to be carried out. An estimate of the duration of each activity is needed. Chapter 2 describes the use of Gantt charts for showing the schedule for a project.
The project plan then needs to be developed further to account for the various types of resources, including people, equipment and facilities needed for the activities identified. With internally resourced IT/business change projects, resources must be obtained from other parts of the company to work on a project. Managers of specialist departments will be key providers of resources such as office space, computer equipment and specialist expertise. Where goods or services from outside the organisation are needed, contract management will be important.
Resource planning identifies the skills needed for the project and when they are needed; for example, a testing expert may only be needed at certain times in the project. Availability of resources often affects the timing of activities.
A useful communication tool for the project manager is the responsibility assignment matrix (RAM), a simple matrix showing individuals associated with the project on one axis and the activities for which they are responsible on the other. It provides a quick and easy view of who is responsible for each task.
Once the activities and resources have been identified, the costs are assessed. The business case for a project is based on it not costing more than a specific amount reckoned to be the value of project benefits. If the costs of the project exceed the value of its benefits, the project becomes uneconomic. It is also possible for an organisation to simply run out of money for a project.
Internal IT projects are usually paid for out of a user department’s budget. Where a project is being carried out for an external customer, there may be a fixed-price contract. Whatever the case, it is necessary to estimate quantities and costs, set budgets and eventually control expenditure.
Sources of development staff
A major IT project often requires an abnormal amount of technical work that the business cannot provide by itself. Additional development skills might be acquired by:
• Recruiting individual specialists on temporary contracts, either directly or by using agencies. Pay for temporary staff is usually greater than that for permanent staff and there may be additional recruitment and training costs. Depending on the type of work, temporary staff could work from their own premises, but usually need workstations within the business.
• In the case above, the temporary staff are employed directly by the business. An alternative approach is to have a contract with an outside specialist company where the developers used are based and remain the employees of the specialist company. The specialist company is paid for the hours that their employees work.
• A more radical approach is to outsource one or more project activities, such as design and construction, to an outside specialist company. The outside company will have management responsibility for delivery of a subset of the project requirements, often for a fixed price. In this case, the supplier selection and the acceptance testing of deliverables would still consume some of the customer’s resources.
1.8.3 Communication planning
Stakeholders, including the project team, have varying needs for communication about the project. These needs and the means by which they may be satisfied are recorded in a communication plan. The communication plan includes, among other things:
• the flows of communication during the project;
• how various communication tools will be used;
• what meetings will be held with what attendees, and at what times.
These issues are explored further in Chapter 8.
1.8.4 Quality planning
A carefully considered quality plan is needed in order to develop a system that meets all the functional and quality requirements documented during analysis.
Quality criteria can be applied to both project products and processes. It is possible to check that deliverable and intermediate products have specified qualities, and that the processes that created them were the correct ones.
Quality needs vary between projects. The deliverables of some projects could be safety critical and would require more stringent quality assessment. This would add to the costs of the project.
The customer must be the final judge of the product’s quality, and must therefore be involved in quality evaluation. Chapter 5 further explores the role and content of the quality plan.
1.9 THE BUSINESS CASE AND BENEFITS MANAGEMENT
The business case is a key document for any project. As noted in Section 1.4.1, the proposal for a project may be triggered in a variety of ways. Once a proposal has been made, senior management will decide whether to go ahead with a proposal, using a combination of qualitative and quantitative criteria, as no single method gives enough information.
Qualitative criteria include organisational fit. Does the project fit with the organisation’s strategic objectives? How does the proposed project contribute to the organisation’s future capabilities and growth? The business risks associated with a particular project will be considered. These are external factors that could reduce the value of a project. For example, the project deliverables might be produced as planned, but the demand for them might disappear because superior technologies have come onto the market.
A more persuasive reason for going ahead with a project, however, is often financial justification, where two of the most common quantitative financial criteria are return on investment and payback period – see Sections 1.9.1 and 1.9.2.
The contents of the business case document would include a description of the project, its objectives, benefits and scope, a cost–benefit analysis, a risk analysis, a conceptual solution, resource requirements and success criteria. Some organisations include alternative options in the business case in order to compare the recommended solution against other approaches. The business case needs to be carefully reviewed by project sponsors.
With IT-related projects, IT specialists should be involved in creating the business case because they contribute information about IT-related development and operational costs. However, the really important participants are the stakeholders who will use, manage and hopefully benefit from the newly developed systems. The project sponsor is accountable for the value of benefits of the proposed system and the non-IT costs of the project, such as those arising from organisational changes.
Both the development and the operational costs need to be considered. This means the project life cycle needs to be extended into a system (or product) life cycle that takes account of all the costs and income that can be expected over the whole life of the delivered system, up to and including any decommissioning costs. This is similar to the concept of the total cost of ownership (TCO) of an asset.
A financially viable project is one where the value of benefits exceeds costs. Conveniently, some benefits can be measured in monetary terms. This would be the case where the project will enable staff costs to be cut. (Note that reducing cost is essentially the same as increasing income. If you save £100 on the fuel bill, you can spend that money somewhere else.) Other benefits are measurable, but putting a precise financial benefit on them is difficult, as in the case of software that diagnoses a particular medical complaint. Finally, some benefits are simply not quantifiable, as when the managing director decides to spend money on a fountain outside the new data centre to impress potential customers. In short, the client organisation will put their own value on many of the possible benefits.
Organisations often consider several projects at the same time. Where money is constrained, they will use business case reports to prioritise which project to start.
1.9.1 Return on investment (ROI)
One way of measuring the financial outcomes of different project proposals is through Return on Investment (ROI). The simplest form of ROI is calculated as:
Say a company uses an external accounting services business to administer their payroll at the cost of £7500 a year. As part of a review, the company examines the cost of bringing payroll in-house. It finds it could run its own payroll at an initial cost of £10,000 to set up the new system and annual operating costs of £5000 (the sums are selected purely for ease of calculation). These cash flows are shown in Table 1.2 for a five-year period.
Cash flows are calculated at the end of each year. Year 0 refers to expenditure that takes place before the new system is operational and the initial debt that exists from investment in the system. In this case it is £10,000.
Each yearly cash flow is calculated by subtracting the expenditure from income in each year. The ‘income’ here is actually the saving from not using the external service provider. We noted above that a saving is effectively the same as income. Annual average profit is the total of all the annual cash flows (including the initial investment) divided by the number of years of actual operation – that is £2500 divided by five years, which is £500. This is converted into ROI by dividing it by the original investment of £10,000 and converting it to a percentage by multiplying by 100. This gives an ROI of 5 per cent.
1.9.2 Payback period calculation
Another way of measuring financial viability is by calculating the payback period. This is the point at which the delivered new system pays off the initial investment and starts to generate a surplus. If you look at the accumulated column in the table (which is a bit like the current bank balance of the project), it can be seen that this is zero in year 4. This means that at the end of year 4 the project investment has been paid off. The smaller the payback period, the better.
A more complicated assessment approach calculates the net present value of the project to be delivered. This calculates all the cash flows in terms of how much money you would need to invest now at a particular interest rate to get that amount of money in the future. This is called a discounted cash flow (or DCF).
COMPLEMENTARY READING
Blackstaff, M. (2012) Finance for IT Decision Makers: A practical handbook, 3rd edn. Swindon: BCS.
1.10 TRANSITION STRATEGIES
Transition is when the products of the project are deployed within the client organisation and are then used by operational staff to generate the planned benefits of the project. The IT elements could well be just one part of a bigger system delivery that includes interfaces with existing systems and human interactions. When a new system is implemented it is often the case that data from predecessor systems will have to be transferred. With the Water Holiday Company integration project, data from two different organisations will need to be merged. The project team will recommend the most suitable changeover method for the project. The following options may be considered.
1.10.1 Direct changeover
In this case, the old system is discarded and immediately replaced by the new one. It can be considered a risky approach, but is relatively inexpensive if thorough testing has been done. DevOps technologies have been developed which automate many of the processes associated with updating web-based applications, but this is most likely to be successful where the IT system is changing but not the user operations.
1.10.2 Parallel running
This involves running the old and new systems together for a period of time using the same inputs and comparing the related outputs – so it serves as a continuation of the testing process. It is a safe, low-risk approach, but can be expensive, particularly in terms of duplicated labour costs. An important management decision is how long the two systems should be run in parallel. Parallel processing works best where there are batched outputs, for example with monthly payment runs in payroll.
1.10.3 Phased take-on
The phased approach breaks the system into components that will be introduced in sequence. It helps to minimise risks but can delay the implementation of the entire integrated system. However, it does present the opportunity to allow users to learn one system component at a time. It also fits neatly with incremental delivery.
1.10.4 Pilot changeover
Like the phased approach, this is a risk-reducing approach. With pilot changeover, the entire new system is introduced to just one business unit or location. It can only be used if the business unit or location can use the entire system independently. Problems can be addressed and fixed before the system is introduced company-wide, but company-wide deployment of the entire system is consequently delayed.
ACTIVITY 1.4
What would be the best implementation strategy for the Water Holiday Company integration project?
1.11 POST-IMPLEMENTATION REVIEW
The post-implementation review (PIR), or project evaluation review, is usually scheduled to take place some 6 to 12 months after the sign-off of the project. Its objective is to review the implemented system in terms of its contribution to business objectives, its usability, operating costs and reliability. It considers the following:
• whether the business and system requirements have been met;
• cost and benefit performance;
• operational performance;
• controls, auditability, security and contingency;
• ease of use.
The output from this process is a post-implementation review report. The review should be led by someone who is independent of the project, and should solicit feedback from users, operations and the support team. The review should address the operational system and not the development project. The additional effort required of them might lead to users not engaging with this review. If this is the case, it is essential to explain to the users the benefits of the process – for example, that changes which could improve the system may be identified as a result.
The PIR report needs to be distinguished from a lessons learnt report. When the project has been delivered by the project team, the project manager should write a report describing the major challenges experienced during the project and how they were managed. The purpose of this report is to identify lessons that would improve the execution of future projects.
SAMPLE QUESTIONS
Answers can be found on page 157
1. Which of the following is NOT a characteristic of a project?
a. Ongoing nature
b. Uniqueness
c. Clear objectives
d. Integration of interrelated tasks and resources
2. Which of the following is NOT managed by the project manager?
a. Time, cost and scope
b. The project team
c. The project sponsor
d. Engagement with the stakeholders
3. Which of the following tools indicates who is responsible for what?
a. A responsibility assignment matrix
b. A resource levelling chart
c. An activity network chart
d. A resource histogram
4. Which one of the following does a payback calculation give to an organisation?
a. An assessment of how quickly an implemented system will produce a profit
b. How much future income from an implemented project will be worth in present-day terms
c. Annual average percentage profit of a project
d. The overall value of the benefits that the project will deliver
POINTERS FOR ACTIVITIES
Activity 1.1
Among the activities that may be considered are the following:
i. Survey existing office requirements (for example, how many desks and chairs there are) and IT infrastructure, including servers and printers, used by the office.
ii. Survey new office space.
iii. Plan new office layout – who and what will go where?
iv. Schedule the sequence of moves – it might be that not all staff should be moved at once as this will allow for some continuity of service.
v. Select a removal company.
vi. Organise the setting up of the infrastructure.
vii. Pack up the old office.
viii. Transfer to the new office, including supervision of placement of furniture, and so on.
ix. Unpack in the new office.
x. Connect telephones, and so on.
As project manager you will probably want to be consulted when decisions have to be made, possibly at points (iii), (iv) and (v) as money is involved here. Useful checkpoints would be just before (vii) to check everything is in order to go ahead and after (x) to check out any outstanding problems.
Activity 1.2
There will be some interviews with fairly high-level managers, including the project sponsor (who may be the managing director who also owns the merged company), to clarify the business requirements of the proposed system. Given the nature of this project, marketing specialists will need to be consulted. It is essential that this consultation take place when the business case is being prepared.
Staff who currently carry out the clerical booking operations in both Canal Dreams and Minotours would need to be interviewed to see how their existing systems work, what data has to be held and what problems there are with the current systems. Operations staff at boatyards and marinas also have to be consulted as users of the new system who need information about the bookings each week, so that boats can be allocated and prepared and holiday-makers checked in. Staff in other departments need to be approached to document the interfaces between the booking operation and other parts of the overall Canal Dreams and Minotours businesses; for example, the central finance function and the maintenance staff who may need to schedule boat maintenance.
Note that users include IT operational staff, who would, for example, have requirements about system security.
We usually say that end-users should be consulted, but, of course, in internet transactions with the public it is not possible to identify who these will be beforehand. In this case, market research with recent customers could provide insights into the needs of online customers.
Activity 1.3
Where potential customers have to ‘volunteer’ to use the system, more careful design is needed than for those which employees are compelled to use. It is assumed that these external transactions will be the subject of design to ensure their ease of use, as part of broader user experience design. Transactions that are made via smartphones are ‘logically’ the same as ones made via a laptop, but need a different design to cater for the smaller amount of information that can be conveyed on a smaller display. The transactions within the overall user experience needing careful design include:
• browse locations and boats;
• check availability;
• record boat booking;
• cancel boat booking;
• change allowable details; for example, amend existing address and ‘crew list’.
Customer communications that could be made by sending email and/or text messages include: booking confirmation; final payment reminders; and proof of booking and other details needed when starting the cruise.
Activity 1.4
The holiday bookings tend to be seasonal, with very busy times of the year and the off-season when the business is dormant. This would seem to favour a direct changeover during a quiet period. This would allow a gradual build-up of traffic, making it easier to deal with any initial teething troubles. Note, however, that direct changeover is often avoided because of the risk that if the new system is faulty there is no alternative system to fall back on.