People, Process and Technology, what does that mean?

When talking to people who have been involved in a larger process design or establishment projects, there seem to be a widely spread understanding about the term people, process and technology. Nevertheless, when asking the question

 

"what was the projects top priority the last 4 to 8 weeks of the project?" 

 

the answer tends to be very technology related. Acceptance tests, transitions from dev and test environments to production. IT activities for handover to operations etc. etc. 

 

Another question I usually ask is 

 

"If you would use people, process and technology as different focus areas for the project, where were the focus highest during the project?" 

 

The answer tends to be process in the beginning, people in the middle and technology at the end. As if these disciplines were stackable on top of each other or three different areas that did not bring any synergies. Yet, everybody knows about people, process and technology. 

 

If you want a solid foundation you need concrete. Think of people, process and technology as water, sand and cement. If you want to mix concrete to build a foundation you can not use more sand in the beginning, water in the middle and cement in the end. You need to mix them with the same proportions in the beginning, middle as in the end. This applies to processes as well. 

 

A process describes a series of events in a particular order which are considered critical, or highly contribute, to an expected result or output. Technology can facilitate a user interface (or automate) for an specific event in the process and show any necessary information required to accomplish the task. People are the ones that know how things should be done, what order, what information that is required, what information is generated, how to perform the work, any applicable logic etc.

 

A balanced mix of them all throughout any project, establishment, continual improvement etc. scenario is important. They are not three dials where you can increase and decrease them as you see fit. If one of them are delayed for any reason, it affects all three in the same way. 

 

It is not like the classical quality, speed, cost. You can pick only two! They are all equally important just as in concrete. This is not only true during a project. This is just as applicable after any project for process maintenance as well. 

 

People, process and technology might be three different terms but combined the right way and you might be on you way to greatness. 

Should i go for services or processes?

What are service orientation and process orientation? Is it s choice between the two, or should they coexist? I get the sense that all "ITIL implementation" projects out there have a tendency to be tool and process oriented and even worse. The "Lets take one process at a time" approach is a long and hard way to learn how to do it right, if that ever happens. If that sounds appealing and firefighting mode is what you came for? Please google for "how to implement ITIL".

 

Process Orientation:

When everyone at IT works there are different workflows that come into play depending on what IT is trying to accomplish. Each workflow has a set of objectives and the combination of workflows is common to enable IT to accomplish certain tasks or results in an effective way. Any new or changed demand from the business IT serves, triggers these workflows to facilitate the new or changed demand. 

 

Process orientation means that these workflows within IT are defined as processes where each process has an expected output and results. Many of the processes are interacting and dependent on each other where results from one process is used and further enhanced in another process to finally deliver what is expected. 

 

Each process is describe by identifying necessary activities, the order of them and the work that should be done. The results from each process are evaluated to assure the right level of quality. The combination of processes and evaluation of the expected end-result is assessed to assure the delivery of what is expected. Any deviations, unwanted characteristics and anomalies are analyzed from a process perspective to identify and improve the process flow, activities, result and output. This does not constitute that work is defined in every detail in every process, far from. 

  

Service Orientation:

Service orientation implies that there is a defined service that is agreed upon between two parties. The service is used by a customer and delivered by a supplier. The secret ingredient of a service is to understand the value it contributes to. The service does not deliver the value. The value is created by the customer when using the service. Without going into any collaboration models for making this partnership work optimally, lets just for the point sake say that there is a service and the service is delivered (by IT) and used (by the business).

 

Service orientation means that from that point on, the service is considered in everything IT does. When the business wants to change way of working (change their business process), any new business demands need to reflect how the service needs to change to support new business objectives and way of work. This is a constant dialog and evaluation that needs to be done together by both parties for the services.

 

This also means that IT needs to understand how the service is used by the business to create value. Again: The value is not delivered by the service, it is created when the business uses the service to achieve its objectives. It is key for IT to understand and learn this.

 

Any new business demand that affects the service will be managed by IT and realized as a new release at some point for the business to use and enjoy. At this point we can use the service for a lot of useful things within IT. We can use the service to allocate costs to show Total Cost of Ownership, measure time to market, evaluate the actual value it contributes to etc. This can be the focus for IT and everything that IT does. Everybody, both business and IT, knows what the service is used for, why the service is delivered and the importance of it at any time. 

 

