BOOK

HISTORY OF PROJECT MANAGEMENT

Project Management is not new and in fact, these days, is now being used in almost all imaginable industries.  However, the practice of project management varies considerably from industry to industry, the levels of perceived success vary widely, and even the meaning of the term project management is open to considerable controversy.  Nevertheless, at the core of the practice, is the art of planning, but the act of planning alone is not sufficient if the plan is to realized.  For example, participants to the plan will have gained a fair idea of what is expected, but it will tell them very little about exactly what has to be done, in what order, and when.

BEFORE COMPUTERS

In the old days, which is not so long ago but before table top computers were invented, it was customary to convert the various parts of the project to be created into lists of the work involved in each item.  These work items were the project’s “activities”.  These activities were then plotted with great care and in great detail with pencil and paper on a drafting board.  These activities were then connected with lines according to the expected sequence of work in real life.  These lines were usually annotated with the estimated time to carry out the work and by whom.

So, by following through on a string of lines, it was possible to provide an estimate of how long that string of work would take to perform, who should be doing it and in what sequence.  Given a starting date, and the days or hours worked per week, it was also possible to read off start and finish dates on a calendar.  This diagrammatic plot was known as a “program” (European) or a “schedule” (Americas).

A JUMBLE OF LINES

It should be noted that since lines and boxes drawn on paper can easily be erased, these schedules were relatively easy to “fudge”.

The problem was that, even with careful forethought, all the connecting lines and their descriptors could become a terrible jumble on the drawing board.  And that is to say nothing of having to insert additional activities that were either not previously thought of, were somehow overlooked, or represented by new work being introduced as a result of a project change order.  It was not usual for the whole project schedule to be redrafted several times over and, because of the time delay involved, data on the work being done would overtake the delivery of the revised schedule.  This way, both the schedule and its author fell into disrepute and were consequently ignored.

CONTEMPORARY PROJECT MANAGMENT

Enter the computer, and more recently the desktop computer that today is many times more powerful than the early versions.  But computers only do exactly what you tell them to do, even if you inadvertently tell them to do the wrong thing, they will not fudge it for you!  Moreover, they can handle much larger amounts of data, making it possible, with the right programming, to handle large and complex projects.  And, of course changes can be made “at the touch of a button”.  Well, maybe not exactly, but certainly a lot faster than re-plotting the whole schedule on a drawing board.

MORE THAN DATA

The key is to know what you are doing, how all the work relates, and to make accurate entries.  Sounds simple but to implement a good plan requires the support of the related discipline of project scheduling.  Project scheduling is the process of converting a project plan into a time-based schedule, given various assumptions on the resources available and quite possibly with other restrictions involved.  And by doing it on a computer, a computerized schedule can be printed out in different ways depending on the required purpose, and in whole or in part, as well as answering a whole variety of queries about the work information entered.  This is especially true of today’s large, vital programs and projects, with large numbers of interested parties involved who simply want their part of the story.  In this case, dedicated planners and schedulers are essential.

But this is not just a question of knowing how to run a particular computer program.  Dedicated schedulers in particular must have a good background knowledge and experience of the type of industry or project sector that they are serving in.  This is in order to understand the complexities faced by the workers on the front lines carrying out the work, that must be reflected in the programming, so that the computerized results are realistic.

INDUSTRY SPECIFIC DATA

Now, while it is valuable for computer program operatives to go out and talk to people doing the work, for the most part they must rely on the data being fed to them.  This means that the reports coming in for data entry must be specific, concise and in the form suited for schedule entry.  Which in turn means that those doing the reporting must also have a fair idea of what project scheduling is all about.  So, if you are in any way involved with this part of project management, as I said earlier, the key is to know what you are doing.

Hence, the need for, and value of this book on the subject of Practical Project Scheduling.

ABOUT THE BOOK

One of the highlights of this book is that the authors make no assumptions about what the reader already knows.  Instead, they start out by instructing the reader on the language and environment of project scheduling.  To get a proper grasp of how to schedule a project in practice, it is essential to know the “language”.  That is, the typical terms used in the process and what they mean – see the chapter:  Definitions, and the typical short forms:  Abbreviations & Acronyms.  Don’t skip these pages, because if you don’t know the language, you will have difficulty not just following this book but, more importantly, in participating in the planning and scheduling of any large project in real time.

These chapters are followed by another vital chapter under the heading of Project Management Terminology.  This chapter introduces the reader to the working environment of a project.  That is to say, it describes the important players in a major project and their respective responsibilities, together with key documents and their purpose.  Here, you may encounter projects whose owners have somewhat different interpretations of roles and responsibilities depending on an organization’s own hierarchy and project purpose.  If so, don’t be discouraged, the elements should be the same.  At the end of this chapter is a useful set of Self-test Questions to see how much you have actually absorbed.

The chapter on Work Breakdown Structure (WBS), although relatively short, describes in sufficient detail perhaps one of the most important tools available in project management.  As the explanation in the Definitions chapter explains: “It is commonly used in the form of a visual diagram where it groups the project’s discrete work elements in a hierarchical way.”  Most importantly, the Planner or Scheduler should participate in the development of a project’s WBS to ensure that its structure is “schedule-friendly”.  Otherwise, if the Planner or Scheduler misses this opportunity, the final project schedule may be unnecessarily complex and difficult to manage.

Then follows a series of seven chapters that represent the core of this book on how to get it done.  These chapters are self-evident from their titles, which are:  Project Scheduling Theory;  Schedules – Introduction;  Schedules – Activities;  Schedules – Key Features;  Schedules – Output;  Schedules – Supporting Documents; and Updating a Schedule.  Of these, the first two chapters are the most significant because they explain how to compose a schedule, the options that you have in setting one up, and some choices in the software available for doing so.  The chapter on Key Features is also a valuable source of information in that it provides a greater depth of understanding of the whole value of project scheduling.

The last chapter in the book, Relationship Management, provides us with an important reminder.  As the authors observe: “Good relationships can be the difference between success and failure – since it is all about getting people’s respect and trust.”  Also about: “Opening avenues for them to deliver what is required in terms of progress information, and to deliver it in time and in the right way.”  And that is not easy.

As the authors go on to say: “As with anything that involves people, establishing processes to encourage good communication and relationships, is not easy.  Such processes, and clear instructions, provide the corner stone for successes in any projects.”  Let’s face it, reporting progress, especially if it is not “good news”, means extra work that is not welcome in the field.  So it is important for the scheduler to make sure that the computer program delivers reports that are of value to those in the field, as well as to those in head office.

Throughout the book, the text is supported by a large number of illustrations, diagrams and callout boxes.  Indeed, the authors are to be congratulated on tackling this complex subject, and the thoroughness that they have brought to bear in doing so.