Why that grumpy attitude?
I don’t know if you have asked yourself that question before as in my heading, but I have from time to time. Right now, I am trailing down the path of Requirements and Information quality and I start to truly understand the concepts of Knowledge Engineering through the work I´m doing with my colleagues at the Reuse Company in Spain.
But I can again get that familiar feeling of frustration. You know this is good for you, you know it would help, but you won’t do anything about it?
Organizational resistance to CHANGE
I have led a couple of change journeys through my career and they have certainly been interesting and challenging. Above all, they have behaved differently when I look at them. The “easy” task of a new tool implementation became a nightmare and the “hard” task of reorganizing and change old work practices were dead easy. I have learnt that it’s hard to predict human behavior and impossible to predict an organizational behavior when it comes to how new ideas are accepted and the need for change is perceived and embraced.
Luckily (or stupidly) I am quite hardheaded and I just won’t give up. “I know I´m right and I will show you all that I am!”.
Some theory behind CHANGE
Have your heard about the change formula? It was developed by a guy called Gleicher in the 70th and has been frequently used since to measure change resistance in an organization. I mean how an organization perceives and react to change. The model has been developed throughout the years and I´m currently using the one by Dannemiller, et.al:
D = Dissatisfaction with how things are now;
V = Vision of what is possible;
F = First, concrete steps that can be taken towards the vision.
If the product of these three factors is greater than R = Resistance, things will start to happen.
So, this model says that if an organization is angry or dissatisfied enough, gets a clear vision of the brighter future (for them personally I might add) and have trust in their leaders who believe in the new idea and points out the next new step, the organization will probably start to move towards the vision.
The truth (from the viewpoint where I´m sitting anyway)
Right now, when I´m busy saving the engineering world with some cool stuff that will help engineers and organizations to improve their information quality in both their requirements and engineering models I feel that familiar notion of suspicion and doubtfulness from the people I meet and that’s fine. I can talk about the increased efficiency and effectiveness, the increase throughput, the lowered engineering effort, the decreased time to market, the lowered technical risk, and the better product quality received, for hours and hours to really clever people.
They all usually nod their heads and become really impressed about what I´m showing and then, when I start to zoom in on the way forward moment, they get that distant shimmer in their eyes and start to mumble about how much they have to do, how their resources are constrained, there need to cut cost and they often end up using the phrase; “This was really interesting. We will have this in mind for the future…”. The wait-and-see moment has arrived and I know that they just closed the door to the opportunity they’d witnessed.
My good! It’s like me coming to a chef in his kitchen, showing that it’s better to whisk the eggs with an electric mixer than the fork he uses just right now. His response is to nod his head, and say; “Yes, that’s really going to help me, but I am too busy right now. Come back when I´m done”.
So, what’s the problem then? When it comes to writing requirements basically all organizations know that they are no good, or at least not so great. If we then add the task to make sure that requirements in natural language (on the problem side) and UML/SYSML models (on the solution side) tell the same story (over time) in a project, we all know they don´t succeed at all, am I not right?!
But (here comes the punchline), they are often TO BUSY to want to look at new solutions that would do magic for them. They are stuck in a feeling of having too much to do and the notion of someone breathing down their necks shouting, “faster, better, cheaper”!
All successful organizations probably manage this “whirlwind of busyness” quite effectively. They have created and adjusted their whole organization around it. They have created efficient workarounds and late fixes to overcome the real problems and the root cause to them. They streamline their processes for engineering change management, they implement continuous integration practices, they implement automatic SW builds and testing, they become experts on risk management and builds effective project organizations to keep the speed up.
They are not seeing the problems any more, they are now basically cumbersome facts of life and they continue to steer that big ship with great(er) speed toward that huge ice berg called “the future”!
We should not forget that these organizations probably also have great “engineering heroes” that saves the day in the most doomed engineering efforts. These people are the ones getting the official gratitude of success, the financial compensation to do so and the glory, so why should they change a winning concept? Everybody is happy, right? But they probably don’t realize that they at the same time destroy more than they fix for the organization as a hole.
So, even if the dissatisfaction is high in the organization (HR sees it every year in the company staff survey) and I can show them those basic steps that needs to be taken, the vision becomes an unreachable nirvana and nothing happens because of the itching “feeling of being to busy”. But imagine the result by using an electric mixer instead of that fork to those eggs?! My good, when that potential is finally released!
The end of all work practice innovation?
Luckily for me there are not only “just clever people” out there, there are also people (leaders) that can embrace the vision, understand the potential and start that journey (even if they too are very busy). Requirements Engineering and perhaps Systems Engineering practices are dying (hard words) as we know them today. Soon it will be all about Knowledge Engineering, mark my words for it!
Basically, it’s because speed in technological innovation and both system- and business complexity increases exponentially and we need new and more flexible ways of managing complex system-of-systems engineering in the future with these AI, cloud-based and distributed systems and organizations.
Organizations (and people) that don´t value its intangible knowledge as their most valuable asset and embrace the need for constant change will disappear quietly in the fog of the past. The future lays ahead those organization what triumph WITHOUT those engineering heroes and who manages their knowledge assets to create, maintain and develops them over time. The right information, to the right person at the right time, that’s the foundation for happy, efficient and innovative originations.
My question is really: “Will you and your organization walk in the shadows or come out and play in the sun”?
That’s all for this time. If you want to know more about knowledge engineering, information quality or just want to chat (or debate), contact me at firstname.lastname@example.org or visit:
Next time I will look more into the concept of MBSE (I hope to get some cool guys experts comments) and I´m thinking about starting some shorter requirements quality lessons. That’s quality in requirements development, really? How SMART are we?