Book Structure
The content of this book is set out in thirteen chapters and one Appendix as follows:
| |
Preface |
| |
1. |
Introduction to Projects and their Management |
| |
2. |
Defining the Project Task |
| |
3. |
Estimating the Project Costs |
| |
4. |
Managing Risk |
| |
5. |
Organizing the Project |
| |
6. |
Work Breakdown Structures |
| |
7. |
Planning the Timescale |
| |
8. |
Scheduling Project Resources |
| |
9. |
Implementing the Project Plan |
| |
10. |
Managing Purchasing |
| |
11. |
Managing Changes |
| |
12. |
Managing Costs |
| |
13. |
Corporate Managers' Support for the Project Manager |
| |
Selected Bibliography |
The book has a total of 213 pages and the Appendix provides a useful and wide-ranging set of references but the book does not include a Glossary of Terms.
An important observation about this book in general is that the majority of the author's background has been with organizations that buy-in product development services under contract. That is to say, projects are executed by contractors. Thus the author is comfortable using the word "contractor" to refer to the performing organization, even though that "performing organization" is simply a group of people drawn from the organization's internal resources. Here is what Dennis has to say about this organizational arrangement:[3]
"Many projects are carried out by a contractor for an external organization (the customer). The customer and contract agree terms and prices in a contract. However, this arrangement is clouded for some management change projects, where much of the work is conducted by employees of the organization itself. Then the organization is both contractor and its own customer. For simplicity, I shall use the term contractor throughout this book to describe whoever carries out the project work and customer to describe the owner of the project, regardless of whether the customer and contractor reside in the same organization."
This strategy by the author certainly simplifies the contents of the book. Unfortunately, where projects are conducted "in-house", typically the staff is on the corporate pay role and their time is not specifically allocated to projects but rather to other headings of more interest to corporate finance. Hence, gathering project production cost data is not seen as a necessity and consequently not seen as a constraint on the work, as it is when the work is done under contract.
Perhaps that is why Agile Project Management is so popular, and more appropriate, for in-house project work, especially where information technology is concerned.
3. Lock, Dennis, The Essentials of Project Management Fourth Edition, Gower Publishing Ltd, Surrey, England, 2014, p3
|
Introduction
