Earlier in the week Dave Gordon at his blog responded to my post on data normalization and rightly introduced the need for data rationalization. I had omitted the last concept in my own post, but strongly implied that the two were closely aligned in my broad definition of normalization beyond the boundaries of eliminating redundancies. In the end in thinking about this, I prefer Dave’s dichotomy because it more clearly defines what we are doing.
Later in the week I found myself elaborating on these issues in discussions with customers and other professionals in the project management discipline. In the projects in which I am involved, what I have found is that the process of normalizing and rationalizing data, even historical data which, contrary to Dave’s assertion can be maintained–at least in my business–acts as a change agent in defining the agnostic characteristics what defines the type of data being normalized and rationalized.
What I mean here is that, for instance, a time-phased CPM schedule that eventually becomes an integrated master schedule has an analogue. For years we have been told, mostly by marketing types working for software manufacturers, that there is a secret sauce that they provide that cannot be reconciled against their competitors. As a result, entire professional organizations, conferences, white papers, and presentations have been given to prove this assertion. When looking at the data, however, the assertion is invalid.
The key differentiator between CPM scheduling applications is the optimization engine. That is the secret sauce and the black box where the valuable IP lies. It is the algorithms in the optimization that identifies for us those schedule activities that are on the critical and near critical paths. But when you run these engines side by side on the same schedule, their results are well within one standard deviation of one another.
Keep in mind that I’m talking about differences in data related to normalization and rationalization and whether these differences can be reconciled. There are other differences in features between the applications that do make a difference in their use and functionality: whether they can lock down a baseline, manage multiple baselines, prevent future work from being planned and executed in the past (yes, this happens), handle hammocks, scale properly, etc. Because of these functional differences the same data may have been given a different value in the table or the file. As Dave Gordon rightly points out, reconciling what on the surface are irreconcilable values requires specialized knowledge. Well, if you have that specialized knowledge then you can achieve what otherwise seems impossible. Once you achieve this “impossible” feat, it quickly becomes apparent that the features and functions involved are based on a very limited number of values that are common across CPM scheduling applications.
This should not be surprising for those of you out there that have been doing this a long time. Back in the 1980s we would use visual display boards to map out short segments of the schedule. We would manually construct schedules in very rudimentary (by today’s standards) mainframe computers and get very long dot matrix representations of the schedule to tape to the “War Room” walls. The resources, risks, etc. had to be drawn on the schedule. This manual process required an understanding of CPM schedule construction similar to someone still using long division today. There was actually a time when people had to memorize their log and square root tables. it was not very efficient, but the deep understanding of the analogue schedule has since been lost with the introduction of new technology. This came to mind when I saw on LinkedIn a question of the types of questions that should be asked of a master scheduler in an interview.
As a result of new technology, schedulers aligned themselves into camps based on the application they selected or was selected for them in their job. Over time I have seen brand loyalty turn into partisanship. Once again, this should not be surprising. If you spent ten years of your career on a very popular scheduling application, anything that may undermine one’s investment in that choice–and which makes employment possible–will be deemed as a threat.
I first came upon this behavior years ago when I was serving as CIO for a project management organization. Some PMOs could not share information–not even e-mail and documents–because most were using PCs and some were using Macs. Problem was that the key PMO was using Mac. This was before Microsoft and Apple got together and solved this for us. Needless to say this undermined organizational effectiveness. My attempt to get everyone on the same page in terms of operating system compatibility sparked a significant backlash. Luckily for me Microsoft soon introduced its first solution to address this issue. So, in the end, the “Macintites”, as we good naturedly called them, could use their Macs for business common to other parts of the organization.
This almost cultish behavior finds itself in new places today: in the iPhone and Droid wars, in the use of Agile, and among CPM scheduling application partisans. It is true that those of us in the software industry certainly want to see brand loyalty. It is one of the key measures of success in proving the product’s value and effectiveness. But it need not undermine the fact that a scheduler is a key specialist in the project management discipline. If you are a Jet, you don’t need to be a Jet all the way.
Since creating generic analogues of schedules from submitted third-party data, I have found that insights into project performance can be noted that previously were not available. The power of digitization along with normalization and rationalization allows the data to be effectively integrated at the proper point of intersection with other dimensions of project performance such as cost performance and risk. Freed from the shackles of having to learn the specific idiosyncrasies of particular applications, the deep understanding of scheduling is being reintroduced. This is a long time in coming.