SPM_A01.qxd
4/23/09
4:28 PM
Page i
Software Project Management
Fifth Edition
SPM_A01.qxd
4/23/09
4:28 PM
Page ii
SPM_A01.qxd
4/23/09
4:28 PM
Page iii
Software Project Management Fifth Edition
Bob Hughes and Mike Cotterell
London Boston Burr Ridge, IL Dubuque, IA Madison, WI New York San Francisco St. Louis Bangkok Bogotá Caracas Kuala Lumpur Lisbon Madrid Mexico City Milan Montreal New Delhi Santiago Seoul Singapore Sydney Taipei Toronto
SPM_A01.qxd
4/23/09
4:28 PM
Page iv
Software Project Management, 5e Bob Hughes and Mike Cotterell ISBN-13 978-0-07-712279-9 ISBN-10 0-07-712279-8
Published by McGraw-Hill Education Shoppenhangers Road Maidenhead Berkshire SL6 2QL Telephone: 44 (0) 1628 502 500 Fax: 44 (0) 1628 770 224 Website: www.mcgraw-hill.co.uk British Library Cataloguing in Publication Data A catalogue record for this book is available from the British Library Library of Congress Cataloguing in Publication Data The Library of Congress data for this book has been applied for from the Library of Congress Acquisitions Editor: Catriona Hoyle Marketing Manager: Alice Duijser Production Editor: Alison Holt Text Design by Hardlines Cover design by Ego-Creative Printed and bound in the UK by Bell and Bain Ltd, Glasgow Published by McGraw-Hill Education (UK) Limited an imprint of The McGraw-Hill Companies, Inc., 1221 Avenue of the Americas, New York, NY 10020. Copyright © 2009 by McGraw-Hill Education (UK) Limited. All rights reserved. No part of this publication may be reproduced or distributed in any form or by any means, or stored in a database or retrieval system, without the prior written consent of The McGraw-Hill Companies, Inc., including, but not limited to, in any network or other electronic storage or transmission, or broadcast for distance learning. Fictitious names of companies, products, people, characters and/or data that may be used herein (in case studies or in examples) are not intended to represent any real individual, company, product or event. ISBN-13 978-0-07-712279-9 ISBN-10 0-07-712279-8 © 2009. Exclusive rights by The McGraw-Hill Companies, Inc. for manufacture and export. This book cannot be re-exported from the country to which it is sold by McGraw-Hill.
SPM_A01.qxd
4/23/09
4:28 PM
Page v
Dedication For Pavle Bataveljic 1945–2008
SPM_A01.qxd
4/23/09
4:28 PM
Page vi
Brief Table of Contents
1 2 3 4 5 6 7 8 9 10 11 12 13
vi
Preface Guided tour Technology to enhance learning and teaching Acknowledgements
x xii xiv xvii
Introduction to software project management Project evaluation and programme management An overview of project planning Selection of an appropriate project approach Software effort estimation Activity planning Risk management Resource allocation Monitoring and control Managing contracts Managing people in software environments Working in teams Software quality
1 21 49 73 103 129 162 192 212 236 254 271 293
Appendix A Appendix B Further reading Index
325 337 375 379
SPM_A01.qxd
4/23/09
4:28 PM
Page vii
Detailed Table of Contents Preface Guided tour Technology to enhance learning and teaching Acknowledgements 1 Introduction to software project management 1.1 Introduction 1.2 Why is software project management important? 1.3 What is a project? 1.4 Software projects versus other types of project 1.5 Contract management and technical project management 1.6 Activities covered by software project management 1.7 Plans, methods and methodologies 1.8 Some ways of categorizing software projects 1.9 Stakeholders 1.10 Setting objectives 1.11 The business case 1.12 Project success and failure 1.13 What is management? 1.14 Management control 1.15 Conclusion Annex 1 Contents list for a project plan 1.16 Further exercises 2 Project evaluation and programme management 2.1 Introduction 2.2 A business case 2.3 Project portfolio management 2.4 Evaluation of individual projects 2.5 Cost–benefit evaluation techniques 2.6 Risk evaluation 2.7 Programme management 2.8 Managing the allocation of resources within programmes
x xii
2.9
xiv xvii
2.10 2.11 2.12
1 1
2.13 2.14 2.15
2 2 4 5 5 8 9 11 11 13 14 15 16 18 18 19
21 21 22 24 26 28 34 38 39
Strategic programme management Creating a programme Aids to programme management Some reservations about programme management Benefits management Conclusion Further exercises
3 An overview of project planning 3.1 Introduction to Step Wise project planning 3.2 Step 0: Select project 3.3 Step 1: Identify project scope and objectives 3.4 Step 2: Identify project infrastructure 3.5 Step 3: Analyse project characteristics 3.6 Step 4: Identify project products and activities 3.7 Step 5: Estimate effort for each activity 3.8 Step 6: Identify activity risks 3.9 Step 7: Allocate resources 3.10 Step 8: Review/publicize plan 3.11 Steps 9 and 10: Execute plan/lower levels of planning 3.12 Conclusion 3.13 Further exercises 4 Selection of an appropriate project approach 4.1 Introduction 4.2 Build or buy? 4.3 Choosing methodologies and technologies 4.4 Choice of process models 4.5 Structure versus speed of delivery 4.6 The waterfall model 4.7 The spiral model 4.8 Software prototyping 4.9 Other ways of categorizing prototypes 4.10 Incremental delivery
40 40 43 45 45 47 48 49 49 53 53 55 58 60 65 67 68 69 70 71 71
73 73 74 76 81 81 82 84 84 86 88
vii
SPM_A01.qxd
viii
4/23/09
4:28 PM
Page viii
Detailed Table of Contents
4.11 Agile methods 4.12 Atern/Dynamic Systems Development Method 4.13 Extreme programming (XP) 4.14 Managing iterative processes 4.15 Selecting the most appropriate process model 4.16 Conclusion 4.17 Further exercises
92 93 95 99 100 101 101
5 Software effort estimation 5.1 Introduction 5.2 Where are estimates done? 5.3 Problems with over- and underestimates 5.4 The basis for software estimating 5.5 Software effort estimation techniques 5.6 Bottom-up estimating 5.7 The top-down approach and parametric models 5.8 Expert judgement 5.9 Estimating by analogy 5.10 Albrecht function point analysis 5.11 Function points Mark II 5.12 COSMIC full function points 5.13 COCOMO 13: a parametric productivity model 5.14 Conclusion 5.15 Further exercises
103 103 105
6 Activity planning 6.1 Introduction 6.2 The objectives of activity planning 6.3 When to plan 6.4 Project schedules 6.5 Projects and activities 6.6 Sequencing and scheduling activities 6.7 Network planning models 6.8 Formulating a network model 6.9 Adding the time dimension 6.10 The forward pass 6.11 The backward pass 6.12 Identifying the critical path 6.13 Activity float 6.14 Shortening the project duration 6.15 Identifying critical activities 6.16 Activity-on-arrow networks 6.17 Conclusion 6.16 Further exercises
129 129
107 108 108 109 111 112 113 114 117 119 120 125 126
130 131 131 133 138 139 140 144 146 146 148 150 150 151 151 160 160
7 Risk management 7.1 Introduction 7.2 Risk 7.3 Categories of risk 7.4 A framework for dealing with risk 7.5 Risk identification 7.6 Risk assessment 7.7 Risk planning 7.8 Risk management 7.9 Evaluating risks to the schedule 7.10 Applying the PERT technique 7.11 Monte Carlo simulation 7.12 Critical chain concepts 7.13 Conclusion 7.14 Further exercises
162 162 163 165
8 Resource allocation 8.1 Introduction 8.2 The nature of resources 8.3 Identifying resource requirements 8.4 Scheduling resources 8.5 Creating critical paths 8.6 Counting the cost 8.7 Being specific 8.8 Publishing the resource schedule 8.9 Cost schedules 8.10 The scheduling sequence 8.11 Conclusion 8.12 Further exercises
192 192 194
9 Monitoring and control 9.1 Introduction 9.2 Creating the framework 9.3 Collecting the data 9.4 Visualizing progress 9.5 Cost monitoring 9.6 Earned value analysis 9.7 Prioritizing monitoring 9.8 Getting the project back to target 9.9 Change control 9.10 Conclusion 9.11 Further exercises
212 212 213 216 218 222 223 229
10 Managing contracts 10.1 Introduction 10.2 Types of contract 10.3 Stages in contract placement 10.4 Typical terms of a contract 10.5 Contract management
166 166 168 172 173 176 176 182 183 188 188
195 197 201 202 203 204 204 207 209 209
229 232 235 235 236 236 237 243 247 250
SPM_A01.qxd
4/23/09
4:28 PM
Page ix
Detailed Table of Contents
10.6 Acceptance 10.7 Conclusion 10.8 Further exercises 11 Managing people in software environments 11.1 Introduction 11.2 Understanding behaviour 11.3 Organization behaviour: a background 11.4 Selecting the right person for the job 11.5 Instruction in the best methods 11.6 Motivation 11.7 The Oldham–Hackman job characteristics model 11.8 Stress 11.9 Health and safety 11.10 Some ethical and professional concerns 11.11 Conclusion 11.12 Further exercises 12 Working in teams 12.1 Introduction 12.2 Becoming a team 12.3 Decision making 12.4 Organizational structures 12.5 Coordination dependencies
251 252 252
254 254 256 257 258 261 261 264 265 266 267 269 269 271 271 273 276 281 283
12.6 12.7 12.8 12.9 12.10 12.11
Dispersed and virtual teams Communication genres Communication plans Leadership Conclusion Further exercises
13 Software quality 13.1 Introduction 13.2 The place of software quality in project planning 13.3 The importance of software quality 13.4 Defining software quality 13.5 ISO 9126 13.6 Product versus process quality management 13.7 Quality management systems 13.8 Process capability models 13.9 Techniques to help enhance software quality 13.10 Testing 13.11 Quality plans 13.12 Conclusion 13.13 Further exercises
Appendix A PRINCE2 – an overview Appendix B Answer pointers Further reading Index
284 286 288 289 292 292 293 293 294 295 295 298 304 306 308 314 319 322 323 323 325 337 375 379
ix
SPM_A01.qxd
4/23/09
4:28 PM
Page x
Preface Preparing the fifth edition of this book has reminded us that project management is not just a crucial element in successful software and IT development, but is also a fascinating topic in its own right. It is an intriguing mixture of the technical and the very human, of the rational and also the intuitive. Initially we offered this topic as an ancillary discipline for software engineers and IT practitioners. We have, however, become increasingly convinced that the discipline should have a more central role: that the question of how systems are implemented is a vital one to be asked at the same time as that of what a system is to do. Not many software books have lasted as long as this one. Clearly the principles of project management are less transient than those of software design and implementation, which have gone through some very major developments over recent years. However, project management has not been immune from change. One development has been the growth in project management bodies of knowledge such as those of the Project Management Institute (PMI) in the United States and the Association for Project Management (APM) in the United Kingdom. There has also been the development of project management standards such as PRINCE2. These developments are to be welcomed as externalizing and codifying good practice – indeed we have included an appendix on PRINCE2. However, we have resisted becoming a ‘PMI’ book or a ‘PRINCE2’ book. Partly this is because we believe that software project management, while incorporating all the key elements of generic project management, also has to deal with the peculiar problems associated with creating software. These include the relative intangibility of software, its extreme malleability, the intimate relationship it has with the systems within which it is embedded, and its sheer complexity. We also wanted to avoid means–end inversion where there was a focus on the recall of specific terminology and procedural detail at the expense of an understanding of underlying concepts and purpose. One new development that has been taken on board has been the growing awareness that a project is rarely an isolated activity but is almost always part of a broader programme of work aimed at meeting organizational and business objectives. There are also agile approaches, such as extreme programming, which have been a timely reminder that software development is an intensely human activity. In contrast to this emphasis on the highly productive, highly interactive co-located team, there is also a growth of dispersed or virtual projects where all or part of the development team is in another country or even continent. We noted these developments in previous editions but have expanded their treatment in this one – this greater emphasis on development team dynamics has led to the creation of a chapter devoted solely to these topics. One major problem has been the conflict between a desire to include all the topics that our reviewers would like to see and the desire for a concise volume that avoids ‘bloating’. Sometimes there are topics and standards which appear to be current and of which one feels people should be aware. On closer inspection, the material for various reasons is less x
SPM_A01.qxd
4/23/09
4:28 PM
Page xi
Preface
useful or relevant than one hoped. In this edition we have dropped an appendix on the British standard BS6079. This is because the new version of this has become what is essentially a general advisory guide on project management practice. As such it duplicates material already covered in this book. Some individual topics have also been dropped because it was felt that they really needed a deeper treatment better conveyed by a more specialist publication than this one: the internal rate of return (IRR) in project evaluation and the Hofstede analysis of national cultural characteristics are examples. In general, though, we have erred on the side of caution in retaining topics. It seems a long time since the first, rather slim, edition published in 1995. As novice authors, Cotterell and Hughes were very indebted to Dave Hatter and Martin Campbell Kelly who had a huge influence on the style of the book. Dave Hatter in particular emphasized the need for each chapter to have clear learning objectives: ideally the reader should finish the chapter feeling they had learnt a new skill. He also instilled the need to explain things clearly – to feel confident in using simple words to explain things that might at first appear complicated. We are aware that we have not always lived up to these values – and have been taken to task by our students and teachers from other institutions who have kindly acted as reviewers. Many of the changes we have made in the new edition are as a result of this process.
Acknowledgements
D
uring the course of preparing the four previous editions since 1995, we have received assistance from many people. These people have included: Ken I’Anson, Chris Claire, David Howe, Martin Campbell Kelly, Barbara Kitchenham (for permission to use a project data set shown in Chapter 5), Paul Radford and Robyn Lawrie of Charismatek Software Metrics in Melbourne, David Garmus and David Herron (the last four, all for material in Chapter 10), David Purves, David Wynne, Dick Searles, John Pyman, Jim Watson, Mary Shepherd, Sunita Chulani, David Wilson, David Farthing, Charlie Svahnberg, Henk Koppelaar and Ian McChesney. We have made use of materials produced by Abdullah Al Shehab and David I. Shepherd in the chapter on risk. David also offered some advice on the developments in earned value analysis. Our colleague Marian Eastwood helped us out on some of the finer points of the Unified System Development Method. We would also like to thank the team at McGraw-Hill. The role previously taken by Karen Mosman was taken over by Catriona Hoyle (née Watson) and Katy Hamilton who, among other good things, instilled the necessary disciplines of timeliness. We have already mentioned Dave Hatter who was our former editor at International Thomson Press and then at McGraw-Hill and we hope he continues to enjoy retirement in the groves and glades of Essex.
xi
SPM_A01.qxd
4/23/09
4:28 PM
Page xii
Guided tour project management
Objectives
O BJECTIVES When you have completed this chapter you will be able to:
❖ explain the main elements of the
❖ define the scope of ‘software project
❖ appreciate the need for careful
Each chapter opens with a set of learning objectives, summarizing what the reader should learn from each chapter.
role of management; planning, monitoring and control;
management’;
❖ identify the stakeholders of a project
❖ understand some problems and
and their objectives;
concerns of software project managers; ❖ define the usual stages of a software project;
❖ define the success criteria for a
project.
1.1 Introduction
T
his textbook is about ‘software project management’. The first question is whether the management of software projects is really that different from that of other projects. To answer this, we need to look at some key ideas about the planning, monitoring and control of software projects. We will see that all projects are about meeting objectives. Like any other project, a software project must satisfy real needs. To do this we must identify the project’s stakeholders and their objectives. Ensuring that their objectives are met is the aim of project management However we cannot know comes from a National Audit Office report, Improving IT Procurement, November 2004.
There has been some debate about the precise validity of the Standish findings but the key point about the prevalence of IT project failings remains clear.
Margin notes New ideas, terms and references are placed in the margin where appropriate. Margin notes also indicate the links to ideas and concepts covered elsewhere in the textbook.
1.3 What is a project? Dictionary definitions of ‘project’ include: ‘A specific plan or design’ ‘A planned undertaking’ ‘A large undertaking: e.g. a public works scheme’, Longman Concise English Dictionary, 1982.
Programme management is often used to coordinate activities on j b
1.3 What is a project?
Uncertainty of outcome
Routine
Jobs
Projects
Exploration
FIGURE 1.1 Activities most likely to benefit from project management
3
ICT projects. In the United Kingdom during the financial year 200 the central government spent more on contracts for ICT projects t contracts related to roads (about £2.3 billion as opposed to £1.4 The biggest departmental spender was the Department for Work a Pensions, who spent over £800 million on ICT. Mismanagement o ICT projects means that there is less to spend on good things such hospitals. Unfortunately, projects are not always successful. In a report p in 2003, the Standish Group in the United States analysed 13,522 and concluded that only a third of projects were successful; 82% projects were late and 43% exceeded their budget. The reason for these project shortcomings is often the manage of projects. The National Audit Office in the UK, for example, am factors causing project failure identified ‘lack of skills and proven to project management and risk management’.
The dictionary definitions put a clear emphasis on the project bei planned activity. The emphasis on being planned assumes we can determine ho to carry out a task before we start. Yet with exploratory projects th be difficult. Planning is in essence thinking carefully about somet before you do it – even with uncertain projects this is worth doin long as the resulting plans are seen as provisional. Other activitie as routine maintenance, will have been performed so many times everyone knows exactly what to do. In these cases, planning hard seems necessary, although procedures might be documented to e consistency and to help newcomers. The activities that benefit most from conventional project man are likely to lie between these two extremes – see Figure 1.1. There is a hazy boundary between the non-routine project and routine job. The first time you do a routine task it will be like a pr the other hand, a project to develop a system similar to previous
Figures and tables Each chapter provides a number of figures to show the various models, project planning tools and charts.
The following characteristics distinguish projects: ■
non-routine tasks are involved;
■
planning is required;
■
specific objectives are to be met or a specified product is to be created;
■
the project has a predetermined time span;
■
work is carried out for someone other than yourself;
■
work involves several specialisms;
■
people are formed into a temporary work group to carry out the task;
50
Chapter 3 An overview of project planning
should be compatible with PRINCE2. It should be noted, however, that Step Wise covers only the planning stages of a project and not monitoring and control. In order to illustrate the Step Wise approach and how it might have to be adapted to deal with different circumstances, two parallel examples are used. Let us assume that there are two former Computing and Information Systems students who now have several years of software development experience under their belts.
Appendix A adds some further details about the PRINCE2 approach.
Case study examples Brief case studies run throughout the chapters to illustrate the application of project management techniques.
CASE STUDY EXAMPLE A: BRIGHTMOUTH COLLEGE PAYROLL
B
rigette has been working for the Management Services department of a local authority when she sees an advertisement for the position of Information Systems Development Officer at Brightmouth College. She is attracted to the idea of being her own boss, working in a relatively small organization and helping them to set up appropriate information systems from scratch. She applies for the job and gets it. One of the first tasks that confronts her is the implementation of independent payroll processing. (This scenario has already been used as the basis of some examples in Chapter 1.)
CASE STUDY EXAMPLE B: INTERNATIONAL OFFICE EQUIPMENT ANNUAL MAINTENANCE CONTRACTS
A
manda works for International Office Equipment (IOE), which assembles, supplies, installs and services various items of high-technology office equipment. An expanding area of their work is the maintenance of ICT equipment. They have now started to undertake maintenance of equipment of which they were not the original suppliers. An existing application built by the in-house ICT department allows sales staff to input and generate invoices for completed work. A large organization might have t ll t IOE l ti d i th t d l ith bl ith i t E h
xii
SPM_A01.qxd
4/23/09
4:28 PM
Page xiii
Guided tour
■
people are formed into a temporary work group to carry out the task;
■
work is carried out in several phases;
■
the resources that are available for use on the project are constrained;
■
the project is large or complex.
The more any of these factors apply to a task, the more difficult that task will be. Project size is particularly important. The project that employs 20 developers is likely to be disproportionately more difficult than one with only 10 staff because of the need for additional coordination. The examples and exercises used in this book usually relate to smaller projects in order to make the techniques easier to grasp. However, the techniques and issues discussed are of equal relevance to larger projects.
EXERCISE 1.1 Consider the following: ■
producing an edition of a newspaper;
■
putting a robot vehicle on Mars to search for signs of life;
■
getting married;
■
amending a financial computer system to deal with a common European currency;
Exercises Brief exercises are dotted throughout the chapters, to allow students to practise the techniques and apply the methodology to real-world situations.
accelerated data transfer. It can be seen that a project plan is dynamic and will need constant adjustment during the execution of the project. Courses and books on project management (such as this one) often focus considerable attention on project planning. While this is to be expected, with nearly all projects much more time is spent actually doing the project rather than planning it. A good plan provides a foundation for a good project, but is nothing without intelligent execution. The original plan will not be set in stone but will be modified to take account of changing circumstances.
Chapter conclusions This briefly reviews and reinforces the main topics covered in each chapter to ensure that students have acquired a solid understanding of the key topics.
1.15 Conclusion This chapter has laid a foundation for the remainder of the book by defining what is meant by various terms such as ‘software project’ and ‘management’. Among some of the more important points that have been made are the following: ■
Projects are by definition non-routine and therefore more uncertain than normal undertakings.
■
Software projects are similar to other projects but have some attributes that present particular difficulties, e.g. the relative invisibility of many of their products.
■
A key factor in project success is having clear objectives. Different stakeholders in a project, however, are likely to have different objectives. This points to the need for a recognized overall project authority.
■
For objectives to be effective there must be practical ways of testing that the objectives have been met.
■
Where projects involve many different people, effective channels of information have to be established. Having objective measures of success helps unambiguous communication between the various parties to a project.
Annex 1 Contents list for a project plan The detail that goes into these sections
■ ■
■
Introduction
■
Background: including reference to the business case
■
Project objectives
Risks to the project Management of the project, including organizational responsibilities ● management of quality ● configuration management ●
Further exercises
1.16 Further exercises 1 List the problems you experienced when you carried out a recent ICT-related assignment. Try to put these problems into some order of magnitude. For each problem consider whether there was some way in which the problem could have been reduced by better organization and planning by yourself. 2 Identify the main types of personnel employed in an information systems department. For each stage of a typical IS development project, list the types of personnel who are likely to be involved. 3 A public library is considering the implementation of a computer-based system to help administer book loans at libraries. Identify the stakeholders in such a project. What might be the objectives of such a project and how might the success of the project be measured in practical terms? 4 A software house has developed a customized order processing system for a client. You are an employee of the software house that has been asked to organize a training course for the end-users of the system. At present, a user handbook has been produced, but no specific training material. A plan is now needed for the project which will set up the delivery of the training courses. The project can be assumed to have been completed when the first training course starts. Among the things that will need to be considered are the following: ● ● ● ●
These questions encourage the reader to review and apply the knowledge acquired from each chapter and to explore further some of the ideas in the chapter.
training materials will need to be designed and created; a timetable will need to be drafted and agreed; date(s) for the course will need to be arranged; the people attending the course will need to be identified and notified;
Appendices Appendix A at the end of the book explains PRINCE2. Appendix B, Answer pointers, provides guide answers to the questions and exercises set in the book.
Appendix A: PRINCE2 – an overview A.1 Introduction to PRINCE2
L
arge organizations can have a number of software and other projects being executed at the same time. Some of these might use external suppliers of products and services. In such an environment it would be helpful if the procedures by which each project were run were standardized rather than having to be continually reinvented. However, each project will make different demands on management: some, for example, might be more technically challenging, might affect particularly critical areas of the business or might involve larger numbers of different types of users. Because the adoption of a management method is not costfree, the degree of control that will be cost-effective will vary from project PRINCE stands for to project. Hence any standard approach should incorporate mechanisms ‘PRojects IN to tailor management procedures and structures to suit localized needs. Controlled In the UK, the government has sponsored, through the OGC, a set of such Environments’. procedures, called PRINCE, which has, after several years, been revised as PRINCE2. The precursor to PRINCE was a project management method called PROMPT, which
The OGC is the Office of Government Commerce, which has replaced the CCTA, the Central Computer and Telecommunications Agency.
xiii
SPM_A01.qxd
4/23/09
4:28 PM
Page xiv
Technology to enhance learning and teaching Visit www.mcgraw-hill.co.uk/textbooks/hughes today Online Learning Centre (OLC) After completing each chapter, log on to the supporting Online Learning Centre website. Take advantage of the study tools offered to reinforce the material you have read in the text, and to develop your knowledge of project management in a fun and effective way.
Resources for lecturers include:
xiv
■
Power Point Slides
■
Tutorial Exercises
■
Artwork from Book
SPM_A01.qxd
4/23/09
4:28 PM
Page xv
Custom Publishing Solutions: Let us help make our content your solution At McGraw-Hill Education our aim is to help lecturers to find the most suitable content for their needs delivered to their students in the most appropriate way. Our custom publishing solutions offer the ideal combination of content delivered in the way which best suits lecturers and students.
Our custom publishing programme offers lecturers the opportunity to select just the chapters or sections of material they wish to deliver to their students from a database called Primis at www.primisonline.com. Primis contains over two million pages of content from: ■
textbooks
■
professional books
■
case books – Harvard Articles, Insead, Ivey, Darden, Thunderbird and BusinessWeek
■
Taking Sides – debate materials
across the following imprints: ■
McGraw-Hill Education
■
Open University Press
■
Harvard Business School Press
■
US and European material
There is also the option to include additional material authored by lecturers in the custom product – this does not necessarily have to be in English. We will take care of everything from start to finish in the process of developing and delivering a custom product to ensure that lecturers and students receive exactly the material needed in the most suitable way. With a Custom Publishing Solution, students enjoy the best selection of material deemed to be the most suitable for learning everything they need for their courses – something of real value to support their learning. Teachers are able to use exactly the material they want, in the way they want, to support their teaching on the course. Please contact your local McGraw-Hill representative with any questions or alternatively contact Warren Eels at
[email protected]. xv
SPM_A01.qxd
4/23/09
4:28 PM
Page xvi
Make the grade!
30% off any Study Skills book! Our Study Skills books are packed with practical advice and tips that are easy to put into practice and will really improve the way you study. Topics include: ■ ■
Techniques to help you pass exams Advice to improve your essay writing
Help in putting together the perfect seminar presentation
■ ■
Tips on how to balance studying and your personal life
www.openup.co.uk/studyskills Visit our website to read helpful hints about essays, exams, dissertations and much more.
Special offer! As a valued customer, buy online and receive 30% off any of our Study Skills books by entering the promo code getahead
xvi
SPM_A01.qxd
4/23/09
4:28 PM
Page xvii
Acknowledgements Our thanks go to the following reviewers for their comments at various stages in the text’s development: Christopher Procter, University of Salford Darren Dalcher, Middlesex University David Gustafos, Kansas State University David Farthing, University of Glamorgan Klaus Van den Berg, University of Twente Miroslaw Staron, IT University of Goteborg Every effort has been made to to trace and acknowledge ownership of copyright and to clear permission for material reproduced in this book. The publishers will be pleased to make suitable arrangements to clear permission with any copyright holders whom it has not been possible to contact.
xvii
SPM_A01.qxd
4/23/09
4:28 PM
Page xviii
