Supporting the “Winds of Change”
A company makes decisions to change direction generally to adjust to market demands and the global evolution in their key vertical markets.
The loss of market shares or the inability to capitalize on emerging opportunities drives the very difficult decision to make the move to a new paradigm.
Of the three primary areas affected by the paradigm shift, technology, new business processes and the financial impact, the greatest impact to the success of the shift is the impact on the company’s human resources: “The Human Element”.
Culture Change
Organizational Change Process
Change in one’s environment affects us as human beings.
All too often a company does not understand that as human beings the psychological effect of change plays a critical role in our ability to accept the changes that are coming.
Planning for Change from a Psychological Perspective
… Does NOT Constitute “Pop Psychology”
…… It Minimize the Adverse Effects of Change
All business transformations involve
people and people mostly react in predictable ways
Changes in one’s working environment can trigger the same grieving process that the loss of a family member or friend.
Hopefully the process of passing through the stages is less painful and more rapid than a family loss but the stages have been proven very similar.
It has been said:
“Grief is the process that allows us to let go of that which was and be ready for that which is to come.”
In order to be ready for that which is to come one must pass through the stages of grief.
1 – Denial – The Denial stage includes feelings of shock, numbness, and disbelief. When change first realized, some people have a hard time believing “this is really happening.”
2 – Anger – Anger can be expressed in a variety of ways. Anger at your co-workers, towards family members, at God for letting this happen at the worst time. The anger can even be expressed towards yourself for letting you be put in this situation.
3 – Bargaining – Taking actions that you believe will prevent or minimize the effect of the change will have on you personally. This can begin even before the change is formally introduced.
4 – Depression – A level of depression can set in if one feels helpless. If you feel that you have no choice but to accept the change then a natural reaction is some form of sadness that could reach the level of depression.
5 – Acceptance – The experience of “depression” is what leads to “acceptance”. Some people think that “acceptance” means we are “cured” or “all right” with the change. But this isn’t the case at all. Acceptance simply means we are ready to try the new changes and move on. This allows us to accommodate ourselves to this new way of doing things in a manageable fashion.
Understanding change can help us realize resistance is normal. This helps us understand the feelings we experience.
Concepts adapted from The Five Stages of Grief originally by Elizabeth Kubler-Ross and reproduced by Dr. Christina Hibbert
Business Domain Mapping
When a company engages in the preliminary stages of business transformation it is generally a very painful experience.
The pain points can be driven by feelings of failure or miscalculation of the effects of the changing business climate.
These pain points must be triaged by the consulting services provider by ensuring the perspective Client that together we will gain an understanding of where the Business Domain is currently and where it needs to be to address the perceived challenges they face.
… Before Introducing Technology Solutions
…… Strong Client Trust Must be Established
Client Trust is earned through taking the time to … Understand the “What”: The Business Arena … Before Trying to Fix the “How”: The Business Process
Sometimes we believe we have a “Better Way of Doing Things” before we truly understand what the “Thing” really entails
This seems obvious but too many times a Sales and Technology team already believes that the product offering that their company is offering is a “Perfect Fit“.
Their premature understanding of the company’s real business challenges will often lose the engagement as the company’s stakeholders have lost confidence that you are willing to really listen to their issues.
Employee Change Acceptance
All business transformations begin and end with human beings.
The greatest, and most expensive, resource of most companies is the money spent on the employee base.
Without people no company can succeed
Help others see the need for change and they will be convinced of the importance of acting immediately.
Step 2: Creating the Guiding Coalition
Assemble a group with enough power to lead the change effort, and encourage the group to work as a team.Step 3: Developing a Change Vision
Create a vision to help direct the change effort, and develop strategies for achieving that vision.Step 4: Communicating the Vision for Buy-in
Make sure as many as possible understand and accept the vision and the strategy.Step 5: Empowering Broad-based Action
Remove obstacles to change, change systems or structures that seriously undermine the vision, and encourage risk-taking and nontraditional ideas, activities, and actions.Step 6: Generating Short-term Wins
Plan for achievements that can easily be made visible, follow-through with those achievements and recognize and reward employees who were involved.
Use increased credibility to change systems, structures, and policies that don’t fit the vision, also hire, promote, and develop employees who can implement the vision, and finally reinvigorate the process with new projects, themes, and change agents.Step 8: Incorporating Changes into the Culture
Articulate the connections between the new behaviors and organizational success, and develop the means to ensure leadership development and succession.
There are basically two groups of employees:
-
Employees that create the Products or Services for a company
-
Employees that manage the Company processes to enable the sale of goods and services
The first group represents the “Worker Bees” that produce the goods and services that generate the revenue for the company. They are forced pass through the change process quickly or risk losing their job. That does not mean that it is any easier than the Management Group
The second group, the Management Group, consists of the following example roles:
-
Middle Managers – Mid-level process managers responsible for low-level daily activities
-
Department – Senior management that is responsible for the outcomes of their middle managers
-
Vertical Managers or Directors – Management responsible for a product division or vertical market
-
Executive Management – Company Leadership that controls the direction of the company
-
Chief Executive Officer – The company “Queen Bee” that manages the results of the Executive management team
It is this group that generally suffers from Organizational Process Debt.
The illogical desire to hold on to
failing processes even when
confronted with the logical requirement
for changing those failing processes
is Organizational Process Debt
Executive group must be targeted for the success of the human being centric change management process for acceptance of the “Winds of Change” before any success can be realize at the lower management levels.
Lower management must “Lead by Example” for the rest of the company resources so that “Employee Trust Equity” can be earned with the people who actually create the success for the company: The Worker Bees.
Applying the Same Failing Process
… Over and Over Again Expecting Different Results
…… Is Einstein’s Insanity Definition for Software Development
Elastic Design
The concept of “Elastic Design” is based on the reality that most sites become marginalized and even somewhat obsolete shortly after their initial release.
This issue can be caused by major requirements and decisions about the business value and technology requirements made too early during a protracted design and delivery process.
Another cause is underestimating the solutions impact on the business and technology environment.
A “Static Solution Mentality” during the requirements gathering stage can result in a static deployment of the business solution.
A Static Solution Mentality spans many areas
Human Resources, Business Requirements
… Technology Requirements and Time-based
The human resource requirements to support the business processes and technology maintenance are funded by decisions that do not reflect the actual deployed solutions.
Most Business Transformations require an iterative process of understanding that span at least 60% of the initiative.
If decisions about these resources are budgeted early in the process they run the risk of being insufficient when required.
Another area is time.
A static mentality regarding the viability of content and content schema based on the business vertical requirements at the design phase can deploy solutions that are frozen in time.
The semantic, relating to meaning or distinctions between the meanings of different words or symbols, of a business vertical is not likely to change that over time but the way those semantics are consumed by a solution is likely to change.
Creating an Elastic Scaleable Design
Business Transformation has a serious effect on the human resource topography.
Positions could become obsolete and many new resource requirements will be required.
Every effort should be made to transfer existing resources to newly required positions whenever possible through formal and informal training initiatives.
This will mitigated environmental issues by fostering a climate of trust that management appreciates the time in service of the legacy resources.
A strong commitment to continuous communication of the changes as they are discovered with all levels of company resources is essential to earn “Trust Equity” with the employee base.
Posting Clear and Understandable Justification for Change
… Detailing the Benefits Employees will gain from Change
A formal training program ahead of the implemented changes to help relieve the fear and stress of corporate change is required.
A Companies Most Important Resource
are its Human Beings: Respect the Individual!
An elastic design with regards to business requirements ensures that the most important design decisions are made late in the delivery process as possible.
As we move through the business transformation evolutionary process we gain more knowledge that we can use for wiser decisions that impact the success of the business transformation.
By delaying important decisions that impact the overall design of the Technology Domain we enable a design to adapt to the changes created from the implementation of those late delivery processes.
When discussing Technology in the scope of Elastic design I am actually referring to the network infrastructure hardware, operating systems and application software requirements for a deployed solution.
There are basically two ways to support a solution deployment:
1 – Corporate supported Network Operating Centers (NOC)
2 – Cloud Services
There are pros and cons to both.
Corporate Supported Network Operating Center
PROs
- Company retains full control and access of all infrastructure assets
- Security concerns regarding Authorization and Authentication are managed internally
- All environmental configurations, specifications and schemas are under corporate control
- Total control of the network availability and contingency management process
CONs
- 24/7 support responsibilities
- All logistics support requirements for the NOC
- Capital expense requirements for all network devices and appliances
- All applications, tools and supporting software must be procured
- Full bandwidth and servicing power costs at all times even when not required
- Ownership and management of all support personnel
Cloud Services
PROs
- Outsourced 24/7 support responsibilities
- Create platforms as required
- License applications only as required
- Scale environments dynamically as needed
- Shut down bandwidth in slow periods
- Pay as you go opportunities
- Cost forecasting becomes simpler
- Environments can be created and destroyed without direct interactions
- All backup and redundancy schema are well-tested and validated
CONs
- Offsite storage of proprietary data and applications
- Shared control of the Security concerns
- Limited direct access to any physical resources
- Shared management processes for your environments
- Loss of some business tax exceptions for environmental costs
Ultimately the elastic design of your system is based on many decisions.
A phased approach to moving from one environment to the other is recommended so metrics can be created to validate the perceived return on investment.
There are 100 ways to do most things
… But only a handful of ways to do them correctly
…… There is no “One Way” for anything
It is a fact that creating technology solutions takes time, sometimes a great deal of time.
The latency between the business requirements gathering and the final deployment of the product to market can be years.
We live in a rapidly change and diverse world market that seems to change almost daily.
This begs the question:
“How can we deploy solutions that are not
obsolete on the day of deployment?”
What is a Semantic Design?
A “Semantic” is representation of a noun, not the noun itself. As stated earlier in this article, the definition of a semantic:
“Linguistics relating to meaning or the differences
between meanings of words or symbols”
If we analyze any business vertical, an industry sector, we can generally define the essential business requirements through a representation of nouns. A company that delivers a created product to a customer defines the following Semantics:
- Vendors – Suppliers for their inventory
- Inventory – Items required to create and deliver their products to their customers
- Product – Manufacturing or construction of a product for delivery to the customer
- Orders – Processing and fulfillment of customer product requests
- Delivery – The acquisition process by which a customer receives the requested product
- Customer – The initiator of the Order and the receiver of the delivered product
These are representations to a business domain that could support any of the following business models:
- Pizza – Pickup or delivery of ordered pizza
- Burgers – Pickup or delivery of ordered hamburgers and other sandwiches
- Videos – Internet streaming of ordered video media
- Music – Internet streaming of ordered music audio and video media
- Working Lunches – Office delivery of working lunch orders
To better understand the concept of a semantic let’s look at ten concrete entities that could be represented from a “People” semantic:
- Customers – People that buy available products from a company
- Vendors – People that supply companies with their inventory items
- Employees – People that receive company benefits such as health care insurance
- Dependents – People that receive company benefits from a family member’s company
- Contractors – People that deliver services to other people or companies
- Clients – People that receive services from companies company
- Colleagues – People that work with other people company
- Constituents – People that are represented by politicians in a designated geographical area
- Lobbyists – People that tries to influence legislation on behalf of a special interest
- Politicians – People who actively engage in the use of tactics and strategy to gain power
When a business solution is designed to the semantics that define the required business process and not to a concrete implementation of that process at any point in space and time, we can define the process as set requirements specifically relevant to that point in space and time
We can manage the changing implementation details that will occur over time by not creating a solution architecture that is based on requirements that have been defined as a one to one concrete implementation during the design phase of a business process.
…By Designing to the Semantics of the Business Domain
…… And Creating Self-descriptive Definitions of the Semantics
… We can Deliver these Mappings for the Semantics
…… Dynamically when the Concrete Representations are Required
In technology we can deliver to the managing application a “Dictionary of Defined Terms” that represents what the application requires at that point in time.
As the definitions change we only need to modify the Dictionary of Defined Terms to change the realized results.
A design that conforms to this paradigm become “Atemporal”,
timeless in nature and is freed from the constraint
of the early requirements that change over time
Elastic Design describes the responsibility of the
Technical Domain to provide Functional Management
for the Dynamic Nature of Business Change over the
lifetime of the deployed technologies
The Language of Business
A common challenge for a company is communication between the employees that use the business systems and the employees that create and maintain those business systems.
“Business Speak” and “Techie Talk” generally do not express the same understanding of key words and ideas.
This can lead to the misunderstanding of the intent of the Business Domain during the requirements gathering stage of an engagement.
An example of this is revealed in this sample User Story:
As a System
I want to create daily reports
So that I can detail the day’s activities
The word “System”, when asked by the roles below, had a very different meaning:
-
The Stakeholder – The Business Application
-
The Subject Matter Expert – A Business Process
-
The Architect – The Technology Solution or a major component of the solution
-
The Developer – An Assembly within a development solution
-
The QA Tester – A current “System Under Test”
-
The Network Infrastructure Engineer – The hardware and software required to host the solution
The solution for solving this communication issue
is a Company Ubiquitous Language driven by the
Business Domain and not the Technology Domain
The Ubiquitous Language is a collection of Business Terms that must be understood and realized in the same way by all Team Members.
The lexicon is a “Living Dictionary” that must be pro actively managed throughout the entire Software Development Life Cycle.
The Software Development process requires numerous human beings to become intimately involved for the project for the initiative to be successful.
Each member of the Business Group and the Solution Provider’s team has a unique perspective of the project and the definition of any term that the member hears.
As stated in the Modern Developer Blog “The Cat Dilemma”, a misunderstanding of terms deemed as understood by the development team can lead to complete failure of the Client’s definition of success.
The Ubiquitous Language
… Is a Lexicon of Terms
…… Created for a Better Understanding of the Business Intent
The terms are always driven by the Business Domain requirements and augmented by the Architecture
The Lexicon is made globally available to the Business and Technology teams for reference and maintenance throughout the entire life cycle of the Business initiative.
The Goal is to create the Dictionary of Terms
from translated words and phrases
that are refined in to a Ubiquitous Language
that all Business and Team members
agree upon the common meanings
Concluding Thoughts
The “Winds of Change” can blow soothing warm breezes or bitter cold air, your understanding of the psychological ramifications of change within your corporate culture will help reduced the pain of change.
People resist change even when change is good for them.
Help them understand how the change will make their professional life better.
Give them the tools for a greater understanding of the vision of the change and the business drivers important to management.
Make the change process “Transparent” to the entire work force so a level of trust can be earned.
Business Transformation is a Process
… That Affects Human Beings
…… Respect the Dynamics of Human Change
Help facilitate the change for all the affected areas:
People, Business Domain, Solution Design
and the Business Language.
Wisdom Pearl # 111 – People and Change
People Resist Change
… Even if the Change is Good for Them
…… Understand this Dynamic When Expecting Results from Your Changes
Latest posts by Brad Huett (see all)
- DevOps: A Bridge to Your DevOps Culture - March 25, 2016
- Embracing Test Driven Development (TDD) - March 25, 2016
- DevOps: Delivering Agile Projects - March 25, 2016