coneblog

We continue with our tour of my Project Management Toolbox. We have looked at the Project Hourglass, and the Scope Axe. There in the top tray I see my Phase Measuring Cups. They are bight shiny and smooth, from much wear. I have probably used them fifty times in my PM career.

These cups have helped me to much success. Applying them properly has been key to delivering many successful projects. Just as important, proper use of the cups in the proposal stage has been instrumental to selling many, many jobs.

If you have been following along this series, you have figured out my metaphor – a physical shop tool connected to an IT Project Manager’s technique. Some, like the Scope Axe, are a nice parallel. The measuring cups are a bit of a stretch, but lets explore the concept.

The concept is this: proper division of a large project into phases is a key factor in the success of the project. Why is this? There are many facets to this concept: Showing success early; Getting something concrete in front of users to support communication; Delivering something early to allow iteration; Addressing areas of greatest risk first; Developing organizational capability in the early stages of a project; Finding and Cleaning the Data before substantial analytics development is done; etc. etc.

A pretty good list, that. I have used all of these from time to time as rationale/guidance in dividing a project into phases. But none of these are the overriding rationale for the practice.

I was fortunate early in my career to stumble on an odd little book in a bookstore in Wilmington, DE. I was working as a contract programmer at the Very Large chemical company headquartered there. I was working in PL/I on MVS (that’s the Big Iron to you, kid). I had discovered pointer variables in PL/I and was doing things with n-dimentional linked lists that neither IBM ever intended of the budgeting app really called for.

I spent some lunchtimes at a local bookstore, and one day found an odd little book. I just went to find it on my bookshelf, but it wasn’t there, I must have lent it to someone. The book is called “Systemantics”. It is a tongue-in-cheek look at Systems an dSystems Follies, but containing some profound insights, along the lines of the classic “Mythical Man-Month”. In “Systemantics” I found a guiding principle for the organization of IT projects.

That principle is this: “A complex system that works almost invariably can be traced back to a simple system that works.” It has taken me quite a while to fully measure the implications of this principle.

One implication is: If you have a complex system to build (and want it to work), you better build a simple version of it first, and get that to work.

So what does this have to do with the measuring cups? I use this principle to break the project into phases. Here are some examples:

If the project has a complex technical architecture, like some of my mobile projects, with hand-held computers, communications layers, scanners, third party libraries, message queues, DBMS, et al, I use the “Confirm Technical Architecture” measuring cup to measure out a Phase in which all the technical components are assembled and shown to work together end-to-end.

If the project has complex, multi-source, obscure, or potentially dirty source data, I’ll use the “Data Identification and Cleansing” cup to set up a Phase to address data issues early in the project.

Or, there was the time I did a project with a recently-funded startup. They were in the process of inventing the business process as we were in the process of automating it. On that project, I wish that I had used the “Model the Business Process” cup to ensure that the business process was well-defined and stable before moving forward.

In each case, the measuring cups were used to create a phase in which the most complex and risky part of the project could be created in a simplified form, and be shown to be working. Then and only then are you ready to take on the whole project.