Last week I found myself in business development mode, as I often am, in explaining to a prospective client our future plans in terms of software development. The point that I was making was that it was not our goal to simply reproduce the functionality that every other software solution provider offered, but to improve how the industry does business by making the drive for change through the application of appropriate technology so compelling through efficiencies, elimination of redundancy, and improved productivity, that not making the change would be deemed foolish. In sum, we are out to take a process and improve on it through the application of disruptive technology. I highlighted my point by stating: “It is not our goal to simply reproduce functionality so we can party like it’s 1998, it’s been eight software generations since that time and technology has provided us smarter and better ways of doing things.”
I received the usual laughter and acknowledgement by some of the individuals to whom I was making this point, but one individual rejoined: “well, I don’t mind doing things like we did it in 1998,” or words to that effect. I acknowledged the comment, but then reiterated that our goal was somewhat more proactive. We ended the conversation in a friendly manner and I was invited to come back and show our new solution upon release to market.
Still, the rejoinder of being satisfied with things the way they are has stuck with me. No doubt that being a nerd (and years as a U.S. Navy officer) have inculcated a drive in me for constant process improvement. My default position going into a discussion is that the individuals that I am addressing share that attitude with me. But that is not always the case.
The kneejerk position of other geeks is often of derision when confronted by resistance to change. But not every critic or skeptic is a Luddite, and it is important to understand the basis for both criticism and skepticism. For many of our colleagues in the project management world, software technology is a software application, something that “looks into the rear glass window.” This meme is pervasive out there, but it is wrong. Understanding why it is wrong is important in addressing the concerns behind them in an appropriate manner.
This view is wrong because the first generations of software that serve this market simply replicated the line and staff, specialization, and business process and analysis regime that existed prior to digitization. Integration of data that could provide greater insight was not possible at a level of detail needed to establish confidence. The datasets upon which we derived our data were not flexible, nor did they allow for widespread distribution of more advanced corporate and institutional knowledge. In fact, the first software generation in project management often supported and sustained the subject matter expert (SME) framework, in which only a few individuals possessed advanced knowledge of methods and analytics, upon which the organization had to rely.
We still see this structure in place in much of industry and government–and it is self-sustaining, since it involves not only individuals within the organization that possess this attribute, but also a plethora of support contractors and consultants who have built their businesses to support it.
Additional resistance comes from individuals who have dealt with new entries in the past, which turned out only to be incremental or marginal improvements for what is already in place, not to mention the few bad actors that come along. Established firms in the market take this approach in order to defend market share and like the SME structure, it is self-sustaining by attempting to establish a barrier to new entrants into the market. At the same time they establish an environment of stability and security from which buyers are hesitant to leave, thus the prospective customer is content to “party like it’s 1998.”
Value proposition alone will not change the mind of those who are content. You sell what a prospective customer needs, not usually solely what they want. For those introducing disruptive innovation, the key is to be at the forefront in shifting the basis for what defines the basis of market need.
For example, in business and project systems, the focus has always been on “tools.” Given the engineering domain that is dominant in many project management organizations, such terminology provides a comfortable and familiar way of addressing technology. Getting the “right set of tools” and “using the right tool for the work” are the implicit assumptions in using such simplistic metaphors. This has caused many companies and organizations to issue laundry lists of features and functionality in order to compare solutions when doing market surveys. Such lists are self-limiting, supporting the self-reinforcing systems mentioned above. Businesses who rely on this approach to the technology market are not open to leveraging the latest capabilities in improving their systems. The metaphor of the “tool” is an out of date one.
The shift, which is accelerating in the commercial world, is emphasis on software technology that is focused on the capabilities inherent in the effective use of data. In today’s world data is king, and the core issue is who owns the data. I have referred to some of the new metaphors in data in my last post and, no doubt, new ones will arise. What is important to know about the shift to an emphasis on data and its use is that it is driving organizational change that not only breaks down the “tool”-based approach to the market, but also undermines the software market emphasis on tool functionality, and on the organizational structure and support market built on the SME.
There is always fear surrounding such rapid change, and I will not argue against the fact that some of it needs to be addressed. For example, the rapid displacement through digitization of previously human-centered manual work that previously required expertise and which paid well, will soon become one of the most important challenges of our time. I am optimistic that the role of the SME simply needs to follow the shift, but I have no doubt that the shift will require fewer SMEs. This highlights, however, that the underlying economics of the shift will make it both compelling and necessary.
Very soon, it will be impossible to “party like it’s 1998” and still be in business.
Life, Project Management, and Everything 