Q1 Figure 1.7 shows how bad an implementation can become. Action needs to be taken to prevent this kind of situation. What would you recommend should be done?
This model is about how badly wrong the development and implementation can become, but it applies equally to the imposition of change. The secret lies in preventing this situation from arising by
Making sure that everyone understands the reasons for the change
Has the opportunity to play a part in influencing the shape of the new situation or system
And doesn’t have to deal with so much change that there are no anchor points for those involved.
Q2 You are the project manager for a new management accounting system that will provide monthly profit and loss accounts to a chain of 30 computer dealerships, each of which is franchised to its local owner/manager. They have all done their own accounting before. What change issues would you expect to encounter? Does the fact that they are PC dealerships make any difference? Why might they have joined together in the chain?
Several change issues will arise;
the imperative to change? Why does the franchise owner want to impose this change – if indeed it is being imposed?
In principle, the fact that they are PC dealerships should make little difference, but they will be well aware of the problems of changing over from one software system to another, and interfacing it to other existing systems.
The dealers probably joined the franchise network in the first place to share purchasing, advertising and marketing costs. They may pay the franchise owner according to their success, in which case the new system may have a big impact on them as it will declare financial information in a consistent manner across all franchisees and reduce the opportunity for creative adjustments by the franchisees.
Q3 Consider the organisation that employs you or where you study. What is its culture? Why does it have that particular culture? What organisational culture would give you most satisfaction as an employee? Where might you find such an employer? Given your preferred organisational culture, what would it mean for you as an employee in terms of your responsibilities and obligations?
Two models for analysing culture have been described in this chapter. Identify your organisation’s culture using these models. Work with others if you can. The culture may be the result of deliberate choice or may have arisen by accident. The key question is whether or not it moves the organisation forwards in an efficient way towards the achievement of its goals.
To identify a culture that suits you, first work out what you want from your work and from your employer. Do you like freedom to get on with things, the opportunity to be creative, and do you have an urge to make changes all of the time. You do? Then an Apollo culture may not suit you. The is no inherently ‘good’ or ‘bad’ culture just different ones, so choosing one that suits you is a personal choice that doesn’t come with value judgements attached.
Q4 You have to design a ‘hearts and minds’ programme connected with the implementation of a new system for the recording and management of stock in a book-publishing company and for the supply of books to booksellers. What would be the main stages of such a programme?
A good place to start is with the reasons for the implementation of this system. If it aims to reduce stock holding costs for the publisher but may lead to delays in shipping books to bookshops, then the message is different from if it also speeded up or made easier the ordering and delivery of books.
Next, make a stakeholder analysis and assess the impact of the new system on the different stakeholders. Involve the stakeholders in planning for implementation and think about getting key ‘change agents’ from the publisher and the book trade to work with you.
Ensure that everyone knows what’s happening and that people are properly trained and supported. Create a forum for the identification and speedy solution of issues.
Chapter 2 Business strategy and information systems
Q1 Why is it important for project managers to understand the strategy of the organisation that uses their services?
It enables the project to be seen in the context of what the business is trying to achieve. It means that links between this system and others under development or in operation can be better understood and managed. It enables the project manager to see how the project delivers value and how further value could come through the identification of new opportunities.
Q2 If you knew about an organisation’s strategy, could you suggest IS applications that would support it? For example, how could a large supermarket chain use information systems for cost reduction, or for a strategy based on differentiation?
Systems that aim at cost reduction strategies might lead to applications development in logistics, stock control and stock planning, or in financial management and budgetary control, or in supplier management. Differentiation strategies might call for TQM applications, the launch of new systems in customer care or in symbiotic applications such as personal banking, loans and insurance.
Q3 If you had to develop a strategy for a small software house employing 50 or so professional computer people, how would you go about it? What criteria would you use to test whether or not the strategy was sound?
A firm of this size is probably owned and run by the top management with some outside financial backing, so you should work first of all with this group of stakeholders. You could take it in stages as follows;
Collect data. What does the management team think? What are the company’s strengths and weaknesses (use SWOT?) and core competencies? What about competitors and markets.
Develop some alternatives and evaluate their attractiveness. Decide on the kind of business they want to be.
Create a vision for the business and a strategy to achieve it.
Put the structures, systems, styles, skills, staff and shared values in place to achieve the strategy.
To test the soundness of the strategy you could ask someone else to assess it for
Clarity. Do all of the company’s managers know what to do in their part of the business to support the strategy?
Empowerment. Is everyone enthusiastic about it and do they feel empowered to act to achieve it?
Concentration. Does the strategy focus on the core competences of the business?
Flexibility. Can the strategy be flexed in the face of market changes and competitive pressures?
Chapter 3 The business case
Q1 At what point in the project lifecycle should the business case be prepared?
The short answer to this is ‘before any serious work has been done and before major resources are committed to the project’. Many projects are preceded by a feasibility study, the aim of which is to see whether there is a prima facie case for undertaking the project and a business case is often a major output from such a study.
In addition, IS studies often start with some form of requirements analysis and specification. Where this is the case, the detailed information discovered here may necessitate a reappraisal of the business case, to make sure that the costs and benefits identified in the feasibility study are still realistic.
In fact, the business case should be revisited at each stage of a project, to make sure that the project is still on target to achieve the business benefits for which the project has been initiated.
Q2 What should be the role of the project manager in relation to the business case?
Ideally, the project manager should be appointed early enough to contribute to the development of the business case – or even to take the lead in its development. At the very least, someone with a project management background should be asked to review the business case to make sure that the approach proposed is realistic.
If the project manager has not contributed to the creation of the business case, then one of his or her first jobs after appointment should be examine it and to satisfy themselves that they are happy to take responsibility for the project. If they think that the scope, budget or timescale is unfeasible, they should raise their objections with the project sponsor and endeavour to negotiate a more realistic programme.
Once the project is underway, the project manager needs to keep a watchful eye on the business case to make sure that the way the project is going is not going to compromise the achievement of the benefits outlined in the business case.
Q3 Explain the term ‘cost/benefit analysis’
Cost/benefit analysis is the process of identifying, and as far as possible quantifying, the costs of undertaking a project and contrasting these with the benefits expected to flow from it. For a project to be approved, senior managers will have to be convinced that the benefits outweigh the costs.
Q4 What do you understand by the terms ‘tangible’ and ‘intangible’ when applied to costs and benefits?
Tangible costs or benefits are those for which a plausible quantitative value can be calculated, such as increased profits or reduced staff costs. Intangible costs or benefits are those where it is not practical to calculate a quantitative value.
In theory, almost anything can be quantified, given enough time and the right resources to do the analysis. For example, ‘improved public image’ could be measured through opinion polls or surveys and could even, perhaps, be linked directly to sales figures. However, in most cases, the expert resources are not available to do the research and, in any case, the results are often debatable and sometimes not believed by the decision makers. It is generally better, therefore, when dealing with intangible costs and benefits to explain in the business case what they are and to let the decision makers put their own (subjective) value on what they might be worth.
Q5 What is meant by the term ‘benefits realisation’ and why is it important?
Benefits realisation is the process of managing a project – and the post-project operation of, for example, a new information system – so as to maximise the chances of getting the benefits claimed in the business case. All projects should be followed, after a suitable interval, by a post-project review, the main aim of which should be to find out whether the expected benefits have been realised or not.
Chapter 4 The organisational framework
Q1 How many different types of customer may there be for a systems development project? Who are they? What kind of relationship and reporting arrangements should the project manager have with the sponsor?
Depending on the specific project, the ‘customers’ could include some or all of the following:
The management of the organisation that has commissioned the project, who will be interested in the achievement of the benefits described in the business case.
The end-customers of the organisation commissioning the project, who will be interested in how it affects the ‘customer experience’.
Managers and others in other departments indirectly affected by the project.
The sponsor of a project represents the management of the organisation that commissioned it. Thus, she or he is THE customer for the project manager and it is important that they have a good, frank and effective working relationship. The sponsor and project manager should agree between themselves a suitable timescale and framework for reporting but, typically, this would involve a regular written report supplemented by a meeting where issues can be discussed face-to-face. The frequency of reporting will clearly depend on the overall size and timescale of the project; one with a total duration of a month or so will probably require weekly reports but, for a project spanning several months, a monthly reporting cycle may be sufficient.
Q2 Describe the roles of (a) the sponsor and (b) the project manager
(a) The sponsor’s role is to represent the organisation commissioning the project and to make the major business decisions concerning it. The sponsor should approve the original project initiation document and decide on any subsequent changes of scope. The sponsor is also the ‘internal champion’ of the project and may, on occasion, have to ‘knock heads together’ where various users cannot agree on the project’s direction. At the end of the project, it is the sponsor who must accept from the project teams the various deliverables specified.
(b) The project manager is responsible for the day-to-day management of the project within constraints laid down by the sponsor. It is a good idea for the project manager to be given some tolerances within which to operate – for example, a completion deadline of 1st March with permission to delay until 1st April if necessary. Essentially, it is the project manager’s job to ensure that the defined scope of the project is delivered within timescale and budget.
Q3 What are the principal problems of managing projects within a completely functional organisation structure?
The main problems of functional organisations are to do with what may be termed a ‘silo mentality’, whereby people pursue functional, rather than organisational, objectives. In addition, people may have little knowledge of – or interest in – things outside of their functional specialism.
The problem with managing a project in this environment is that, if the project is run from within one function, people from other functions may not cooperate fully with it, or may even work to frustrate it. If the project is cross-functional, the project manager may face interference from line managers in the various functions.
Q4 What are the pros and cons of a ‘pure’ project organisation compared with a project operating within a matrix structure
A ‘pure’ project organisation contains within itself all of the resources needed to complete the project’s objectives. Thus, the project manager has the whole project under his or her direct control. However, the project may be inefficient in its use of resources, since one cannot have less than one resource of a particular type even if there is not a full-time job for that person. In addition, project team members often suffer from a feeling of insecurity, not knowing what will happen to them at the end of the project. Finally, the project may become somewhat detached from – and possibly resented by – the rest of the organisation.
A project operating within a matrix structure tends to be more resource efficient since it is perfectly feasible, say, to have the part-time services of a particular specialist. Team members also do not lose touch with their ‘home’ functions. The main problems with matrix structures stem from people having more than one manager, leading to difficulties in prioritisation of effort and time management.
Q5 In a PRINCE2® project structure there are formal committees, a project board and specific roles. What is your opinion about the value of this kind of arrangement? How do you see it working in large and small projects? Could it be useful for projects outside IT?
The use of established roles within the PRINCE2® environment usually smoothes setting up a project, since people get to understand what is required of, for example, the ‘executive’ on a project board. The project board itself provides an excellent forum for the various stakeholders and customers (see question 1) to come together to make decisions about the project. Part of the design brief for PRINCE2® was to make it suitable for non-IT projects. PRINCE2® has been proven in practice over a large number of large projects.
Smaller projects often have some difficulty with the PRINCE2® approach, since it can feel somewhat bureaucratic and top-heavy in these circumstances. But it is a tailorable approach and, for example, the project board can be reduced to two people executive/senior user and senior supplier) if that seems appropriate. The reporting regime between the project manager and project board can also be streamlined and abbreviated for smaller projects.
Chapter 5 The programme and project support office
Q1 Explain why the concept of PPSO arose in the first place.
The origins of the PPSO lie in the provision of administrative support for project managers, to take care of some of the routine tasks such as writing meeting minutes and updating plans. In time, it was realised that this sort of support was required for all projects and could be most efficiently supplied by having a PPSO that supports a number of projects. This also enables PPSO personnel to develop a good understanding of the basic issues of project management, which can be placed at the disposal of many project managers.
Q2 What are the advantages to an organisation of having a PPSO?
The main advantages to an organisation from having a PPSO include:
Collection of information on past projects, which can be used to assist in planning and risk management.
Consistency of approach, in terms of practices, planning and documentation, across all projects – thereby avoiding ‘re-inventing the wheel’ for each new project.
Independence, whereby the PPSO can provide a slightly different perspective on all projects for senior management.
Specialism, where PPSO staff develop skills – for example in project management tools – that can be used by many projects.
Centre of excellence – the development of a central repository of guidance for project managers and project teams.
Q3 What conflicts are likely to arise between project managers and PPSO staff?
PPSO staff can, if they are not careful – or if they are not properly managed – begin to think that they are actually running projects, rather than acting as a support function. The management of the project remains the responsibility of the project manager.
In addition, in pursuit of consistency, PPSO staff may try to impose on all projects the same ‘one size fits all’ methods and standards, where specific projects require a more tailored approach.
Finally, where senior management ask a PPSO to audit the various projects that they support, the PPSO can come to be seen by project managers as a ‘police force’, rather than as a support organisation.
Q4 What skills are useful when working in PPSO?
The skills that are most useful probably include:
A logical approach to the collection and analysis of information.
The ability to draft succinct meeting minutes and reports.
Skill in using project management and other software packages.
Tenacity in getting to the real facts of a situation.
Diplomacy and tact for dealing with people involved in projects, who are usually under a lot of pressure.
Chapter 6 Development lifecycles and approaches
Q1 You have been asked to take charge of a system development where the customer requires about 50 per cent of the functionality very urgently to meet a business opportunity but where the remaining functions can be delivered over the next few years. Which of the various development lifecycles do you think would be most suitable for this project and why?
Either the incremental or the spiral model would provide a good approach in this situation. With the incremental approach, the whole system is designed in outline and then developed and delivered as a number of stages. The spiral model assumes no overall design at the outset and the system evolves as new features are introduced in progressive stages. Which of the two lifecycles is most suitable in the circumstances described may depend on how fully the users of the proposed system can specify their overall requirement at this stage.
Q2 What would you say are the principal advantages and disadvantages of the sequential approach to system development offered by the waterfall and ‘V’ lifecycle models?
The waterfall approach and its ‘V’ model variant offer a logical set of steps that have to be followed to develop and implement a system. They provide good control for a project manager as – in theory at any rate – each stage should be complete and signed off by the project sponsor before proceeding to the next. This also means that each stage builds properly on its predecessor and hence assists in the creation of a high-quality deliverable. The models assist in resource deployment as it is easier to see what skills are needed at each stage – business or systems analysis during requirements analysis, designers during the design stages, development during code and test and so on. The ‘V’ model has the additional advantage that it shows explicitly the connections between the earlier and later project stages – between requirements specification and user acceptance for example.
The main disadvantages of these approaches are that projects undertaken with them can take rather a long time from inception to delivery and this is often not very suitable for modern business conditions, where change is incessant and constant. With the linear approaches, changes that arise later in the project are difficult to accommodate as the earlier stages should be revisited to reflect the changes. Finally, these approaches do assume, as a starting point, that the users can specify in some detail what they want from their new system whereas in many cases – for example, where a system is needed to meet an unprecedented business situation – this is very far from being the case. Where such uncertainty exists, an evolutionary lifecycle (the spiral) is probably more suitable.
Q3 Some critics have said that the use of structured methods, such as SSADM, increases both delivery time and bureaucracy. Do you think these criticisms are justified and what are the claimed advantages in the use of structured methods?
It is true that structured methods require more work to be done ‘up front’ in a project, during the analysis and design stages. The formality and rigour that their techniques impose require analysts to get down to more detail than often happened using ‘traditional’ methods. The upside of this, of course, is that there is greater clarity about what the users want which should (a) reduce the actual work of system construction, since programmers do not have to keep going back to the users with questions and (b) result in a system that better meets the users' real needs.
An additional advantage of the depth and quality of documentation that results from a structured approach is that it is easier to maintain and enhance the system once delivered. Bearing in mind that most of the costs of an information system are incurred after initial delivery, this can be of considerable benefit.
However, it has to be admitted that, although these advantages sound plausible, there is an unfortunate lack of hard evidence to prove that they have been realised in practice. To a large extent, the benefits of the structured approach are only apparent to people who have worked in the IS field for some time, especially those involved in maintenance and support.