Process orientation analogy - The business is a group of carpenters that build custom houses, IT is the supplier of tools and the infrastructure to run the tools e.g. electricity, heat, water and fences and gates etc.

 

For IT to support the business, it organizes in different departments. For simplicity lets say there are two departments, one focusing on the availability of electricity on the worksite during the full construction of a house. The other department is focusing on availability of machines and carpenter tools on the worksite during the same full period. Each carpenter (business area) at the business has its own requirement for tools depending on what they work with and when the tool is needed during the construction period. 

 

IT defines the processes required to accommodate the business from these two perspectives and the results from each process are evaluated to assure the right delivery and level of quality, but still as two departments in two different perspectives, tools and electricity. Most of the defined IT processes are shared between to two departments but the work that is performed within an department  is mainly to facilitate their own perspective. Both departments claim to deliver what is expected with high availability but there still seems to be a constant argument between the business and IT of shortcomings and delays.  

 

When talking to the tool supplying IT department they can show that all new and changed requirements from each carpenter has been fulfilled and when talking to the electricity supplying IT department they claim the same. When closely examining tools they seem to live up all requirement and when doing the same with electricity it is available and on time. IT has still no insight nor knowledge in how the business actually builds a house and what constraints the carpenters needs to manage when doing that.

 

The argument of shortcomings and delays continues with a firefighting mentality from IT emerges to try to serve the business better.

Service orientation analogy - The business is a group of carpenters that build custom houses, IT is the supplier of tools and the infrastructure to run the tools e.g. electricity, heat, water and fences and gates etc.

 

For IT to support the business, it needs to understand how the business builds a house. Each carpenter specializes in a separate part of the build and the tools and infrastructure required differs over time and between the carpenters. There are also variations in number of tools needed at a particular time and based on the build phase.

 

For each carpenter (business area), a selection of services are defined. When defining these services there is a focus of explaining and understanding of how the value is created. How should the tools and infrastructure be used by the carpenter in the most effective way to achieve the best value? The service definition emerges. Now IT understands how the packaging and combination of tools and electricity (and anything else included) should be delivered and used in an optimal way by the carpenters.

 

A new way of structuring IT is developed. IT is still organized in two departments based on tools and electricity. The difference is that with a clear understanding of business needs the deliveries from IT is combined  and packaged based on optimizing the carpenters ability to work effectively. This is now the primary focus and collaboration between the departments is managed accordingly.

  

Analogies combined:

With both service and process orientation in place it was obvious that there where a lot of requirements and workflows that never was managed properly.

- A new bigger machine occasionally blew the fuses causing everything to stop.

- At specific times the number of machines used simultaneously caused fuses to blow causing everything to stop.

- It is far more efficient to install electricity in multiple locations throughout the construction site and inside the house so that the carpenters could use the tools where the material was located or being used, eliminating the need of unnecessary carrying of materials around the site and inside the house. 

- Some of the tools used by the carpenters could be shared due to that they where used during different periods instead of suppling a complete set of tools individually.

- New specialized tools and equipment where developed to further facilitate the carpenter needs

- Workflows where improved with services in i focus

- collaboration and dialog where improved considerably when the service and value was common ground for both parties.

 

Processes orientation and services orientation combined:

Service orientation does not in any way replace the need of process orientation. Even when IT is service oriented, process orientation is still necessary and relevant. The addition of service orientation gives IT a better ability to understand business needs and what combinations of IT and improvements that constitutes. Service orientation is all about delivering a service that effectively can be used by the business to create value for the business. Process orientation is how we optimize our work when identifying and managing and deliver those improvements. 

Summary:

You can focus on process orientation which have a high probability to lead to a IT orientation with low business context. Processes orientation is a good way of optimizing how something should be done whilst service orientation is why, what it is and how it is used to create value. This might be the difference of IT being perceived as cost effective technology broker vs. high valued business driver.  

 

Neither of the two orientations needs to be rigorously documented with all details and definitions. The contrary. Make the simplest design and focus on validation, evaluation and collaboration when improving your design.   

The secret with exceptional process design

1. When is a process perceived as good?
2. When is a process perceived as bad?
3. What is process design?

 

These are questions that everybody that works with process should ask oneself. I use these questions frequently just to remind myself of the secret with exceptional process design. So what do I mean with process design? I guess you could include quite a lot in the term "process design". I have heard people say its about drawing activities and their relations and I have heard people say it is about a customer - supplier relationship and I have heard that it is anything in between. I will come back to what I think process design is but lets start with the questions in the right order.

 

