Process vs. Neglect

What’s the opposite of the word “process”? Neglect. That’s right – “neglect”.

That is how Thesaurus.com defines, as the antonym, for the word “process” when used as a verb. When I saw this, I was completely blown away by how simply and elegantly the opposite of the word provides a perfect summarization of the consequences of poor process implementation.

Therefore, it can be neatly summarized, “if you are implementing poor processes in your business, you are neglecting your business”.

Let us consider more closely how the implementation of structured processes benefit an organization and remove “neglect”.

We may begin our contemplation by deliberating on the performance of a task in an organization with proper processes in place vs. the performance of a task in an organization without proper processes in place. A good example for a process to consider that most readers would be familiar with would be the Change Management process. Therefore, let us consider the task of making a change in the two types of organizations described above. The steps involved in a typical change management process would be along the lines of the following list:

• Submission and recording of the proposed change


• Initial acceptance or rejection of the change based on completeness of the submission


• Classification of the change (categorization and prioritization)


• Detailed analysis of the proposed change for final approval and implementation plan


• Implementation of the change


• Evaluation of the implemented change and closure

The figure below illustrates the creation of an organization matrix that represents the change management steps. (Click on the picture for a larger version)

The crosses represent the interaction between a step and a stakeholder or team of the indicated department or function (as ITIL defines it) indicating where someone performs an activity required for the successful completion of the task. This figure shows the implementation of a change when a 6 step change management process is followed. It may be observed that there is a clear definition of the roles and responsibilities of the teams and stakeholders concerned. Furthermore, a certain degree of repeatability is guaranteed with this setup. If a project manager leaves and someone else takes his place, the same steps will be followed with similar results.

Now let us consider the change in an organization where processes are poorly implemented as shown in the figure below:

The outstanding points here are that there are fewer steps and lesser involvement of functions and stakeholders to the point of absurdity. To describe the situation in more detail, after a change is recorded, design implements it as per their convenience and there is some QA involved after which the change is released without a formal release step. While this shorter process might superficially seem like it requires less work and is more efficient, the pitfalls are numerous and dangerous. The major drawbacks are:

• A high likelihood of introduction of defects or undesirable side effects to the system due to lack of communication and analysis of the change


• Further risk of issues that may crop up over time due to lack of post implementation evaluation and closure


• Risk of problems to associated interdependent systems due to inadequate analysis of the change


• Lack of documentation and historical archiving that could make related changes in the future easier and more efficient to implement


• Extremely vulnerable to chaos, inefficiency and defects if multiple changes are being made simultaneously


• Quality and timeliness of the task is dependent on the project manager and/or other stakeholders. If there is a staff fallout, there can be very severe consequences.

The drawbacks outlined above are specific to the poor implementation of the change management process. In a similar fashion, poor implementation (or lack) of other processes leads to related problems and defects within those process areas. These, then, ultimately result in large amounts of rework required to be performed which lead to cost and scheduling overruns. Furthermore, defects being delivered to customers will cause a tarnishing of the organizations image and lead to reduced sales. All of this will then hurt the bottom line: revenue and profits.

It is, therefore, clear that a conscientious and detailed implementation of industry standard processes by an organization leads to reduced problems, enhanced quality, improved sales and increased revenue and profits. Poor implementation of processes is simply inexcusable neglect.

Pick and choose

It is easy to get overwhelmed by the extensive array of process techniques that exist nowadays. Just for starters, we have ITIL, COBIT, and CMMI for general overall process and governance. Then, there also exist SDLC, RUP, Agile, Lean etc. We have PMI and PRINCE2 for Project Management. For quality, there exists QAI’s CSTE certification and Six Sigma for continuous improvement. Also, Function Point Analysis and Balanced Scorecards with a plethora of choices exist for metrics. This, by no means is a complete list, but just a few examples to give you an idea.

For an industry that has historically been in chaos due to a lack of set standards, a lot of process choices are now making the rounds. However, this newly available variety coupled with a lack of awareness and understanding seems to cause more problems and a general desire to shy away from process implementation for most people and organizations. Personally speaking, it is only after a great deal of studying lots of different process standards and gaining practical experience in the application of these techniques that I felt prepared to start consulting and post a related blog. For those who have not devoted the effort to adequately train themselves in the area of IT processes, a degree of confusion and frustration will naturally exist. However, it is too often that someone not fully knowledgeable on processes finds themselves in the position of making process decisions for an organization. What inevitably follows is a desire to “play it safe” masked by vague generic comments cloaked with several acronyms that are the current “hot” buzzwords. The “cubicle dwellers” and “naysayers” are only too happy to curtail the process improvement by causing roadblocks every step of the way. No wonder then that most process improvement initiatives die out faster than a speeding bullet and are as successful as the recent financial bailouts have been in restoring the economy.

