IT Process Improvement

After the Victory

2011-01-02T19:46:00.000-08:00

So, let us imagine that we have successfully implemented a process improvement. Victory at last! What may surprise many readers is that the improvement effort has not completed yet. In fact, a large percentage of successful process improvement efforts slide back to square one after the improvement has been made and the effort declared a success.

Let us take a closer look at this phenomenon. What typically happens after a successful improvement effort is that the improvement team or specialist gets moved to another improvement effort. Upper management, too, lessen their attention on the team that was undergoing the improvement. This results in the recently improved team or department in a fledgling state and very susceptible to moving back to their old (bad) habits. Furthermore, they may not be entirely comfortable with the analysis and effort required and without the specialist’s presence may end up spending excessive time and effort on what should be quick and easy. This in turn gravitates the team members to go back to their old ways.

To ensure that this does not happen, even after an improvement effort is declared a success, lines of communication between leadership, the improvement specialists and the team being improved must remain open. Regular checkups with the team should be performed by the improvement specialists albeit less frequently. An improvement effort is not an on/off switch but rather a living, breathing thing that must be properly cared for.

The Cubicle Shuffle

2010-12-19T20:13:00.000-08:00

At my client organization’s offices, an interesting and traumatic event for those affected by it was the usual employee cubicle shuffle, where recently moved people had to box up and shift elsewhere. Now, there are many reasons why such a sequence of events would take place (and sometimes they are out of human hands). Generally, however, this is due to poor resource management.

When folks hear about People Management, they generally think along the lines of motivation and psychological counseling and support. However, the most basic part of the organization is the staff and their management at the most basic level involves management of their shelter and place of work. This repeated cubicle shuffle simply denotes the lack of organizational planning to accommodate the most basic requirements of your most basic components.

Effective people management begins with a CMDB that records not only the basic information about the employee such as cubicle number, email address, phone number etc. but also makes note of their skills and capabilities including past experience and skill sets. Much can be researched and perused on the net regarding this topic, but the magic is in the implementation of it.

The Magnificent Seven

2010-11-29T13:50:00.000-08:00

In the pursuit of quality, it is necessary to utilize techniques to analyze and evaluate metrics in a quality-oriented fashion. There are seven basic techniques that have been utilized for many decades now in the world of quality management. The utilization of these techniques has resulted in organizations making great strides in their quality management efficiency and quality delivered to the customer.

The seven techniques are as follows:

Cause and Effect Diagram (Ishikawa Diagram): This breaks down the possible cause of a variation from specifications into six different areas – People, Methods, Machines, Materials, Measurements and Environment. These can be further subdivided into smaller components. The basic idea is to link these areas to the process in order to evaluate which area (or sub-area) could be causing problems. This can be used proactively to evaluate the process for problems before they happen or reactively to zero in on a problem once it has manifested itself.

Check Sheet: This is a simple document that is used for collecting data in real-time and at the location where the data is generated. The document is typically a blank form that is designed for the quick, easy, and efficient recording of the desired information, which can be either quantitative or qualitative. When the information is quantitative, the check sheet is sometimes called a tally sheet. There are 5 basic types of check sheets: Classification, Location, Frequency, Measurement Scale and Check List.

mean, standard deviation and upper and lower control limits also displayed. If analysis of the control chart indicates that the process is currently under control then data from the process can be used to predict the future performance of the process. If the chart indicates that the process being monitored is not in control, analysis of the chart can help determine the sources of variation, which can then be eliminated to bring the process back into control.

Histogram: A histogram consists of tabular frequencies, shown as adjacent rectangles, erected over discrete intervals (bins), with an area equal to the frequency of the observations in the interval. Histograms are used to plot density of data, and often for density estimation: estimating the probability density function of the underlying variable. The histogram provides insight on the problem (or potential problem) that may be related to the data being plotted.

Pareto Chart: A Pareto chart contains both bars and a line graph, where individual values are represented in descending order by bars, and the cumulative total is represented by the line. The purpose of the Pareto chart is to highlight the most important among a (typically large) set of factors. In quality control, it often represents the most common sources of defects, the highest occurring type of defect, or the most frequent reasons for customer complaints, and so on.

Scatter Diagram: A scatter diagram uses Cartesian co-ordinates to display values for two variables for a set of data. A scatter plot can suggest various kinds of correlations between variables with a certain confidence interval. Correlations may be positive (rising), negative (falling), or null (uncorrelated). If the pattern of dots slopes from lower left to upper right, it suggests a positive correlation between the variables being studied. If the pattern of dots slopes from upper left to lower right, it suggests a negative correlation. A line of best fit (alternatively called 'trend line') can be drawn in order to study the correlation between the variables.

Stratification: Stratification is a technique that separates data gathered from a variety of sources so that patterns can be observed. These patterns can then be further analyzed to zero in on the root cause of the problem.

The seven basic techniques of quality management have been staples in the toolbox of any quality professional for a long time now. It does not take a lot of effort to start utilizing these techniques in your organization quickly and efficiently. There is really no reason why any and every company shouldn’t be using these tools extensively.

Business’ Disappointment

2010-11-16T22:22:00.000-08:00

At my client organization’s offices, while passing through, I overheard two ladies in the marketing team expressing their dissatisfaction with IT and the help desk in particular. I stopped and spoke with them a little bit about what was troubling them. What emerged was the usual lack of quality and support provided by IT for the applications that they use to perform their job functions.

What IT must always keep in the forefront of their minds is that they are ultimately servicing the business. If staff in business cannot access the applications that they require to perform their duties, then this will result in their incapability to bring in new business and increase sales volume. This, in turn, will lower the organization’s competitiveness and damage the brand image. Ultimately, this will result in lower profits and less resources available to all departments including IT.

I have always emphasized that IT is key in today’s times. Most other departments within the typical organization (Sales, Marketing, HR, Accounts etc.) are fairly mature. However, IT is relatively new in that processing information utilizing computers has only been going on for a few decades or so. Sales and marketing have, in their way, been occurring since the dawn of time. What this means is that, generally, IT has the greatest potential for improvement within the organization. A 10% improvement is usually quite easy to achieve in the IT department of most organizations, if not a much higher percentage. If an organization can improve their IT by that amount, it is obvious that they will surge ahead of the competition due to the efficiencies that will be inherent in this improvement to the entire organization. IT is, therefore, the most significant catalyst to an organization’s success nowadays.

It is easy for IT to pigeonhole itself inconstantly putting out fires and only focusing on meeting quarterly numbers. However, this is a short sighted strategy that will hinder the organization and ultimately hurt IT. Constant improvement is not a luxury but a necessity for all of us, especially IT.

Skills Management

2010-11-01T16:56:00.000-07:00

With IT being more knowledge centric and requiring an ever greater array of skill sets to get things done, one of the major challenges facing organizations today is the effective management of skills.

Now the skills can be brought on board in a number of ways. There is the option of acquiring In-House talent a.k.a. Full Time Employees. One could get Contractors (which is essentially the same thing nowadays). Consultants could be brought in as well. And then we have the ever present outsourcing option as well.

It is in the regular evaluation, analysis and relevant action in the area of employee/supplier skill set that the effective management of the organizations skills can be successfully undertaken. The ITIL body of knowledge refers to this as Supplier Management and outlines a strategy of classifying suppliers (which can be said to include employees as well) into long and short term suppliers as well as strategic or commodity suppliers. There are, of course, many different techniques and tools to perform the task of managing the skills and suppliers of the organization and these are readily available online. The focus of this post is to emphasize the need for these techniques and the warning to avoid the trap of forever being in fire-fighting mode and not ever getting to perform this important task.

There are many aspects to IT management. Some tasks are considered “essential” such as the successful completion of a critical project. Other tasks such as Skills Management are generally fall into the “we’ll get to them if we can” category. While the completion of the critical project will keep the lights on for tomorrow, it is the other tasks that distinguish a ordinary organization form a world class one.

The Wisdom Hierarchy

2010-10-11T23:41:00.000-07:00

The Wisdom hierarchy is often mentioned in passing and for a lot of folks is a new topic. It is, however, a great way to gauge the state of an organizations’ (or teams, or even individuals) depth of understanding of a topic.

The components of the Wisdom Hierarchy consist of Data, Information, Knowledge and Wisdom. The first component, Data, is simply that. Usually data is a list of numbers that provide almost no meaning to anyone, unless they are connected in some way to some context. Typically data is unorganized and unprocessed.

Information, the next evolution in the hierarchy, is described as “organized or structured data, which has been processed in such a way that the information now has relevance for a specific purpose or context, and is therefore meaningful, valuable, useful and relevant”.

Knowledge is then derived from information, also applying experiences and insights gained through true cognitive and analytical activity. If someone "memorizes" information, then they have amassed knowledge. This knowledge has useful meaning to them, but it does not provide for, in and of itself, a way to further the knowledge.

Wisdom is the accumulation of the previous levels along with a deep understanding that enables the ability to increase effectiveness.

As readers may have guessed, it is the ability to operate at levels of wisdom that every individual, team and organization should aspire towards. However, how is this to be accomplished? Why, with proper process improvement techniques in place, of course.

The Strategic Plan

2010-09-19T22:51:00.000-07:00

The one thing most companies do not create or work out of is a strategic plan. Now I am not talking about a project plan that should be (and is also usually not properly) created for every project but a master strategic plan for the IT department of the organization. This plan should cover a lot of different issues and plan for the long term growth of the company.

The strategic plan should of course first and foremost define and build upon the relationship between the products and services that a company produces and the utilization of these by its customers. This, in the end is the life blood of any business endeavor whether it is IT or retail sales. Financial management, Demand management and just good old fashioned service strategy must be performed to achieve this.

Of course, technology must be involved to decide what should be researched and developed in the future in order for the organization to be more competitive. Constant technological improvement is the lifeblood of any technological organization or department. This is obvious.

Furthermore, supplier management should also be considered in a longer term role within the overall strategy. Possibly, certain suppliers should be handled as longer term partners while other suppliers have a less intimate relationship with the organization. By the same token, a plan for the staff should be thought of and monitored in order to reduce the dramatic changes brought on people’s lives with changes in their employment status.

In reality all aspects of the organization must be considered at the high level and incorporated in a strategic plan. Individual project plans and so on should be deeper dives in to the overall strategic plan. It is the author’s hope that top management performs strategic planning in a well organized and complete way.

Science is not a Democracy

2010-09-06T18:46:00.000-07:00

This post might be one of the more meaningful and pertinent to today’s times that I have published in a while. A phenomenon that I have observed taking place is the inclusion of people of various different educational backgrounds working together in the same team. Now this brings together Engineers with Sociology, Psychology and English majors (with no technical knowledge or training). What proceeds to generally happen next is a free for all with everyone trying to come up with the answer in order to get the much vaunted promotion.

The answer to 2+2 is 4. It is not 3. It is not 5. And it will never be anything but 4. Even if all the non mathematics majors go on indefinite strike insisting that in their opinion it should be 3, the correct answer will be 4. If you were to throw a ball up in the air, it will eventually reach an apogee after which it will fall back down (real estate owners, are you listening?) to where it was projected from. The world of science is not a democracy. The laws of physics are not open to debate. Yes, you might be able to circumnavigate the law of gravity (for example) utilizing an airplane but even that follows certain laws of aerodynamics of its own. So what I am trying to illustrate here is that there is one right answer in science and countless wrong answers. Science is not like a philosophy paper that you handed your professor in college with the knowledge that you would at least be guaranteed a “C” grade. In science it’s either an “A” or an “F”.

Now let us go back to our scenario of many different expertise levels working together on a project. What I have seen happen often and is a major stumbling block to efficiency is that people who have no clue regarding what the right answer is will insist of speaking “their turn” and forcing their incorrect answer on everyone. If an attempt is made to try and shut these people up, they will instantly round on that person and accuse them of attempting to stifle them and be a “bully”. In extreme cases, the “human rights” of these people will be claimed to have been violated. The manager often ends up playing the role of the judge and a great deal of time and effort is wasted not to mention many times the wrong decision being taken because the English majors were feeling “left out” and the consequences of the wrong decision in terms of defects and rework.

What is really to blame here is the old boys (or old girls) network style of doing things where someone with 10 years of experience in the company has to be taken care of even if they have no knowledge of the position that they are now in. Truly, management needs to handle this situation effectively as what will happen is that the people with expertise will simply leave for better environments to be found at other organizations. Then the company will simply be left with “human rights activists” and zero technical expertise. Management really needs to let people with low technical expertise know what the problem is and to get them to stay out of the way of people with technical expertise.

Sneaking in Improvement

2010-08-23T10:13:00.000-07:00

One thing that I have noticed recently is the tendency of companies to move operations to other states to avoid higher taxes in certain states. This is particularly true of California which has the highest taxes for businesses anywhere in the USA. Of course a similar phenomenon has been going on for years with outsourcing to other countries. Now I am not arguing for or against this type of action as it varies from organization to organization and the specific issues concerning each organization. However what I am suggesting is that process improvement could be sneaked in during these times of upheaval as they create the opportunity to get past the usual petty politics during normal times.

The great thing about times of change that involve cost cutting is that the petty power games get steamrollered over by the change coming through. This lessening of petty power politics allows the organization to employ process improvement methodologies and best practices far more easily than during normal times. Of course care must be taken to balance the implementation of process improvement along with the organizational changes that are taking place. However, in spite of the organizational changes taking place, I feel that there is an opportunity to make positive changes that would be difficult in normal times.

It is sad but true that organizations must sneak in something as important as process improvement when people’s guards are down. Until people’s attitude towards process improvement changes, it will have to be performed in whatever way it can be done.

Petty Little Power Games

2010-08-09T09:12:00.000-07:00

If I could travel back in time, I would among other things (buying Microsoft stock at the right time etc.) ask the titans of Quality (Deming, Crosby, Juran etc.) how they navigated past the petty power struggles.

To clarify what I mean, I was asked recently why best practices are not widely implemented. My answer? “Petty power struggles”. What do I mean by that? Consider an organization that is low maturity and does not implement the best practices out today. Inspite of its low maturity, there is a sort of structure there. People after years of working there have become managers, directors etc. They have a pecking order of sorts. Now consider that a best practice like ITIL is to be implemented at this organization. The first thing about this development that will strike terror in everyone’s heart is the potential damage that this would bring to the various little power structures all over. A person who was a manger may now no longer be one and someone with ITIL certification could possibly be in a more commanding position. This could occur at all different levels across the organization. So how do people respond to this possible threat? By not implementing the best practice and keeping the status quo. If management insists, the “threatened” staff find numerous ways to cause problems, delays and confusion that effectively bring the implementation to a grinding halt. The most common is that the current project that needs to be completed will be delayed if a best practice implementation is to be performed. This effectively frightens the upper management into delaying the implementation until this important project is completed. At this point the game is as good as over. All the staff have to do now is threaten the well being of other projects as they come down the pipeline and the implementation effort is effectively history.

Over and above this, staff can be deliberately difficult, deliberately dense and intentionally make mistakes in the implementation effort to further undermine it. The one thing they usually do not do is study up on it and become experts at it thus ensuring a position of power in the new way of doing things. That would be the obvious and straightforward way of doing things, but human nature being what it is, the more difficult path is generally chosen in order to preserve the present (and inefficient) status quo.

What these obstructers do not realize is that the future will involve best practices whether they like it or not. The only question is how smoothly or otherwise the best practices will be implemented and with what fallout.

Negativity Doesn't Help

2010-07-26T13:19:00.000-07:00

Last year this blog site did quite well at the Computer Weekly IT blog awards for 2009. Out of a sense of curiosity, I went to the blog site of one of the other sites that had done well also to have a look at what they were up to. I was surprised and dismayed that this other site seemed to do nothing besides ridicule and put down ITIL and other methodologies. Now, of course if a scam of some sort exists and someone is spreading the word on that, they are doing the world a favor. However, to mindlessly put down something that has been designed to help seem seems quite pointless.

The interesting part of this for me is that ITIL is quite benign. You can do what you want with it. You can turn around and have nothing to do with it or you could partially implement some of it or you could go the whole hog and really implement all aspects of it to a rigorous level. The choice is up to you. So why blame ITIL? Why the negativity?

It would seem that people will do anything and everything except the right thing. There is no use in either being negative or attacking something that is there to help. Particularly if the choice is in your hands and you can use it or not as you please. My experience has been that any methodology works if implemented correctly and all methodologies fail if implemented incorrectly. So really it’s up to you.

Making Matrixed Work

2010-07-12T07:21:00.000-07:00

The matrixed style of management is becoming more and more popular in IT project and services nowadays. It would also seem that this style will continue to gain popularity in the future as well. However, like anything in this world, there are advantages and disadvantages to this style of management and there can be problems with this approach if the potential negatives are not handled correctly.

The matrixed style can basically be summarized as the selection of staff from a function or bench to perform tasks in a project which upon completion results in their returning to their function or bench to await subsequent deployment. The advantages of this are:

Much greater agility, especially when the organization has to handle multiple projects simultaneously

Individuals can be chosen according to the needs of the project

Greater individual contribution as the staff members of a matrixed environment have each been chosen for their specific skill set

Project managers have greater autonomy and control over the project management

The disadvantages of the matrixed environment are:

Conflict between the home department and the project for staff members

Difficulty in managing the project of the project manager does not have enough power

Staff morale is reduced due to stress of having to find another project to work on

The matrixed environment is attractive because the disadvantages can be managed leaving the organization to reap the benefits of the advantages. So what can be done to ensure that the matrixed environment can work? Some suggestions are:

Identifying team members and ensuring the proper line of command over them is established to disallow any chance of conflicting work assignments

Establishing effective communication channels. This is crucial because the staff members will be getting potentially conflicting information from their “home’ departments. Therefore, communication has to be extremely solid

Effective project information dissemination. The matrixed structure offers a higher potential of staff not getting the information that they should get regarding the project. This should be thought about and planned for right from the beginning

Of course much more information regarding the structure and management of matrixed organization exists and the interested reader can research this online. It is just a shame to me that a efficient way of doing things gets a bad name simply because of the simple avoidance of some the pitfalls.

The Point of Statistics

2010-07-05T21:12:00.000-07:00

Out and about in the world of IT, I tend to see a great deal of variety as I meet with different organizations and individuals. One thing that a lot of people (especially without a technical background) tend to be unclear about is the basic reason for the existence of statistics. Improvement initiatives like Six Sigma rely heavily on statistics and it is a good idea for those weak in this area to strengthen up and learn a bit more about it. The purpose of this week’s post is to get folks started with a high level summary of the topic and those that are interested can research the topic further online.