1. When is a process perceived as good?

Can you recall any occasion when a process has been the subject for praises? No? Well any occasion when a process has been the subject for positive attention? No? A big thank you? A tap on the shoulder? A friendly word? A look? Any thing?

 

That something work fine is usually not expressed in gratitude of a process. Gratification is not that uncommon but it seldom correlates to a particular process. Customer experience can be good and when it is, thing just work. Why is that? How come things just work? Is it because they have the sharpest minds? Is it because they have the best process design? Is it because they have the best tools?

 

2. When is a process perceived as bad?

I guess that you can recall a few occasions where a process has been the subject for blame. I know I can. Why is that? Is it due to a bad process design? Bad tools? Lack of best people?

 

Whenever expectations are not met there will be a sense of dissatisfaction. Whenever expectations are met there will be a sense of satisfaction. Both of these cases will affect the trust and this trust is the basis for the overall experience and satisfaction. How do we create trust? How do we increase trust? How do we even influence trust?

 

3. What is process design?

There is a fundamental element with any process and that is the expected process output. But it does not stop there. There has to be a profound understanding of what that output is to be used for and what the expected result of that should be. This is commonly referred to as the value. The process has an output and that output is used to create value. This is the guiding star in all process design.

 

So lets go back to trust and experience. How do we influence trust and experience? What are the basics in trust? Trust is earned. It can not be demanded, asked for, taken for granted etc. It is earned. Earned by constantly proving commitment of a common goal over time. What are the basics for experience? Experience has a more short term relevance. We could have a bad experience and still have a solid trust. But over time if the bad experiences are frequent our trust will gradually decrease. The opposite also apply, if good experiences are frequent over time out trust will increase. 

 

The secret with exceptional process design!

It does not require the sharpest minds. It does not require the best tools. It does not require the best of anything. It does however require two things.

1. The fundamental element of process design.
2. Relentless effort to improve.

 

The fundamental element of process design.

Remember the guiding star? The expected process output and the understanding of what that output is to be used for to create value. This has to be the primary objective in all process related work.

 

Relentless effort to improve.

Any effort to improve process output and value could be a process related issue. It might not. It could be anything. Nevertheless, our ability to improve is dictated by our ability to identify and apply improvements. It does not matter how we identify the improvements as long as we do. Use anything at hand. Process -measurements, -operators, -stakeholders, -feedback etc. and never forget the primary objective, output to create value.

 

Summary

My conclusion is that nevertheless if there is trust or not. If there is inexhaustible effort to identify and apply value oriented improvements there will be an increase of trust over time and things will just work eventually. And what did we say about things that just work? That it is a sign of good processes. The key to exceptional process design is to never loose sight of you guiding star, value. And never get tired of digging down in the dirt to find gold nuggets in the shape of improvements. The improvements can be related to education, available information, routines and procedures, tools etc. It does not matter. If it increases value, put it on the list. That is the secret of exceptional process design!

I want information and a purpose

I love my work. I am officially a process nerd in everyone's eyes :) But long ago i started to asked myself why. Why do i like it so much? Is it something magical in the processes modeling that makes it so interesting? Is it the creation and visual blooming that occur on a whiteboard when you start drawing it? Is it the pleasure when verifying that the outcome was actually what it was supposed to be? is it the feeling when CSI work starts to show in metrics and KPI's?

There is a lot of joy in the work, thats for sure. But the last years i have seen a pattern. What really is the essence of my satisfaction is in the construction of it all. When you start, you know what triggers it and you know what the outcome should be. In the beginning, everything in between, is just a blur and it is here it starts. Finding all INFORMATION. It is everywhere and it is endless. There are people involved, everyone has their requirements and suggestions. Opinions flow and everything is discussed e.g. tools, user interfaces, routines, sequences etc. It like a wonderful bowl of spaghetti, all nestled in one and each other. 

Sorting out the structure, dependencies, sequence and foremost identify all relevant INFORMATION needed to get to the outcome, is what triggers me. The more information you can get hold on the better, if you are able to structure it, otherwise it can be a nightmare. What i have realized is that i do not want a process, I want an information flow. Information guides me, not a process. I do not care if we are working on the Incident, Change, Problem, Event or any other process. That is so irrelevant as long as the outcome is clear. What is the purpose of gathering the information, who needs it, where does it come from, when is it available, in what context, how should it be structured, when is it needed and the guiding star: what are you supposed to do with the information once you get it, and dont give me any "it is nice to have".

