Chris Doig's Blog

Color Blind Spreadsheets

While working on our Sox projects I was emailing spreadsheets around. To help track progress I "traffic lighted" certain cells: Green for no problem, yellow when I was waiting for someone, and red when I had to do something myself. I was using Excel 2007, but those receiving my spreadsheets were using Excel 2003. Every time I saved the file, Excel 2007 would wand me about a minor loss of fidelity but I paid little attention. That was until one user complained that there were no green cells on the spreadsheet – only yellow.

Now I must admit to being color deficient (or partially color blind). So when I chose green for the cells, it was a bit of a yellowish green. And when Excell saved my spreadsheet in 2003 format, it changed these green cells to bright yellow! My guess is that the 2007 version of the program uses 24 bit color (like a photo), whereas the 2003 version uses only 8 bit color (like a gif file). And when the 24 bit color was downgraded to 8 bit, the yellow green was changed to bright yellow – totally altering the meaning!

So beware when using Office 2007 and 2003 products in a mixed environment. Things can bite you if you are not careful.

Caveat emptor – Let the buyer beware.

In a recent Network World article IT Managers are warned against buying consumer class laptops. The logic implied is that higher prices mean better quality systems. Unfortunately my experience shows that paying more money by no means guarantees that you will get better systems.

In October 2007 I purchased four HP Compaq 8510p systems for evaluation for evaluation purposes, and supplied them to several end users, one of who was our corporate lawyer. Right from the beginning these systems had problems, with the ATI graphics card resetting and with the wireless cards taking over 15 minutes to connect.

Then things went downhill . Our corporate lawyer, who uses only MS Office, had blue screens every day with "infinite loop" error messages from the graphics card driver. (A little web research show that some ATI cards have suffered from Infinite loop errors for over 3 years). A driver update did nothing. HP sent a replacement for the corporate lawyers system. Within a few days the replacement system started blue screening. At the same time my laptop's graphics card started resetting occasionally. So HP sent two more replacement machines. When the first machine would not even boot, saying that the BIOS was not ACPI compliant things didn't look good. Sure enough, our corporate lawyer's machine started blue screening again, with increasing frequency. Eventually she gave it back to me, saying that it was useless. Another user has SAS on their machine. This one green screened – a first for me! (It looked like it went into character mode, showing rows of little green boxes).

With our Sox project taking up much of my time I just haven't been able to get these problems resolved. But apart from that, you really don't expect new laptops that cost about $2200 each to suffer from these problems. Out of 4 machines supplied every single one has a graphics card problem, and at least two of them have wireless problems. Including the replacement machines, the failure rate is over 100%! I am still struggling to get HP to resolve these problems.

Needless to say, we won't be buying any more HP laptops, which is a pity because I really liked them. While this experience can't be typical (if it was, I would expect HP to be out of the laptop business) it does show that paying more for laptops by no means guarantees that you will have fewer problems. If anything, considering the volumes sold, maybe it would pay IT manager to buy consumer class laptops.

Caveat emptor – Let the buyer beware.

Reusability with Standards

In February this year I did a presentation for Teamstudio on Notes Best Practices. Part of that presentation covered standards, and I want to extend an idea on standards by making the following claim: "In the corporate IT world a standard amounts to an agreed upon solution to a recurring problem."

In the software world there is a lot of talk about reusing code. Well, this same thought can be extended (reused?) to go beyond just code. When you create a standard (rule, procedure etc.), you effectively create a solution to a recurring problem. Each time you implement or use that standard, you are taking all the thought & effort that went into creating the standard the first time and reusing it. Let me supply some examples...

• You develop a standard configuration for a Notes client install (or any other software package). Now you company's help desk has just one client install to work with. Every time new help desk people come on board they only have to learn how to support that one client install. Compare this to the situation where there are multiple client installs, each one slightly different.
• You create a standard for your Notes development: all projects must go into under the "Dev\Projects\ProjectName folder, where "ProjectName" is the name of the project. Thus all project files will be grouped in one place. Now, every time a new project is started there is no need to decide where to put the project: just follow the standard. If an old project suddenly needs work, you know exactly where to find it. Compare this to the situation where developers can put projects anywhere they want on a development server, and chaotic mess that results from this approach.

Now, I have often had people say to me "But with all these rules, standards, procedures etc. you are taking away our freedom to be creative". But reality is quite different: standards actually provide greater freedom to be creative. Why? Because standards solve the mundane, recurring problems and leave you free to be creative on the more interesting problems. Do you really want to solve the same problems again and again, or would you rather focus on new problems?

To sum up, creating standards to solve recurring problems and you have reused the effort of solving those problems the first time. While there is a cost to manage standards, the reusability component can lead to significant cost savings. Another benefit is that a standards driven environment is much simpler to manage (i.e. complexity is reduced), and tends to be significantly more reliable. Finally, standards free people from mundane problems, allowing them to focus on more interesting problems. And you though reusability applied only to code...?

IT Management failures

I was very interested to read comments in Ed Brill's blog on a Notes to MS Exchange conversion. Over the weekend Brian Benz  and I were discussing this, and we both reached the same conclusion: The problem with Notes in this particular instance was not a technical failure, but a management failure. Let me explain. If you look at the Microsoft case study you will see that "employee contact information was stored on multiple, incompatible systems". To quote  from the Microsoft report: Mike Cleary, Director of Strategic Technology at RSM McGladrey stated "There was no unified up-to-date corporate phone book on-line, anywhere." Several observations can be drawn from this:

Users require a Notes account to use Notes. In this day and age I can't see any employee of a firm like RSM McGladrey not having an email account. So all employees must have been listed in the Domino Directory at the very least. There may have been multiple domains (and therefore multiple Domino Directories). Usually this happens as a result of acquisitions. If that was the case, then the real problem was that IT management had never deemed it important enough to consolidate all user data into one Domino Directory. A classic IT management failure to prioritize projects correctly.

In any company the HR department owns the people data. When people start or leave, these changes are initiated in HR, and then move out to other departments like Payroll, IT, Facilities etc.. The problem appears to be that there was no system in place to manage people information in the Domino Directory - information like an employee's manager, phone numbers etc. What this indicates is a process failure, or put another way, another IT management failure. IT management didn't see the need to put a process in place to keep people data up to date. Yet clearly there was a need, because it was one of the first things that was done when the MS solution was put in place.

In any corporation People information is very important. While you can store this information in the Domino Directory, most companies have needs that would mean significant changes to the Domino Directory. For this reason they create a corporate directory in Notes. This often starts out as a phone list and grows from there. A good example that I have used in the past is one where users can see the reporting structure, and drill down. See the image below.


Example of a corporate directory showing drill down. Note the (partial) business card in the bottom right frame that includes a picture.
Again, IT management never saw the need for a corporate directory or they would have built one. It is not hard to do, in fact it is often one of the first applications to be build when a new Notes installation goes in. For more power, add Sametime to the mix - a trivial development effort with a huge return. It was only when MS (rightly) pointed out the problem, that IT management realized there was a problem.

Both Brian and I concluded that this company has only done window dressing. The real problems are in IT management and a lack of IT processes. Remember that if an IT process is not documented, it is not an IT process. We both felt that unless there was a significant awakening by IT management, the same problems that existed in Notes would re-appear in the new systems.

One thing that I have always maintained is that when you have problems with Notes (or Exchange, or any other similar system) the real culprit is very seldom technical. The real culprit is that IT management is asleep at the wheel.