Statistics exists mainly because you cannot measure everything. Let me illustrate this with an example. Let us assume that I own a paper clip manufacturing company. Now this company is manufacturing one million paper clips a day utilizing four different machines. Can I measure and test each of the million paper clips being produced every day? I would require a staff of at least 10,000 to do that which would drive me into a loss making state very quickly. So what do I do? I take a “sample” of the 1,000,000 clips being produced (also known as the “population”). The derivation of the sample could be performed in many thought provoking ways. As there are four machines, perhaps a sample of 1,000 clips could be taken from each machine on the hour every hour for a total of 32,000 clips to be tested for defects. This way if a particular machine is malfunctioning, it will be quickly and easily spotted. Of course, there are many permutations and combinations of deriving the sample units from the population, this being only one of many.

Astute readers will have noticed one problem with all of this and it is the following: we produced 1,000,000 paper clips and we only tested 32,000. How do we know that this sample accurately represented the population? What if we only tested the 32,000 that were good and the remaining 968,000 are bad? And this is where statistics helps us. Not only can we perform useful operations like mean, median and standard deviation on our sample, we can use statistical techniques to tell us how accurately the sample’s data co-relates to the population itself. So, in our example, we can say that the sample of 32,000 turned out to be 98% defect free and we are 90% sure that the remaining units of the rest are the population also are 98% defect free. This, ability to predict quality levels of the units that were never tested is the chief strength of statistics and the various techniques of statistics that exist. Of course there are other applications of statistics, but this is the primary one.

I speak of statistics this week because it is about time that IT organizations start utilizing all the tools available to them through this discipline and improving their efficiency. There are organizations that utilize function points and advanced statistical techniques in a big way and they are at levels of efficiency that are going to be very hard to beat. It’s time for the others to get going.

The Love of Ad-Hoc

2010-06-22T12:05:00.000-07:00

I was yet again exposed last week to an instance of an organization performing their tasks in an ad-hoc style. I see this seemingly in built preference to ad-hoc so often that it strikes me as remarkable. While there should be a consideration towards reduction of cost and efficiency and optimization, ad-hoc is not the path to effective cost cutting, efficiency or optimization. A lot of work is required for achieving these 3 characteristics and simply avoiding any effort at structuring the way things are performed is not beneficial in any way.

And yet, ad-hoc is so prevalent even today. From an ad-hoc style of gathering requirements to an ad hoc style of designing, developing and testing, the ad-hoc way seems quite ubiquitous. Why is this? I think that it really just boils down to laziness and inertia. Sure, there is some measure of ignorance and lack of awareness of the current best practices out there, but this, too, can be finally attributed to laziness. Perhaps the feeling of comfort that comes from leaving things alone is also a factor. “Don’t fix it if it isn’t broken” seems to be the mantra of safety. However, the problem with this is that your competition isn’t leaving well enough alone. The competition is marching forward and if you don’t you will be left in the dust.

Hoshin Kanri

2010-06-14T21:20:00.000-07:00

After postings of a more philosophical nature, let us delve into the nuts and bolts of IT process improvement with Hoshin Kanri. In Japanese, “hoshin” means shining metal, compass, or pointing the direction and “kanri” means management or control. The name describes the alignment an organization towards accomplishing a goal through effective planning.

Hoshin Kanri links the high level executive goals and objectives to increasingly lower levels of management and activities until the lowest level activity is aligned to the organization’s overall objectives.

At the beginning of the Hoshin Planning process, top management sets the overall vision and the annual high-level policies and targets for the company. At each level moving downward, managers and employees participate in the definition—from the overall vision and their annual targets—of the strategy and detailed action plan they will use to attain their targets. They also define the measures that will be used to demonstrate that they have successfully achieved their targets. Then, targets, in turn are passed on to the next level down. Regular reviews take place to identify progress and problems, and to initiate corrective action.

The levels of activity from high to low are:

Corporate level objectives

Service level Objectives

Functional Objectives

Team Objectives

Specific Activities, Goals & Resources

The advantage of this type of setup is that not only is the organization aligned towards high level objective but it is also very well positioned to quickly make adjustments to change in strategy. That is, a higher degree of agility and ability to rapidly change will be introduced. A better setup of accountability will also exist with Hoshin Kanri.

Hoshin Kanri is another tactical advantage an organization can give itself. It is not an end-all or be-all but it can help optimize things further. The interested reader can find out more about this technique online.

The Trust Factor

2010-06-08T21:29:00.000-07:00

As I spend more and more time and effort promoting the implementation of best practices, it emerges, more and more that the first and most important step is trust. Trust in the person giving advice and recommendation, trust in the process methodologies and finally trust in themselves: that they can implement the best practices successfully.

Usually all three areas of trust are missing. This then requires the process of gaining trust from people and the organization. However, trust is something that has to be earned and typically earned over time. Consistent reliable, dependable performance over time is usually what builds trust. This can be done to achieve the trust required but can an organization afford the time required for this trust to fall in place? The time involved could easily be months, perhaps years. By this time, the competition could have implemented these strategies and best practices and moved far ahead in the race.

Therefore, it is necessary that organizations and people quickly gain trust in what is best for them. This, however, is something they must decide. And there we have the Catch-22. How do they decide what is right for them when they don’t trust it? The only way out of this quandary is awareness and education. Become more aware of the best practices out there and the ability to make the right choices will get a lot easier.

The conclusion is that a higher degree of awareness and knowledge is needed to have the right level of trust for the right technique. Those who do not improve continuously will pay the price for their lackadaisical attitude.

Decisive Action

2010-05-31T09:37:00.000-07:00

There are far too many people out there, at all levels, from top management to entry level, that are allergic to taking decisive action. Now a decisive action does not mean a stupid action. It does not mean an improperly thought out, unplanned, immature action. I mean the type of action where a stand of some sort is made and held to instead of the typical wishy-washy let’s stay forever safe and not get anywhere type of fence sitting that has resulted in the IT industry being so chaotic and unstructured.

Not every minute of every day is going to require decisive action. But when the need for such action is required, it is imperative that it be taken. Perhaps the greatest general ever, Napoleon Bonaparte, was famous for taking decisive actions that would alter the course of history, sometimes in the thick of battle. What he is less famous for is the huge amount of planning and preparation he went through prior to his decision making. The result? A legend, who almost took over all of Europe.

Now, we in our cubicles and offices need not worry about being a Napoleon, making life or death decisions, but the principle remains the same as does the benefit. So how does all this apply to IT Process Improvement? To cite just one example, when a decision to implement a methodology is made, it should be implemented with a decisive, do or die energy. Now this does not mean that it should not be carefully monitored and course corrections taken. This does not mean that risk analysis and mitigation be not performed. It does mean that we don’t give up at the first obstacle that comes by or worse even not take the decision to implement an improvement in the first place. Even an entry level person in his cubicle can apply decisive action taking in small and measured ways. Of course, if the organizational culture is one of non-decisiveness then it may be best to be discrete in this aspect as I can testify by my own experiences. This is an ideology that is most effective when applied by the senior management and it naturally trickles down to the lower levels as the organizational culture becomes imbued with a certain fearlessness.

Plan carefully and then take decisive action. This has always been the way of the truly successful.

The Unwanted Stepchild

2010-05-24T07:35:00.000-07:00

Speaking with a client last week, I was yet again made to realize the lack of emphasis placed on continual improvement at all levels within the organization. The roles in their organization were based on frantic attempts to make it through the day with essentially no emphasis on any sort of improvement initiatives. It would seem that improvement is considered the stepchild in most IT organizations. And yet this is the most effective long term strategy an organization can employ to get ahead of the competition.

Oh sure, there is a conceptual agreement that there should always be continual improvement. However, when the rubber hits the road, it all falls apart. Why is this?

Mostly, it’s a lack of commitment and follow-through at all levels within the organization. Lack of planning and not keeping up with changing techniques and methodologies is also to blame. Perhaps most telling of all is what I hear consistently that not all new methodologies are “good”. Or just because some governing body has released a new body of knowledge, it is not necessary to implement it. Perhaps so, but it is surely necessary to be aware of it and at least consider it. On this topic, I would like to emphasize that most reputable governing bodies (PMI, ASQ, QAI etc.) have very deeply field tested bodies of knowledge. These techniques and methodologies were created by academics and industry professionals and then utilized in the field numerous times before even being brought to the public. Most people are unaware that ITIL is over 21 years old. Things don’t stay around for 21 years in the IT industry unless there is something to them.

The fact of the matter is that there are a huge number of improvement tools, techniques and methodologies out there. But the desire to implement all this needs to be realized. Until then, continual improvement will remain an unwanted stepchild.

Sifting Through the Avalanche

2010-05-17T08:24:00.000-07:00

With the topic of age and leadership analyzed to death in the last couple of weeks, an issue that came up repeatedly was is there really a necessity for constant learning by everyone. The challenging thing about this issue is that there is a huge volume of information and change coming at us all at the speed of light. So how do we sift through this vast amount of information in a way that most benefits us? Clearly, we cannot ignore all this information and do nothing. And yet it is humanely impossible for one person to learn everything. So what is the answer?

The most obvious starting point would be to specialize in one’s area of expertise. This means that a Project Manager should pay special attention to the changes in tools, techniques and methodologies that are occurring in the area of project management and to ensure that they learnt what was important and relevant to them. However, staying current in one’s area of specialization is the bare minimum required nowadays.

It is at this point that the IT professional must choose where they wish to move towards in terms of their career and longer term goals and keep current with that. Also, one area that most IT professionals would do well to master is the use of proper terminology and an awareness of what the industry standard is even if it is not utilized at their place of work. A higher level learning of overall management techniques such as ITIL and CMMI may also be a good idea, irrespective of specialization.

Over and above this, folks will want to keep up with the culture of the times which is changing all the time as well. It was not very long ago that Facebook, Twitter and MySpace were pretty much unheard of. Now Facebook has overtaken Google for the number of hits worldwide. Clearly this is something both individuals and organizations must keep abreast of now.

It’s getting to be so that constant learning is now a mandatory part of our lives. It’s a question of how smart we can be about it. Like anything else it’s going to be a challenge of getting the most bang for the buck, or in this case, time.

Age and Leadership 2 – Stayin’ Hip

2010-05-10T14:34:00.000-07:00

Last week’s post on age and leadership sparked some lively debate on various discussion boards. The range of issues brought forward by various people and their points of view resulted in a continuation of the topic with this week’s post. Many thanks to the people who posted their point of view and sparked debate and discussion. After all that is what a blog is all about.

Let us start at the beginning. As IT projects usually start with requirements definition, let us also start with the requirements necessary for leadership positions. After all how can we discuss the effect that age has on leadership abilities when the leadership abilities themselves are undefined? Some of the criteria for effective leadership are:

Communication skills

Problem solving skills

Adaptability to change

Time management

Stress management

Interpersonal relations and teamwork

Ability to set goals and articulate a vision

Managing conflict

This is, of course, not a comprehensive list, but it does cover most of the criteria. The interesting thing about this list is that it has been true and relatively unchanged for millennia. So how does the current age of information and technology affect these criteria? How are these issues affected by the fact that we are in the year 2010?

Adaptability to change has never been as important and that too, at all levels. Market changes, customer preference changes, technology changes, methodology changes, tools and technique changes are all occurring at incredible speed. Of course not all changes are necessary or even good. However, the ability to make the decision on which change to implement is necessary and this can only be achieved by being very well informed and in touch with what is current.

Furthermore, all the other criteria now require knowledge of the latest tools and techniques to accomplish effectively. Time management is not possible without the latest handheld device and mail, VoIP and other technologies today.

For true leadership, the ability to read the future, i.e. the visionary capability, is impossible without a thorough understanding of the market and the culture of the times, which is vastly different from just 10 years ago. I, myself, have to keep going to urbandictionary.com to lookup words that did not exist a few years ago.

So what emerges is that a great deal of extra effort is required by all professionals nowadays and senior management in particular to keep up with all that is necessary to perform their duties effectively. What steps could be taken to achieve these leadership abilities relevant to our times? Some effective steps that can be undertaken are:

Constant learning (or at the least, awareness) of new technology and methodologies

Regular association with younger people and observance of their activities

Staying current of the "lingo" used nowadays (which is a job in and of itself)

Being open to change and constantly adapting to the new changes in technology AND culture.

In my opinion, the professional who performs these steps will be useful irrespective of age. Even an 18 year old who fails to perform these steps will be obsolete. Perhaps the moral of the story is that we must remain in a state of constant learning more than ever before.

Age and Leadership

2010-05-03T09:39:00.000-07:00

Top executives tend to be on the older side and this for the most part makes sense. After all they have accumulated years of experience and this must surely translate to an effective implementation of said experience to drive the company to new heights. Or does it? Could we have a 30 year old CIO performing better than a 60 year old CIO? This week’s post is more about getting your opinion and views on this issue, so please do go ahead and post your comments and opinions.

Let us consider the argument of experience: after all that is about the only positive thing aging brings to you. Everything else is negative in that the body and (to some extent) the mind begin to degenerate, never to reach the prime levels once achieved (typically between age 18-21). So given that experience (and I include the accumulation of knowledge over the course of years as experience) is the prime advantage of an older person in a leadership role, does this really apply to IT leadership and in particular the CIO role?

IT leadership and the CIO role in particular require a great deal of constantly updating your entire paradigm of how IT functions on a regular basis. After all you have to lead the way not only in understanding new techniques and methodologies but also in creating and implementing them. Furthermore, market share must be captured where the market consists of “playas” that SMS, IM, Tweet and MySpace each other. I, myself, have to work consistently towards keeping myself in touch with the terminology utilized by the younger generation and find urban dictionary (www.urbandictioanry.com) an invaluable tool for doing so. But the point I would like to raise is will a 60 year old be able to be in tune with this new market and all its peculiarities? Will a 60 year old have the capacity to constantly learn new techniques and methodologies all the time? I know that is what I find myself doing and believe me there are times when it is a lot of work and I find myself pushing beyond my limits. So there emerges a counter argument that while a older person will have experience, will he/she have the CORRECT experience that will be of value in this brave, new world?

There are, of course, no clear and obvious answers to this quandary. I am in no way suggesting that the old timers be shipped to the glue factory immediately. However, I would certainly recommend that the old paradigm of only allowing older folks to reach high levels of leadership not be adhered to blindly. My prediction is that we will see more and more organizations appoint younger professionals in leadership positions. This is already happening as we blog.

Beyond Application Development

2010-04-26T11:19:00.000-07:00

I come from an application development background myself. Moreover, I was involved in all aspects of app dev including Business Analysis, Programming, Quality Assurance and Project Management. It was only when I was first exposed to ITIL that I realized the tiny little well that I was a part of and the vastness of all the other parts of IT that existed that I had tuned myself out off.

SDLC, which, let us assume, for the sake of simplicity consists of the world of app dev is only a part of the going ons of an IT department. For those of us who have been involved in the SDLC most of our careers, there is a tendency to think only in terms of the application development lifecycle. However, the shift to understanding the entire IT infrastructure is important. There is currently a paradigm shift occurring in the IT industry globally where IT’s services to the business are being considered as opposed to the software IT produces only. The difference being that along with the application (or product) comes a host of related services. Consider a software application. The following will need to be considered once it has been released into operation:

Support for users during operation including a help desk that will provide at least first line support.

Continuous security management. This is particularly true for any sort of application that involves transfer of confidential data and financial information
Capacity Management to ensure that the application can support the agreed upon number of users or load.

Constant Availability Management checking to ensure that the application is performing as per specifications and to ensure quick follow up if it isn’t.
Service Continuity Management to ensure that in the event of a disaster, the application can be brought back up as soon as possible.

A continually evolving relationship with the customer to ensure alignment with customer needs and future needs.

A strategy that encompasses customer demands and financial considerations to ensure that the correct portfolio of services and applications is chosen, developed, delivered to the customer, operated and finally retired at the appropriate time.

A set of supporting processes that assist in providing the above services to the customer.

All this and more must be performed to ensure overall customer satisfaction over and above the development and testing of the software. The de facto standard for the services described above is ITIL. It is a large body of knowledge that most professionals will need to spend a significant amount of time and financial investment to master. It is recommended that most people get started immediately if not sooner.

The Importance of a PMO

2010-04-19T09:06:00.000-07:00

Project Managers are common across organizations all over the planet and their work function is well understood. However, what about a Project Management Office and its relevance to the organization? In most of my experiences with PMOs, there is a great disparage in the way PMOs are set up in organizations which results in confusion and lack of standardization across the industry.

There are two basic ways a Project Management Office can be setup in an organization. The first way is to set it up as a sort of super manager of the project managers and perform project portfolio management and task delegation functions for the entire Project Management function of the organization. Secondly, the PMO could be set up in a consulting capacity where it provides meaningful, training guidance and process improvement capabilities. There are pros and cons to each approach as is the difference in investment cost and return on investment in each case.

The main tasks that a PMO is expected to perform are:

Project support: Provide project management guidance to project managers in the organization.

Project management process/methodology: Develop and implement a consistent and standardized process and ensure that it is followed by the staff in the organization.
Training: Conduct training programs as needed.

Department for project managers: Maintain a centralized office from which project managers are loaned out to work on projects. This may not be performed if the PMO is being done on a consulting model.

Internal consulting and mentoring: Advise employees about best practices.
Project management software tools: Select and maintain project management tools for use by employees.

Portfolio management: Establish a staff of program managers who can manage multiple projects that are related and allocate resources accordingly.

The trick really is to determine at the beginning what kind of PMO would best fit the needs and culture of the organization. The next trick is for the PMO to not get involved in everything right at the beginning but to grow its role and responsibility incrementally. A major risk that PMO’s face is that direct metrics to determine their effectiveness tend to be difficult to set up and there is a grey area regarding their value and effectiveness to the organization. This could lead to a situation where the PMO is under-utilized by staff because they do not have quantifiable proof of the benefits provided. All this must be planned for and thought through as early as possible.

My personal view is that all organizations should have a PMO: the only difference being how much they are involved in the organizations project management activities. If nothing else, there is value in having a body that standardizes processes and methodologies for the organization.

Managing IT and Everything Else

2010-04-12T15:40:00.000-07:00

There are 2 main areas that an organization must perform a balancing act in today’s particular marketplace and environment. One: there has to be excellent supply chain, enterprise resource planning HR, Sales & Marketing, Accounts and Finances etc. in place and managed well both in the day-to-day and long term basis. This results in an efficient and cost effective service to the customer. The second is an effective utilization of technology in all its forms that are relevant to the organization. This could include a savvy webpage, an easy to use online store, email and networking services to the employees of the organization etc. It is imperative, however, that both these areas are implemented and managed effectively.

The first part, the “overall management”, is the traditional management style that has been in place for centuries. The danger with this is that organizations strong in this area tend to neglect the IT side of things. Furthermore, they tend to neglect the IT connection to the rest of the organization and fail to seek out new ways to involve effective utilization of IT in a constant and repetitive manner. Recently Wal-Mart has come under fire for failing to maintain high levels of IT capabilities while being quite successful in its supply chain setup.

The second part is of course the effective implementation of IT. The danger here again is that the organizations, strong in IT tend to be weak in the rest of their management. Furthermore, with the rapid changes in all aspects of IT including process methodologies, this is a herculean task for any organization even one with a core strength of IT.

