Monday, March 29, 2010

Balance Balance Balance

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.

Monday, March 22, 2010

Those Who Help Themselves

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.

Monday, March 15, 2010

The 8 Dimensions of Quality

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.

Monday, March 8, 2010

The IT Business Gap

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.

Wednesday, March 3, 2010

The Smallness Excuse

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.