Negativity Doesn't Help

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

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

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

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

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

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

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.