Choosing your networking technique

selecting computer programs, someone competent in programming must be involved; however, he would be involved for the purpose of technical evaluation only. The key person in the selection process should be the manager responsible for the project. The programs will be a tool for his management of the project. He must determine the extent to which other project people become involved in the selection. A technical team may be selected to narrow the field of choices, but the ultimate, in-depth evaluation of the final alternatives must involve the project manager extensively if he is to benefit from the system. To repeat an earlier statement: Managers who are not willing to invest some of their time in learning how the system works are not likely to make good use of the system, and they may, in fact, make worse decisions with it than without it.

img

img

There are three networking techniques commonly used as project management aids in planning and scheduling. These are CPM, PERT and PDM. While there are a virtually limitless array of bells, whistles, embellishments, gimmicks, devices and “brochure claims” associated with proprietary or modified techniques and programs, each can be placed in one of these three categories. When this is done, it becomes starkly evident, in most cases, that all the proprietarieness was added to get around, disguise or overcome a shortcoming or disadvantage indigenous to the basic technique.

Project managers are often deluged by self appointed experts touting their particular system or, more frequently, the one they’ve used and with which they feel comfortable. To the best of my knowledge there has not appeared an even modestly comprehensive tabulation or comparison of technique features, most program features resulting from being based on that technique and of the influence the project characteristics or demands can have on technique (and thus program) suitability. The attached tabulation attempts to do this for the three basic techniques and is believed to be self explanatory. Hopefully it is prepared in a form that will enable the project manager to separate chaff from wheat, decide what’s best for his current project and all this without getting tangled up in algorithms, core requirements, computerese expressions for features or results he needs, and schedulers or salesmen oratory.

One question that frequently is asked relates to the differences between PERT and CPM. The usual answer is that there were some early differences but that these have pretty much disappeared. I disagree strongly with this statement. There are some basic differences which, while they can be overcome or blurred in manual use of the technique, strongly influence the computer programs and techniques based on each technique. A perusal of the tabulation of Features of Networking Methods will reveal some major differences. I personally believe the differences result from one fundamental difference of the environments in which they were developed. CPM was developed to enable directing and scheduling the efforts of a cohesive group with a relatively common goal, not too disperse geographically, with good clean lines of communication and a relatively uniform consistent (corporate or at least project) set of procedures and methods. PERT was developed to enable the monitoring and displaying to all concerned the effects of efforts of autonomous groups with multiple (sometimes conflicting) goals converging only in general at the higher(est) levels, quite disperse geographically, with very structured (torturous) and extended lines of communication and with a very wide diversity of procedures and methods (sometimes conflicting for any one group) which had to be satisfied. These differences remain embedded in the philosophy, terminology, techniques, computer programs, applications and literature of the two techniques though time, cross-pollination and practice has blurred many of the early sharp distinctions.

image
This material has been reproduced with the permission of the copyright owner. Unauthorized reproduction of this material is strictly prohibited. For permission to reproduce this material, please contact PMI.

Advertisement

Advertisement

Related Content

  • Project Management Journal

    Identifying Challenges and a Research Agenda for Flow in Software Project Management member content locked

    By Dennehy, Denis | Conboy, Kieran Flow and its associated tools and metrics are increasingly being reported as an approach used to achieve continuous deployment of software and delivery of value in software development projects. Yet…

  • PM Network

    Escaping Pilot Purgatory member content locked

    By Waity, C. J. Pilot projects can bridge the gap between a brilliant idea and a valuable product—but only if the bridge is successfully completed and built to scale. And in the age of disruption, that doesn't…

  • PM Network

    Hands-On member content locked

    By Karunaratne, Charmaine Although the software development life cycle (SDLC) is an important part of any software project, IT project managers rarely seem to raise the topic. Instead, they leave it to the development teams…

  • PM Network

    Best of Both member content locked

    By Graetsch, Ulrike Maria When leaders at rapidly growing organizations establish a project management office (PMO), they're often seeking better control over which projects are started, more oversight of projects in…

  • Project Management Journal

    How to Buffer the Family Costs of Project Citizenship Behavior member content locked

    By Zhong, Rui | Xia, Nini | Hu, Xiaowen | Wang, Xueqing | Tiong, Robert Previous studies have mainly concentrated on the desirable aspects of project citizenship behavior (PCB) but largely ignored its dark sides. We seek to fill in this gap by exploring whether and when…

Advertisement

Publishing or acceptance of an advertisement is neither a guarantee nor endorsement of the advertiser's product or service. View advertising policy.