Building Quality

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

“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

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

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.