The fact of the matter is both sides of the equation must be taken care of for an organization to perform optimally and the tendency to veer one way or the other must be kept in check. Gone are the days of the tech savvy “whiz kid” creating a multi-billion organization just by his brilliance. Also gone are the days of the old school management style. A strategic all round approach is necessary to survive nowadays with experts being called in to provide advice on best practices in all areas of management.

IT Investments

2010-04-05T11:25:00.000-07:00

For all the flak, the Government usually takes for being bureaucratic and slow and inefficient, in the world of IT, the Governments of the western worlds in particular are doing well to adopt a lot of sensible policies and procedures to help increase efficiency. In fact, the US Dept of the Interior’s Information Technology Capital Planning and Investment Control Guide (CPIC) is one of the best investment frameworks out there for IT investments.

It actually all started with the GPRA (Government Performance and Results Act) which mandated that all federal agencies had to be results–oriented. This included defining general goals and objectives for their programs, to develop Annual Performance Plans specifying measurable performance goals for all their programs and to publish an Annual Performance Report showing actual results compared to the projected goals for each program. As a result of this, the Government’s Office of the Chief Information Officer came up with the CPIC guide to govern and manage the IT investments for the Government and to align all IT investments to the to the strategic goals of the Department.

The CPIC process consists of circular flow of 6 phases:

Pre-Select Phase: In this phase, the business recommends IT services based on their requirements. A concept is created and a Business Case for the new IT service is developed, evaluated and approved. Based on these actions a final approval to move forward will then be obtained from the relevant stakeholder.

Select Phase: In this phase, a project plan is created with established performance goals and quantifiable performance measures. Costs, schedules, benefits and risks are identified and evaluated. With the completion of all steps in this phase, approval is obtained to proceed to the next phase.

Control Phase: The goal of the Control phase is to ensure that through timely oversight, quality control, and executive review, the IT initiatives are conducted in a disciplined, well-managed, and consistent manner. It is in this phase that the project is moved from the requirements definition to implementation. The project management occurs here with the project progress being monitored, reported and evaluated with course correction taken as needed. This phase is considered complete when the production deployment or implementation is completed.

Evaluate Phase: In this phase, the actual results after implementation are compared to the projected results and any changes or modifications needed are implemented. A Post Implementation Review (PIR) is conducted in this phase and based on the results corrective action is taken. Once this is completed, the next phase is entered.

Steady-State Phase: During this phase, analysis is used to determine whether mature systems are continuing to support mission and business requirements. Customer satisfaction is evaluated and opportunities to improve performance and reduce costs are considered. The investment stays in this phase until a determination is made by the appropriate stakeholders to modify, replace, or retire the system. A major enhancement can be defined as, new architecture, or new functionality. The cycle then begins again at the Pre-Select Phase.

The CPIC fits in nicely with ITIL and its Service Strategy Phase. It also fits in well with ITIL’s consideration of IT Services as a portfolio of services which CPIC does as well. The interested reader can easily obtain more information on this and other Investment management frameworks. The question isn’t which one to choose but how well are we implementing and evaluating the one we have chosen. If IT investments are not being performed under a proper investment management process but rather by some sort of emotional, ad-hoc fashion by top executives, then return on investments is going to be low – guaranteed.

Balance Balance Balance

2010-03-29T07:49:00.000-07:00

At a recent chapter meeting with IT and Quality professionals, the topic of documentation came up. To my surprise a lot of folks were against documentation: not in principle but in the extreme application of it. But why did they assume that documentation equates to extremely detailed and intensive documentation? A somewhat “light” version of documentation could be implemented which would cover important issues without involving too much expense and effort. A medium level documentation effort might very well be the right one for a specific situation. Why assume a super detailed documentation effort right from the onset and crucify it immediately? This tendency to be either at one extreme (little to no documentation) or the other extreme (super detailed documentation) is a damaging and ultimately self-debilitating style of thinking. This same extreme to extreme thinking occurs when process implementation (or improvement) or any other beneficial initiative is brought up and then creates a significant roadblock in the implementation of the effort.

In reality, any level of documentation or process implementation or Six Sigma effort can be performed. It does not have to be an ultra grand trillion dollar effort. A proper analysis of what best serves the organizational needs must first be performed. With the result of this analysis, a proper, well thought out approach should be planned and implemented. It is usually best to start with a pilot version of the effort as opposed to implementing it all across the organization in one go. A phased approach is also beneficial in that any issues with the effort can be corrected and reworked smoothly and incremental low risk implementations are made. I do not wish to go into the details of an implementation but rather emphasize the benefits of a balanced approach and the needless harm and problems induced by an unbalanced (extreme to extreme) thinking approach.

To be perfectly honest, each moment of each day calls for analysis and a balanced response. I can’t slam on the accelerator of my car too hard or I’ll hit the car ahead of me. If I don’t hit the accelerator hard enough, the car behind me will be frustrated. I must analyze the traffic conditions at each moment and make the correct response. Whether it is driving my car, shopping for groceries of implementing six sigma improvements, each unique situation calls for a unique response. As IT professionals, it is especially necessary for us to keep this balanced approach in mind due to the enormous mix of variables in the workings of IT. Even the effort at achieving balance will bring about major positive results and harmony. And the IT work environment could use all the harmony it can get.

Those Who Help Themselves

2010-03-22T14:47:00.000-07:00

Hindu culture pays particular importance to the beginning of anything; whether it is a new life, a new TV brought into the house, a wedding or the start of a new job. In each case, Lord Ganesh (the infamous “Elephant God” to westerners) is invoked and prayed to first so that he may grant a long, smooth and trouble free life for the person or item that is starting out. But what about projects, products and services? It is valuable to apply the same importance that Hindus do to beginnings but in a more scientific and less mystical fashion.

The methodologies and techniques to handle project or service beginnings exist. However, it is typically the usual combination of ignorance and laziness that causes these methodologies to go largely unused. A project is typically started out of a knee-jerk emotional reason or having been a brainchild or dream of one individual. The same is typically true of a service. The result of a improperly planned initiation is that there are numerous difficulties encountered all through the life of the project. While ROI is generally thought of nowadays and some semblance of financial planning is performed, other important questions are rarely asked such as: Who are the key stakeholders and are they all on board for the duration of the project? What resources will be needed and will they be made available to the extent that will be required? What is the end vision for the project and will it really benefit the organization?

Some suggestions on initiating a project correctly are as follows:

Create a Business Case for the Project and obtain the relevant approvals.

Perform a feasibility study which would include, risks associated with the project and alternative solutions.

Create a Project Charter and obtain the appropriate approvals.

Set up a Project team and obtain the required resources from key stakeholders.

Interface with the PMO office and align with the correct processes, procedures, systems and tools.

Perform an initiation phase review to ensure that all initiation activities were performed and the required outputs of the Initiation phase were obtained and the initiation goals achieved.

With these steps performed, a lot of problems that might have occurred are proactively prevented from occurring in the first place. Project initiation is really about analyzing the project to find potential problems and address them right at the beginning. It is best not to simply pray to Ganesh for a smooth project. After all, God helps those who help themselves.

The 8 Dimensions of Quality

2010-03-15T15:39:00.000-07:00

According to David Garvin, a Harvard professor and author of the volume “Managing Quality”, quality can be divided into 8 dimensions. The division of quality into sub dimensions provides a way to easily design, manage, deliver and measure the product or service to the customer. Perhaps the best thing about this division of Quality into 8 sub dimensions is the better understanding of the customer requirements that is gleaned from it (sometimes an understanding of the customer is achieved that the customer themselves are not consciously aware of themselves).

Let us consider the proposed dimensions of quality as suggested by Garvin. They are:

Performance (or the primary operating characteristics of a product or service): As might be expected, the characteristic of the product or service to deliver on what it primarily does would be on the list. For a car, the torque, horsepower, brake specifications etc. would be characteristics of performance.

Features (or the secondary characteristics of a product or service): The extra features available or delivered by the product and service are also a characteristic that determine quality. For example, leather seats and a high-end sound system in a car would be attractive features.

Conformance with specifications: The traditional understanding of quality in the old paradigm where the primary importance is given to ensuring that the product or service meets specifications accurately. However, this is useful only if the specifications are correct (i.e. the previous 2 dimensions are accurate).

Durability (or Product Life): How long the product or service functions before failure. This is an important characteristic even if not specifically stated by the customer. After all who doesn’t like a product that works for a long time? This was displayed during the 80s when the Japanese Auto makers successfully penetrated the US market with only superior durability on their side.

Reliability (or frequency with which a product or service fails): Mercedes Benz automobiles require less frequent oil changes. This is an attractive feature to most customers.

Serviceability (or the speed, courtesy and competence of repair): If a product or service requires a great deal of disruption and cost to the customer to repair then even if the frequency of failure is low, it could be unattractive to the customer. Luxury sport cars are very expensive to maintain and are a factor in the decision of the customer to purchase them, over and above the purchase price.

Appearance/Aesthetics: A good example of the importance of aesthetics are Apple’s products that bring a distinctive style to the customers which is definitely a part of their success.

Image/Brand/Perceived Quality: The positive or negative feelings customers associate with the company based on previous interactions. Ford “Quality Is Job One” and Maytag “the Lonely Repairman” even used Quality as a marketing slogan and positioned themselves strategically in the marketplace with this characteristic.

With the 8 dimensions of quality defined, we may observe that this breakdown provides a useful tool to assist with determining the customer requirements, especially when the customers are unclear on what they want. Furthermore, the design and delivery of the product or service is simplified as well due to the separation of quality characteristics that can then be separately administered. The organization’s marketing and selling strategy can also be influenced with a well defined understanding of the quality characteristics that are being offered. The benefits of paying attention to the 8 dimensions of quality are significant and should be emphasized in all organizations.

The IT Business Gap

2010-03-08T08:21:00.000-08:00

Probably the most common phrase heard nowadays is “IT / Business Alignment”. There is also a great deal of information, techniques, methodologies and consultants (myself included) that offer ways and means of making such alignment possible. However, how does one go about it at a basic high level?
One model that comes to mind (and there are various models that exist) is the IT-Business Alignment Cycle which basically consists of 4 stages:

Plan: The requisite first step in any model, the planning of what IT must provide to the business must be performed first. This involves understanding Business’s needs and the plan for designing and delivering IT solutions that satisfy these needs. A high level of communication should be formulated and maintained between Business and IT for this to be successful on an ongoing basis. The ITIL processes within the domain of Service Strategy are effective in meeting the needs of the planning stage.

Model: This involves the execution of the Plan conceived earlier to the extent that the required IT services are designed and released to the Business’s live environment successfully. The ability to track CI’s via a well defined Configuration Management is crucial. Moreover, the ability to provide for the IT service’s Availability, Capacity, Security and Continuity should also be handled utilizing the corresponding processes.

Manage: This involves the successful operation of the IT service being provided to the Business on a day-to-day basis. For this to be successfully accomplished, the IT department must have effective Incident and Problem Management processes in place with a capable Help Desk function in place at the minimum. Effective Change and Release Management processes are also very important. The ability to track and monitor promised service levels is also a necessity in this stage.

Measure: If you can’t measure it you can’t manage it. This stage actually applies all across the organization and incorporates itself with the previous three stages. The basic premise here is to verify via metrics that the promised services were delivered and managed successfully. This can and should incorporate measuring at levels that are not visible to business at the component level. Measuring IT performance at a functional silo level is also beneficial in order to measure and improve IT functional capability. Continual improvements are a key goal of accumulating and analyzing the metrics in any organization.

A constant iteration of these stages should provide a basic framework for keeping IT and Business successfully aligned. Of course far more information is available on this topic and the reader is encouraged to springboard off of this post and delve deeper into this extremely crucial and significant topic.

The Smallness Excuse

2010-03-03T22:00:00.000-08:00

During a conversation I had with an IT executive today, he mentioned something along the lines of how large organizations tend to be more process oriented and smaller organizations tend to be more ad-hoc in their activities. He then also went on to say that it was too much overhead for a 50 person company to employ all the various resources and staff and tools needed to implement processes. It seemed to me, however, that he was committing the usual blooper of going from one extreme to another. That is, either we implement processes in a big way or not at all.

If an organization is small, does that mean it can be chaotic and do as it pleases? Do processes have no place in a 50 person organization? Granted that fewer staff mean lesser communication issues and less complexity in general but does this mean that there needs to be no discipline whatsoever?

As I mentioned previously in the post “Pick and Choose” a while back, organizations are at liberty to implement processes to the extent that they feel is necessary and beneficial. In this week’s post, I would like to make a few suggestions on how smaller organizations can make smaller scale process implementations. First, however, I would like to highlight the importance of processes to a small organization.

First of all, a small organization is just that and more than likely it is up against bigger rivals with access to greater funds and resources. What this translates to is the fact that the smaller organization has to rev up its game to a high level in any way that it can simply to survive. Therefore, it actually emerges that process is more important to a smaller organization than a larger one. Kind of like how a little kid in the schoolyard has to train harder to stand up to the bigger boys. Secondly, any structure laid out when an organization is small will translate to already laid out groundwork when the organization grows. Processes will only have to be modified in the future as opposed to being implemented from scratch. Therefore, it is far more important that smaller organizations pay the appropriate respect to processes, structure and organizational discipline.

So how does a smaller organization implement processes in a cost-justifiable manner? The answer lies in a proper understanding of processes themselves. What is a process in its simplest form? Simply a grouping of related steps that achieve a common goal in a structured manner. Smaller organizations will tend to have a smaller number of steps or may only wish to structure some key steps that are crucial. Therefore, all they have to do is group a smaller number of key steps in a process structure and they too have a process in place. Confused? Consider the Change Management process. At a large organization, they may have a lot of logging in, analysis and authorization steps which could be streamlined to one or two steps in a smaller organization. Likewise some of the implementation and post implementation steps could be streamlined in a smaller organization as well. However, by keeping the main steps of Change Management within a process and implementing it, the smaller organizations are giving themselves the advantage of being process oriented.

Furthermore, smaller organizations can implement a select few processes to start off with and then keep adding others as they grow and can afford more resources for these tasks. Keep in mind that at a small organization, one person could perform multiple roles. So a Change Manager could also be a Configuration Manager as well and two resources are not needed as one will suffice.

It’s really a matter of how much the folks up top are aware and want it. Where there is a will there is a way. Small organizations can be highly process oriented and enjoy the benefits of that. Smallness is in no way an excuse for anarchy. The reality of it is that it is simply laziness that prevents small organizations from being structured and process oriented.

Staff Planning for Critical Tasks

2010-02-22T13:07:00.000-08:00

I was recently reminded of the time I spent a few years ago assisting my client in preparing a matrix of critical job functions and primary and secondary staff that would perform the tasks. This was prompted by a sequence of events where the usual staff that perform the tasks were out sick and the secondary were on vacation. Consequently the important work ended not being accomplished as it was of a sensitive security nature and just anyone couldn’t login and perform the task. Senior management then came in with the edict that such a situation must never occur again. Therefore, we found ourselves documenting the matrix and a plan for what should happen if both the primary and secondary staff were unavailable.

Of course, the obvious lesson in all of this is plan ahead for such contingencies and you won’t be caught with your pants down at the crucial moment when they do happen. A plan to prepare properly for critical tasks from a staffing point of view would consist of:

Identifying the critical tasks and the resources necessary to perform them and the scheduling limitations involved.

Documenting the steps involved and the various procedures

Identifying the critical staff members – both primary and secondary

Perform practice runs. Simulate a crisis situation and invoke the plan. See if it works out and if not, make the necessary changes to ensure it works right

Plan and setup the primary and secondary staff to work from a different location (or home)

At a higher level, plan to reduce the necessity of performing the critical task or create a workaround if there is a staff crisis situation. This would possibly necessitate the involvement of senior management and other departments but would be potentially very useful in a crisis situation.

These are some of the typical, basic steps to take to ensure adequate staff coverage at all times. Of course, specific situations will warrant specific steps and readers should plan for their specific situations accordingly. However, the steps above should be a good starting point. The important thing to do is to plan before the crisis actually hits.

Modernizing Legacy Systems

2010-02-15T19:04:00.000-08:00

Running into a co-worker at a company I worked at years ago, we sent into the routine of asking how things were with each other etc. When I asked him if they had finally made a move out of their old AS400 system, he replied in the negative. Now this is an old legacy system that has the effect on the company similar to swimming with a pair of 50 pound cement blocks glued to your feet. Of course, the company has made numerous attempts to modernize and move away from the legacy system in the past but they have all been unsuccessful. So we have the situation that the system is still in place and taking up a higher than necessary operation cost with the company unable to upgrade or replace it effectively.

This is actually a very familiar situation for a lot of organizations. Perhaps the legacy applications are not so large and not so old but the various mechanisms that prevent it from being sent into nothingness to rest in peace are the same. First let us look at the advantages and attractions of legacy systems:

Over a large span of time, they are firmly entrenched in the organizations way of going about things and are quite stable (even though they may be inefficient).

The legacy systems typically run mission critical applications that would disrupt the users/customers a great deal if they had to be replaced.

The legacy systems are familiar to large numbers of users and they know all the special ins and outs of the system well. A new system will entail re-education of the new system to users.

The disadvantages of legacy systems on the other hand are:

Enormous cost of ownership due to prehistoric technology and underlying systems. Large number of servers and staff are needed to keep it all going and make modifications as and when necessary.

Built eons ago with a specific purpose in mind which makes the system extremely inflexible and resistant to modifications. Any alterations take a large amount of resources, time and cost.

Typically poorly documented with only a few crusty old timers knowledgeable in the inner workings of the system which translates to difficulty in making modifications or replacing the system. Also the few who are familiar with the legacy systems resist attempts to share the knowledge and produce documentation since keeping things in the dark makes them valuable and reinforces their job security.

So how do we go about replacing the legacy systems? A few guidelines are as follows:

Create as much documentation as possible for the existing system. Ideally a complete set of requirement and functional spec documents should be created.

Perform proper risk management and mitigation strategies. Monitor risks all through the modernization for occurrences and perform mitigation as needed.

Strategize on the best way to perform the modernization. Perhaps a full scale replacement and recoding is required. Perhaps commercial off the shelf software will do the trick. Perhaps it can be replaced in bits and pieces?

Understand and educate staff that the disadvantages of clinging on to legacy systems are enormous and their co-operation in the matter will only be to their benefit.

Making fundamental changes to legacy systems is a hazardous task mainly because the inner workings of the systems and the inter-dependencies are so rarely understood. Typically, a small modification can have far reaching consequences. Therefore, it is best to approach this cautiously but not so cautiously that it never gets accomplished.

QA to Developer Ratio

2010-02-08T17:59:00.000-08:00

