Project management: All hands on deck may sink the project

Engineering and IT Insight: When you call “All hands on deck!” to help finish a late project, ensure that all of the extra resources don’t further sink the project. If adding extra people at the end of a project, apply them to independent subtasks, use experienced people, and organize work to minimize required intra-project communications.

By Dennis Brandl April 19, 2012

One of the classic books of software engineering deals with project management. Unfortunately, many automation engineers and project managers are not familiar with the work. The book is “The Mythical Man-Month: Essays on Software Engineering” by Frederick P. Brooks (ISBN 0-201-83595-9). Originally published in 1975, updated in 1982 and again in 1995, it is based on a series of IBM development projects. While a book on software written over 35 years ago may not seem relevant in today’s Internet connected, mobile, software-dominant world, it still has valuable lessons for anyone who is involved in systems that have a software component. One of the primary lessons taught in the book is that “adding manpower to a late software project makes it later.” This simple and timeless lesson is often forgotten in the rush to complete projects, especially if a project is in trouble late in the development cycle.

The reason for this non-intuitive lesson, also known as “Brooks’ Law,” is that software projects, including automation software projects, have inherent integration requirements. Pieces must fit together, without errors, for the system to work correctly. Yet software is not visible or easily reviewable until the pieces are ready for integration. Add in the complexity of hardware elements in automation projects and the need for integration is even higher. Therefore, to make a reliable system, there must be a significant amount of communication among architects, developers, managers, and users. As people are added to a project, the communication paths increase nonlinearly (for the mathematically inclined, this is {n*(n-1)/2}), while the benefit of the additional people increases linearly, at best. In addition, there are other costs to adding people to a project, such as additional training (usually performed by existing team members), additional systems and tools (usually supported by existing team members), and additional coordination meetings (usually attended by existing team members).

When a project is behind schedule, upper management sometimes has a desire to throw resources at the project hoping that it will fix the problem. In some projects, teams of outsiders will descend on the project team to “help,” often only getting in the way, creating more paperwork, and taking valuable time while getting up to speed on the project. These activities delay the project and make the already late project even later. Frederick Brooks’ experiences at IBM and experiences of most project managers show the fallacy of throwing people into a project at a late stage. When this occurs, the project usually will get even further behind schedule, prompting management to add even more resources and cause even further delays.

You can solve this dilemma by adding resources that meet very specific requirements and by having a project organization that is designed for the late addition of personnel. If you are adding people late in the project, then you must minimize interactions with other team members. This means that people you add must be already trained in the system being used, must understand the policies and procedures in place for the project, must work on a very specific and well-defined task, must be able to work independently with minimal direction, and must not be allowed to redefine requirements, designs, or implementations that have already been agreed to. In short, you need experienced senior level people who are willing to stay within their immediate work tasks and not attempt to “fix” problems in other areas. These people are in short supply, and often extra personnel will come in with minimal knowledge of the system being developed and the policies and procedures to follow. For example, if you need additional testing resources on a project, then add only experienced testers who can follow previously defined tests. If you need code development, then add only experienced resources who understand the system and how to read requirements, so they can develop code without extensive interaction with other parts of the team.

The second way to add people late in a project and not make it even later is also discussed in Brooks’ book under the chapter titled “The Surgical Team.” If your project team can be organized using the surgical team model where every member has a very special and well-defined role, then communication paths are reduced and learning is reduced (assuming the new person has a good knowledge of the role). If you have this organization, then adding resources to support specific roles will benefit the project instead of slowing it down. A simple rule of thumb that can be derived from Brooks’ Law is “the maximum number of people on a project is dependent on the number of independent subtasks in the project.” The more tasks are subdivided because of extra “help,” the longer it will take to complete the subtasks.

If you call all-hands-on-deck to help finish a late project, ensure that all of the extra resources don’t further sink your project. If using extra people at the end of the project, apply them to independent subtasks, use experienced people, and organize work to minimize required intra-project communications.

– Dennis Brandl is president of BR&L Consulting in Cary, N.C., www.brlconsulting.com. His firm focuses on manufacturing IT. Contact him at dbrandl@brlconsulting.com. Edited by Mark T. Hoske, Control Engineering, www.controleng.com.

Read more Engineering and IT Insight columns by using the following link.

https://www.controleng.com/cgi-bin/ce.cgi?cmd=Search!&fmt=long&form=extended&GroupBySite=no&m=all&ps=10&q=%22dennis+brandl%22&sp=1&sy=1&type=&ul=&wf=2221&wm=wrd&s=DRP

What are your manufacturing IT project principles?

What are your manufacturing IT project principles?