I conducted a brain teaser the other day. I challenged myself to define the major information flows required to replace all the operation processes defined in ITIL. One information flow replacing 5 ITIL processes. I know, it was doomed from the beginning but i did it anyway as an experiment, to challenge the paradigms i have and with a lot of simplifications. Some interesting thoughts arise from it though. Information defined in a process that is needed in the same process is usually structured the way the process needs to consume it. The logic used is based on the logic from the process. When initially designing a process you do it one by one and therefor it makes sence focusing on logic for a specific process. Some examples are -Incidents, they are categorized and structured the way we think is good when it comes to firefighting and analysis of that. -Changes, they are categorized and planned through time and with impact assessments due to the importance of that. And it goes on like that throughout the most of the processes. What if the Incident process had to structure, store and manage all Incident information base on requirements from Change and Knowledge Management, or the Change process had to store and manage all change information based on requirements from Event and Incident management and so on. 

So my mind was set. I would structure all information from one view but which would i take. I started to think of many different views and i asked myself the following question. What do i know about the environment I am trying to define? We are still talking about all the Operation processes in ITIL. What could be the common view? Hmmm the conclusion was that the only thing i know for sure is that whatever we do today, will not look the same in a couple of years. Could i use this somehow in my view for structure? And i could. I asked myself what i could use as a base for something unknown and it was so obvious. Continues Service Improvement (CSI)  is a perfect base for the processes. If we have a process today and we know it will change over time it is CSI that will make it happen. SCI does not only improve something to be quicker, bigger, taller. It changes it as well. SCI is not only vertical, it is also horizontal. If the customer is the focus for SCI and all the processes are based on the ability to perform SCI improvement i think we have very good conditions to actually amaze people.

So if my information structure should be based on SCI, meaning that everything should be initially structured and based on the ability of measuring, reporting and improvement, what would happen? The first thing i noticed was that it all had a big meltdown. Suddenly there were no processes any more. From an improvement perspective the analysis required data from every process every time. That means that already from the the first step in every process, which is registration, the information should be stored and structured from a CSI perspective. That is the only way to secure that it will transform over time, as will the requirements of it (and if CSI is focusing on the customer you can figure out the rest). All this lead me to a quite interesting information flow covering all the major steps in each operation process. 

Just imagine the change impact assessment and risk assessment quality when incorporating historical statistics for issues involving affected HW or SW, persons involvement , time of day, historic availability, incident ratio related to changes, early life support outcomes and the list goes on. Everything i mention here is fully possible already today. There is nothing odd about it. It is already out there. But when i take a closer look at the information itself, how it is structured, shown in UI, ad hoc availability etc. I see that there are limitations due to that the way information is consumed from the process itself often rules and other processes "use what they can", if they want. The information is not isolated but but it is not effort less to use either.

So what will happen in a couple of years? Do we have processes or do we have information flows and rules that guides us from a improvement perspective? I do not know. but i know why i like my job :) I feel like the character Sherlock Holmes, and every day is a new episode with a new mystery that has to be solved. A new unknown that has to be broken down to particles, logically assembled together to create magic. 

I will continue to design and create processes but the process is a byproduct of something larger. The information flow and the improvement requirements is ruling my world. I want information and a purpose.

Design a process, communicate and implement value

As a process designer we need to think ahead. We need to think ahead and see the future value as clear as possible to be able to do a good process design. The better we can see the future, the better our process will probably become. It is a matter of time traveling and make the necessary changes in real life and it is right here i see something that we could improve tremendously.

What do i mean with that? A basic way of designing a process could be to develop a ASIS process design that clearly shows how the process is implemented. A TOBE process design to identify the gap that has to be covered. A implementation plan that removes the gap and takes us from ASIS to TOBE in an effective manner. Sounds easy don't it? Usually there is no trouble in developing the ASIS or the TOBE process. The implementation plan should be no big deal either. So why is there a general understanding in the business that implementing process is hard? I frequently hear and read that communicating during implementation of the process is what is the hardest thing with processes implementations. As soon as you show a process to a stakeholder or an process operator for verification during design you either get rolling eyes and a general lack of interest or the opposite, an theoretical acceptance but not the corresponding action in reality when implementing. How come we during the process design so often get acceptance from both performers and stakeholders but in reality we struggle so hard with the implementation and realization of it? 