This week, during interaction with potential clients, I was speaking with them about their QA department and asked “What is your QA to developer ratio?” The answer was an embarrassed laugh followed by an explanation of how there were very few QA team members compared to the development team. This gave me a good idea not only of the immediate problems faced by the organization but also the lack of strategic thought, the lack of executive planning, and the longer term problems that the organization will face in the future.

I did not even bother to ask why they had a low QA to developer ratio as the guaranteed answer was going to be “lack of funding” or some variation thereof. Which, therefore, indicates that the management does not consider quality an important part of what the organization provides to the customers. Oh sure, if I were to state this directly to them, they would deny it vehemently but actions speak louder than words and the true meaning of their actions is that they do not give quality the importance that they claim to. Now, in certain rare cases, a low QA to developer ratio is acceptable and makes sense. This would be in low price, commodity items where the development process was very mature and error free and not a lot of QA was needed nor made financial sense to be deployed. However, in the case of complex software with a not so strong development team producing it, a QA to developer ratio of less than 1 to 1 is simply stating that you do not consider quality important. There is, of course, no one specific ratio that serves all organizations. However, in my opinion for most IT and software type of situations, at the minimum, a 1 to 1 ration of QA to developers is necessary. To really provide “Cadillac” service, in my opinion, a 2 to 1 ration of QA to developers should be implemented. The 2 to 1 ratio, while being expensive, really puts a lot of pressure off the QA staff and makes the QA process fun and not such a pressure cooker kind of an environment. However, most companies are very far from the 1 to 1 ratio so I won’t put too much emphasis on anything higher than that. Of course, in mission critical software where lives are at stake, the QA to developer ration has been known to go as high as 4 to 1 or even more which illustrates that organizations do spend on QA when they have to.

It really boils down to whether the goal is to squeeze out as much of a profit as possible for the quarter, or to truly plan for the future and be as well setup to deal with it as possible. As a QA team member in the past, I can assure readers that a high QA to developer ration is very, very beneficial and ultimately cost effective to the organization in the end.

The Right Way to Reduce Cost

2010-02-01T15:58:00.000-08:00

When organizations are faced with the task of reducing their cost, very often, they instinctively think of the removal of personnel. While this may be the correct course to take (especially in extreme market conditions such as the present), generally a great deal of cost savings can be obtained from the removal of waste.

IT waste is unique in that it generally cannot be inventoried and stored for later sale like steel pipes or copper wire. If a developer sat on the bench for a day then the company just wasted a man-day and the equivalent dollar amount and there is no way that this expenditure can be recovered. Therefore, a great deal of care and effort should be expended towards ensuring that waste does not occur in the first place. The second source of waste is needless rework due to defects and misalignment with business requirements. This is particularly true for organizations that perform application development. So another great way to streamline costs would be to ensure products and services are created right the first time which then minimizes the cost of performing testing and rework.

I am reminded of my time consulting at a large mortgage bank. The application being updated and released monthly always had issues in production after each monthly release. Multiple efforts of QA and user acceptance testing had to be performed, in spite of which defects would find their way to the end user. The following highlights my strategy as a consultant to resolve this situation:

My first step was to create a system of metrics for measuring and analyzing defects so that we knew where we were and how changes were improving the performance or otherwise. After all if you can’t measure it, you can’t manage it.

Next, I ensured worked with QA to re-strategize their approach and to create new test plans and test case documents. This ensured that the application was tested thoroughly and defects were at least found and not missed and sent on to the customer.

At this stage, a great deal of pressure was taken of user acceptance testing and those personnel could be partially taken off testing and utilized elsewhere (which was a cost saving already). The defects found by QA were then analyzed for their root cause by development and this information was then utilized to ensure that the error did not occur again.

The result of all this was that development began to produce software that was relatively defect free and the pressure on QA was significantly reduced while UA only performed a cursory check of software to be released. A number of personnel were freed up to work on other tasks and customers began to see zero defects in production.

Therefore, a great deal of cost savings was achieved along with improvement in quality and increased customer satisfaction. The alternative, which would reduce headcount and therefore cost, would still leave the organization with the issues and inefficiencies it had before but with fewer people to solve them with. Clearly, the former is the better way to go.

IT Risk to the Organization

2010-01-25T21:31:00.000-08:00

As IT is a department within an organization with the goal of typically servicing other departments, there is a set of risks that IT poses to the organization. What I am talking about is different from the risks within an IT project execution or the day to day functioning of the IT department. I am focusing on the risks the IT department as a whole poses to the organization that it services.

The risks can be divided into the following main groups:

Consequences of failure of services provided by IT

Security risks

Outsourcing and Partners failure risks

Governmental and Legislative Risks

The IT head as well as senior management within the organization should consider these risks and work in tandem to manage them. This can be accomplished in the following ways:

Create a risk management strategy and monitor and act on it regularly

Engage outside auditors to analyze the risks from a new perspective

Always be on the lookout to transfer risks

And strengthen the quality of IT processes within the organization

In this way, organizations can get a proactive handle on the potential risks and manage them before they become a critical issue. It all really boils down to taking the effort and making it happen. There exist endless possible excuses to not do it, but in the end you have to consider that the competition is doing it so can you take the risk of not managing your risks?

Levels of Cost Optimization

2010-01-13T07:40:00.000-08:00

If an organization wished to optimize its costs, there are numerous ways it can go about it. The question is which method of optimization will bring about beneficial results in the long term and which methods are knee-jerk reactions that bring about a short term benefit (and even a long term loss).

Gartner provides us with a framework of cost optimization that consists of four levels, each at a higher level of maturity and benefit. The broad categorization of these four areas is:

IT Procurement: which consists of smarter procurement techniques and buying from cheaper and better vendors etc. This is also the least “mature” of the techniques and only provides very low level benefits that have little lasting impact.

Cost Savings within IT: which consists of identifying opportunities to reduce IT costs. This usually ends up being lay-offs or outsourcing. While these are valid steps to take, they are again not “high maturity” decisions that will have long term and strategic benefits to the organization.

Joint Business and IT Cost Savings: This is one level more strategic than the previous method, where IT confers with business to come up with areas of cost optimization that will have minimal negative impact on the business.

Enable Innovation and Business Restructuring: This consists of encouraging innovation, implementing process improvements and restructuring business to align with customer demands. This is by far the best technique to bring about cost optimization with long term strategic benefits.

Organizations, however, rarely take the long term, visionary approach and approach cost optimization with the attitude of haggling with vendors and laying off people. This kind of cost cutting will rarely result in lasting benefits.

Eight Percent

2010-01-04T10:52:00.000-08:00

As per Gartner, the cost involved in developing an IT application and bringing it to the live state is only 8% of the cost required in keeping it live for 15 years. And this, in a nutshell, is where most organizations do not plan properly and run into problems. The “whole life cost” or total cost of ownership (TCO) is rarely computed in a responsible manner. Rather, a knee-jerk reaction to changing market circumstances prompts the decision making process (if there is one) and a project is hastily assembled. After the project is completed, and the maintenance costs start mounting, there is “surprise” at the mounting maintenance costs. Then IT has to request more funding for its operations.

This whole sequence of events can be avoided if organizations simply add up the TCO and make responsible decisions in conjunction with business. The areas of expenditure that should be taken into account are:

Planning

Design

Construction/acquisition

Operations

Maintenance

Renewal/rehabilitation

Financial (depreciation and cost of finance)

Replacement or disposal

A great many tools and techniques for TCO exist and are readily available on the web. However, my goal here is to emphasize the importance of performing TCO and to be aware of the pitfalls involved in failing to perform this step.

The reason, in my opinion, that a lot of organizations suffer from poor TCO calculations in spite of the information being easily available and not very difficult to compute as well is because they often emotionally stake the next project as the “magic” deliverer of their present dilemmas. It is this emotion and lack of calculated analysis that leads organizations into the quicksand of wrong decisions and incorrect cost computation.

Organizations must make an accurate and well though out business and financial analysis of every proposed undertaking. If they neglect this step, they will pay for it later as 92% of the unaccounted cost is waiting to hit them where it hurts.

Giants of Quality

2009-12-29T12:23:00.000-08:00

The area of quality (for both IT and non IT) has had a few champions that completely redefined the epistemology of quality and the means of achieving it. I speak of W. Edwards Deming, Phillip B. Crosby and Joseph M. Juran. It is especially impressive to me as a quality “evangelist” myself, that they achieved what they did at a time when quality was not as well understood and significant as it is today. Championing quality today is a task I find extremely challenging and difficult to sell after the initial enthusiasm that top management displays. So the mind boggles at the difficulty that these champions must have faced and overcome back half a century ago. This week’s post is a dedication to their tenacity and passion for quality.

While Deming performed significant work for the World War II effort that resulted in improved statistical process control techniques, his true success came in Japan. The US experienced a great demand for its manufactured goods across the world and quality was sacrificed for mass production. The Japanese, however, understood the importance of quality and made the sacrifices necessary to achieve world class quality. This, of course, resulted in the Japanese overtaking the US in terms of desirability of their manufactured products and transforming a small island nation into a major world power and economic giant. Deming’s work in quality improvement was so effective that he was awarded the Order of the Sacred Treasure award by the Prime Minister. He then returned to the US to teach, author and consult. His years in Japan, however, remained the most effective in terms of the adoption and utilization of his techniques.

Crosby was famous for his zero defects philosophy and his belief that “Quality is Free” authoring a book with the same title. He also championed the concept of “doing it right the first time”. He contributed greatly with his lectures and seminars towards quality as a practice.

Juran pushed for the education and training of personnel and introduced the composition of three managerial processes: quality planning, quality control and quality improvement. Like the others, he authored, lectured and consulted about quality.

In writing about these giants of quality, I feel that we can learn a great deal from their life and work and the contribution they made to the world. It must have been difficult: but they persevered and won. How many like these exist today?

A Plethora of Sourcing

2009-12-21T08:34:00.000-08:00

Procuring resources and capabilities for the tasks that require to be completed has been an important part of IT management since the introduction of IT into the business model. In the past, however, procuring talent meant visiting university campuses for entry level positions and posting advertisements in newspapers and job-websites for more experienced candidates. With the advent of greater complexity and faster changing technology and best practices, consultants were brought in to fill the gaps.

However, with the availability of significantly cheaper and at the same time good quality resources being available in foreign countries, outsourcing was the buzzword for a while. Now, however, many types of sourcing possibilities exist and IT executives have a smorgasbord of options to choose from. Some of the lesser known types of sourcing that also exist are:

Multi or Co-Sourcing: where tasks are performed by both the internal organization and an external provider

Knowledge Process Sourcing: is a type of sourcing where highly knowledge intensive work is carried out by highly skilled staff. E.g. Sox auditing may be assigned to a third party organization that specializes in SOX audits.

Global Sourcing: Global sourcing often aims to exploit global efficiencies in the delivery of a product or service which could include low cost skilled labor, low cost raw material and other economic factors like tax breaks and low trade tariffs

Strategic Sourcing: which consists of techniques to optimize the procurement of services and overall sourcing strategy of the organization

Corporate Sourcing: where divisions of companies coordinate the procurement an distribution of materials, parts, equipment, and supplies for the organization
Second-tier Sourcing: is a procurement policy that rewards those suppliers that achieve or attempt to achieve the minority-owned business (MBE), spending goals of their customer

Crowd Sourcing: a technique of assigning a task to a group of people or community as an open call. Beta testing by PC game companies is an example of this technique where a group of typically teenage game enthusiasts perform testing for a small fee or even free.

Open Sourcing: utilizes previously proprietary software under an open source/free license. This may not always be a good choice but the price is certainly right.

So it emerges that there are quite a few type of sourcing techniques available and are no longer rare occurrences as they used to be in the past. The method of choosing which type of sourcing to use remains the same, however. A careful analysis of the needs of the organization along with consideration of its long term goals and objectives and an evaluation of the pros and cons of each type of sourcing possible will result in a mature procurement decision. A key here is to keep an open mind to the sourcing possibilities and to not be guided by one’s own prejudices in the matter.

SaaS: Pros and Cons

2009-12-14T22:49:00.000-08:00

Software as a Service (SaaS) is a technique of software deployment whereby a provider licenses an application to customers for use as a service on demand. SaaS software vendors may host the application on their own web servers or download the application to the consumer device, disabling it after use or after the on-demand contract expires. The advantage of this is the transfer of the risks and responsibilities from the customer to the SaaS provider. There is also a potential benefit in cost for the customer as the “on demand” aspect of the billing only charges the customer for when the application is utilized. This also reduces the administrative burden of maintaining and tracking licenses across the organization for customers. Furthermore, cost savings may be realized due to a multitenancy approach to the architecture of the application and its data handling. While this entails a greater initial development effort for the provider, economies of scale are achieved by only requiring one instance of the application to service multiple customers.

So to itemize the benefits that SaaS offers:

Cost: SaaS delivers application at a lower cost than delivering them in-house.

Risks and responsibilities transferred: The risks and ownership of resources and capabilities required to deliver the applications are transferred from the customer to the provider. This is typically very attractive to smaller companies.

Efficient resources utilization: Freed up from delivering technology, IT resources can utilize their time on issues that impact the organization and business urgently.

Flexibility: The SaaS provider will typically offer flexible contracts and charging models. The customer will also be able to easily and with minimal risk try the service before committing to a contract. The ability to switch between providers is easier than with traditional outsourcing.

However, the following cons also exist:

Limited customization: As the SaaS provider caters to multiple organizations, they may not be capable of customizing the application for each individual organization to the extent required by them.

Scalability: Currently SaaS offers scalability to service smaller organizations but this is expected to improve as technology evolves.

Reliance on another: while this is listed as a benefit, it can also be a risk as all control of the application is placed on the provider and if they fail, then the customer organization suffers.

While SaaS is not a magic solution, in my opinion it does offer some benefits for organizations that have specific conditions and requirements that match the benefits that SaaS has to offer.

SaaS does not replace in-house IT; however, research indicates that it could well represent 25% of the software market by 2010. Therefore, SaaS should be kept in mind as an alternative should the situation and conditions merit it.

How Much is Enough?

2009-12-07T09:17:00.000-08:00

This week’s post sparked from a phone conversation I had with a friend who is now an IT QA Manager at a company in Los Angeles (to go unnamed). What struck me was his comment on how there was a lot of chaos at the company due to a rapid rise in new business which was not matched by a proportional rise in IT resources and capabilities. When I commented that it sounded like poor management to me, he countered by claiming that the IT management was doing well to manage the situation. But to me the balancing act of taking on new business in proportion to the resources and capabilities available is under the domain of management as well.

Which brings us to the question of when to say “no” to the customer. Or to handle it another way, the company could raise prices high enough so that demand falls to levels that the organization can provide at adequate quality levels and without putting undue stress on staff. I suppose marketing purists might insist that any and all new orders must be taken on at all costs or there will be irrecoverable market share damage. However, I would counter that taking on new business to the point that your quality levels drop and disruptions and defects are common is no way of maintaining market share either. In any case, this particular company (that my friend works at) has obviously chosen the take all customers at any cost approach. My personal experience in my own career has been that most companies tend to make this choice. But is this wise?

Now there are no obvious answers here and a lot depends on various factors such as the economy, the goals and objectives of the organization (long term and short term) etc. However, in my experience, it has always been negative in the long term when an organization has adopted the approach of taking on all orders and actively seeking out more orders even when the rest of the organization is struggling to keep up with demand. This is especially puzzling when we consider how easy it is to manage demand by simply charging higher and allowing market forces to balance things out without hurting customer’s feelings. When the organization has upgraded its capabilities and capacity, it can always lower prices to re-stimulate demand for its service.

To me, it seems like the goal of meeting large quarterly targets is based on a desire to rake in bonuses and stock price returns at the cost of the company’s long term success. In other words it is a case of greed. However, unlike as depicted in fiction, greed is not good. How much is enough, Mr. Gekko?

The Art of Release

2009-11-30T11:34:00.000-08:00

As customers expect modifications to services to be made more and more quickly, the ability to actually make these modifications successfully becomes more and more crucial. Now, a lot of processes and capabilities need to be in place for this to happen, but it is in Release Management that the actual update to the live environment happens. Therefore, Release Management is a member of that special clique of processes that actually have a direct contact with the customer.

Release Management is thought of in many organizations as scheduling and simply making the update in the live environment. However, this is more of a departmental oriented organization’s view of the process. In a process oriented organization, the Release Management process covers the tasks of building, testing and releasing to the live environment. These tasks are carried out using resources and staff from functions (departments) like Development, QA etc. Release Management interfaces significantly with the Change and Configuration Management processes in order to communicate the change information back and forth as needed. The Release Management process also takes ownership of a central location of storage of the master software and hardware spares. This is formally known as the Definitive Software Library (DSL) and the Definitive Hardware Store. The DSL need not be a physical location but could be a database where final builds are stored. This should not be confused with a day-to-day version control tool. The DSL is an important way of ensuring that the latest builds are kept separate and there are no confusions during release implementation. Licenses are also stored in the DSL making it a useful tool in maintaining legal compliance and identifying and locating unused licenses which are a complete waste to the organization.

Details of the Release Management process are freely available on the net. My goal here is to highlight its usefulness and benefits. The benefits include:

fewer disruptions in the live environment due to changes

standardization of hardware and software versions

better management of risks involved in releases including the implementation of a rollback plan

legal compliance with licensing

better utilization of licenses

It is, therefore, in the organization’s best interest that Release Management is taken as seriously as possible and steps taken to implement it systematically and rigorously. In today’s competitive world, every little bit makes a difference.

Stress Point Analysis

2009-11-23T11:10:00.000-08:00

Stress Point Analysis is a new technique that assists management in understanding the state of an operation; its strengths and weaknesses and where the effort to improve should be expended for maximum results and returns. It is a data driven technique in which most (if not all) members of the organization complete a web based questionnaire providing their input on the state of the operation. This data is analyzed and the state of health of various stress points in the organization is made available.

Stress Points in this model are defined as barriers to operation excellence. They are defined as:

Improvement & Innovation

Alignment & Fit

Measurement & Control

Resource & Demand Management

Process Capability

Each of these five areas can be operating at the following possible levels:

Outstanding

Scope for Development

Cause for Concern

Stressed

Analysis and evaluation of the stress point areas can give management an idea of where they are and the steps required to improve the stressed areas. They can then take the required steps to reduce problems in the stressed area so that all the 5 areas are at a high operational level.

All this is the theory proposed by Stress Point Analysis. In my opinion, it is a useful tool that could be of value to an organization but it is not a magic solution that will solve all the problems. Like all other methodologies, much depends on the successful implementation and day to day carrying out of the system. Still, it is something new that is out there now and I wished to bring to light for you to have a look at and decide on its potential value.

The Honesty Policy

2009-11-16T08:34:00.000-08:00

Last week’s post on Business Cases sparked some interesting feedback with one reader’s assertion being that business cases were always written with a bias benefitting the originator of the case with the committee in charge of analyzing and approving the case, unable to catch the bias and correct it. This got me thinking on the complex people dynamics present at all work environments and the even more complex dynamics present in an IT environment (due to the extraordinarily rapid change ever-present in IT). Honesty is vital for any type of improvement to be successful including IT Processes and I feel this topic deserves a post even if it isn’t “technical”.