The first step is to understand the industry that your organization is in, its customers and the products and services being offered to them. This analysis will then provide information on the levels of quality, availability, security, reliability, continuity etc. of the product or service expected by the customer. For example, “high quality requirement” industries like airlines and biomedical (where lives are at stake) would absolutely mandate a Six Sigma initiative as opposed to a typical web design setup where quality, although important (and not to be neglected) does not have the same life threatening impact.

An understanding of the capabilities of the resources available (people, finances and tools) is also necessary. For example, you may wish to implement Six Sigma, but if your staff don’t know the first thing about Six Sigma, then it will be some time (not to mention effort and money) before you can get a Six Sigma initiative in place. Furthermore, if the staff are used to a certain way of doing things then it will require some effort to get a new way of thinking in place. A transition between processes can create new defects that could be passed on to the customer making the aforementioned transition a tricky proposition requiring careful planning and forethought. A certain amount of realism is always necessary when planning anything and IT process improvement is no exception.

With all these factors understood, a realistic choice of process techniques and timetable for implementation can be decided on as opposed to going with a certain process because the CTO happens to be familiar with that process and nothing else (which is too often the case). Most process professionals get stuck with some “pet” technique of theirs that they have some background and knowledge in. They even develop a fanatical obsession with their pet process, blindly disregarding any other possibilities. This is short sighted and self-defeating. Remember, it is the flexible tree that survives the strong winds, not the rigid and unyielding one. What might come as a revelation to some is that processes standards can be “mixed and matched” to suit the organization’s needs. For example, ITIL could be used as an overall process approach with Six Sigma techniques being used for continual improvement. A sample combination of IT processes that I think work quite well synergistically and would serve most organizations capably are:

• ITIL as an overall process technique “umbrella”


• Six Sigma for continual improvement which fits in very well with ITIL


• PMI Project Management techniques for project management


• IIBA’s (International Institute of Business Analysis) for industry standard business analysis guidance


• SOA (Service Oriented Architecture) and Object Oriented Design and development techniques (if producing software)


• QAI’s (Quality Assurance Institute) quality and testing techniques for verification and validation


• COBIT (Control Objectives for Information and related Technology) for governance and SOX compliance (if needed) which fits in very well with ITIL


• Function Point Analysis (if producing software) and Balanced Scorecards which again fit in very well with ITIL and its Key Process Indicators (KPIs)

While at first glance, this list might seem overwhelming for an organization to put together, what must be understood is that all aspects of all these techniques need not be implemented at first pass. Simply what makes sense and provides “the most bang for the buck” within each of these techniques should be identified and executed. And this is where the artistry comes in. Only a professional who has studied these techniques and has experience in their implementation will be able to combine the specific aspects of these tactics to the particular situation at hand. Unfortunately these species of professionals are rare, indeed.

It is also recommended that process improvement activities be carried out iteratively. Too often, organizations attempt to implement everything in one go (Big Bang) with unrealistic goals, timelines and resources. This, then inevitably results in a great deal of chaos and confusion with the naysayers nodding their heads sagely, stating “we told you so; all this newfangled process stuff is just a fad and doesn’t work”. Things then quickly return to the status quo with the organization in an even worse situation than before having expended a great deal of time and resources for nothing. It is important that organizations implement process improvement continuously in iterations, picking and choosing where they can get the most benefit for their particular situation.

It is, therefore, recommended that organizations implement improvements in a recurring phased approach that targets the most attractive benefits to their specific circumstances from a variety of industry standard process definitions.

Metrics

“If you can’t measure it, you can’t manage it”

This is about as accurate a phrase as I have ever heard in my life and yet we have a multibillion dollar industry where a standardized set of metrics is generally not in place.

Consider a room in a house that is 10 ft by 20 ft. The area of the room is therefore 200 sq ft. Now if a carpet installer comes in to measure up for new carpeting, he will measure the room and come up with 200 sq ft. Sure, there may be a slight deviation in his measurements: he might come up with 199 sq ft or 201 sq ft but he will be in the vicinity of 200 sq ft. Next, if a painter is brought in, he too will measure the room to be 200 sq ft. Any other workmen will also measure the room to be 200 sq ft in area. The reason for this consistency is that the world of “areas” has a standard of measure. This is square footage in our example but could be square nanometers for nanotechnology or acres for measuring farmland. The point is that there is a standard of measurement which is universally followed and therefore leads to consistency across the board.