Many years ago when i was a process youngster i had such firm belief that i could, and would, change the word by designing better processes. That was it. It was a revelation for me and i could see the "code" in front of me, just like in the movie The Matrix when you see the rain of letters and numbers falling down on their computer screens, i could read it. I did a lot of good during those years but boy what a fight it was. The effort of establishing a TOBE and get it reviewed, accepted and even communicated was a walk in the park compared with actually establish the changes and implementing the new way of working. The constant discussion of metrics, tools, activities, input, output, people depend on you, this is required not optional etc. Anybody could have been discouraged by this but i had seen the light so I just kept trying even harder. The more i talked about the process the more alienated i got. I was a process fool with a tool! That was a long time ago and a lot of water has passed under the bridge since then and my conclusion are that the more we talk and communicate about the processes itself, the further from reality we are perceived. 

What we need to come to terms with is that the process is just a visual representation of a series of activities that can be sequential, parallel, conditional, mandatory etc. and is usually a combination of them all. The way we design and visualize a process has absolutely nothing to do with a operator actually performing a part of the process. It has nothing to do with why something has to be performed in a certain order or not. What we, as process designers, are experts in is to see and understand the purpose of a process and how to, by a series of activities and flows, achieve that purpose. We use our technique to represent the information required in the process and all conditions that needs to be fulfilled. We can even measure the process to see progress and outcome and propose adjustments based on that. But as i said earlier it is not a question of designing the TOBE or ASIS or even the implementation plan that is the challenge. It is in communicating and establishing the process to achieve the purpose and value designated with it. 

So the dilemma here seems to be, how do we design and implement a process without talking, showing or ever mentioning the process itself to the outside world? We need to communicate based on outcome and use a language that establish trust and ambition. The process itself absolutely needs to be designed and constructed but we maybe need to look at it as if it was confidential. Yes, it is a big secret of the trade and is never to be communicated or shown outside the design room. The only thing that is to be revealed is the purpose of the process and the value that it will bring. This would mean that we will have to change the way we speak and communicate when it comes to processes. There are some ground rules for process design so lets take a look at what should be present in a process and see where we end up. 

- A process have a defined trigger.

- A process have a defined end result.

- A process have a purpose.

- A process brings value.

- Each activity have an initial condition that needs to be met before it should be performed.

- Each activity has an end result condition that needs to be met before considered finished. 

- Each activity have a responsible performer (even if automated).

- Each activity is supported by a tool (even if performed with pen and paper).

- Each activity is dependent on information that is required to be performed.

- Each activity generates information before considered finished.

If we could se the above in a process design we could consider it to accomplish the basics in process design. But if we apply the dilemma on this situation and agree on that never mention or to show the process itself, how do we communicate about it? Well the first question is who are we communicating with? If we are communicating with a stakeholder we certainly should talk about the purpose and value the process brings. Even every activity can be described in value. So what of the ground rule list should be considered when talking to a stakeholder?

Interests of a stakeholder:

- A process have a defined end result.

- A process have a purpose.

- A process brings value.

- Each activity has an end result condition that needs to be met before considered finished. 

- Each activity generates information before considered finished.

Every point in the list above can be described as purpose and value. As you can see everything is result based. It is what we get from the activities and process itself. Each process activity can even be described in value and purpose if needed to go to that level of detail. Still, never to have mentioned or shown the activities or the process design itself.

How would the list look if we would talk to an operator (performer). This time i divide it in two parts. The first part is what i consider operator requirements. Basically what the design suggest should be achieved and available for the operator before performing her work (process activity). The second part is what is expected of the operator and must be achieved by her to consider the activity as performed. 

Requirements by the operator:

- Each activity have an initial condition that needs to be met before it should be performed.

- Each activity is supported by a tool (even if performed with pen and paper).

- Each activity is dependent on information that is required to be performed.

 Required of the operator:

- Each activity has an end result condition that needs to be met before considered finished. 

- Each activity generates information before considered finished.