I would like to focus on honesty as pertains to evaluating and stating the state of the organizations capability and maturity. I am not focusing on employee theft and feigning a sick day type of dishonesty. Recounting my personal experiences on this issue, I have always suffered whenever I have been honest. No matter how diplomatically or at the other extreme, bluntly, I stated the truth; it wasn’t what people wanted to hear. But I ask myself, would the same people who hated me for speaking the truth would have also liked their doctor to lie to them about the state of their health and sugar-coat their true medical situation? Clearly people do not consider their work and source of income to be as important as their body and health even though it brings home a paycheck. However, the principles of medicine are similar to an organization’s efficiency or process improvement initiative. One must first get an honest and competent diagnosis after which options can be evaluated and a course of treatment pursued. This is true with medicine as well as organizational processes. However, people tend to not welcome an honest approach at the workplace even though it ultimately affects your ability earn and provide for yourself and your loved ones.

Partly, it is the Ostrich approach where an Ostrich buries its head in the sand when it sees a lion attacking. Its logic being that if I can’t see the danger, the danger will pass me by without hurting me. Partly, it is also self-interest in that new methodologies will usher in change that will result in those having a power base within the organization losing it and ending up less powerful than before. Of course, if these folks would simply keep up with the latest techniques, they would never be threatened. However, they wish to reap the fruit of the work without performing the hard work that is keeping up with the latest in their profession. Staying at the cutting edge is hard work which not everyone is willing to perform.

On the other hand, an honest approach is extremely important, even crucial in today’s competitive world. An organization has to make the correct decisions based on the reality of the situation that it is facing. If it doesn’t it will end up fooling nobody but itself and misalignment with the customer’s needs, defects, rework and other assorted problems will inevitably arise. If the competition is brave enough to face its problems squarely and head-on, then the competition will inevitably end up the winners with superior market share. So obviously an environment of honest evaluation must be fostered and maintained.

How might this be achieved? As always, the foundation remains in the hands of top management. They must lead by example and display to the rest of the organization that they stand for honest evaluation and a “don’t shoot the messenger” approach. The implementation and education of the staff of cutting edge methodologies and best practices is also important and sends a positive message across the organization. Moreover, educating the staff, results in improved awareness effectively banishing the fear of the unknown that causes so much staff discontent and resistance. Finally, effective discouragement should be meted out to those who pursue a dishonest approach therefore discouraging any further such behavior from others.

In the end, all members of an organization have to record, evaluate, analyze and report in an honest fashion for the organization to remain competitive and profitable. A dishonest approach results in the organization and ultimately the employee’s loss and misfortune. Truly a dishonest approach is fooling no one but itself.

A Case for the Business Case

2009-11-09T09:51:00.000-08:00

Being in business requires making decisions based on what makes the most sense and is most aligned to the organizations goals and objectives among the choices available. For each decision, various alternatives will typically exist and different paths or avenues will be available that could be followed with their specific pros and cons. To make sense out of this situation and to work out the correct decision requires the implementation of Business Cases.

A Business Case is a decision making tool that captures the reasoning behind initiating a project or task and the effect it will ultimately have on profitability. The financial impact of spending money is analyzed including the rate of return, cash flow, length of payback period and other financial criteria as appropriate.

Very often, the decision making is performed far too informally with top management, making snap decisions base don their past experiences. While past experiences of senior personnel is a valuable input, a formal business case analysis that includes background analysis of the project, expected business benefits, options considered and the reasons for accepting or rejecting the options, expected costs to be incurred, gap analysis and potential risks is a far superior technique of decision making that results in far more mature and responsible decisions being made that are in better alignment with organizational strategy and goals.

The benefits of proper business case analysis and implementation are:

Proper Investment decisions are made with fewer budget shortfalls during the course of the project

Proper understanding of the scope of the project resulting in adequate resource allocation and schedule expectations which in turn leads to superior project management

Correct decisions made on whether to take on the project or not due to a good understanding of the project requirements and the organization’s capabilities to meet those requirements.

Proper prioritization of projects

Good understanding of inter-dependencies within projects and the rest of the environment so that fewer unexpected errors occur.

Ultimately the implementation of business cases should bring about a change in epistemology within the organization that causes all personnel (from the lowest to the highest) to think in terms of the benefits to the organization and comparison of alternatives based on alignment with organizational objectives for each decision.

It is only when all the members of an organization make decision (large or small) with a systematic, structured decision making process that the organization’s decision making will be fully optimized and the organization will reap the benefits presented above. If top management consider themselves above the need to perform business case analysis, the organization will pay the price for their arrogance with problems and issues that are caused by poorly thought out decisions.

The Design of Design

2009-11-03T09:02:00.000-08:00

As the marketplace has transitioned from primarily products to mostly services, the need to design services has emerged as an important area of knowledge and specialization. The design of products has been well understood and established within IT now. The design of software utilizing object-oriented principles and methodologies is well known. The design of networks and firewalls is well understood and performed efficiently nowadays which was not the case, say, a decade ago. However, the design of services is still not approached with the level of understanding and maturity that other areas of IT have achieved.

This state of affairs is understandable as the concept of services within IT still elicits a great deal of confusion. To clarify, services differ from products in that while both satisfy customer’s needs, in the case of a service; the customer does not take ownership of the resources and risks associated with the providing of the service. Furthermore, the service generally consists of providing the customer with a complete experience as opposed the solitary experience of purchasing and utilizing product. Therefore, the design of a service involves certain special considerations that are listed below:

Services must be designed to satisfy business objectives, based on the quality, compliance, risk and security requirements

Services must be designed that can be easily and efficiently developed and enhanced within appropriate timescales and costs

Identification and management of risks so that they can be removed or mitigated before services go live

The design of secure and resilient IT infrastructures, environments, applications and data/information resources and capability that meet the current and future needs of the business and customers

The design of measurement methods and metrics for assessing the effectiveness and efficiency of the design processes and their deliverables

The production and maintenance of IT plans, processes, policies, architectures, frameworks and documents for the design of quality IT solutions, to meet current and future agreed business needs

Contribute to the improvement of the overall quality of IT service within the imposed design constraints, especially by reducing the need for reworking and enhancing services once they have been implemented in the live environment

To accomplish these objectives, the design of services can be broken down in to the following aspects:

Service solutions, including all of the functional requirements, resources and capabilities needed and agreed

Service Management systems and tools, especially the Service Portfolio for the management and control of services through their lifecycle

Technology architectures and management architectures and tools required to provide the services

Processes needed to design, transition, operate and improve the services
Measurement systems, methods and metrics for the services, the architectures and their constituent components and the processes

These areas of design can be performed by the implementation of Design processes like Availability Management, Capacity Management, Security Management etc. Further information regarding these can readily be obtained online by the interested reader.

Design must evolve from product design to service design as the paradigm shifts from products to services. Attempting to design services with a product design structure in place will result in poorly thought out services that do not satisfy the customer and result in defects and incidents in production. Clearly the changes required in today’s IT environment reach deep down in the organization’s structure and are not superficial by any means.

ISO Issues

2009-10-26T11:23:00.000-07:00

A quick thanks to all who have commented and contributed to the blog site. To clarify some issues that have arisen, it is beyond the scope of this blog to provide detailed educational training. My vision with this is to get folks started off on a particular topic. Those who have expertise in the topic may not learn something new, but could (and should) contribute and add to what is presented by posting comments. On the other hand, those who are new to the topic can gain an introduction by reading the post and then further pursue the topic by obtaining the relevant study material if they are so inclined. With that stated, let’s move on to this week’s topic – ISO.

ISO (the International Organization for Standardization) has existed for a long time (Feb 23, 1947 to be exact) and caters to a lot of different industry domains and knowledge areas. Headquartered in Geneva, ISO is a non-governmental organization but is well known all over the world with significant influence and power. As its name implies, the organization is primarily concerned with the setting and maintenance of worldwide industrial and commercial standards. ISO provides guidelines for over 17,500 standards. While numerous standards exist that relate to technology, the standards most relevant to this blog site are the ISO 20000:2005 (IT Service Management) and the ISO 27000 (Information Security Management) standards.

As a consultant, I am passionately in favor of standards. One of the most frustrating things for me is to spend my time (and therefore the client’s money) in the attempt to understand the way things are setup and the terminology used at each organization that I consult at. What is fascinating is that each organization has its own “lingo” and way of defining items and resources. One might expect that their processes would differ but the very language they speak differs as well. This is not just inconvenient for a consultant or new employee but leads to confusion and problems/defects when interaction between other organizations is carried out. In today’s age of inter-dependency and outsourcing, it is important that all organizations speak the same language. Other benefits of implementing standards include compliance with governmental and regulatory requirements and the ability to enter global markets (some foreign countries require ISO certifications as a mandatory qualification to enter their market). Last but not least is the organizational efficiency and quality improvements inherent in improving the organization’s processes.

But for standards to work, they have to be implemented. So, how does one go about implementing an ISO standard? First, the decision must be taken and supported at the top management level and then accepted at the organizational level. I have observed too often the adaptation of some standard or methodology by the top brass while the cubicle level folks are dead-set against it. This almost always leads to the failure of the standard being employed. If not all at least a significant majority of the organization’s staff must be in favor of implementation of the standard.

Next, adequate resources must be planned for and set aside for the implementation of the standard. Training should be provide to key players in the implementation and outside consultants brought in as necessary.

If certification is desired, then an independent audit to assess and certify compliance to the standard’s requirements should be obtained.

ISO is a vast organization with a huge body of knowledge and my attempt to bring some of the IT aspects of it to light is a only but a first step in the right direction. Interested readers may pursue the subject in more detail via numerous resources available online.

Problem Management

2009-10-19T12:26:00.000-07:00

In most IT organizations, a systematic process to handle problems does not exist. Rather, the functions of a problem management process are carried out by Project or Program Managers or some sort of committee or advisory board. A well thought out problem management process is only rarely setup unless the organization is under some sort of ISO 20000 certification program.

Problems are underlying reasons for incidents. Incidents being disruptions to expected levels of service experienced by customers. Problem management aims at resolving incidents and problems caused by end-user errors or IT infrastructure issues and preventing recurrence of such incidents. Therefore, there are two aspects to problem management: a proactive aspect and a reactive aspect. In the proactive aspect, the services are monitored for possible problems and steps are taken before thresholds are breached. In the reactive aspect, a problem has already occurred and steps must be taken to resolve it. Problem management then works with other processes to resolve the problem in question.

The major sub processes within Problem Management are:

Problem and Error Control: To constantly monitor outstanding Problems with regards to their processing status, so that where necessary, corrective measures may be introduced.

Problem Identification and Categorization: To record and prioritize the Problem with appropriate diligence, in order to facilitate a swift and effective resolution.
Problem Diagnosis and Resolution: To identify the underlying root cause of a Problem and initiate the most appropriate and economical Problem solution. If possible, a temporary Workaround is supplied.

Problem Closure and Evaluation: To ensure that - after a successful Problem solution - the record and prioritize the Problem contains a full historical description, and that related Known Error Records are updated.

Major Problem Review: To review the resolution of a Problem in order to prevent recurrence and learn any lessons for the future. Furthermore it is to be verified whether the Problems marked as closed have actually been eliminated.

Problem Management Reporting: To ensure that the other Service Management processes as well as IT Management are informed of outstanding Problems, their processing-status and existing Workarounds.

The advantages of Problem Management are:

Reduction in service disruptions to the customer

Proactive identification and prevention of failures which leads to fewer defects experienced by the customer

Quicker resolution of an existing problem

Better communication and information management regarding problems and known errors

Better problem analysis and understanding of trends that could be utilized in a proactive manner

Therefore, it is clear that Problem Management provides significant benefits to an organization and should be implemented with the seriousness that it deserves.

Supply Stability

2009-10-13T10:46:00.000-07:00

Supplier management in the past was usually handled by the departmental secretary who chose which corner shop to buy the paper clips and pads from. Advanced version of this function also included choosing the best take-out joint for lunch or snacks. Nowadays, however, supplier management is a major process that is becoming more and more crucial in an organization’s ability to function efficiently and remain competitive due to the increasing complexity of inter-dependency between organizations.

The products or services that are being supplied by the supplying organization are numerous and complex. Consulting, material, equipment, information, knowledge and people are a few examples of resources and capabilities that are exchanged between organizations. While products need to be monitored for quality, price, delivery punctuality etc., the more intangible resources such as consulting and knowledge require further specialized skills in the management of its suppliers and delivery.
Suppliers can be broken down into the following categories by importance:

Strategic Suppliers: Where goods and services are hard to obtain and require adequate stockpiling for safety. The goods and services being supplied are crucial to the operation of the organization.

Tactical Suppliers: Less difficulty in obtaining goods and services. The items are not as crucial to the successful workings of the organization.

Operational Suppliers: Goods and services are relatively easy to obtain and there are alternatives to choose from. The items are not so crucial to the running of the organization.

Commodity Suppliers: Goods and services are easy to obtain and there are many supplying organizations to choose from. The items being supplied are not crucial to the opration of the organization.

Supplier Management is the process that ensures that external services and configuration items, which are necessary for the service delivery, are available as requested and as agreed at the service level. Some of the responsibilities of this process are:

To ensure that the supplies are made as per the pre-defined requirements and service levels.

To ensure that every supply runs through a set of standardized steps and procedures in order to ensure repeatable and predictable results every time.

To manage the risk to normal service operation due to lower control levels and accessibility inherent in using external suppliers. This involves the periodic assessment and testing of supply quality and service levels provided with the supplying organization.

To document analyze and review every supply decision and activity.

The best way to handle all this is to implement a well defined and formal Supplier Management process complete with a Supplier and Contracts database and Supplier Manager. The basic sub processes within the Supplier Management process are:

Supplier Request Recording

Supplier Selection

Supplier Evaluation

Supplier Negotiation

Supplier Service Delivery

Supplier Renewal /Termination

The proper execution of these sub processes will ensure the smooth and efficient function of the Supply chain. The act of receiving supplies from another organization is, therefore, seen to be an important one and should be given the importance and respect it deserves by proper planning and execution of a formal process for it.

Testing Maturity & Improvement

2009-10-05T14:43:00.000-07:00

Testing is an important and significant part of the product or service lifecycle. This is true of any industry but more so in the case of IT where the sheer complexity of the trillions of bits and bytes zipping around bring about an incredible permutation and combination of possible ways things could go wrong. To counter for this complexity the implementation of a high level of testing maturity is essential within the IT organization.

For overall organizational maturity, organizations can avail of CMMI and its 5 maturity levels. Testing also has 5 levels of maturity within the Testing Maturity Model (TMM) that integrates well with CMMI and other methodologies. Furthermore, the Test Process Improvement model also exists that has been developed based on practical experiences and knowledge of test process development.

TMM was developed in 1996 at the Illinois Institute of Technology, and was designed to be a counterpart to the CMMI model. The 5 maturity levels are similar in definition to CMMIs levels which can be easily viewed online. TMM advocates the implementation of various test processes that increase testing maturity within the organization.

Similarly, TPI offers 20 Key areas with increasing levels of implementation for each area. Some of the key areas (not all) include:

Test Strategy

Moment of Involvement

Estimating and Time Planning

Metrics

Test Tools

Evaluation

Communication

Reporting

As may be deduced, this is a far more structured approach than the old fashioned write a few test cases at the last minute and frantically test till midnight strategy that some organizations are utilizing to this day. Moving beyond simply preparing for testing by creating test cases and test plans is simply not enough. It is now imperative to be optimizing the test processes and continuously improving to be at the right combination of efficiency and quality.

Simply put, organizations should make themselves aware of the latest in testing techniques and methodologies like TMM and TPI and implement the recommended processes before the competition does. Not doing so will only put the organization at an unnecessary disadvantage that is a great handicap in today’s difficult times.

The Rain in Spain

2009-09-28T01:57:00.000-07:00

When Dr. Higgins attempts to improve Eliza Doolittle’s speech in My Fair Lady, he starts with the basics: practicing speaking with marbles in her mouth, repeating basic sounds and words, the most famous being “the rain in Spain is mainly in the plain”. The parallels with an organization seeking to improve its processes are similar in that the basics must be mastered first before one can be the belle of the embassy ball.

What are some of the basics that an organization can put into place while attempting to improve? Some choices are:

Strategy: Easily the most neglected area of organizations worldwide and IT organizations in particular, certain basic techniques of Strategy should be implemented. While full blown strategy methodologies might be a bit much for the beginning effort towards improvement, fundamental techniques of demand analysis, financial management and portfolio management should be implemented.

Customer Point of Contact for Negotiation: While organizations do have this in place in some fashion, it is rarely enacted formally enough to bring its true value and benefits to the table. ITIL’s Service Level Management process is a well defined methodology for achieving this objective. The ability to not merely interact and form a point of contact with the customer but to build a relationship and understand their needs allows for superior alignment of IT with customer’s requirements. This effort returns rich rewards and is definitely much value for money.

Change & Configuration Management: Again implemented by most organizations but not adequately. A good first step for organizations committed to improvement would be to evaluate what they have in place and tighten up and further align with what users require. At an organization that I consulted for in the past, they had a home grown Change/Configuration management tool that had fields and options that users did not need or use and did not have needed fields and options. Clearly they could have benefitted immensely with a properly thought out tool that fitted with their needs better.

Service Desk, Incident and Problem Management: Another set of those processes that most organizations do have in place but could desperately use an overhaul and update of. Common service desk shortcomings are lack of current information made available to service desk personnel, increasing call volumes and increasing and more complex changes to the service. Incident and Problem management also suffer from lack of communication from change and configuration management typically.

Continuous improvement: While there may not exist an organizational maturity to reach six sigma levels at the present, certain basic improvement techniques can certainly be implemented. A basic technique of Root Cause Analysis and resolution to prevent similar mishaps occurring in the future is easy and requires minimal investment. Therefore, there is no reason to not implement a RCA system of continuous improvement, no matter how limited resources are available in the organization.

It is often argued that times are too challenging or resources not available to implement process improvements by those not enthusiastic about improvements. However, there are small and simple steps that can be carried out that yield rich returns for the effort expended. It is possible to get started without a great deal of investment and disruption. With the improvement and stability gained with these initial steps, further and more complex process improvement endeavors can then be undertaken. Even if an organization is dedicated to a large scale process improvement effort, the basics must first be completed successfully. Remember, the rain in Spain is mainly in the plain.

Continuity

2009-09-21T11:53:00.000-07:00

Service continuity is now an expected feature in any organization’s portfolio whether IT or non-IT. In the past, customers were sympathetic and understanding regarding disaster events that unexpectedly disrupted services. However, nowadays, organizations are expected to have accounted and planned for possible disaster events and to prepare and execute continuity plans in the event of the disaster actually occurring. Finally, after the dust clears, the operations should be brought back to a normal state.