However, in the world of IT and particularly software centric IT organizations, we have a great deal of confusion and chaos. A set of requirements generated by the customer produce a wide range of responses from one company to the next. One company might state that they can complete the project and deliver the solution to the client in 2 months while another might forecast 6 months. After which, both companies will end up being delayed and deliver late and over budget anyway. No wonder then that 7 out of 10 IT projects “fail” in some respect.

Now there are many reasons for this astonishingly high failure rate in IT, but the attribute that would assist the most in obtaining a clear picture of the situation and determining the steps to rectify the problems beforehand would be metrics and their proper application. Interestingly, metrics are also something that I, personally, as an IT process consultant have had the most difficulty in getting people/organizations to implement.

In my first post, I had touched on reasons for this difficulty in implementation of metrics and process improvements in general. It usually boils down to fear of negative impact to people’s career if the correct numbers were to emerge. It is the “cubicle dwellers” that generally fear the impact of metrics. Due to this short sightedness, however, they suffer working in a highly chaotic and stressful environment dealing with unnecessary emergencies and problems. My view is that if you are doing an honest day’s work, you have nothing to fear from metrics and your work being measured. It is, however, ultimately up to management to ensure that a positive atmosphere is created regarding metrics and their application in the workplace.

In my opinion, the IT department of any and every organization should implement an IT Balanced Scorecard, a derivative of the Balanced Scorecard (introduced by Nolan Norton and Robert Kaplan). For software centric organizations, I would also recommend the implementation of Function Point Analysis as a subset to the IT Balanced Scorecard.

The IT Balanced Scorecard consists of the following 5 categories:

• Financial Performance: This should include budgeting, accounting and charging (if applicable) metrics


• Project Performance: Metrics could include the ratio of investment to return for new projects as well as enhancement projects


• Operational Performance: This includes metrics that measure the performance of the product or service being offered such as availability, uptime, downtime and Mean time to Failure etc.


• Talent Management: Metrics that measure the IT Human capital such as Staff Satisfaction and Retention, Staff Training and attractiveness to external job seekers


• Customer Satisfaction: Metrics that provide feedback of the customer satisfaction levels

It is up to each organization to populate each of these categories with the appropriate metrics that would provide a clear picture of the IT department and its alignment with the company’s mission and strategy.

The paradigm shift of the Balanced Scorecard from previous metrics techniques is the focus on alignment with customer’s requirements and satisfaction as opposed to short term focus on cost reduction and low-price competition.

