A Schedule More Complicated Than a Rube Goldberg

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.

Don't make your schedule as complicated as a rube goldberg machine

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

The Goldilocks & the 3 bears of project management

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

Creating Unnecessary Bureaucracy

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

Free Process Group and Knowledge Area Study Material

page43

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 atthe 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

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.

Great Video on a Secret of Passing the PMP Exam

If you're studying for your PMP®, I think you must watch this video.  This guy, Jeff Minder (PMP) of Victory Vets, gets it. As a disclaimer, I am in no way profiting or promoting his service.  I just think he did an awesome job with this video.  While I've been working on HueCubed, I've realized the importance of memorizing page 43 of the PMBoK.  I don't think you can memorize the entire PMBoK and expect to pass the PMP Exam.  To be honest, I would hope you wouldn't.  The exam is a series of scenario based questions.  You are not going to be asked to define a project.  Rather, a lengthy statement will be made and you'll probably be asked if it is a project, operations work, both, or neither. But back to the video and memorizing page 43.

My analogy of memorizing page 43 is like a child memorizing his or her ABCs.  When they memorize their ABCs, they can then identify which letters are vowels and which are consonants.  They can then build words to put into sentences.  Sentences go into paragraphs...and so on and so on.  Memorizing the ABCs will not make kids literary geniuses.  Rather, they use the ABCs as building blocks for future learning.

When you're looking at page 43 of the PMBoK, you'll see Process Groups, Knowledge Areas, and processes.  You need to memorize these core processes and understand where they fit into the big picture of a project.  In this video, Jeff explains the proper way to read page 43.  Yes, there is correct way to read that page.

From my perspective, the other note to make about this video happens at 6:17.  The PMBoK and testing are written toward a projectized organizational perspective, in comparison to functional, matrixed, or composite.  Remember that!

How Do You Know Your Metrics Are Worth It

GQM Paradigm

So you want to create some metrics.  More importantly, someone has told you that you need to create some metrics.  How do you know if you're just making work for yourself or if you're just putting a spin on the same old data?

Ask yourself what the goals of your project are.

In trying to determine what to measure in order to achieve those goals, I recommend using a Goal-Question-Metric (GQM) paradigm. It can actually be applied to all life-cycle products, processes, and resources. I've been using this process for a few years and it really helps me creat a quality metric.  The GQM paradigm is based on the theory that all measurement should be [1]goal-oriented i.e., there has to be some rationale and need for collecting measurements, rather than collecting for the sake of collecting. Each metric collected is stated in terms of the major goals of the project or program. [2]Questions are then derived from the goals and help to refine, articulate, and determine if the goals can be achieved. [3]The metrics or measurements that are collected are then used to answer the questions in a quantifiable manner.

Here is an example of the GQM in action:

Goal (use this 4-step process to shape a goal)

[1] Purpose [2] Issue [3] Object (process) [4] Viewpoint

Goal 1

[1] Purpose [2] Issue [3] Object (process) [4] Viewpoint

Maintain a maximum level of customer satisfaction from the Help Desk user’s viewpoint

Question 1

What is the current help desk ticket trend?

Metrics 1 Metrics 2 Metrics 3 Metrics 4

Number of help desk tickets closed Number of new help desk tickets % tickets outside of the upper limit

Subjective rating of customer satisfaction

Metrics 5

Number of new help desk tickets open

Question 2

Is the help desk satisfaction improving or diminishing?

Metrics 6 Metrics 7 Metrics 8 Metrics 9

Number of help desk calls abandoned Number of help desk calls answered Number of help desk calls sent to voicemail

Subjective rating of customer satisfaction

As the great Lord Kelvin once said, "If you can not measure it, you can not improve it."

Image based on Basili, Caldiera, and Rombach "The Goal Question Metric Approach", 1990

Seeing Value From The Customer Perspective

I recently sat in a meeting between a vendor and client, where the client was attempting to communicate their need to route new work deliverables to an existing Change Control Board (CCB). The contractor came back and said they believed the CCB in this case would not provide value and perhaps it should be bypassed.

Note to all vendors: Just because a process does not appear valuable to you, it does not mean the process does not provide value. The use of the CCB provides a (formal) control point helping to prevent unauthorized work and cost overruns. This goes further then just having a client billed for unauthorized work. Any work done without prior authorization has a risk of negatively impacting project schedule, cost, or quality. The mere act of doing unauthorized work impacts the scope.

I don't care if you're using Agile, Waterfall, or other methods to deliver value.  What is important is you understand your process and what mechanisms provide the greatest value to the customer.

If you think you need to deviate from a documented or understood process, rewrite your process to account for the deviations. If you are unwilling to change your documented process, the deviation is unworthy of being done.

I created the Visio diagram (above) a few months back to help both the customer and vendor visualize what we were trying to accomplish.  The challenge was implementing Scrum in a very formal and controlled environment.

I certainly recognize many don't have such a formal process.  Instead of CCBs, you may call them Product Backlog Review Meetings.  Counter to this, you may have a very fluid and simple software development life cycle (SDLC).  If so, you still need to understand your process and you still need to communicate with your customer.  Understand what their highest priorities are and deliver.