IT organizations are expected to manage service continuity and this is generally included in the Service Level Agreements when the services are being negotiated and agreed upon with the customer. An IT Service Continuity Process with a Service Continuity Manager as the process owner should be established to carry out this activity on an ongoing basis. The process should then create a set of IT Service Continuity Plans that support the overall business continuity plans of the organization. The plans should identify possible disaster events and the contingency and continuity activities that should occur if the disaster does strike. Furthermore, the plans should include a description of how a return to normal service operation should occur after the disaster is over and the contingency plan is no longer necessary.

After the creation of the continuity plans, regular Business Impact Analysis (BIA) activities should be carried out to ensure that all the plans are in sync with changes that have been made to the service and organization.

Other activities of the Service Continuity Process include assisting the Change Management in assessing changes for any possible impact to service continuity and working with suppliers and the Supply Management Process to ensure supplies are made during a disaster event.

Of course, during the occurrence of the disaster event, the IT SCM process comes into the forefront and initiates the contingency plan in order to continue service delivery to the customer. Service Continuity monitors the situation until the disaster event subsides and then presides over the transition back to normal operations. To conclude, the process records the success of the continuity event and makes notes for future improvement.

Disaster recovery and service continuity are no longer a luxury but a necessity in today’s market. Organizations must take service continuity seriously in order to maintain customers in the competitive environment we live in now.

Security

2009-09-15T03:05:00.000-07:00

In the good old days, security meant a guard with a gun or a well trained Doberman that refused food from strangers. Now, we have hacking, phishing, identity theft, viruses, spyware, adware and a host of other malicious attack techniques. Over and above this, an aspect of security that is generally not considered as deeply, there exists the possibility of problems and issues occurring simply due to non-intentional, non-malicious errors. An example of this might be that due to a bug in the code, sensitive client’s information is available to view by everybody. This wasn’t a deliberate move on the programmer’s part but simply an error in the code. However, the net result was a compromise in the security level of the application.

The solution to security issues is, of course, a well defined and implemented security management process. The cornerstone of the security management process is the overall security policy for the organization. The Service Level Agreements of each service should also include security requirements that can then be individually addressed.

Security activities can be divided into the following steps:

Planning

Implementing

Evaluating

Maintaining

Reporting

Controlling

Security activities can also be broken down into the following types:

Preventative – such as firewalls, login requirements, ID cards etc.

Reductive – backups and testing etc.

Detection – Antivirus and antispyware software, network intrusion monitoring etc.

Repression – Blocked login after 3 failed login attempts, card retention after failed pin entry etc.

Correction – restoring backups, removing viruses that have entered the system etc.

Therefore, it is clear that a lot of thought and work must be devoted to security in order to maintain the security requirements that are considered part and parcel of any product or service nowadays. Security must be a consideration right from the very beginning when a service is being conceived at the strategy stage and should be designed into the service. Too often, very superficial security considerations are made in the beginning which results in inadequate security of the final product. Organizations must now consider security as important and significant as any other aspect of their organization’s functioning.

Taking Stock

2009-09-07T14:40:00.000-07:00

In my experience, most organizations do not have a good understanding of their capabilities. I do not mean that they have not taken a good inventory of what they possess. Sure, they probably have a list of how many laptops and desktops are scattered around the office and the number of employees pounding the keyboards. They know how many licenses of Windows and Office are out there and the number of desks and chairs. The problem is that they do not have a good understanding of their organization’s capabilities; what the organization can achieve in how much time and more importantly what it cannot achieve.

The definition of an asset in the context of IT is a combination of resources and capabilities. Resources are defined as direct inputs for production and some examples are financial capital, applications, infrastructure and people. Capabilities represent an organization’s capacity, competency and capability for action. Some examples of capabilities are management, knowledge and processes. Generally organizations maintain a good checklist of their physical resources but have a poor idea and understanding of the less tangible capabilities that they possess. This lack of understanding makes management more challenging and in particular, makes improvements difficult to implement. After all, how can you improve that which you don’t understand in the first place?

Improvement is by no means the only aspect that suffers when an organization does not have a good understanding of itself. The ability for IT to align itself with business and to support business processes also suffers. So does agility and the ability to make quick changes which is crucial in today’s world. Financial estimating is also highly inaccurate when the capabilities of an organization are not understood completely.

Therefore, it is clear that an organization must understand its capabilities completely and move beyond just an inventory stock keeping of its resources. How does an organization go about understanding its capabilities properly? The first step, of course, is to keep a good stock of the organization’s resources as they are the building blocks of capability. A well setup Configuration Management system is crucial in achieving the ability to keep tabs on the resource items. The configuration Management System should also maintain relationships between the items that allow for an understanding of how a change in one item will affect another item or a system.

Next, a reliable process of documentation must be setup and maintained. Arm in arm with the documentation process, a system of collecting and analyzing metrics must be created and maintained as well. Metrics must be carefully collected and archived for future reference.

Finally a system of modeling should be setup that utilizes all the aforementioned data to provide a realistic estimate of the organization’s capabilities. The modeling should be set up to predict finances and costs, schedules, technical complexities and project and service deliverables.

With all this setup and relevant information available, management can make crucial decisions with confidence. Furthermore, the organization will make accurate estimates and will be extremely agile and better aligned to customer’s requirements. Simply by understanding one’s own self.

Booms and Busts

2009-08-31T11:27:00.000-07:00

The current financial conditions are unlike any previously seen in the history of the world. A perusal of the last 15 years indicates that cyclical patterns of high growth and frenzied activity alternate with periods of decline and layoffs. This pattern does not seem to be abating in the near future and it seems that booms and busts will be part of a way of life for all of us for the next 15 years as well, whether we like it or not. This situation only reinforces the need for both individuals and organizations to position themselves strategically for the turbulent future advancing upon us. While it may not be possible to exactly predict the timings and nature of the booms and busts, certain basic steps can be taken to ensure a smoother ride.

Firstly, for individuals, training and certifications in their chosen area of expertise should be undertaken in order to separate themselves from the herd. Continuous learning and self-improvement are no longer the activities of a few “nerds” but a necessary part of survival for everyone nowadays. Individuals must also keep up with the latest in industry innovations and stay aware of the latest tools, techniques, methodologies and standards. Those who have kept themselves at the cutting edge will be in a superior position for advancement as companies scramble to make themselves more efficient and competitive.

Which brings us to organizations and what they can do during financial swings from a process standpoint. During the boom periods, companies have a tendency to focus entirely on taking advantage of the business available and not caring much about the way the growth and the new business is being handled. This, then, translates to a skewed and mismanaged growth that is inefficient and costly. Furthermore, the profit generated during good times is rarely saved and kept aside for the rainy day. Companies, like individuals, must save and set aside revenue for use during lean times. The tendency to operate only for the quarterly result is not a good strategy for the long term and senior management and the board should understand and support this way of doing business.

During the busts, the companies should then call upon the revenue saved from the good times and instead of laying off people, put them to work in making improvements and efficiencies for the future. A lean period is a good time for a company or organization to become CMMI certified or ISO certified utilizing staff that are freed up due to diminished business. That way, when the good times roll in again, the company is now more efficient and better positioned to take advantage of the new business.

Granted that this is very theoretical and a bit on the Pollyanna, “in a perfect world” perspective, but what are the alternatives? Haphazardly growing frantically during the boom period and then laying of people and losing market share during the bust? Clearly, both individuals and organizations must plan for the cyclical market conditions that are now a way of life in the most intelligent manner possible. Assuming that things will go smooth and steady in the future is hazardous and foolhardy at best.

The Need for Strategy

2009-08-24T23:57:00.000-07:00

In a study, it was determined that the area of strategy within IT organizations and for that matter even non-IT organizations) is the most undeveloped and under-utilized with the greatest scope of improvement and realizing benefits. I have certainly found this to be true in my own career and dealings with various organizations.

The word strategy instantly brings to mind the concept of long-term planning. A highly reactive response to solving a customer’s immediate problem as quickly as possible is not a strategic activity. However, deciding what new products and service to introduce 3 years down the line is an example of strategic activity. What I have noticed too often in the past is that organizations get into a constant state of firefighting and reactive problem solving which results in adequate strategy never being realized. It is up to management to ensure that sufficient resources are dedicated to strategic activities and kept free of the day to day firefighting tasks.

Strategy is important because it provides the initial roadmap or path to the organizations long term goals and objectives. A wrong decision taken in the initial plan can have disastrous consequences in the long term. Furthermore, possible risks and downturns need to be evaluated and accounted for in the future planning. Over and above all this, the strategy team should evaluate the current products and services and the customer’s happiness with respect to them and make course corrections based on this as necessary. Therefore, it is apparent that the strategy step is crucially important and should not be neglected.

So now that we are convinced of the importance of strategy, how do we go about strategizing? The different areas of strategy, in my opinion, can be broken down to three main components. Understanding of your organization (which includes current products and services, resources and capabilities etc.), understanding the customer (demand patterns, market conditions etc.) and financial information (including Budgeting, Accounting and Charging). These are found in the ITIL body of knowledge as the Portfolio Management, Demand Management and financial Management processes within the Service Strategy Module.

Therefore, with the information needed to adopt strategy for IT services being readily available, there is really no excuse for the implementation of poor strategy. All the greatest generals in history, considered strategy the most important part of their military campaign, beyond even the number and strength of their armies and the technological sophistication of the weapons being used. Indeed, Napoleon Bonaparte won numerous battles simply because of his superior strategic planning. In the battlefield of business, the implementation of correct strategy will ensure economic victory.

IT Information Systems

2009-08-17T23:35:00.000-07:00

It is important that IT organizations design and maintain adequate information systems to facilitate the flow of information necessary to achieve their goals. There exist certain guidelines for these information systems within the ITIL body of knowledge.

The overall information database that houses all the others is called the Service Knowledge Management System (SKMS). All the information systems mentioned below as well as any other custom systems are housed within this system. Some of the recommended information systems are:

The Configuration Management System (CMS) which contains the details of the Configuration Items that exist within the organization and their relationships with each other. This system is within the purview of the Configuration Management Process and the Configuration Manager.

The Service Desk System which contains logs of all service requests and customer incidents. This is managed by the Service Desk function and the Service desk manager.

The Capacity Management Information System (CMIS) which contains details of the capacity requirements for the business, service and components. The existing capacity specifications for the systems in place and the Capacity Plan for all the services also exist in the CMIS. This is managed by the Capacity Management process and the Capacity Manager.

The Availability Management Information System (AMIS) which contains details of the availability requirements at both the service and component level. The existing availability specifications and the availability plan for all the services also exist in the AMIS. This system is managed by the Availability Management process and the Availability Manager.

The Security Management Information System (SMIS) which contains the Security Policy for the organization and the various details of the security system in place. This system is managed by the Security Management Process and the Security Manager.

The Supplier and Contracts Database which contains information pertaining to the supplier and contractors of the organization. This system is maintained by the Supplier Management Process and the Supplier Manager.

These are the primary Information Systems that ITIL recommends that It organizations maintain. Of course, there could be other specific to the company systems as well that are beneficial if created and maintained by the organization.

The inter-communication between these systems is also crucial in making the whole communication flow work and must be undertaken by care by the organization. However, if implemented correctly these information systems provide a useful framework for communication and document control within the IT organization.

Excess Capacity

2009-08-10T10:35:00.000-07:00

The characteristic feature about IT that makes it different from other types of industries is that there is very little potential for storing or maintaining an inventory of the services being provided. In manufacturing, for example, the manufactured product can be stored in a warehouse and sold later. However, in IT that is usually not possible. Of course, in the case of a manufactured application like say Windows Vista, the boxes of Vista could be stored in a warehouse but due to the short lifespan of software products, this could only be done for so long before the app is obsolete and incapable of being sold. Furthermore, as the software apps can’t be recycled (like steel pipes for example) the stored quantities that aren’t sold are a complete loss. And in the case of non-product services the resources (people, tools, apps, computers) are simply sitting idle if not used to full capacity. The loss in this case is instantaneous and unrecoverable.

Now a certain amount of buffer capacity is necessary so that in the event of some problem or spike in customer requirements, things are still under control and manageable. However, a disturbing trend that I have seen very often is that a lot of capacity is kept as a buffer to compensate for poor management of IT. The efficient and consequently competitive and profitable IT organizations manage their capacity so that they are only taking on the amount of resources and capabilities that deliver value and no more. How can this be accomplished?

To fine tune the resources so that just what is needed is being delivered requires a number of factors to be in place. The first and most important is the correct analysis and understanding of customer demand cycles. This is where the demand management process is of great value.

An ongoing formal relationship with the customer utilizing Service Level Management is also crucial to establish the correct point of contact with the customer in order to fully understand requirements and to implement continuous improvement measures.
Financial management is important in keeping track of the expenses with respect to the planned budget. This monetary bookkeeping can greatly assist with keeping track of customer demand patterns.

At the center of it all, of course, is the capacity management process which plans for and monitors service capacity. However, this process cannot function adequately without correct inputs from the aforementioned processes and other sources.

It is possible to fine-tune and optimize capacity delivery to the customer but only after a proper planned effort is made with other processes in place that provide the relevant information. Organizations seeking to be competitive must make the effort to optimize their delivery or else they will be overtaken by competitors that make this effort.

Product and Service

2009-08-03T11:10:00.000-07:00

An observation from being an ITIL teacher is that a common challenge people learning ITIL face is the ability to differentiate between a product and a service. Typically these are folks from a software development and QA background and can only see the world through the actions taken to develop the application.

Let us consider a situation where the IT department develops and releases an application to the business. Now it is easy to consider that the application itself is all that is being provided to the customer. However, the application must also typically be maintained and supported for the customer. The factors involved in this are:

help desk support

incident and problem management

regular contact with the customer

evaluation and analysis of changes needed by the customer

making the changes

releasing the changed application to the live environment

Furthermore, proactive monitoring of availability, capacity, security and disaster recovery must also be performed to ensure that the agreed upon uptime of the application is maintained.

All these actions together provide the overall service for the application to the customer. The application as a product itself delivered to the customer is one thing. But the application functioning as it should at the agreed upon levels for the agreed upon period of time is quite another thing.

Therefore, we see the reason for processes like availability management, capacity management etc. Simply having a department of programmers is not enough as IT now requires the ability to handle all aspects of service provision to the customer. IT departments must evaluate the processes that are required for them to provide service to the customer and then set up and manage these processes within their department. Even programmers should at least be aware of the service aspects of the application being programmed by them.

Connecting with the customer

2009-07-27T10:55:00.000-07:00

There are typically two situations when connection of an IT department with the customer at a significant level occurs. One when initial requirements are being threshed out and the other when there is a problem or issue that needs resolution. Organizations nowadays are relatively mature in their handling of the second situation where issues and problems are reported and resolved. This has been mostly due to implementation of incident handling and help desk processes and advents in help desk tools and applications. However, the interaction with customers during requirements is usually not handled very well. Furthermore, a more proactive approach to customer management is largely missing in most organizations.

The ITIL body of knowledge provides the Service Level Management process for exactly this purpose. The SLM process, which exists in the Design stage of the ITIL lifecycle, essentially performs two main functions:

To determine the level of IT service needed by the business (customer) and

To identify whether the required services are being met or not and if not, why not?

By the successful performance of these two functions, SLM helps to maintain and improve the IT service provided to the business. But more significantly, the SLM process and the Service Level Manager (the SLM process owner) create and maintain a relationship with the customer. It is through relationships that the ability to truly satisfy and even delight the customer can be achieved. The reason for this is that it is rare for the customer to truly understand what they want in technical terms. Therefore, they do not put down in a detailed requirement specifications document all aspects of what they want. The IT staff members following the spec document then faithfully produce a product or service that does not truly delight the customer but meets specifications. To truly understand the unstated and unspecified needs and desires of the customer, a relationship must them be established and maintained by the IT organization. That way, the customer can be guided into including, in a spec document, what they really want but are unable to put down specifically.

The service level manager, therefore, should have both technical skills and relationship skills which include communication and negotiation skills. The service level manager should also be able to act as an emissary for both sides, the customer as well as the IT service provider.

The SLM process consists of the following high-level steps:

Cataloguing the services

Implement Service Level Agreements

Monitoring, reporting and review of actual service levels

Review of Service Performance and adherence to SLAs

Implementation of service improvements as needed

Of course each of these steps has several steps of their own and relevant inputs and outputs. However, it is by following these steps that an IT organization can ensure proper customer service in a proactive fashion.

The old style of informal and unregulated contact and interaction with the customer is no longer the appropriate method of carrying out business. Every IT department should have a formal point of contact with the customer(s) and a proactive process of ensuring service quality and constant improvement. There is no way of avoiding or bypassing this requirement any longer.

Making it Happen

2009-07-20T11:21:00.000-07:00

While it is possible to pontificate and theorize till the end of the millennium, at some point in time, the rubber has to hit the road and certain process improvement steps actually performed. The situation is not unlike those who read up on working out, watch YouTube videos on working out, buy exercise DVDs, talk about working out a lot but never actually work out. They obviously see no fitness improvements and the same is true of process improvement efforts that never actually make the improvement.

A degree of sympathy for this situation is understandable, however. After all, there are numerous challenges in the way of implementing process improvements which I have mentioned in previous posts. A major concern that all stakeholders have with process improvement efforts is the fear that the improvement may end up causing more trouble than benefit. This is particularly true of IT process improvement endeavors that attempt to make significant changes in a short time or the “big bang” style of improvement. I, personally, usually advocate a phased, iterative approach to most organizations. This way, the benefits while not staggering are visible and the risks suitable diminished. The situation is mostly psychological as when management and staff see small changes making a difference, they are more open to the larger improvement efforts and a cascading effect of improvement kicks in. However, all this only happens only when a start is made.

The major shift in paradigm for most organizations now is to go from a department oriented approach to a process oriented approach. However, this involves major changes, upheavals and most importantly the potential disruption of everyday activities that could result in the inability to meet customer targets. The mistake that is usually made is that a proper preparation and accommodation for making process improvement changes is never adequately made. The erroneous expectation is that the IT department can perform and deliver in spite of all the changes and upheaval taking place all around. This is something like expecting your mood to be the same even though the in-laws have showed up to visit.

While it would be great if a large improvement could be easily be made, the reality of the situation usually is that improvements have to be made in small increments. This is because of the aforementioned problems and the fact that people generally have a psychological block towards change and deviation from the status quo. Over and above this, extra staff members have to be hired, proper training doled out and adjustments to the workload and time lines made. In short, the matter has to be looked at from all angles and planned properly. You can’t suddenly decide to implement a process improvement effort after getting charged up attending an ITIL or Six Sigma seminar. The motivation after these kind of events should spark a planning effort for improvement and not the full fledged improvement itself.