As you can see it is much easier to isolate the purpose and value in each process activity if we break it down to this level and simply answer the question WHY for each process step and each statement for process design. This way we can communicate with any person about the process or even a small part of the process but disguise it in terms of purpose and value FOR her, or the purpose and value contributed BY her to achieve the overall purpose and goal with the process.

It is more about the words we use than in the format we do it in. If you are used to present and communicating using slides continue with that. Just make sure you never reveal the process design in the material. Always express yourself in beneficiary terms FOR the attendee or requirements OF the attendee. This is applicable for stakeholders, operators, managers, end users etc. The process is just a tool of the trade and a way to describe the information flow, the activities where it is used and modified/created for a specific situation. It can be used for many things and should mainly be used where both the author and receiver base their assumptions/analysis/design on processes.

In other circumstances you are better of hiding it!

service vs process

I have read numerous examples and descriptions of this topic but i miss an important point in them. Thats why I will make my own contribution in the matter so I will start from the beginning.

A service is the bundling or packeting of something that is consumed by someone and there is a provider which take responsibility in delivering it according to some kind of agreement. The service might consists of multiple parts/options where some can be mandatory and others can be optional. Sometimes the service is static and can only be purchased in its current shape but nevertheless, the consumer needs and wants it.

A process is the way (a sequence of activities) where a defined outcome is achieved. Its supposed to be efficient and repeatable so that the outcome is achieved every time the process is triggered and completed. The framework ITIL consists of processes, and the description of them, and is a common way of describing the way (workflows) an IT department is trying to work.

The service is consumed once or frequently over time. The process is triggered and driven according to the flow.

This far i think it is quite strait forward but how about the missing point? Well when defining a service there are things that are crucial. If part of your goal as a provider is to contribute and align with your customer. The first thing to understand is what the heck is the consumer trying to do and achieve. The other thing is to understand the process of how the consumer is doing it ........ but ........ here is that process again? This time the definition of the process is still valid but now it is not the IT departments processes that we are talking about. Now it is the consumers process we are talking about and this is the point i miss. As an IT service provider we need to define internal processes for how we do our work but that does not have anything to do with the services we provide. To define a service we need to have a clear understanding of the consumers process and its only then we can align and contribute.

To define a service where the consumer actually perceives it as valuable it needs to be fitted into how the consumer achieves its outcome. We as a provider need to understand the consumers process and choose a part of it or the complete consumer process and define how IT is used to achieve the outcome. When this is done we can package a service to enable the consumer process, or part of it. For better understanding and communication, the service should be named as or similar to the part of the process its enabling. If the service is designed to support or enable a complete process, the consumer process outcome is good start for the naming of it.

If IT can define a service where its utterly clear for both the consumer and the provider what the service enable or supports, eg. exactly what part of the consumers process it is supporting, and the consequence when the service is not available, eg. how important the outcome is at the specific moment for the consumer, you have a good foundation to start with defining services.

With this information IT can design a service where the following is true.
- When available, both parties have the same understanding of what it is used for and what it is enabling.
- When unavailable, both parties have the same understanding of how critical the situation is at that specific moment in time.

in one case it might not be critical until next day/week/hour and in the other it might be critical at once. This is only achieved by understanding the consumer process and the value of the outcome for the consumer. The process within IT is the way we manage and deliver our IT services. The service is the way IT enable the business process IT supports.

Analogy: Whats the point of knowing that there is a flat tire on a car if we do not understand that the rest of the car is useless for the driver without it? It would be better if the parking break was broken and we understood what that meant and could tell the driver to continue to use the car but not to park in tilting conditions until fixed.

Process development or decommission

People seem to think that process implementation is about a design phase and a implementation phase. Once it is in place you are done? I think nothing could be more wrong (well actually allot could be more wrong but just bare with me on this). To actually get a beneficiary evolving process you need to care for it. Being actively caring is the key for the process evolution so lets call that management :)

To manage your process you can develop it along with time and adjust it for better compliance or efficiency but if you do not nail the effectiveness whats the point? Some call it effectiveness and some call it outcome but let us agree on that every process has a purpose and for sure the purpose has to add value for someone and that someone is probably not you!

So what happens if you do not actively manage your processes. well one thing we do know and that is that everything change. So basically if you do not have active development you will have active decommission ("not to do" something is actually to do something as well). Your process will loose it's focus (effectiveness), not due to that it is changing, but due to the fact that the outcome will not match the changing business needs over time.