for J. William Bennett

William Wrigley, Jr. (1861-1932) once said "When two men in business always agree, one of them is unnecessary."  Without experiential deliberation there can be no change. Without change there can be no progress.  Doing something "the way its always been done" or finding no fault in a faulty process, is as common today as it was in Wrigley's day. Not addressing such issues can render your business unnecessary.

Professional Experiential  Portfolio

for

J. William Bennett

 

Artifacts protected by Password: Some artifacts herein are password protected due to methodology content. For access to these files contact mail@JWBennett.info and I will supply passwords to those with confirmed interest.

Solutions are more than just programming. Finding the right technology for an application, the right tool for the programmer or the right measurement for gauging service level compliance - solutions address the issues, the underlying causes and discrete requirements.

I see solutions coming from two distinct directions: Defining the problem and engineering the solution.  The problem definition stage comes in the Solution Analyst discipline. Engineering from the Programming and Implementation disciplines.

Solution Analysis:

Problem or requirement analysis is an art as much as it is a science.  There is little that can replace experience when dealing with diverse needs.  My broad subject matter expertise allows me to focus the resources available on the best possible areas of analysis.  I know when proposed solutions are unworkable and which have promise.  I know how to test theories and manage scenarios to minimize risk and maximize returns on the analysis.

I often go as far as working in the place of an affected worker to learn the tasks and issues surrounding the requirements.  I visit other IT organizations to see other similar solution implementations, keep abreast of the latest technology trends and attend continuing education seminars regularly. 

I have developed an impressive resume library of some of the top subject matter experts and IT technology leaders in IT today.  I do not hesitate to call on them if the need arises. An effective Solutions Analyst can never rest on his or her  laurels.  This industry introduces new technologies, potential solutions and potential problems each and every day, 365 days a year.  Solution analysis is truly as much who you know as what you know.

Once a solution is decided upon, most analysts must rely on developers to translate the solutions requirements in to functional programming.  It just so happens that over 15 years of my career has been dedicated to systems development. Thus, whether writing the programs myself or directing a team of developers, I have the additional knowledge to insure the end solution meets the requirements.

Even when solutions are found in 3rd party software, commercial-off-the-shelf (COTS) systems or packaged tools, the installation, customization and integration of these solutions is only as good as the project planning and experience of the implementation team.  My experience in project management, integration and implementation is broad and extensive.

Programming:

When a solution requires in-house programming, I have had quite a bit of sole-source experience.  Besides the major developments of JOBTRAC and OPCON/XPS which included hundreds of thousands of lines of code and years of development and support, I have written dozens of smaller systems on many different platforms.  Often the scope and complexity of the development is not a measure of its value.  Frequently it is the ability to 'see' the problem in a different way and develop a solution to the problem rather than a solution to a symptom.

In this list of accomplishments (taken from the Development page), I first list the problem then the solution as designed.

Problem:  Verizon IT (GTEDS) has several regional data centers that report computer usage by task id.  Applications programmers work on projects for over 30 states telephone companies and the time charged to each company by the GTEDS subsidiary is controlled by task id.  There are anywhere from 10,000 to 15,000 task ids in effect nationally at any time.  Task ids are part of the accounting code used on JCL and TSO logons.  They are assigned manually and a group of 5 people in the Tampa, FL headquarters of GTEDS reconciles all the task ids from all data centers every month. They discover and reassign about 4,000 task id errors each month. 

Solution: I wrote an internal SVC exit routine (much like a modern day dll, SCI or driver) that loads a table of valid task ids into memory.  This SVC is dynamically activated, deactivated and refreshable. I then set up calls to this SVC by all JCL and TSO entry points.  In 3 months error rates go to zero. Five people get better jobs.  Billing to state phone companies is done 45 days sooner and is accurate. 

Problem: Interfirst Bank in Texas has a problem with applications programmers putting new programs into production before they are fully tested. Sometimes they are true emergency fixes and test time is not available, but often it's just lack of discipline. One of the biggest problems is an audit trail. There is no positive identification of who did what, when or why.

Solution: Over 18 months in development, the Automated Change Management (ACM) application provided 3 interactive levels of authorization for changes to be applied. I was the sole author of the system. ACM included a front end to IBM's Linkage Editor build program that logged all program update activity to production bin libraries. A central program task was created that applied changes 24hrs a day. A complete log of all changes and their attributes was maintained. Changes could be scheduled or sequenced (don't apply this change until after this job runs or this other change is made, etc.). These features are now standard in many of today's systems, but the user friendly nature of ACM actually made it easier to apply changes than the old process of running your own job. That's still a problem in today's systems. 

Problem: I'm engaged in my first big consulting contract at Cameron Iron Works (CIW) in Houston. They have an accountant as a CIO. He can barely spell CIO, but he is an extremely good accountant. He wants to associate the technical service level objectives (SLO) to something he can understand - financial impact.

Solution: I developed a reporting tool that gathers information from computer task monitors, user logon activity, disk seek data, tape mount data, etc. and compile a report that associates cost of processing with services.  Then produce data on response time and report delivery service.  This data and reporting was successfully used to upgrade DASD and add memory to processors by demonstrating the cost of NOT doing so. 

Problem: Sysco Corp help desk keeps responding to the same 'known problem' over and over. There is no integration between the logging system used to log problems and the technical support people who work on the problems. No priorities no escalation.. a mess.  They are an austere organization. No money will be spent on fancy problem tracking software.

Solution: The only system available to both the help desk and technical support groups was the IBM VM system used for email. Using VM/CMS and ISPF for CMS I developed a CMS Dialog manager using ISPF tables to log incidents and assign responsibility.  An on-line reporting system was developed in VM/CMS to report on status. The status report was made available corporate wide and reduced the status request calls to the help desk by 80%.  The new system also resulted in a 60% drop in problem reoccurrence and a 50% improvement in root cause analysis and permanent solution of a problem.

Problem: Chevron Corporation's General Manager of Global Shared Services is tired of going into meetings and being 'blind sided' with questions like 'When will Brazil's link be back up?' (he never knew it was down!).  He often has no information on the status or resolution of an incident. Root cause analysis takes 20-60 days. The problem is exacerbated by multiple silos of accountability and responsibility. Some services are outsourced, some run by business units, some by central IT.  What is happing, where its happening and what are the impacts associated are nearly impossible to ascertain. An ongoing central deployment of ITSM cannot bridge the silos in question.

Solution: The Downstream Enterprise IT Reliability Information System (DERIS) was designed to provide and end-to-end "critical business process" view of reliability. I started by directing the project team to define the critical 'business sensitive' transactions (e.g. those transactions that represent customer facing impacts to Chevron revenue or customer commitment) and the key revenue generating locations in which they run. I then designed and directed the development of a reliability database, dashboard and a set of synthetic transactions to report the reliability and performance of these transactions from the end-user perspective. In it's first release DERIS is giving Chevron a view of critical transaction reliability (performance, availability and accuracy) by business process, by location, by business unit in a standard SharePoint dashboard.  The next phase will be to connect this capability to ITSM and RCA projects for an integrated system.

Summary:

Problem analysis and solution implementation are probably my favorite challenges in IT consulting.  It is often thought that a consultant with as many years in this business as I is more of a conceptual thinker than a technical practitioner.  This is not the case.  I would rather do it than talk about it; and rather solve the problem than the symptom. 

It's knowing the difference that my experience affords.

Home | Contents | Feedback | Search | Top of Page | Home | Contents | Feedback | Search | Top of Page | Site Help