The Seven Deadly Sins of Project Management

This web-log post is about projects, but only those project where a commitment has been made by a board or senior management to start and complete it. It attempts to be general enough that insights can be applied to any industry.

Preliminary work on a project will have to be budgeted. Regardless of its outcome, this expenditure will be a sunk cost = a cost that has been incurred and cannot be recovered. With a go ahead, the entire project will not only have to be budgeted, but in some way financed either using owner equity or debt financing, or a combination of both. Liquidity (cash flow) is critical for any project.

The selection of a project manager is critical to project success. The project manager is responsible for the initiation, planning, execution, validation and evaluation of the project. At a minimum, each of these has to be part of the scope statement, and incorporated into the project plan.

After each of the sins listed below, there is a paragraph long comment on atonement = making amends.

Sin #1: No Budget

There is only one sin worse than having no budget, and that is regarding the budget as a project plan!

Atonement for this sin: Make sure there is an adequate budget that covers the entire project period, that is approved of by the board authorizing the project. Before, any project begins: 1) Make sure there is adequate financing. 2) Make sure there is sufficient liquidity (cash flow) for the project.

Sin #2: Managing a project as a process

In many hierarchical organizations, managers are promoted from lower ranks, so that they have an understanding of the roles required below them in the hierarchy. One of the unique characteristics of a project is that it requires the interaction of professionals possessing different qualities. In addition, tasks are non-repetitive, in contrast to process (or operations) management where repetitive, permanent functional activities are the norm.

Even if a project manager can appreciate a project’s temporary nature, with defined beginning and end points, s/he may fail to understand the implications of time, budget and staff constraints, especially in terms of project goals and objectives.

Atonement for this sin: Ensure that the project manager has the education/ training to manage a project. At a minimum s/he must understand the basics of the Critical Path Method.

Sin #3: No Scope Management

Scope requires the project manager to specify the quantity, quality and variety of tasks to be performed, along with the time and other resources available. A scope statement can then be compiled that specifies what the project is to deliver in detail, and to describe more generally the major objectives for the project. These objectives should include measurable success criteria.

At the most fundamental level, Scope is expressed in a statement that is SMART:

• Specific
• Measurable
• Agreed Upon
• Realistic
• Time Bound

Scope involves determining the work that needs to be done to meet stakeholder requirements. Many project managers like to distinguish two types of scope: project scope and product scope. Project scope specifies the the work that needs to be done to deliver a product or service, while product scope specifies the features and functions that characterize that product or service.

Another way of understanding scope, is to separate what has to be done (the functional requirements/ product scope) from how it is to be done (project scope). If requirements cannot be defined and described, then there can be no effective project control, allowing project/ requirement creep to emerge.

Scope creep involves large, unplanned and often irrelevant changes to a project that add costs and/ or development time. Very often these occur because there is no change control built into the project. Change control is a procedure to be included in the scope statement that outlines how changes will be implemented. It must distinguish between acceptable and unacceptable changes. The change control procedure should specify how any change will be implemented.

Atonement for this sin: Make sure there is a SMART scope statement, and make certain that all project participants understand this statement, and its consequences.

Sin #4: No Project Plan

The main purpose of writing a project plan, is for the project manager to define tasks, and to appreciate transitions between them. The fact that there may be disparities between perceived and actual implementation times is of secondary importance. Some projects benefit from the use of software tools, such as MS Project/ LibreProject, or equivalent. In other cases, a simple tempo-plan on paper suffices. Tasks have to have milestones/ way points associated with them, so that everyone knows when a task has been completed. These have to be measurable.

Most projects rely on a critical path, a sequence of tasks that have no leeway in terms of an early or late start. Project slack (also called project float) has to be determined to identify the critical path through the project. Slack can be calculated manually or automatically, using a formula that takes into consideration start and finish times/ dates, durations, predecessor times, task dependencies and constraints. Negative slack indicates that this amount of time must be saved earlier in the project to prevent delay. It is an indication of incorrect finish time for the project.

Tasks outside of the critical path can begin earlier or be delayed, by varying amounts of time. Tasks are placed on a project activity diagram, that shows total slack (the time available for a task to slip before it delays the whole project) and each task’s free slack (the time available before it delays successor tasks).

Atonement for this sin: Except for the smallest of projects, someone assigned to the project must construct a project plan based on the critical path method, make sure the plan is used. Significant deviation from the project plan must be reported to the authority commissioning the project, usually some sort of board. Project managers have a responsibility to communicate with stakeholders, and to ensure everyone understands the project plan, at least in outline, and how it will affect each stakeholder.

