Blog

There is an assumption in the world of software and systems engineering that by gaining a detailed understanding of a system’s constituent parts we can fully understand the system as a whole. In other words, by breaking down a desired solution into discrete bite-size snippets, we can see how everything fits together and thus we will clearly understand how the overall solution will operate.  However, this approach seldom works in practice for our industry. Why?

I have struggled with this disconnect between a highly valued scientific methodology (think Use Cases) and the reality observed through years of dealing with our corporate real estate clients and their internal IT organizations. We know, for example, if the business takes the time to fully understand and document how they work (business process engineering) before diving into the details of a functional specification, there is a very high success rate with the ultimate underlying technology deployment. Then I read an intriguing exposé in the January 2012 issue of WIRED Magazine entitled “Trials and Errors: Why Science is Failing Us.” What this article pointed out about medical science in general, and pharmaceutical companies more specifically, is a narrow-minded reliance on cause and effect known as reductionism. This is exactly the disconnect I had seen played out over and over when real estate problems were reduced to functional silos by well-intended, but horribly mistaken technology experts.

Take for example: A business process is documented, business rules and operating procedures are defined, and the areas where the process can be automated are identified. The users of a future solution have defined how they need to work as a logical flow of activities and tasks. Then the software implementation team takes each discrete task and one-by-one develops steps and business rules that support that discrete activity. Within this myopic assessment, the nuances of the business’ true needs are lost. Thus we see:

1. Software’s out-of-the-box (OOTB) functionality being deemed “good enough” based on a cost benefit or risk benefit assessment that at this level of oversimplification rarely takes into account the upstream and downstream impact of the decisions being made.
2. Misinterpretation of the process documentation leading to an erroneous assumption that it is so unique that it cannot be accomplished with OOTB functionality, which leads to highly custom functional requirements that far too often lead to an overly cumbersome and intrusive technology deployment. 

In other words, the solution is broken down into discrete units that can be easily translated into rules and thus optimized or customized to the point of uselessness.

Thus, I have come to terms with my lack of understanding of this disconnect. The reality is that though not rocket science, the work and methods deployed by CRE and FM professionals are complex in their associations and interactions. Defining systems to support functions such as these is more difficult that defining systems driven by clearly defined rules and regulations. This is why we will continue to see successful technology deployments when the technology is subjugated to the business need, and why we see these same systems fail when they are not.