Occam’s razor (or Ockham’s razor) is the principle that “entities must not be multiplied beyond necessity”. The popular interpretation of this principle is that the simplest explanation is usually the correct one.

It has inspired numerous expressions including “parsimony of postulates”, the “principle of simplicity”, the “KISS principle” (Keep It Simple, Stupid).

Though most of Occam’s principles are enrooted in philosophy, many approaches (especially the principle of simplicity) can be found in the basics of design principles.

Given a choice between functionally equivalent designs, the simplest design should be selected. Implicit in Ockham’s razor is the idea that unnecessary elements decrease a design’s efficiency, and increase the probability of unanticipated consequences. [¹]

When comparing technologies that perform the same function, a technology that is simpler in design will tend to be simpler to construct and repair, but will tend to require greater skill to use, whereas a technology that requires less skill to use will tend to be more complex in design and more complex to construct and repair. For example, a straight razor is relatively simple in design and construction, but requires considerable skill to use, whereas an electric razor is relatively complex in design and construction but requires little skill to use. [²]

---

Now, go back and reread the two referenced passages, substituting design and technology with project management approach.  I particularly like the straight razor analogy, mostly because I shave using a straight razor.  I only had to cut myself once (badly) before I realized I needed real skills to use such a simple tool.

So, what’s my transition?  Just because you may know a lot about project management, doesn’t mean you need to make things complicated.  At the end of the day, very few customers care how it got done.  They just care that the product or service was delivered on time and within budget.  If you’re looking to add project management control points, look for what will lower risk and increase value throughput.  The idea is to make your process as simple as possible, allowing things to get done.  Don’t add control points to a process for no other reason than to make work for everyone.  Don’t simplify too much either, resulting in the wild wild west.  I’m always looking for that happy medium.  So, go forth.  Study your craft and learn everything you can about project management.  Just be careful not to cut yourself.

[¹] http://www.visualgui.com

[²]  http://www.omick.net

Image source: suddenimpactmedia

I just reviewed an Integrated Master Schedule (IMS) comprised of almost 5000 lines.  I didn’t write the thing.  I was just asked to review it.  You might be saying to yourself that must be an absolutely awesome schedule, detailing every nuance of a project.  Counter to that, you might be saying to yourself that is the most overdeveloped schedule ever creating, complicating the most trivial of work.

In the business of project management or leadership, you should always be asking yourself, “does this make sense?”  If it doesn’t, you should be looking for the Goldilocks approach to documentation or process.  Do something that is not too complicated or simple.  Do something somewhere in the middle.

As I read through the IMS, I started to think of a Rube Goldberg machine and the OK Go video titled This Too Shall Pass.  Rather than reading a very straightforward schedule, identifying all of the deliverables and a decomposition ad nauseam, I saw a schedule that both inveigled and obfuscated.  A Rube Goldberg machine is the perfect analogy for this schedule.

A Rube Goldberg machine is irreducibly complex. It is a single system which is composed of several interacting parts, and where the removal of any one of the parts causes the system to break down. If one component is missing, the machine doesn’t work; the whole system is useless.  This is NOT how an IMS should be written.  I see a schedule as a tool of transparency.  It is a way to communicate if a project is on time in a passive manner.  A fully resource loaded (properly decomposed) schedule can help you do a lot of other things.  But 5000 lines?  I don’t think so, not in this case.

Image Source:  www.rubegoldberg.com

No, I’m not blond nor am I talking about bears.  I’m trying to get people to understand there has to be balance in project management.  Once again, one of my son’s bedtime stories makes a pretty good analogy.

As I’m reviewing all of the contract deliverables due from the vendor this month, I ask myself if it is really all that necessary.  I don’t think so.  What do I mean by contract deliverables?  I’m referring to anything from a high level design (HLD) to detail level design (DLD), an integrated schedule (IS) to a cost performance report (CPR).  That’s hundreds and hundreds of pages of documentation, every month, with the expectation the future will be predicted or the past explained.  Organization 1: Too much documentation and process – too little value.

This is actually quite the contrast from where I started as a project manager.

When I started out in project management, I worked for a very small organization that basically flew by the seat of its pants.  Nothing was documented.  If the customer didn’t like the change, we’d just redo the work.  There was a considerable amount of waste but we were able to actually delivered some product (value).  In hindsight, if we would have had more documentation and process, we would have had fewer budget and schedule overruns.  Organization 2: Too little documentation and process – too little value.

More recently, I worked for a medium sized organization that was maturing its business practices.  They realized they needed a minimum level of documentation to help lessen waste and manage stakeholder expectations.  The goal?  Have the right amout of documentation and process to deliver the greatest amount of value.  For the most part, there wasn’t too little or too much documentation or process and there wasn’t too little value as a result.  For the most part, Organization 3 was just right.

In all seriousness, ask yourself the question, “for the task I’m about to commit resources to, is there too little or too much documentation or process for the amount of value I can expect to deliver?”

image courtesy of fcps.org

I’ve rewritten this post several times now.  The catalyst for this toned-down rant was the company-wide distribution of a new dress code policy.  As background to this story, I was hired by a small business to support a Federal Government contract.  If you want bureaucracy, the Federal Government is certainly where you’ll find it.  Where I don’t expect to find it is with a small business.  I’ve worked for both large and small businesses.  The bigger they get, the more layers of bureaucracy there is.    It doesn’t have to be that way.  I think some small businesses think you have to add a lot of crap to processes, in the hope someone will think there is value.  Draconian policies do not translate to value!  As I read the new policy, I became more and more incensed.   I come  from a military background, so if someone has anything to say about my appearance, they should say it to my face.

This dress code policy was not necessarily directed to me.  That is where the problem rests.   When you feel the need to communicate TO and not communicate WITH your people, you have a problem. This situation could have been easily avoided by a superior and a subordinate having a conversation.   Instead, we get a vague policy that runs the gambit of  “no shaggy hair” to “hair color should be kept within the family of traditional hair colors”.

Give me a break.   This is a failure of both communication and of leadership.  It doesn’t matter if we’re talking corporate, project management, or communication processes.  Take a big step back and ask yourself if writing that process makes sense.  Action and communication is what will become culture.  Processes just become a pain in the ass that slow things down.

Image from kailash.balnac.com

5-9-42

This is the number combination I want you to remember.

5 Process Groups

9 Knowledge Areas

42 Processes

A colleague of mine just passed his PMP® exam.  What was one of his regrets?  He should have memorized page 43 of the PMBoK.  Why?  Page 43 is an excellent road-map.  Go to any process on page 43 and you’ll have a corresponding process group and knowledge area.

Want to Report Performance?  You’ll find it at the crossroad of  Communications Management and Monitoring & Controlling. By memorizing the items on this page, you will be able visualize where you are within a project lifecycle and answer a bunch of questions on the exam.

To make it easy on you, I created a simple piece of study material, based on page 43 of the PMBOK

• Page 1 has all of the process groups, knowledge areas, and processes
• Page 2 is missing Initiating processes
• Page 3 is missing Planning processes
• Page 4 is missing Executing processes
• Page 5 is missing Monitoring & Controlling processes
• Page 6 is missing Closing processes
• Page 7 is missing ALL of the processes

Click here to get a free PDF copy of this 7 page study worksheet.

With so many other things, memorizing isn’t going to do you any good if you can’t practically apply what you committed to memory.  I can’t say I have a use case from the real world, where memorizing page 43 would apply.  But, if you want a leg up on passing the PMP® exam, I think it’s a great start.