A Balanced Approach
Today I want to discuss a balanced
approach to senior IT engagements, which are usually with the CIO.
Most small firms that offer services only offer them to the principal
in the firm as the lead, who is usually the founder. Most large
firms manage the engagement at a senior level, but fairly inexperienced
people do the actual work. In choosing a service provider to look
at a strategic situation, or when doing an audit of a critical problem,
it is very important to go outside of the comfort zone of your “vendor
list” and choose a partner that can get the job done—someone who
tells you the factual truth and resists pandering you.
Some experiences that I have had from my own background clarify my point here. I once engaged someone from a small firm to be a long-term advisor to me when I was new in my CIO position. This person was generally very good, although the person did charge me for the same stories over and over again. The person was very good at conducting requirements specification sessions, and she could handle an eight-hour session without taking notes. In fact, she could recite most of what she heard in the sessions and then create a fairly accurate requirements specification (back in the waterfall methodology days—lots of paper). Since many people edited and reviewed the document, we had a 90% document accuracy rate, which was a great first step. Employing her services in this way was beneficial.
She was not, however, a retail operations guru, and one member of our senior management team asked her to review some store operations procedures. She called me at home (pre-cell phone era) and reported that she uncovered a major problem that she needed to act on immediately—we had a gun control problem. Well, we did not have guns and we did not sell guns, but this very intelligent person believed she had uncovered a major problem that she had to act on at midnight. I told her the store folks were talking about pricing guns, which today would be hand-held wireless terminals for pricing. Store employees use these to put price tags on merchandise. She, however, insisted that I was wrong, and that she was going to take this major problem forward. I told her it might support her credibility with the staff if she went back to the source and got the facts straight. She did, and she continued to look brilliant to our senior team.
Another example focuses on architectural review. If you ask pure software architects to review the architecture of a system, they are going to come back to you with a component review. In the process, they point out the inefficient way that the code components are built and the standards that are applied, and those that are not. But if you have business architects do the same review with the same instructions, you get a review of the interfaces between the systems, including interface deficiencies, and the like. Often times you need both.
I have seen return codes in a multi-tier system that were not properly trapped in a record update process cause a 0.1% failure rate on record updates. The business architect would have missed this problem because it was inside the component in the last application that processed the record. The software gave back a return code, but it was an inaccurate one. The system’s integration test passed the system because the error code was “forced” into the test bed using dummy data—in other words, it was not a full integration test, and the provider of the defective component was not part of the implementation effort. This is a common shortcut because of the use of multiple providers of software components. There is simply no substitute for a full integration test that accurately simulates all potential failures.
Having been in the industry for thirty years, I could go on and on about such things as relative files that lost their pointer for six records and returned the wrong record; memory leaks in Java virtual machines that, at one release of the operating system, caused major slowdowns; and comments from a major systems implementation vendor like, “I am not sure why he fired us. This is the first time we did not have to back it out of production.”
My point is, select your high level service providers wisely. Make sure that they have the experience needed to do quality work for you. Make sure, too, that they tell you what you need to hear, and not what you might want to hear. If the vendors in your Rolodex, or on your “list”, are unable to offer you quality and honesty, then you need to find people who can.
Having worked on both ‘sides’, first as a CIO, and then as a service provider (software and services) in the IT Industry, I have a perspective that affects the way that we, at Dhara, offer high-level assistance to a firm’s CIO. In our company, we also have the experience of working in many environments. One of our other principals has extensive experience in architecture and engineering, another has experience in marketing and executive management, and as I have indicated, I have extensive senior IT management and product development expertise. We only do SmartCIO engagements when they can be lead by one of these people, assisted by the others, as needed. For more information about our services, go to http://www.dharacg.com , or email us at sales@dharacg.com.
Fred Geiger
www.dharacg.com
Some experiences that I have had from my own background clarify my point here. I once engaged someone from a small firm to be a long-term advisor to me when I was new in my CIO position. This person was generally very good, although the person did charge me for the same stories over and over again. The person was very good at conducting requirements specification sessions, and she could handle an eight-hour session without taking notes. In fact, she could recite most of what she heard in the sessions and then create a fairly accurate requirements specification (back in the waterfall methodology days—lots of paper). Since many people edited and reviewed the document, we had a 90% document accuracy rate, which was a great first step. Employing her services in this way was beneficial.
She was not, however, a retail operations guru, and one member of our senior management team asked her to review some store operations procedures. She called me at home (pre-cell phone era) and reported that she uncovered a major problem that she needed to act on immediately—we had a gun control problem. Well, we did not have guns and we did not sell guns, but this very intelligent person believed she had uncovered a major problem that she had to act on at midnight. I told her the store folks were talking about pricing guns, which today would be hand-held wireless terminals for pricing. Store employees use these to put price tags on merchandise. She, however, insisted that I was wrong, and that she was going to take this major problem forward. I told her it might support her credibility with the staff if she went back to the source and got the facts straight. She did, and she continued to look brilliant to our senior team.
Another example focuses on architectural review. If you ask pure software architects to review the architecture of a system, they are going to come back to you with a component review. In the process, they point out the inefficient way that the code components are built and the standards that are applied, and those that are not. But if you have business architects do the same review with the same instructions, you get a review of the interfaces between the systems, including interface deficiencies, and the like. Often times you need both.
I have seen return codes in a multi-tier system that were not properly trapped in a record update process cause a 0.1% failure rate on record updates. The business architect would have missed this problem because it was inside the component in the last application that processed the record. The software gave back a return code, but it was an inaccurate one. The system’s integration test passed the system because the error code was “forced” into the test bed using dummy data—in other words, it was not a full integration test, and the provider of the defective component was not part of the implementation effort. This is a common shortcut because of the use of multiple providers of software components. There is simply no substitute for a full integration test that accurately simulates all potential failures.
Having been in the industry for thirty years, I could go on and on about such things as relative files that lost their pointer for six records and returned the wrong record; memory leaks in Java virtual machines that, at one release of the operating system, caused major slowdowns; and comments from a major systems implementation vendor like, “I am not sure why he fired us. This is the first time we did not have to back it out of production.”
My point is, select your high level service providers wisely. Make sure that they have the experience needed to do quality work for you. Make sure, too, that they tell you what you need to hear, and not what you might want to hear. If the vendors in your Rolodex, or on your “list”, are unable to offer you quality and honesty, then you need to find people who can.
Having worked on both ‘sides’, first as a CIO, and then as a service provider (software and services) in the IT Industry, I have a perspective that affects the way that we, at Dhara, offer high-level assistance to a firm’s CIO. In our company, we also have the experience of working in many environments. One of our other principals has extensive experience in architecture and engineering, another has experience in marketing and executive management, and as I have indicated, I have extensive senior IT management and product development expertise. We only do SmartCIO engagements when they can be lead by one of these people, assisted by the others, as needed. For more information about our services, go to http://www.dharacg.com , or email us at sales@dharacg.com.
Fred Geiger
www.dharacg.com
Comments