Leadership Oblige

Leadership is crucial to the success of any organization. It is even more pivotal in the case of guiding organizations through changes and improvements due to the resistance typical in such endeavors.

The textbook definition of leadership is that it is “a process by which a person influences others to accomplish an objective and directs the organization in a way that makes it more cohesive and coherent”.

While this provides a high level description of the duties of a leader, how does one go about successfully performing this role? And more relevant to us at this site, how does one perform leadership duties in order to successfully implement IT process improvements?

There are many attributes that a successful leader must possess. They include ethics, beliefs, values, character, knowledge and skills. All these skills can be learnt and practiced by virtually anyone. However, it is very rare that individuals who find themselves in leadership roles seek out the characteristics of a good leader and attempt to mold themselves in that way. The few that do tend to get caught up in the bog of “bossing people about” and end up losing track of the “inspiration” part of the role.

My goal with this post is not to go in to depth on the theory of what constitutes exemplary IT leadership. There are many resources on the net that will cater to that. I would like to share with you some of my own experiences and anecdotes to illustrate leadership qualities that are outstanding.

A leadership example, albeit fictional, that stands out in my mind is something I saw while reading Frank Miller’s graphic novel “300”. This is the award winning graphic novel that the film starring Gerard Butler was based on (and follows quite faithfully). There is a panel depicting the fight between the Spartans and the Persians in the narrow pass that is advantageous to the Spartans. The bodyguards of King Leonidas are depicted thinking “We’d fret for our King – if we could just keep up with him” as their King fights several paces ahead of them thanks to his superior fitness and fighting abilities, unprotected by his bodyguards, as they are unable to keep up with him. What struck me about this depiction of the Spartans and their leader is that not only do the Spartans love their King and are willing to risk their lives for him (a rarity in the IT world for starters), his talents and skills are so far beyond theirs that they are unable to assist him even though they wish to. How often do we see something like this in today’s world? Perhaps that is why the 300 Spartans and their King are immortalized in legend while today’s leaders are immortalized in corporate scandal.

In my own experience, working and consulting at various organizations, a disturbing characteristic I saw time and over again was the manager’s descent into “policeman mode”. This consisted of unnecessarily elaborate monitoring of employee entry and exit times as well as breaks and time away from the desk. More than necessary monitoring of internet activity as well as conversations with coworkers was also a characteristic of this state of affairs. Of course, such measures are necessary and appropriate in the event of an employee underperforming or abusing his privileges. However, these manager’s entire time was spent in this type of paranoid patrolling. Needless to say, processes at these organizations were minimal and the maturity was extremely low. The talent and skill levels of these so-called managers was laughable as was their knowledge level of what was current in the industry. Coincidence? I don't think so.

My interpretation of this situation is that the “paranoid police man act” stems primarily from inadequate knowledge and awareness of the correct managerial and technical duties that are expected from a leader. . In the rapidly changing world of IT, a great deal of effort must be undertaken on everybody’s part to keep current. It is, therefore, easy for people to slip and fall behind in the chase to keep up with current methodologies and techniques. What happens next is that since there is a lack of knowledge on the correct actions to be undertaken, the only thing left to do for the manager is to perform a large amount of monitoring of his employees.

Another common pitfall I repeatedly see IT leaders fall in, is the tendency to jump from one band-aid solution to another as opposed to determining a feasible long term strategy and sticking with it. Well established processes will be of no use if top management comes in and changes everything at the last minute. Occasional emergencies do occur but if you are having emergencies every day then you need to reconsider your entire approach from the top down. Very often, the business forces IT to change projects midstream which causes havoc with scheduling and capacity management. The probability of introduction of defects in the product or service also increases. The business as well as IT must work in cohesion to create an atmosphere that allows for high maturity and stability within the organization. Perhaps the business would be well advised to take a slower and steadier approach to gaining market share than a rapidly shifting and chaotic marketing approach.

Over and above these two main duties (that are often mishandled), the responsibilities of IT leadership are:

• Championing the cause of IT Processes and their improvement


• Fostering a culture of staff commitment and understanding for IT Process Improvement


• Ensuring training at all levels


• Providing resources for IT Process Improvement from the board


• Setting realistic goals including a reasonable schedule and not attempting to change everything all at once

In Victorian times the aristocracy was expected to take responsibility for their privileges by performing acts of kindness towards the less fortunate. The term used to summarize this concept was “noblesse oblige”. In today’s day and age, it is time for leaders to understand the concept of “leadership oblige” that has been outlined above.

Process Interaction

Integrating a process with the rest of the organization so that it interacts correctly with stakeholders and projects is just as critical as the architecture of the process itself. In my last post, I had detailed some of the significant characteristics of the process’s structure. In this complementary post, I will conclude the explanation of the characteristics of a process by clarifying the interaction of a process with its environment.

As mentioned in the previous post, a process can be likened to a programming language function call. What is interesting to note is that in a typical organization, there will be multiple calls on the process for completion of a task. For example, Project 1, Project 2 and Project 3 might each require a change to be performed. They will each request the change management process to perform the change requests. Therefore, the change management process will have 3 separate instances of change management in progress simultaneously. This is why the existence of a process owner is necessary for each process. In the case of change management, the change manager will ensure that each of the three instances of the process complete satisfactorily.

The change manager will not necessarily be a subject matter expert on the content of the changes being made but will ensure that the steps to be performed as part of change management are dutifully acted out. The project manager or service manager (as ITIL prefers it) will be the one to take care of subject matter details regarding the changes. In a similar fashion, all the other processes will have a process owner to ensure that the process is adhered to correctly. The project/service owners will generally have their project’s benefit at heart and will be only too happy to sidestep parts of the process in order to speed up their task’s completion. To prevent this return to chaos and inefficiency, the process owner will tend to have to perform a “policing” role within his jurisdiction. The process owner will also be responsible for the setup and maintenance of tools and databases utilized by the process such as a change management database or a CMDB (configuration management database) utilized by configuration management.

Another important point to be noted is that a process may transpire in a one-time fashion or in a continuous fashion. For example, the availability management process at an internet service provider will continuously scan for failure in the service availability. This is an example of a process in its “continuous” incarnation. In spite of the continuous monitoring, the service being provided may fail and cause disruptions to the customer. In this case, availability management will interact with problem management and other processes to provide a solution. This would be a “one-time” example of the availability management process in action.

To sum all this up, let us consider the introduction of a new service in a high maturity organization utilizing well defined processes.

To begin with, a strategy for the new service will have to be defined. The execution of the Service Portfolio Management, Demand Management and Financial Management processes will be the appropriate starting processes to be executed. The results of these processes will provide an alignment of the new service to the value it creates for the customer, financial estimates and an understanding of the pattern of business activity that will help in determining the demand by the customer for the service. Repeated iterations of the processes may have to be run before final data is established.

After the strategizing is completed, the design of the service may be instigated. The Service Level Management, Service Catalogue Management, Availability Management, Capacity Management, Information Security Management and Service Continuity Management processes will be executed. These processes will utilize the outputs of the previous processes as their input and produce SLA, OLA, Service Design Packages, capacity, availability, security and continuity plans. As before, repeated iterations of these processes may need to be executed before final information and products are achieved. The service is typically fully designed and ready for deployment at this stage.

To transition the service to the customer environment, the Configuration Management and Release and Deployment Management process will be executed. Again multiple iterations of these processes may need to be executed before a final successful deployment is achieved.

Simultaneously, the Change Management process may be executed as needed right from the beginning of the strategizing in order to manage and record changes being made.

Once the customer is utilizing the service, Incident Management, Problem Management and Request Fulfillment processes will be invoked to maintain the service at the agreed upon levels for the customer. In the event of modifications to the design of the service being needed to be made, the strategy, design and transition processes may be re-executed to provide that change.

