ICPM

Teach and Institute Leadership

It is the age-old distinction that usually merits much lip service and little true implementation. There is supervision/management, and then there is leadership. Project managers can either be supervisors or leaders, regardless of their job title.

Continuous Improvement

This is one of my favorite points from Dr. Deming. I see so many mistakes that are made again and again, and lessons learned that are either completely undocumented or filed away after a project, never to be seen again.

Do all of the other project managers in the firm get exposure to lessons learned from other projects? Usually not, in my experience. Surely, individual project managers and sponsors learn from their projects, but organizational learning and continuous improvement require a formal process for the documentation, analysis, and incorporation of lessons learned into a common methodology.

Consider Costs and Benefits of the Entire System and Deliverable Lifetime

The textbook wording of this point varies, but is usually something like “Stop making decisions purely on the basis of cost.” When I read the various descriptions however, I believe the textbook title is not an adequate summary.

When Deming talks about not making decisions purely on the basis of cost, he is referring to a plant perspective and talks about the importance of having regular suppliers.

Inspection is a Tool for Improvement, Not a Whip

Deming's third point urges practitioners to design quality into processes, using inspection as an information-gathering tool to do so. In project management, the processes and systems make up a methodology. Does your organization have a consistent methodology, or does everyone run projects their own way?

Inspecting project performance through the lens of continuous improvement facilitates applying lessons learned to a consistent and ever-improving methodology. This can not be done effectively unless there is a consistent system of managing projects in the first place.

When I was working with a system support group we had to scramble each month to determine the Return on Investment (ROI) for the system enhancements.  Changes ranged from new reports to added functionality with other odd things in between.  Needless to say, determining the ROI for adding a product color field to a report lacks a certain excitement and requires a lot of creativity.  Technically it is the responsibility of the business group to assign ROI, but it generally falls on the technical team to make it happen. 

Dr. W. Edwards Deming was recently re-introduced to me in my Project Performance and Quality Assurance class. I have heard of him before and touched on some of his philosophy in other classes, but focused much more in-depth this time. The majority of his philosophy around quality and organizational management resonates with me. So, I've decided to do a series of articles on Deming's 14 points, and how they relate specifically to the field of project management.

Here are Deming's 14 points, paraphrased in my words:

During World War II, the Allied forces occupied many of the Pacific islands.  Up until that point, the inhabitants of these islands had never seen manufactured goods.  With the military occupation, goods such as sunglasses, chocolate and coca-cola literally fell from the sky.  To islanders unfamiliar with manufacturing or powered flight this bounty was a delivery from the gods. 

I have a friend who used to work for the Internal Revenue Service (IRS) as a tax collector for the United States.  When he performed an audit he expected you to be honest and work with him to determine what was owed.  He had the authority to make your life miserable if you chose to mess around.  After trying unsuccessfully on one case to work through issues with an individual he showed up at the company before 6:00 AM with padlocks and chains to impound all of the vehicles.  In concert with this move he froze all financial assets as soon as the bank opened. 

Every software professional that has been part of more than one project knows for sure:no two projects are the same. Different circumstances make most software projects unique in several aspects. And with different situations come different approaches to handle project life effectively: there are mutliple ways to “do” a project. Different circumstances require different approaches.

I'm a Theory of Constraints (TOC) enthusiast. So what exactly is TOC? Here's a short, short summary. In short, it's a method of identifying and strengthening the weakest link (constraint) in any process, in an iterative approach to ongoing improvement. There are also tools that go along with it to help identify assumptions and constraints, etc. TOC was developed by Eli Goldratt. The Avraham Y. Goldratt Institute is the organization that maintains the TOC body of knowledge.