organizational process improvement

Driver’s Seat — How Software Normalization Can Drive Process Improvement

Travel, business, and family obligations have interrupted regular blogging–many apologies but thanks for hanging in there and continuing to read the existing posts.

Over the past couple of weeks I have taken note of two issues that regularly pop up: the lack of consistency in how compliance is applied by oversight organizations within both industry and within government, especially in cases of government agencies with oversight responsibility in project management; and the lack of consistency in data and information that informs project management systems.

That the same condition exists in both areas is not, I believe, a coincidence, and points to a great deal of hair-pulling, scapegoating, and finger-pointing that would otherwise have been avoided over the years.  I am not saying that continual process improvement without technology is not essential, but it is undoubtedly true that there is a limit to how effectively information can be processed and consumed in a pre-digitized system compared to post-digitized systems.  The difference is in multiples, not only in the amount of data, but also in the quality of the data after processing.

Thus, an insight that I have observed as we apply new generations of software technology to displace the first and second wave of project management technologies is an improved ability to apply consistency and standardization in oversight.  Depending on where you stand this is either a good or bad thing.  If you are a traditional labor-intensive accounting organization where you expect a team of personnel to disrupt the organization in going through details of a paper trail, then you are probably unhappy because your business model will soon be found to be obsolete (actually it already is depending on where your customer sits on a scale of digitization).  If you are interested, however, in optimization of systems then you are probably somewhere to the positive on the scale.

Software companies are mainly interested in keeping their customers tied to their technology.  For example, try buying the latest iPhone if you have an existing plan with a carrier but want to switch to someone else.  This is why I am often puzzled by how anyone in the economics or political science professions cannot understand why we have new technological robber barons with the resulting concentration in wealth and political power.  One need only look at how the railroads and utilities tied entire swaths of the country into knots well into the 20th century prior to anti-trust enforcement.  The technology is new but the business model is the same.

The condition of establishing technological islands of code and software is what creates diseconomies in processes.  The costs associated with multiple applications to address different business processes increases costs and reduces efficiency not only because of proprietary idiosyncrasies which create duplicative training, maintenance, and support requirements, but also because of the costs associated with reconciliation and integration of interrelated data, usually accomplished manually.  On the systems validation and oversight side, this lack of consistency in data drives inconsistency in the way in which the effectiveness of project management systems are assessed.

Years of effort, training, policy writing, and systems adjustments have met with the law of diminishing returns while ignoring the underlying and systemic cause of inconsistency in interdependent factors.  Yet, when presented with a system in which otherwise proprietary and easily reconcilable data is normalized to not only ensure consistency but quality, the variations in how the data is assessed and viewed diminishes very quickly.  This should be no surprise but, despite the obvious advantages and economies being realized, resistance still exists, largely based in fear.

The fear is misplaced only because it lies in the normal push and pull of management/employee and customer/contractor relations.  Given more information and more qualitatively insightful information, the argument goes, the more that oversight will become disruptive.  That this condition exists today because of sub-optimization and lack of consistency does not seem to occur to the proponents of this argument.  Both sides, like two wrestlers having locked each other in a stronghold that cannot result in a decision, is each loathe to ease their own grip in fear that the other will take advantage of the situation.  Yet, technology will be the determining factor as the economic pressures become too hard to resist.  It is time to address these fears and reestablish the lines of demarcation in our systems based on good leadership and management practices–skills that seem to be disappearing as more people and companies become focused on 1s and 0s.

Note: The post has been modified to correct grammatical errors.  Travel took its toll on the first go-round.

Ch-ch Changes — Software Implementations and Organizational Process Improvement

Dave Gordon at The Practicing IT Project Manager lists a number of factors that define IT project success.  Among these is “Organizational change management efforts were sufficient to meet adoption goals.”  This is an issue that I am grappling with now on many fronts.

The initial question that comes to mind is which comes first–the need for organizational improvement or the transformation that comes results as a result of the introduction of new technology?  “Why does this matter?” one may ask.  The answer is that it defines how things are perceived by those that are being affected (or victimized) by the new technology.  This will then translate into various behaviors.  (Note that I did not say that “Perception is reality.”  For the reason why please consult the Devil’s Phraseology.)

This is important because the groundwork laid (or not laid) for the change that is to come will then translate into sub-factors (accepting Dave’s taxonomy of factors for success) that will have a large impact on the project, and whether it is defined as a success.  In getting something done the most overriding priority is not just “Gettin’ ‘Er Done.”  The manner in which our projects, particularly in IT, are executed and the technology introduced and implemented will determine the success of a number of major factors that contribute to overall project success.

Much has been written lately about “disruptive” change, and that can be a useful analogy when applied to new technologies that transform a market by providing something that is cheaper, better, and faster (with more functionality) than the market norm.  I am driving that type of change in my own target markets.  But that is in a competitive environment.  Judgement–and good judgement–requires that we not inflict this cultural approach on the customer.

The key, I think, is bringing back a concept and approach that seems to have been lost in the shuffle: systems analysis and engineering that works hand-in-hand with the deployment of the technological improvement.  There was a reason for asking for the technology in the first place, whether it be improved communications, improved productivity, or qualitative factors.  Going in willy-nilly with a new technology that provides unexpected benefits–even if those benefits are both useful and will improve the work process–can often be greeted with fear, sabotage, and obstruction.

When those of us who work with digital systems encounter someone challenged by the new introduction of technology or fear that “robots are taking our jobs,” our reaction is often an eye-roll, treating these individuals as modern Luddites.  But that is a dangerous stereotype.  Our industry is rife with stories of individuals who fall into this category.  Many of them are our most experienced middle managers and specialists who predate the technology being introduced.  How long does it take to develop the expertise to fill these positions?  What is the cost to the organization if their corporate knowledge and expertise is lost?  Given that they have probably experienced multiple reorganizations and technology improvements, their skepticism is probably warranted.

I am not speaking of the exception–the individual who would be opposed to any change.  Dave gives a head nod to the CHAOS report, but we also know that we come upon these reactions often enough to be documented from a variety of sources.  So how to we handle these?

There are two approaches.  One is to rely upon the resources and management of the acquiring organization to properly prepare the organization for the change to come, and to handle the job of determining the expected end state of the processes, and the personnel implications that are anticipated.  Another is for the technology provider to offer this service.

From my own direct experience, what I see is a lack of systems analysis expertise that is designed to work hand-in-hand with the technology being introduced.  For example, systems analysis is a skill that is all but gone in government agencies and large companies, which rely more and more on outsourcing for IT support.  Oftentimes the IT services consultant has its own agenda, which oftentimes conflicts with the goals of both the manager acquiring the technology and the technology provider.  Few outsourced IT services contracts anticipate that the consultant must act as an enthusiastic–as opposed to tepid (at best) willing–partner in these efforts.  Some agencies lately have tasked the outsourced IT consultant to act as honest broker to choose the technology, mindless of the strategic partnering and informal relationships that will result in a conflict of interest.

Thus, technology providers must be mindful of their target markets and design solutions to meet the typical process improvement requirements of the industry.  In order to do this the individuals involved must have a unique set of skills that combines a knowledge of the goals of the market actors, their processes, and how the technology will improve those processes.  Given this expertise, technology providers must then prepare the organizational environment to set expectations and to advance the vision of the end state–and to ensure that the customer accepts that end state.  It is then up to the customer’s management, once the terms of expectations and end-state have been agreed, to effectively communicate them to those personnel affected, and to do so in a way to eliminate fear and to generate enthusiasm that will ensure that the change is embraced and not resisted.