This simplified description of the sequence of process executions necessary to introduce a new service to the customer illustrates the methodology of the process-oriented approach. It may be observed that no individual steps were executed. Rather all required steps were part of well defined processes that were called when required. This is the paradigm shift from the old technique of executing steps when needed to the new way of calling a function when a task is required to be performed.

Therefore, for an organization to successfully implement a process oriented methodology, the design of the process as well as the setup of the process’s interaction must be carefully carried out. The sooner organizations make a shift to the new paradigm, the sooner they will enjoy the benefits of higher maturity and stability.

Process Structure

All processes share certain basic characteristics. However, this is rarely understood properly by most people responsible for defining processes in organizations. In this post, I would like to point out certain important characteristics that all processes possess that everyone should be aware of.

In my first post, I had presented ITIL’s definition of a process as “a structured set of activities designed to accomplish a specific objective”. In this post, I would like to expand on this definition and provide more details of the characteristics of processes.

To start with, let us ask ourselves why should a process exist at all in the first place? If we were to look at accomplishing a task or a project in an organization, the task or project would be broken down into a series of steps. The PMI body of knowledge acknowledges this as the Work Breakdown Structure (WBS). Therefore, pursuing this line of thought, all we need to do is perform the steps and, hey presto, we have our project completed. Where does a process come into this then? Indeed, low maturity organizations do go about their business in the manner I have defined above. While it is true that certain steps need to be performed to accomplish an objective, there is a low maturity way of performing a step and a high maturity way of performing a step. When properly defined processes are utilized in performing the steps, the steps are accomplished in a mature way.

To illustrate my point let us consider making a change in an organization. Whether we use a process or not, the key step that has to be performed is the “Making the Change” step. In an organization that does not utilize processes, people simply charge in like rampaging bulls in the proverbial china shop and perform the step of “Making the Change”. In an organization where a change management process exists, the step of “Making the Change” is part of a sequence of steps that are performed when the change management process is called. The phenomenon is not unlike a function call in the C++ programming language. For example, when one needs something to be printed on the screen, the “printf” function is called with the text that needs to be shown on the screen. In a similar fashion the change management process is “called” with the details of the change to be made as its input. The output of the change management process is the completed change, the results of the change and other pre-specified metrics.

While it is not entirely accurate to compare a process to a programming language function call, it is useful to illustrate how a process works. A process is simply a predetermined sequence of steps that accomplish an objective. However, because they are predetermined, there is a certain stability and repeatability associated. In the previous example, when changes were being performed without a process, the success of the change was heavily dependent on the staff performing the change. However, in the case of the organization with the change management process, as long as the staff were capable of performing the steps outlined in the process, the success of the process was largely independent of their competence level. Also, with processes in place, the metrics defined as part of the process’s output will automatically be generated. In the case of no defined process, if the staff do not collect any metrics, no metrics will be produced at the conclusion of the step.

Having understood the correct methodology of process implementation in an organization, let us study the structure of a process.

To begin, every process has a trigger that starts off the process. In the example of the change management process, the trigger might be the submission of a change request.

A process also has inputs and outputs. The inputs can be information that is required to perform the process and the output can be a finished product or data that has been updated. Outputs can also include reports and reviews. The reports usually include metrics relevant to the process.

The structure of a process can then be further subdivided into 3 groups: Process Control, The Process itself and the Process Enablers. The figure below illustrates the information presented thus far (click on the picture for a larger view).

Process enablers consist of the resources, tools and other capabilities that are required to perform the process. This includes people, hardware, software, office space, knowledge, experience and any other resource that might be required to successfully implement the process.

Process Control is an important part of a process. It consists of the resources and framework required to monitor the process and make modifications if necessary. A process owner is part of the process control segment of a process and is responsible for the overall functioning and quality of the process. Other process control components are documentation, policy and process objectives.

The process itself consists of activities, procedures, roles and responsibilities, work instructions and metrics. This is where the actual steps of the process are carried out.

There are certain fundamental characteristics of all processes. They are listed as follows:

• A process ultimately creates value for the organization