On the other hand, with competition as intense as it is, continuous improvement is no longer an option or a luxury. It is a basic necessity and should be included as part of the organization right from the organization’s inception. Therefore, at some point organizations have to make the jump into the water.

Sooner or later, improvement efforts will have to be made. The question is how open and prepared will organizations be to make the efforts. Those that have understood the importance of continuous improvement will reap the benefits while those who attempt to make changes at the last minute will struggle for survival.

Communication Conundrums

2009-07-13T10:21:00.000-07:00

Perhaps the greatest challenge and the main cause of issues and problems in IT (or anywhere else for that matter) is lack of effective communication. This is paradoxical as on first thought, the advance in technology and mobile devices nowadays should actually enhance communication. However, we see that in spite of the high tech capabilities to communicate being available, we still run into many “he didn’t tell me” or “ I was never informed about such and such” scenarios. Why is this?

In my opinion, the primary cause for poor communication is a lack of emphasis on this area by senior management. Communication must be deeply embedded in the very fabric of the organizations architecture and the ones to drive this through are the top management. Communication must be encouraged and rewarded, while a “shoot the messenger of bad news” predilection strictly discouraged.

Therefore, achieving successful communication can be divided into two parts: setting up the infrastructure for great communication technically and setting up the environment for communication “mentally” or “psychologically”.

The first part is relatively easy, as there exists an abundance of technology, applications and devices that create the infrastructure for effective communications. A great deal of information on this topic exists on the net and it is beyond the scope of this blog post to go into it in great detail. Furthermore, it is the other part of the problem, the psychological one that I feel deserves greater attention.

I have yet to meet a senior executive who did not believe in communication and publicly acknowledged the importance of it and yet most organizations that I have interacted with suffer from poor communication. Furthermore, these were organizations that had the latest infrastructure, applications and setup to communicate effectively and yet were facing significant shortcomings in their exchange of information, which in turn led to ineffective performance and low quality products and services delivered to the customer. The answer was that although the environment for effective communication was created technically and logistically, it was not created mentally or psychologically in the staff members minds.

Some significant barriers to effective communication in an organization are:

A change in predisposition required to communicate effectively. Most IT staff members are not used to efficient communication and have to make a shift in their habits to become proficient in this capability.

The formation of tribes or silos that have poor communication outside of their structure. This is something we have all seen and experienced. The QA department, for example, may deal well with each other internally but are in poor communication with the requirements group or the development group.

Too much information. If staff members are overwhelmed by too much information, then it becomes difficult to separate the wheat from the chaff and important information can get missed or ignored.

Lack of standardized terminology within the organization. I have personally experienced test cases being described using three different names at an organization I worked at in the past. Needless to say, the testing was extremely poor and out of control there. This is where standardized methodologies like ITIL and Six Sigma can assist in bringing a standardized terminology throughout the organization.

Control issues & political games. Certain staff members might wish to deliberately avoid the circulation of information for their personal gains. Tactics of scapegoating, blaming, silence and exclusion are typically utilized here to achieve the control goals by people. It is imperative that management discourage this type of self-centered behavior and set a high standard themselves.

With each of these problems, management can play a crucial role in providing a solution by discouraging negative behaviors and setting themselves up as a role model of positive conduct. Especially important is the avoidance of “shooting the messenger syndrome” by management. Of course, over and above management guidance, the organization needs to foster an environment of easy and efficient communication by incorporating a planned communication strategy. The PMI body of knowledge offers the following communication management processes:

Communications Planning – determining the information and communication needs of project stakeholders

Information Distribution – making needed information available to project stakeholders in a timely fashion

Performance Reporting – collecting and distributing performance information. This includes status reporting, progress measurement and forecasting

Manage Stakeholders – managing communications to satisfy the requirements of and resolve issues with project stakeholders

Each of these processes is outlined in greater detail in the PMI Body of Knowledge publication and can be modified to suit the organizations individual needs. Clearly, the tools and techniques are available. What seems to be lacking is the determination by all concerned to make it successful.

Communications is the lifeblood of IT and just as a body with poor circulation will be host to disease and degeneration, so will an organization suffer from an array of problems and inefficiencies if communication is not managed and cultivated properly. It is the organizations own interest that the implementation of world class communication practices is given high priority and attention.

Portfolio Management

2009-07-06T10:21:00.000-07:00

The products and services that an organization offers to its customers have a life span encompassing conception, development, introduction, growth, maturity, decline and termination as shown in the figure below.

It is up to the business to analyze the market conditions and customer needs and determine when a product or service should be introduced and what the functionality and specifications of the product or service should be. Business, also determines when the product or service has run its course and should be retired from the active pipeline. IT, too should view its connection to the business as a set of services that it provides to its customer (the business).

IT at a fundamental level is a set of services utilized by the business, typically applications and infrastructure provided by either internal IT departments or external service providers. Organizations are now less focused on IT infrastructure and applications than on coupling the infrastructure and applications internally to automate end-to-end business services and to manage them the business services efficiently. The challenge here is the successful matchup of business needs with IT infrastructure. Service Portfolio Management is the process that at the strategic level ensures that IT provides the business with what the business needs presently and will need in the future. The steps involved in achieving this Service Portfolio Management are:

Define: what IT services exist and what would be needed in the future

Analyze: based on company’s goals and objectives as well as finances available

Approve: formal decision of stakeholders on what course to take

Charter: officially begin the action that has been decided on whether, to create a new service, refresh an existing service or to retire an obsolete service

The point here is that it is not just the business services that are being defined, analyzed, approved and chartered but the relevant IT services that are needed to make the business services work. Companies must now think in terms of IT as a set of services to the business and not just a group of applications and infrastructure. The apps and infrastructure make up the IT service which then supports the business service. The business service makes the sale which brings in the cash.

Therefore, it is important that IT services are planned for simultaneously as business services being planned and implemented with appropriate communication between business and IT. For example, in the Steel Pipe company example in a previous post, the business portfolio would consist of steel pipe 2 feet long, 4 feet long and six feet long. However, the IT services would include email services, laptop and desktop services, networking and internet services, CRM services and programming services of the heavy machines utilized in manufacturing the pipes. If the company was attempting as part of its business to add a new range of steel products to its business portfolio, the IT department of this company should understand what modifications it would need to make to the IT services being offered to the business. If this new business required IT to now develop its own applications as opposed to purchasing off the shelf applications, IT services would have to add Application development and testing to its “menu” of services. This would logistically entail hiring staff and purchasing desktops and servers and operating systems etc. However, looking at IT as a service to the business, we now have a new service that needs to be setup by IT. Clearly, the earlier IT sets about setting this new service up the better for the organization.

Very often IT is not involved in the analysis of how the services it offers to the business should be modified until far too late. It is a sign of high organizational maturity when the alignment between business and IT occurs at the strategic planning stage and not later on in the game. This then leads to a smoother delivery of the required services with fewer defects and less chaos and inefficiency as things have been planned early on and not at the last minute. Less problems, better service and higher employee morale are the result. All of this makes Portfolio Management a necessary process for any IT organization.

Financial Order

2009-06-29T09:28:00.000-07:00

An interesting, and in my opinion, welcome, trend taking place nowadays is the financial accountability that the IT departments are being held up to. In some cases, companies are choosing to subcontract out the work to outside IT firms that provide the results without going over-budget rather than their own IT departments that are constantly in arrears and perpetually asking for more funds.

The old paradigm was that IT would ask the board of directors for as much as they could and then try to deliver the promised work with the given funds. If the money ran out, then they would go back to the board for more. Needless to say this was not a solution that was going to work in the long term and IT departments are now facing the fruits of what they have sown. Namely, being thrown to the side as the work is given to those that can deliver as promised.

The long and short of it is that IT, even if it only service internal customers within the organization, must now handle its finances adequately. While it does not need to go into the complexities that the accounting and finance department of the organization may go into such as 401(k)s and IRA accounts and so on, certain basic bookkeeping and accounting is now mandatory for IT departments. Essentially, an IT department must now consider itself a separate company within its parent company; at least as far as its accounting and finances are concerned.

The solution is the application of adequate financial management within the IT department. The ITIL body of knowledge provides a framework for the application of financial management within the IT department as part of the larger framework of the overall financial department of the organization. Financial management essentially consists of three areas:

Budgeting

Accounting and

Charging

Budgeting consists of predicting the spending of money by the IT department during a budget period (usually a quarter or year). This involves creating spending plans and estimating the work to be performed and the cost of performing the work. The monitoring of the actual expenditure vs. the estimated budget and making correction to the budget as needed is also part of the budgeting process.

Accounting consists of providing detailed information of the expenditure incurred by the IT department on a day to day basis, comparing the actual expenditure to the budgeted expenditure and taking corrective action as necessary.

Charging consists of the recovery of the cost of IT expenditures in a simple, fair and affordable way. The IT department may choose to charge or not charge and simply provide budgeting and accounting information based on the policy set by the organization.

When Financial Management is successfully applied, the organization enjoys:

Superior financial compliance and control

Enhanced decision making thanks to availability of financial details

Superior portfolio management due to understanding of costs and benefits and the ability to accurately compute the ROI

Better operational visibility and control

Improved value capture and creation

The serious application of financial management is now a necessity in every IT department and seeking a bailout from the board is fast disappearing as a possible option. IT must now consider itself accountable over providing services as well as handling finances adequately.

Support Amnesia

2009-06-22T09:39:00.000-07:00

The product or service lifecycle can usually be broken in to four parts: the strategy for providing the service, the design and development of the service, the transition of the service to the live environment and the support of the service in the live environment. Very often, the estimate for the cost and effort required during the support stage is unrealistic and below the actual numbers that are experienced. Why is this?

Organizations too often have an inflated sense of their ability to create a product or service that falls within the customer’s requirements of quality and functionality. Due to this, they assume that once the product or service is released to the live environment, there is no further work involved besides taking a few help desk calls from some “non-techie” customers that don’t understand the” jargon” of the manual. The reality, of course, is that several requests for change will be demanded from the customers, which in turn will require corresponding rework, retest and release cycles. This, of course, requires time and resources that were not planned for which in turn throws the scheduling and budget in disarray. A great deal of trouble and anguish might have been averted if only the effort required during support had been accurately forecasted.

Ideally, the product or service should match the needs of the customer so well that very little effort should be required during the support stage. Indeed, the less effort required during support, the more successful the organization has been in delivering the product to the customer. However, as organizations are generally not at this level of delivery competence, they should realistically factor in the effort that will be required during the support stage. At the same time they should also continuously improve their strategy, design and transition stages so that less support effort will be required in the future and the maturity of the organization increases with time.

Having stated the ideal case, the reality is that most organizations do not adequately evaluate the effort required during the support stage. This is caused, in my opinion, by the following factors:

An inability to face up to the unpleasant news of poor delivery and the subsequent requirement for further resources. Management here can play a crucial role by not shooting the messenger and dealing with the bad news in a mature and capable fashion.

Lack of company maturity and metrics in place to adequately understand the status of the product and its true state. A collective effort by the entire organization will have to be made to resolve this.

Unrealistic demands by management on the system. Management should not allow themselves to be seduced by market conditions and demand more than is possible from the capabilities of the organization. It is really their job to have properly forecasted market conditions and planned their strategy in advance with respect to the capabilities of the organization.

A poor understanding of the support stage itself by the stakeholders will naturally result in the inability to accurately forecast the time and resources required to implement support adequately.

When cost and schedule are thrown into disarray by the emergency allocation of resources to support, the areas where these resources were drawn out of will then also suffer. The breakdown of one project tends to have a “ripple” effect that then affects the entire organization’s activities in varying degrees.

Support is easily the most visible stage because this is where the customer actually makes contact with the organization, typically with an issue or problem needing resolution. Of course, in the previous stages customer representatives were in communication with the organization in order to provide requirements and evaluate and approve progress. However, this is where the customers and not just representatives actually connect with the organization for problem resolution. This is where the organization can really impress the customer despite the fact that the customer may have a problem or be in a state of dissatisfaction. Despite all efforts, there will be problems and issues that the customers will experience. It is the way the organization handles the problem and the unsatisfied customer that will determine whether the customer takes their business elsewhere or not.

Therefore, it is evident that support must be planned for with an honest look at the organization’s capabilities and adequate time and resources should be allocated in order to provide proper support. Failure to do this will only cause needless chaos and instability with disgruntled customers taking their business elsewhere.

Too Much Quality?

2009-06-15T10:27:00.000-07:00

Quality is one of those concepts like money, enlightenment or status that everybody wants but never can quite get enough of. What is insidiously dangerous about organization’s and people’s desire for quality is that they usually do not realize that it is simply a metric or measure of the customer’s expectation and must be delivered at that level: no more and no less.

Does that mean providing a lower level of quality because the customer wants it even if the organization is capable of producing a higher level? Yes! That is exactly what I am asserting. To make sense of this seemingly contradictory statement, let us first understand quality and its implied characteristics.

The definition of quality as per ISO is "the totality of features and characteristics of a product or service that bears its ability to satisfy stated or implied needs." This includes the characteristics of availability, reliability, maintainability, serviceability, performance and security as defined by the customer in their requirements.

Availability may be thought of as the ability of the product or service to perform its agreed function when required and is usually expressed as a percentage.

Reliability is the measure of how long a product or service can perform its agreed function before interruption. It is usually expressed in units of time.

Maintainability is a measure of how quickly and effectively a product or service can be restored to normal working after a failure. It is usually expressed in units of time.

Serviceability is the degree to which the servicing of an item can be accomplished with the given resources and timeframes. This is usually performed by a third party supplier and is measured in units of time.

Performance and security are specific to the customer requirements of what task the product or service should perform and what levels of security are necessary. These characteristics vary widely from product to product.

So it may be stated that the sum total of these characteristics at levels specified by the customer make up the overall characteristic of quality which then must be delivered to the customer by IT. But the question under discussion is should an organization provide a higher than requested level of service to the customer if it is capable of doing so? While this was an accepted practice in the past, in today’s environment, it is not a recommended practice. But why is it not recommended? Let us consider an example.

An internet service provider delivers two levels of internet service. One level is at 250 Kbps and the other is at 500 Kbps speed. The price is $30 per month for the 250 Kbps and $40 per month for the 500 Kbps service. Now it might be logistically attractive for the company to provide 500 Kbps to everybody and simply charge $30 to those who signed up for the 250 Kbps service. However, once the $30 per month paying customers get used to the higher level of service, they will complain of service degradation if the service falls below 500 Kbps which is what they are now used to. Even though the company is technically not failing to provide the agreed level of service, as the speed is still above 250 Kbps, the customers will in all likelihood switch to the competitor even if the competitor was providing 250 Kbps speeds. Furthermore, the company will be shortchanging itself because they could enjoy lower operating costs (and therefore higher profits) if they provided 250 Kbps service to the $30 customers and held them at that level.

Organizations with high impact of failure such as hospitals, military, NASA etc. may choose to pursue higher than promised quality levels simply as a buffer to shield themselves against the catastrophic cost of failure. But this is a pre-planned, thought out action and not simply a blind surge towards more quality whether the customer wants it and is willing to pay for it or not.

By and large though, quality is not a holy grail that should be pursued blindly to perfection but in reality simply a metric that should be analyzed for customer demands, cost-effectiveness and return on investment and set to levels that make sense. Then the quality levels should be achieved and delivered to the customer at exactly the stated amounts. Any other path of action will lead to a reduction in competitiveness for that organization.

Testing Tribulations

2009-06-08T10:23:00.000-07:00

Testing is an essential component of the system development lifecycle. However, typically too much emphasis is placed on it to make up for earlier inefficiencies. I deliberated on this topic two weeks ago in the “Building Quality” post where I recommended that quality has to be built into a product or service by performing each step in the lifecycle correctly with frequent checks and balances. That being said, testing is an important part of the overall lifecycle and must be given the importance it deserves.

My goal in this post is to highlight some of the incorrect approaches to testing that I have observed during my travels. I do not propose to go into the details of proper testing methodologies here, as that is beyond the scope of a blog post and moreover is readily available on the internet.

As mentioned, one typical incorrect approach is to rely on testing to rectify poor requirements and design magically. Another common mistake is to produce inadequate documentation and information during the earlier stages resulting in a challenge for testing staff to fully understand the scope of the testing required. This, then, results in poorly prepared test plans and test cases which result in incomplete and inadequate testing that ultimately allows defects to appear in production.

Even if an organization chooses to not incorporate frequent checks during its entire lifecycle, at the very least, care must be taken to ensure that the testing team is given the information that is required for them to complete their task successfully. This consists of involving representatives of the testing team in the requirements discussions at the requirements stage. Test personnel should also review requirements documents and provide feedback from a testing perspective. Design and development should also involve the test team in the creation of the functional specifications and obtain review and feedback from them. Testers should be involved in the display of mockups and prototypes as well, in order to adequately prepare for the testing to come. In this way, when the time for testing actually arrives, the test team will have a deep understanding of the product to be tested and have well thought out test plans and test cases produced. This, then, will result in thorough and detailed testing performed that will effectively detect defects in the product.

The second misstep commonly made is the inadequate allocation of resources to the test team. I have personally worked at a company where they had 3 testers when they really needed 20. As might be imagined, not only was the testing inadequate, it was an extremely stressful and frustrating time for the testers most of whom left the company. Management often does not have an accurate idea of how time consuming writing and executing a test case can be. Management also often insists on operating with the best case scenario forecasted as if simply wishing for the best will result in the best actually happening. Adequate resources must be planned for right at the beginning, during the project charter and made available at the correct times for testing to be performed appropriately.

The third mistake frequently made is that testing is often the first candidate for outsourcing. A very important rule of thumb for outsourcing that I advocate is that an organization should never outsource a functionality that is not under a high level of control and maturity at its home location. If you don’t have it under control at your own place, how on earth are you going to make a success of it when it is on the other side of the planet? Things will only go from bad to worse. However, management taken in by superficial analysis of reduced costs make the transition of testing to outsourced locations far from home which then results in more problems.

The fourth mistake typically made is the excessive trust on automation and other “tools” to bring about magical savings in cost and time. I have covered this issue in my previous posting titled “Automation Angst” which explains that automation can easily result in increased time and cost if improperly implemented. Care must be taken to setup automation for only those situations that will provide a positive return on investment.

With these mistakes being made, testing usually (and naturally) performs inadequately after which it comes under fire. I have always been fascinated by the blame always falling on testers while incompetent business analysts and programmers that are also responsible (if not more so as they are the ones who introduced the defects in the product in the first place) get away scot free. Perhaps readers might comment on this observation? This pressure results in test personnel leaving the organization which only worsens the situation as new personnel have to then be hired and brought up to speed.

Truly, testing must be set realistic expectations and supported in a mature and educated way by management as opposed to the typical “test us out of trouble” mentality. It is in the organization’s best interest to make the right choices as the competitive nature of today’s world will not allow for this kind of immaturity.

Automation Angst

2009-06-01T03:31:00.000-07:00

Automation.