For organizations that create and release software, Function Point Analysis (FPA) provides a standard of measure for requirements. Past attempts at measuring software development included Lines of Code which suffered from lack of standardization between development environments (java vs. C# for example) and Man-Hours which simply isn’t enough information. To describe FPA simply, it is an adjusted count of the transactions as well as data access operations that a requirement necessitates within the software hardware environment of the application. When all the function counts for the requirements are added a standardized measure of the software requirements is obtained for the project. The beauty of this is that if one certified function point counter adds up the function points for a project’s requirements and another counter independently recounts the function points for the same project, the number of function points that would emerge from both counters would be the same. I hope I am not the only one excited by the positive ramifications of this technique! With a combination of the Balanced Scorecard and FPA in place, a fundamental basis of measurement can be made available in order to evaluate the situation, plan for the future and correct mistakes before they get out of hand.

The implementation of new metrics within an organization need not be a traumatic event. A sequence of steps that make the implementation a walkover are:

• Initial training and education of relevant stakeholders


• Analysis and development of the strategy of the metrics to be created (usually derived from the company’s high level corporate strategy)


• Selection of the metrics (care must be taken here to select metrics that can be accurately measured)


• Definition of the measurement technique and the data collection technique
  Assigning ownership to the appropriate stakeholders


• Actual data collection and quality assurance


• Review by management and analysis of success of implementation

It is recommended that this process be repeated regularly in order to introduce new metrics or phase out irrelevant metrics as necessary. As IT is an ever changing environment it is inevitable that the metrics being collected and analyzed will also be subject to change.

To summarize, without measurement, management is impossible. The implementation of an IT Balanced Scorecard and Function Point Analysis allows any organization to be in a superior position of knowing where they are on the map. A logical process of metrics implementation allows no reason for organizations to recoil from setting metrics in place so it is baffling to the author why so few organizations have this vital technique engaged worldwide.

Benefits for all

IT Process Improvement is a sadly neglected element of most every organization. A common misconception is that only hard-core IT companies need bother with enhancing their IT processes. The truth of the matter is that in today’s age of increasing dependence by the business on technology, the optimization of IT is crucial for any organization in any industry and not just a Microsoft or IBM or Wipro.

A common misconception is that IT process improvement is limited to the IT department only with no interaction with the other departments of the organization. The belief is that adjustments to the SDLC methodology (or RUP or whatever the IT dept uses) is the only domain of IT process improvement. While this is definitely an area that the IT process expert would apply his or her energies to, improving and aligning the IT department’s services to the rest of the organization is also part of their task. In fact it is the fundamental task from a revenue generation point of view.

Let us for a moment consider a company that produces steel rods. No fancy software being produced. No high tech outsourcing – just steel rods, three feet in length, being produced. Let us consider some of the departments within this organization as shown in the figure below:


Now let us consider some of the interactions taking place. The various departments will require communication with each other as well as interaction with outside stakeholders such as customers, suppliers and contractors. In today’s day and age, a well structured network and email will take care of basic communication needs. This network and email setup will need to be deployed and maintained. Over and above this, a comprehensive ERP and CRM application will be needed to manage the resources, activities and information within departments and external organizations. The proper selection, deployment and maintenance of this application will then need to be performed. Furthermore, the machinery used in the production of the pipes will have their own software application written in a proprietary CAD language which will then require skilled personnel to maintain and operate the machinery and the related software. There may be custom applications that have to be designed, developed, deployed and maintained.

While we can go on and on, what already emerges is that a great deal of Information Technology (defined last week as the use of computers and software to convert, store, protect, process, transmit and retrieve data within an organization) will need to be applied and attended to.

Now let us consider two competing steel pipe companies. They both obtain the same raw materials at the same cost. The number and quality of the personnel employed by the two companies is about the same as is their size and infrastructure. Company A takes its IT processes seriously and is constantly seeking to improve and evolve them, whereas, Company B is lackadaisical about its IT claiming “we don’t need to worry about all that tech gobbledygook – we make steel pipes for heaven’s sake!”

Company A utilizing effective Change Management, Configuration Management, Capacity Management, Service Level Management, Supplier Management, Service Continuity Management, Availability Management etc. and implementing improvement initiatives like Six Sigma will enjoy the following benefits over Company B:

• Improved resource utilization


• Decrease in defects/rework


• Elimination of redundant work


• Improved project deliverables including schedule


• Improved availability, reliability and security of IT services


• Improved service quality which translates into improved finished product quality (superior IT provided to the pipe manufacturing dept results in superior pipes being manufactured)


• Services aligned to customer demands which leads to improved customer satisfaction


• Integration of central processes


• Effective documentation and common terminology that helps with repeatability


• Effective metrics that help in understanding the status of processes and production in the organization


• Continuous process, product and service improvement

All other factors being equal, (cost of raw material etc.) this will then translate into higher sales and increased profits for Company A.

So it becomes apparent that even in a “non-IT” organization like a steel pipe manufacturing firm, IT processes and their constant improvement are crucial ways to gain a competitive advantage. And in a case of highly technical IT companies like Microsoft, Adobe, Wipro etc. the importance of IT processes and their improvement is even more significant. The difference between a Microsoft and our steel pipe company is that not only does Microsoft’s IT have to service its internal customers, it creates products and services for external customers as well. The IT at the steel pipe company only services the internal customers (i.e. the various departments within the organization). Other than that, the IT departments are the same in what they fundamentally do in both organizations.

It is usually a surprise to most folks that the ITIL body of knowledge was first implemented in a significant way by the hotel/hospitality and airline industries. After gaining maturity and delivering positive results while being utilized by these industries, the IT world caught on and began to implement ITIL more seriously. This is not surprising when you consider that the goal of ITIL is to align IT with the business and to constantly improve processes and services being provided.

To summarize, IT process improvement is a significant technique that all companies that have evolved beyond manila folders and calculators must utilize to stay competitive.

Awareness

Welcome to the first posting of the IT Process Improvement blog. My goal in publishing this blog is to provide a site where we may share our experiences, learn what’s new, and network with like-minded folks. Experts, novices and everyone in between are welcome to participate and contribute with their perspectives, questions and comments. My posts will vary in technical depth and subject coverage depending on the topic of the post but I will attempt to compose the posts in a way that everyone benefits from the read. Feedback is welcome at viveks@comwick.com.

The title and central theme of this blog site is “IT Process Improvement”, but what do these words really mean? It would behoove us to fully comprehend and understand the significance and implications of this much used but much misunderstood phrase.

“IT” or “Information Technology” is defined by the Information Technology Association of America (ITAA) as “the study, design, development, implementation, support or management of computer based information systems, particularly software applications and computer hardware”. But what do we mean by “information systems”? “Information systems” refer to a system of persons, tools, data records and activities that process data and information in an organization. Therefore, “IT” can be thought of as the use of computers and software to convert, store, protect, process, transmit and retrieve data within an organization.

“Process” as defined in the ITIL (IT Infrastructure Library) body of knowledge is “a structured set of activities designed to accomplish a specific objective”. ITIL further explains that correctly defined processes are measurable, provide specific results, are customer-centric and are traceable to a specific trigger.

“Improvement” as defined by the dictionary is “a change or modification by which a more valuable or desirable condition is achieved”.

So now that we have clarity on each of the individual words, putting it together we may state that “IT Process Improvement” may be defined as “changes and modifications made to a structured set of activities that organizations utilize to manipulate their data utilizing computer software and hardware, that results in value being added to the activities” Or to put it more simply, the goal of IT process improvement is to add value to the organization and its customers by modifying the activities carried out by the organization to achieve its goals.

I had stated earlier that this is a much used but misunderstood phrase. It is much used because management in general and senior management in particular wants to “improve their processes” and be in a “state of continuous improvement”. Their attempts to implement the various process techniques and methodologies then create buzzwords that circulate around the water-coolers and cubicles of the organization. However, companies are rarely successful with their process improvement attempts and most of these well-meant undertakings peter out like poorly maintained jalopies. And this is where the “much misunderstood” statement comes in. Management must be clear right from the beginning about what their goals regarding process improvement are, what they plan to achieve and in what time period, what the costs and impacts to the business will be and the steps that they will take to achieve this. The staff of the organization should be educated on the process model to be followed and the benefits of implementation to the organization as well as to their own work lives emphasized. My experience with attempting to implement IT process improvements in the past has ALWAYS run into these two snags:

1. Unrealistic expectations of the process implementation and its benefits by Senior Management.



2. Resistance by the staff due to:


1. generic resistance to change (inertia, apathy, laziness) and



2. fear of a negative impact on their career and status in the organization if their work should actually be measured and metrics reported.

On the other hand, competition is intense. Perhaps more so in IT than in any other industry in the history of the world. Those that do not change and change fast, simply die. This has been more than validated in the current recession/depression ensuing worldwide. A point that is being made clear by the spate of bankruptcies and layoffs manifesting worldwide is that companies that did not position themselves to be extremely competitive are paying the price. Not staying competitive was never an option and IT process improvement which was generally considered a luxury by both IT and business decision makers has been proven to be a necessity. It was never a luxury in the past and never will be in the future, either. In reality it is an indispensible way that any organization can gain a significant advantage over its competitor in cost-control, superior product design and service delivery and customer satisfaction which obviously translates into increased sales and increased profits. Details of how IT process improvement creates a competitive edge will be addressed in future posts.

So the conundrum we have here is that a state of continuous improvement must be attained if an organization wishes to survive and yet achieving this state of “continuous improvement” requires more than just studying the process techniques or even attaining a certification or two. It takes AWARENESS. Awareness of the need to improve, awareness of the tools, techniques and methodologies out there. Awareness of the roadblocks that one will almost certainly encounter along the way. Awareness by the staff and employees that this is not a way for them to lose their jobs but a necessary part of everyday life to simply exist. And this awareness must exist at every level of the organization for the improvement initiative to be successful.

Hence my desire to publish this blog; I hope that in doing so, I will steadily, week by week, reach out to the IT community and increase the levels of awareness out there so that IT process improvement will be a much more accepted and successful undertaking carried out by organizations worldwide. Fortunately, forward thinking organizations such as SEI, ASQ, PMI, OGC, IFPUG etc. provide a rich source of knowledge and tools for use by IT professionals to stay competitive. Stay tuned for awareness of these techniques and more in future posts at the “IT Process Improvement” blog.