• A process is based on certain predefined objectives


• A process is started by a trigger event and takes one or more inputs and delivers defined outputs


• A process once defined and setup should then provide repeatable results


• A process should have the ability to take corrective action based on feedback, if required

It is, therefore, evident that the setting up of processes is no small task. The organization that spends adequate thought and effort in planning and setting up their processes will be rewarded with an efficient and harmonious work environment. If organizations ignore processes and simply charge in with a “sequence of steps” type of attitude they will endure numerous problems, delays, defects and customer dissatisfaction.

It is rare, however, that processes are correctly structured and deployed in most organizations. It is the authors hope that this blog site will assist in spreading awareness and contribute towards a paradigm shift towards greater organizational maturity.

Evolution of best practices

I would like to begin by thanking all of you who have contributed to this blog by posting comments and sending me feedback. It is your involvement that will make this blog site a successful venue of knowledge, networking and new ideas. So please feel free to contribute with your comments, questions and feedback as well as suggestions for topics for future posts.

A suggestion I have for making maximum use of this blog is to research on the net what may be new to you that I mention in my posts. The same is true for anything that you may not fully understand. While I strive to express myself in as lucid a manner as possible, it is well beyond the scope of a blog site to provide extensive training in technical issues. A great deal of information is quite easily and freely available for your perusal on the internet.

For this week’s post, I would like to present my thoughts on the evolution of process standards and the subsequent need for us to be constantly learning and updating our skills.

An interesting fact that most people are not aware of is that IT is a relatively young industry. When compared to the automobile industry which has been around for about 150 years or steel manufacturing which has been around for centuries, we can appreciate the relative immaturity of the IT industry.

It was merely a few decades ago that the company destined to be Apple Inc was being operated in a garage by two men with vision (Steve Wozniak and Steve Jobs). Clearly they were not following Six Sigma or CMMI in their garage office at that time. So, in spite of the chaos and inefficiency that is synonymous with IT, the industry has come a long way in a short time. A little known fact is that all industries have been through an initial period of chaos and confusion during their youth. It is, therefore, entirely natural that the IT industry faces the challenges that it does today. However, it is up to us, its practitioners, to guide it through its immaturity to more stable times. This can only be accomplished by constant learning and application on our part.The dynamics of the evolution of process standards is shown in the figure below (as always, please click the picture for a larger view).

It all starts with an organization’s desire to rise above the competition. This results in innovative techniques being researched and developed. Organizations might also collaborate with academic bodies that conduct the relevant research (e.g. the SEI at Carnegie-Mellon University) and other professional institutions (PMI, ASQ, etc.).
If experimental implementations of these innovative techniques yields positive results, the techniques are put into practice on a regular basis at that organization. Typically at this stage, only a few organizations have adopted these techniques on a regular basis. The techniques are called “best practices” at this time.

Over time, other organizations also adopt these techniques which are then known as “good practices” or “generally accepted principles”. They might even be adopted by governments and other regulatory bodies as “regulatory requirements”.
Finally, the techniques are widely implemented and commonplace. At this stage, they are known as “ordinary traits” and are usually taken for granted by all stakeholders including customers.

In order to rise above the competition (since everyone is now implementing these “ordinary traits”), organizations research and develop new techniques. The process, in this fashion, continues endlessly.

We see this phenomenon in practice with popular certifications: ITIL has recently switched from version 2 to version 3 and no doubt there will be versions 4 and 5 in the future. Most certifications expire after 3 years for this very reason. Also, organizations with their own proprietary methodologies regularly improve and update with the passage of time.

All this indicates one very simple reality: all IT professionals must keep constantly learning and updating their knowledge and skills. While this may be disgruntling to some who thought that their education was complete after their college commencement ceremony, fact is that constant learning has to be a part if life for all. My suggestion is to take on this obligation positively with an attitude of fun and curiosity at what’s new in the world of IT processes. This is the way, I, myself have studied and improved over the years.

By making it fun.

And I invite you to do the same.