The mere mention of the word evokes feelings of magical fulfillment to the uninitiated. A promise of utopia is invoked; where machines perform the work, leading to reduced operating costs and improved profits. Unfortunately, the reality is that automation is a quagmire of decisions and implementation choices that if undertaken incorrectly can result in wasted resources and delayed and defect ridden products and services. I, myself, have learnt this the hard way in the past during an automated testing implementation project that I was involved in.

The definition of automation is “the use of control systems and IT applications to control machinery and processes resulting in the reduced need for human intervention”. Put another way, automation consists of programming applications to perform tasks that humans would otherwise have to do. Sounds good so far and you would be right. Even the ITIL body of knowledge devotes a section to tools and technology emphasizing the benefits of automation. However, while manufacturing industries have employed automation quite successfully, implementing automation in the world of IT involves added challenges and obstacles.

Let us first consider the areas that could potentially be automated; if not fully, to a partial extent. A sample list of areas that could be setup for automation is listed below:

Testing: Testing and particularly software testing has been a candidate for automation for a long time now and many organizations implement automated testing to some extent. Tools like Mercury Interactive’s Winrunner, QTP and so on are quite common in the industry nowadays.

Service Desk and Incident Management: While at some point in the incident handling process, human interaction is inevitable, a large portion of the process can be automated successfully, particularly for simple queries (like password resets). Automated phone menus that answer frequently asked questions, interactive web sites that answer customer queries etc. are examples of this concept.

Design: Again, while human involvement is inevitable, a lot of work can be automated utilizing design tools. The ability to perform modeling and forecasting during design, utilizing tools, is extremely beneficial.

Process automation: A variety of tools and applications exist that assist with the performance of various processes and procedures. Hewlett Packard and Computer Associates to name a few offer tools that are ITIL aligned.

Availability Monitoring: If an organization provides a network service, it will also have to monitor the network for disruptions. The ability to automate this monitoring capability is very helpful in providing good reliability. Other areas like security, capacity and continuity can also benefit from automated monitoring.

While this list is by no means comprehensive it gives us an idea of the potential for automation implementation that exists in IT. Now let us consider the potential benefits of automation listed below:

Reduced cost due to fewer requirements for human resources and reduced operation expenses.

Higher quality products and services (if implemented correctly).

Better repeatability as machines will have less variations than humans. This in turn leads to reduced defects.

Faster production as machines are generally faster than humans. This results in quicker delivery times.

Ability to operate at all times as machines can be run at night and on holidays.

Attracted by these potential benefits, most organizations take a stab at implementing automation in the workplace. However, there are pitfalls that exist that most often go unconsidered. The potential dangers of automating are:

Overly unrealistic expectations of automation. For example, while some part of testing can be automated, a machine will only report that which it has been programmed to check. If any defects exist outside of its programming they will go undetected. Therefore, the correct balance of automated and manual testing must be implemented.

Inadequate understanding of all the costs and resources involved to implement automation. Often, only the cost of the automated tool is taken into consideration. However, the cost for setting up the automated system and the constant adjustments that must be made as the product or service changes is generally not taken into account resulting in budget overruns.

Incorrect identification of areas that would benefit from automation. A product or service that is in a constant state of change is not a good candidate for automation as the effort expended in constantly updating the automated tool to accommodate the changes will nullify the benefits. An area that consists largely of repetitive actions is a better candidate for automation than an area with complex functionality that does not have repetitive tasks.

Therefore, it is clear that the implementation of automation deserves a great deal of analysis and consideration. Generally a combination of manual and automation implementation is necessary and the correct ration of the two must be properly understood. Furthermore, the pros and cons of implementation should be clearly analyzed and understood. The correct areas for automation should be chosen to provide maximum bang for the buck. Automation should not be viewed as a one time implementation but a repeated iteration of phased implementations that provide more and more automation coverage with each implementation.

To summarize, intense competition and evolving technology necessitate the use of tools and applications to take away the burden of work from humans. However, a well thought out plan to implement automation must be undertaken otherwise the consequences are unforgiving.

Building Quality

2009-05-25T09:40:00.000-07:00

Quality has to be built into the product or service with each step in the lifecycle, from inception up to deployment to the live environment and continuing on with excellent customer support. While this seems quite obvious and elementary, more often than not the burden of quality falls entirely on testing before release to production. In other words, typically quality is attempted to be “tested into” the product as opposed to built in from start to finish.

You cannot “test” quality into anything.

Let me repeat that. You cannot “test” quality into anything.

At the most you can unearth defects while testing and put a stop the release on hold but you cannot infuse quality into the product at the QA stage.

The only way to build quality into a product or service is to ensure that each and every step in the inception, creation, delivery and support of the product is performed correctly and to specifications. You cannot have poor strategy, poor design, poor development and then attempt to sort it out by placing enormous pressure on the QA team. However, this is what happens 90% of the time. In my own personal experience in the past, I have very often been in this situation as part of the quality assurance team. We would inevitably find ourselves testing like crazy just before a release with defects being uncovered left and right and unplanned rework and retesting being setup that played havoc with schedules and sleep cycles. I believe that it is a combination of lack of awareness of the right methodology and the characteristic of human nature that “likes to wait till the last minute before kicking into high gear” that is responsible for this situation at so many organizations. Mostly, though, I think that it is a lack of awareness and a stubborn refusal to implement the correct methodology that causes this strange predilection towards “testing” quality in to a product or service.

Let us consider the correct way to manage the design and delivery of a product or service with quality being built in properly. The figure below shows the various stages in the lifecycle along with key steps that must be undertaken during each stage to ensure quality (as always, click on the image for a larger version).

As may be observed, customer involvement and approval occurs at every stage of the lifecycle including inception. If any issue is found during the customer interaction and review at each stage, the problem can be addressed and resolved at that stage itself. The error usually made when the correct methodology is not followed is that the customer representatives see and experience the product at the time of release to the live environment. At this point, if there is an error or deviation from customer expectations, it is too late to make any sort of meaningful correction. If corrections are made, they usually cost a great deal and cause severe schedule overruns. With customer opinion and feedback being received right from the beginning, errors and potential problems can be sorted out straight away at greatly reduced cost and effort expenditure. And when the testing stage is reached, a much more mature and stable product will be brought in for testing resulting in fewer defects being uncovered and less rework required.

Clearly, quality has to be built in to a product or service with each step that is performed. Any attempt to create quality by simply performing large amounts of testing prior to release is absurd and infantile. It is quite puzzling that so many organizations stubbornly insist on carrying on with this erroneous approach.

ITIL At Your Service

2009-05-18T00:26:00.001-07:00

“People do not want quarter inch drills, they want quarter inch holes” - Professor Emeritus Theodore Levitt, Harvard Business School.

Service is defined as “a means of delivering value to customers by facilitating the outcomes that customers want to achieve without the ownership of specific risks and costs”. In other words, it is the ability of the provider to supply their customer’s wants and needs effectively, reliably, securely and economically.

A welcome paradigm shift currently taking place in IT is the service oriented approach towards IT management and governance (not to be confused with Service Oriented Architecture which is a development technique). This is a move towards viewing the value provided to the customer as the paramount service that the IT department provides to the customer. In the past, the IT department was usually so caught up in achieving technical excellence, that alignment with the business was lost. Due to this missed alignment, the external customers would be unsatisfied as their needs were not being adequately met and the company would suffer loss of market share and profits.

The old paradigm was the “product” approach in which the company that made more of the product for cheaper and sold masses of it was considered the winner. Thanks to far stiffer competition now, the customer has the ability to quickly and easily shift loyalties and patronage to the competition. Therefore, the focus now is the satisfaction of the customer to the point that the customer will not even consider shifting to the competition. This can only be achieved by pleasing (or as some like to say, delighting) the customer at many different levels.

ITIL is the hottest buzzword in the world of IT these days with widespread interest in training and certification as well as implementation. In my opinion this is a desirable development and in this post I would like to provide a brief summary of ITIL and its benefits and how it ties in to the new challenge of delighting the customer at all levels.

ITIL stands for Information Technology Infrastructure Library and as the name suggests consists of a standardized definition of various processes relevant to IT. The “library” reference indicates that like a library, the body of knowledge is capable of being used in parts or all together as a whole. After all, you can read all the books in a library or only one or two. The choice is made based on what is needed. If ISO/IEC 20000 certification is being attempted by an organization, however, then all the processes recommended by ITIL must be deployed to at least the prescribed minimum amount.

ITIL is structured around a service lifecycle approach. The service lifecycle consists of 5 major phases: Service Strategy, Service Design, Service Transition, Service Operation and Continual Service Improvement. The figure below describes the interaction of the phases at a high level.

As shown, Service Strategy is central to the successful delivery and support of services to a customer. This is because all the other phases of ITIL regularly refer to Service Strategy with their current state and metrics throughout the service lifecycle. Not only does Service Strategy initially create a strategy for a service and provides high level requirements to Service Design, this phase also proactively monitors success of the strategy implementation from data provided by all the other phases at regular intervals and decides if the current strategy is appropriate. Modifications to the strategy are made, if necessary, and the updated strategy is then provided to and followed by the other phases. The processes within Service Strategy are:

Service Strategy

Financial Management

Demand Management and

Portfolio Management

Together these processes assist Service Strategy to set objectives, policies and guidelines for Service Management successfully.
Service Design provides guidance for the design and development of services and Service Management processes successfully. Based on initial high level information provided by Service Strategy, Service Design provides the creation of services and related processes that are required to accomplish the service delivery and support to the customer. The processes utilized by Service Design are:

Service Level Management

Service Catalogue Management

Capacity Management

Availability Management

IT Service Continuity Management

Information Security Management and

Supplier Management

Service Transition ensures the quick transition of services to the customer without disruptions by building capabilities that facilitate this functionality. This involves the management and coordination of processes, systems and functions that package, build, test and deploy a service in to production. The processes utilized by Service Transition are:

Transition Planning and Support

Change Management

Service Asset and Configuration Management

Release and Deployment Management

Service Validation and Testing and

Evaluation and Knowledge Management

Service Operations ensures efficiency and effectiveness in the support of delivered services to the customer. This is a critical phase as the customer, who is the source of revenue, is provided the service at this stage. Customer interaction with the organization also occurs here making it the “face” of the organization to the customer. The Service Operations processes are:

Event Management

Incident Management

Request Fulfillment and

Problem Management and Access Management

Service Transition also utilizes the following functions:

Service Desk

Technical Management

IT Operations Management and

Application Management

Continual Service Improvement has a role throughout the service lifecycle and seeks to improve the design, transition and operation of service provided to the customer constantly. ITIL provides a guideline for a 7-Step improvement process model to facilitate constant improvement. The 7-Step improvement model consists of the following steps:

Define what you should measure

Define what you can measure

Gather data

Process data

Analyze data

Present and use information

Implement corrective action

This model is utilized not only to improve the service but also to improve the processes themselves as needed.

As may be observed, these five phases of ITIL provide processes that cover significant areas that an organization may need to work on. The beauty of it is that each process consists of standardized pre-determined steps including input information, output information and metrics produced. Therefore, a structured and repeatable way of implementing the steps required for service management can be utilized by adopting the ITIL methodology eliminating the usual chaos and inefficiency typically associated with IT.

Brave New World

2009-05-11T09:16:00.000-07:00

Organizations face significant challenges today as opposed to 20 years ago. The rapid advancement of technology is the primary reason for this as people can now obtain information quickly and easily, make changes to their financial strategies with the click of a button and research doctors and their feedback by past patients from their armchair. The result of this technological advancement is that the customer (whether a customer of donuts or a customer of software) is extremely savvy and aware. The customers, themselves under deadlines and obligations caused by this state of affairs, cannot afford to be sympathetic to disruptions in service availability. Loyalty from the customer is now becoming less and less dependable and providing service to the customer in such a way as to retain their patronage ranks paramount in the minds of organizations nowadays.

To illustrate my point, I would like to compare the interaction of a Bank with its customers 20 years ago as opposed to today. The differences may be laid out as follows:

Services Offered: 20 years ago, a bank offered basic services and a few rigid loan possibilities. Today, a vast portfolio of services is offered by even the smallest “credit union” type of bank in order to service the more sophisticated customer's growing list of demands. Therefore, services offered have grown more numerous and complex.

Availability: In the past, a bank was accessible by the customers only if they physically visited the premises of the bank. Banking activities could only be carried out during the typical 9-5 hour range and not much was available during the weekend. Today, customers expect access to banking activities 24x7 through a variety of means such as telephone, internet, cell phone and other devices. Thus, availability expectations are now much higher than before.

Incident and Problem Handling: Decades ago, a bank could count on a certain degree of patience by the customer when things went wrong and customer expectations were not met, allowing the bank enough time to restore service levels. Today, the customers will switch to the competitors services in a heartbeat due to pressures and deadlines that they themselves face. Hence we may state that incident and problem handling expectations have increased tremendously.

Disaster Recovery: In the past, banks could expect a certain degree of sympathy and understanding in the event of a disaster (e.g. fire) that disrupted services. While sympathy might still exist in the hearts of customers today, due to the customers themselves having to adhere to a high level of expectation to their own customers and/or superiors, they will reluctantly switch to the competitor’s services in order to stay solvent. Therefore, effective contingency planning and handling of disasters is a must today.

Security: 20 years ago, a heavy vault and a man with a gun was all that was required by a bank (well, maybe several men with guns) as far as security was concerned. Now, we have hacking, phishing, identity theft, piracy, social engineering and a host of other modern threats. Security issues and the means to counter them are now far more numerous and complex.

Financial Management: In the past, while banks did meticulously maintain their accounts, the regulation and reporting of financial statements is now far greater than before. Financial management is, therefore, more involved and complex as well.

Ability to Change: In the past, banks were often compared to elephants or dinosaurs, mocked for their inability to change. Now, agility is a crucial attribute of survival with the bank’s ability to bring in new and improved services to the customers being a significant means of achieving greater market share and profits. The ability to change quickly, without causing disruption is now a very important attribute in any organization.

Customer Relationship: In the past, customer needs were minimally analyzed. Products and services were usually devised while thinking of customers as a group and individual customer needs were largely ignored. Today, individual customer service is the norm and special products and services are created routinely for singular needs. Therefore, establishing a relationship with and analyzing and understanding individual customer needs are extremely important today.

It is thus illustrated that the challenges organizations face today are greater in complexity across all aspects of management and customer interaction as compared to the past. What is more alarming is the trend for the future seems to indicate an even greater increase in complexity and customer expectations. Therefore, it is imperative to get organized not just for today but also as preparation for an even more challenging and demanding future.

The ITIL (Information Technology Infrastructure Library) set of best practices have been created with these challenges in mind. ITIL provides guidelines for Availability Management, Portfolio Management, Incident Management, Service Continuity Management, Financial Management to name a few. The reader will notice that these processes correspond exactly with the challenges detailed above. Next week’s post will focus on ITIL so please stay tuned for that information.To summarize, it is a brave new world we are plunging into at breakneck speed. Only a disciplined approach utilizing industry standard best practices will enable companies to stay competitive and ahead of the competition. All employees from top management to the individual workers will have to adopt a philosophy of continuous improvement or the harvest will be unmerciful, as recent events have demonstrated to us all too vividly.

Documentation Dilemmas

2009-05-04T09:32:00.000-07:00

Two areas that I have always found lacking in almost every organization that I have interacted with are metrics and documentation.

While the reasons for lack of effective metrics application in organizations are varied and include psychological mind games and politics, the reasons for poor documentation are simple. They are laziness and the misconception that “things will get along fine without proper documentation”. Truly, this is an area that senior management can influence easily; gaining a lot of return for a small amount of effort expenditure.

Detailed definitions of standards for documentation exist in abundance on the internet. Therefore, the focus of this post will not be on standards and templates for documents. Rather, the justification for proper documentation and suggestions for ease of implementation of proper documentation will be presented.

The purpose of documentation is to either provide proof or evidence of something or to provide a form of communicating information. While the first reason is generally relevant for adherence to standards (such as SOX) or to backtrack and determine causes of a problem (after the problem has occurred), it is the second reason, documentation as a form of communication, that is proactive and will assist in removing defects “before they occur”.

I, personally, have always been a scrupulous documenter; a quality, that I believe, was inculcated into me at a young age by my parents. While the habit of keeping detailed documents made me efficient at work, I was also considered a bit of an oddity for my documentation habits. When I would attempt to reason with those who preferred less documentation, the standard reply would be “But I know all that. It’s already in my head. I don’t need to put it down on paper.” While this may be true, what about those poor souls who do not have it all memorized? What about new employees of the company that do not know everything? The great thing about documentation is that it allows everyone to be on the same page quickly. It also provides a baseline from which everyone can work together. The benefits of detailed documentation are:

Better communication between business and IT and a properly aligned agreement of the services and functionality to be provided to the business by IT

Better documentation of risk which leads to better handling and management of risk

Improved traceability throughout the system development lifecycle which leads to a better aligned product or service with fewer defects

The ability to make changes quickly and without disruptions which leads to better product positioning by the business and an edge over the competition

Improved disaster recovery capabilities due to properly documented disaster recovery plans

Effective training of new employees allowing them to be productive faster

Errors that are avoided because of clear, well-written procedures

Effective gathering of metrics which can then be analyzed for potential improvement drives and improved pinpointing of problems and opportunities

Improved sales that result from the availability of easily referenced product information

Better scheduling and project management

Improved inter-employee communication leading to less chaos and enhanced employee morale

Therefore, the benefits of detailed documentation are numerous and ubiquitous. It is a shame that fear of a small amount of initial effort derails the documentation effort and all its benefits. It is up to senior management to enforce the proper application of documentation and not let a few tantrums by the staff hinder this important aspect of the organization. It has been my experience that once the initial hurdle of “extra” documentation has been cleared, people generally get used to it and it becomes a part of everyday life.

A technique that I have used often in the past to produce prodigious amounts of documentation has been to utilize existing documentation and simply “cut and paste” new information into the existing format. For example, once a Service Level Agreement has been created, it is easy to start with it and create another SLA for a different but related service in the same organization. This technique can be used for requirement documents, project plans, test plans and test cases. It is generally only the creation of the first document that requires significant time and effort.

Documentation is really at the heart of effectively managing anything, whether IT or any other activity. Other industries have understood and embraced quality documentation techniques and standards long ago. It is time IT adopted these techniques as well.

Leadership Oblige

2009-04-27T10:02:00.000-07:00

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

2009-04-20T01:57:00.000-07:00

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

2009-04-13T02:10:00.000-07:00

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

2009-04-08T22:57:00.000-07:00

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.

Process vs. Neglect

2009-03-30T01:50:00.000-07:00

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

2009-03-23T02:30:00.000-07:00

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

2009-03-15T22:20:00.000-07:00

“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

2009-03-08T01:34:00.000-08:00

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

2009-03-02T03:01:00.000-08:00

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:

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

Resistance by the staff due to:

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

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.