Sin #5: No Resource Management

After scope management has been satisfactorily implemented as a project plan, the next phase involves resource management. Some projects, such as building construction, will have materials management as an important component. Other projects, including software projects, will find that materials management is minimal, or even non-existent. Regardless of the type of project, much managerial time will almost always have to be allocated to human resource management, if the project is to run smoothly.

In a building construction project, materials management is seldom a problem because everyone, even the project manager, knows that the building has to be made of something, and probably many different things. A bill of materials (BOM) is produced automatically by almost every Computer-Aided Design (CAD) system. These BOMs are first used for scope management, and after that in conjunction with resource management. Problems emerge with materials management, when they are not properly specified during the scope management phase.

Most of the problems associated with resource management come from a failure to appoint a reference group, or even a project group. These two problems will be treated as separate sins.

Atonement for this sin: Materials management – Ensure that a BOM is used, where it is appropriate. Understand how to use a BOM, and ensure that all members in the project group understand how to use a BOM. Provide training if necessary. Human resources management – see sin #7 – no project group.

Sin #6: No Reference Group

In every project there are a large number of stakeholders. In building construction there will be municipal/ county building authorities, neighbours who live on and/ or own surrounding properties, and potential occupiers/ renters/ owners, at a minimum. In software projects there will be assorted classes of purchasers, who may or may not be users. In projects involving local government there are civil servants, as well as politicians, who may view processes totally differently.

The purpose of a reference group is to ensue that a project meets the needs of different user groups, at the same time that it doesn’t encroach on the rights of non-users, who may be impacted by the project. Without a reference group, the project manager and others in the project will be living in a fantasy world. Thus, one of the first tasks of a project manager is to ensure that there is a process to find stakeholders, and to invite them to be part of a reference group.

Atonement for this sin: Ensure that a reference group is appointed, and that it mirrors the diversity of people affected by the project. Ensure that reference group meetings are scheduled and held. Stakeholders must ensure that someone representing their group is appointed to the reference group, that they are invited to reference group meetings, and report back to stakeholders.

Sin #7: No Project Group

Some project managers think they can run a project alone, without involving people possessing different qualities, who together (but not alone or separately) understand the non-repetitive tasks involved. Normally, they can’t.

This does not mean that members of the project group have to devote significant amounts of time to meetings, or other forms of interaction. Rather, members of the project group spend most of their time working on those parts of the project they are assigned, reporting on the state of milestones/ way points as they occur.

When disruptions occur, or when other events impact project progress, there can be a need for project meetings to discuss alternatives.

Atonement for this sin: Ensure that a project group is appointed, and that it mirrors the diversity of people working on the project. Ensure that project group meetings are scheduled and held. Members of a project group, must schedule and attend regular project group meetings. It is particularly important, that project managers ensure that feedback from the reference group is presented to the project group.

Project management has matured considerably, during the past eighty years, but not noticeably since the first projects I worked on in the 1970s. The only difference I have noted is the use of project management software to replace the calculations I had to perform by hand. This was undoubtedly the result of PERT (Project Evaluation and Review Technique) developed for the Polaris submarine project, and CPM (Critical Path Method) developed by DuPont, in the 1960s.

Before these developments there was (not so) managed chaos. “During the 1940s, line managers used the concept of over-the-fence management to manage projects. Each line manager, wearing the hat of a project manager, would perform the work necessitated by their line organization, and when completed, would throw the “ball” over the fence in hopes that someone would catch it. Once the ball was thrown over the fence, the line managers would wash their hands of any responsibility for the project because the ball was no longer in their yard. If a project failed, blame was placed on whichever line manager had the ball at that time.” Harold Kerzner 2017 Project Management: A Systems Approach to Planning, Scheduling, and Controlling, 12th edition, p. 39.

Despite the injustice of this system, it was the users/ customers who suffered the most. Kerzner continues, “The problem with over-the-fence management was that the customer had no single contact point for questions. The filtering of information wasted precious time for both the customer and the contractor. Customers who wanted firsthand information had to seek out the manager in possession of the ball. For small projects, this was easy. But as projects grew in size and complexity, this became more difficult.” (p. 40).

I was very fortunate to have John Reagan as a mentor in 1972 at Habitat Industries, a pre-fabricated housing manufacturer. He kindled in me an interest in project management that continues to this day, even if it was more frequently used in teaching computer science and technology subjects, than in the construction trades.