Select Page


The Seven Deadly Project Sins: Part 7 – Best Practice Sloth (#7 in the series The Seven Deadly Project Sins)
By Tim Bergmann

This document is seventh and last in a series about the Seven Deadly Project Sins.

I have been focusing on some of the “soft-elements” of the project, some temptations that the project manager needs to be on the lookout for in order to foster success on the project.

The Seven Deadly Project Sins as I have defined them are:

  • Elitism
  • Project Envy
  • Resource Gluttony
  • Project Lust
  • Personalization
  • Over-allocation of Resources
  • Best Practice Sloth

The seventh Deadly Project Sin – Best Practice Sloth can increase risk on the project beyond all of our expectations.

From the Wiktionary at

Sloth is defined as:

  1. (uncountable) Laziness; slow in the mindset. One of the seven deadly sins.
  2. (countable) A herbivorous, arboreal South American mammal of the families Megalonychidae and Bradypodidae, noted for its slowness and inactivity.

To oversimplify the definition, sloth is a laziness that occurs.

So what is “best practice sloth”?

Project Managers sometimes get lazy and don’t follow best practices for project management. I list this as one the “Seven Deadly Project Sins”. PMI lists “Project Management Risk” as one of the four main risk categories in the PMBOK Guide.

If a project manager is not dutiful and does not follow reasonable practices for project management, then he or she introduces risk to the project. This project risk can be created by sloth or laziness. This project risk can be created by inattention. This project risk can be created by ignorance. But this project risk can also be created by attempting to “streamline” the project management functions in order to get more done.

In my career I have had the opportunity to view many different customer companies and their views towards project management and project processes. If I had been paid additional monies for every time a customer told me that there was not time to do project management properly, I could probably have retired by now.

Let’s talk about some absolute bare-bones minimum project requirements. What do you need to accomplish the project?

  1. You need authority to start the project
  2. You need to know what you are going to do (scope of work)
  3. You need to know how long you have (schedule)
  4. You need to know how much you can spend (budget)
  5. You need some controls that you can use to measure the project
  6. You need to produce results
  7. You need to know when you are done (this is a project, after all)

So let’s talk about some ways that “best practice sloth” can creep into the project.

Let’s start at the very beginning. When you start your project, do you really have some sort of document that formally authorizes the project to start? Or is it more informal – the hallway conversation or the verbal advisement that you need to start the project? I know that many organizations do not respect the formal project charter. But if you don’t know what you are planning to do and what parameters surround the event, how do you know that you have done it.

Every project must have some form of formal, usually written authorization to begin. Every project manager should feel compromised if they don’t have a description of their authority level on the project. The project charter is your basic insurance policy that you need to have in order to perform the work associated with the project.

How about your scope of work? How many times have I heard a customer say “we don’t have time to write all of this down”? If you don’t document your intent – how do you know what to do? Is it better to guess, to have to ask daily, to constantly be open to whimsical change?

We have already discussed the problem of over-allocation of resources on the project. Many times the project schedule causes the over-allocation problem to exist. The point of proper project management practices is to define how much time is required for the project to be completed. Lack of proper processes often dooms the project to failure when an arbitrary and uninformed schedule constraint is dictated for the project.

And, just like the schedule constraint, what about the budget? I know that if almost every project manager were asked they would require more money, more resources and more schedule time for the project. Within reason the project manager has to work within the time and budget constraints allocated to the project. But, just like the schedule, the best way to create the project budget is to consider all of the resource needs required to do the project work, and to consider the schedule element so that a reasonable cost budget is determined. If the project manager fails to take this crucial step, the project may fail due to lack of budget.

Controls are an important part of the project. Controls will measure the project against the defined scope, schedule and budget parameters. Controls should protect the project from unnecessary changes. But if we do not have controls, the all of the parameters of the project are subject to frequent, unnecessary and many times whimsical changes.

Finally, we have to produce actual real quantifiable results from the project. Not have things “90% complete”. 90% of an item does not make a completed item. Try driving a car that is 90% complete. It might run, but the experience would probably not be pleasant.

The last thing that we need to look for is the opportunity to close the project. We need to have a specified, documented description of what constitutes completion so that when we get to that point we can perform an orderly process of ending the project. After all, that’s what we are here to do – to finish with an acceptable result.

There are tens, upon hundreds, upon thousands of different ways that a best practice can be missed on a project and an unacceptable result can occur. It is the job of the project manager to make sure that best practices are followed to mitigate the probability that the project results will be unacceptable. Laziness, expediency, poor enterprise practices and other reasons are not good enough reasons for the project and project manager to fail. Let’s hope that reasons for failure can be confined to unusual circumstances, not circumstances created by ignoring best practices for project management.

This is the last of this series of project management tips, so I will climb down off of my “soapbox” for a while. In this series I focused on the “Seven Deadly Project Sins”. But I am absolutely, positive that there are more than seven.

I would encourage each of you to look around and define what some of the other “sins” are that continue to compromise projects. Take some time to write your own tips or send me an e-mail to share yours.

Thanks for your attention and consideration.

This article was first published as a series of articles from August 2007 through February 2008 entitled “The Seven Deadly Sins of Project Management”. This series of articles were published as “Project Management Tips” on PM World Today and is reprinted here with permission from the author.

The author, Tim Bergmann, is Chief Learning Officer for True Solutions Inc. in Dallas, Texas. Mr. Bergmann is a highly qualified project manager with three decades of experience managing a wide variety of information technology projects. Mr. Bergmann’s experience includes project management, operations management, infrastructure planning and implementation, business continuity planning, customer service and business development.

In 2006 he co-authored the best selling “CISA Study Guide” marketed by Sybex. Mr. Bergmann’s credentials include Project Management Institute’s Project Management Professional (PMP) and Disaster Recovery Institute’s Associate Business Continuity Professional (ABCP).

Mr. Bergmann has seen a progressive management career with several Dallas-based companies such as Compass Computer Service, Zale Corporation, Chief Auto Parts and B. R. Blackmarr/BrightStar Technology Group. His most recent engagement prior to joining TSI was as Director of Education for another D-FW based training company where he developed multiple course content and delivered project management and business continuity training.
As a consultant, he has worked with several Fortune 100 companies in a project management role. Mr. Bergmann has performed premier projects for the world’s largest auto manufacturer, a leading global insurance and investment provider, a regional power generation company, the world’s largest specialty jewelry retailer and a Dallas based transaction network and financial services provider.

He can be reached at

Recommended PM App

Recommended PM App