Keith O Hudson

From January 1999 to June 2010, I worked at America West Airlines (now US Airways), mostly as a contracts manager for the IT contracts. For two years right after the merger (2006, 2007) I did process re-engineering to bring some of the pre-merger processes together. During my entire time at AWA/USA, I have been passionate about trying to streamline and automate business processes to the greatest extent possible given the tools available, which included primarily mail merge, macros and Microsoft Access. I love computers, and I reasoned that if a business task is capable of being performed by a computer, we shouldn’t have a human doing it.

For instance, when I first joined the Contract Services Group in the IT department as a contract analyst, I discovered the administrative assistant spending close to 40 hours laboriously printing paper copies of the contracts kept in the contract management database system one at a time, since the manager of the group didn’t trust electronic backup.  (He didn’t trust a system that was not within his full control. I’m a lot like him.)  After a little research, I found that the database system was written in Microsoft Access, and that I could connect to the tables through a separate Access database, so I built a new front end for the contract management system that shortened the backup printing task from 40 hours to 5 minutes. I made the first screen we saw when the database opened a summary list of all the contracts that you could scroll through or search on, instead of making the user drill down through multiple levels of screens to find the contract she was looking for.

I revamped the method for entering new contract information so that it could all be entered from a single screen, instead of having to go to six separate screens. I estimate that reduced input time by at least 40%.  I built in a module that allowed us to verify the contents of about 1,000 contract records in the database in an orderly fashion without interrupting our other work, in about 6 or 8 weeks time.  I built a project management database to keep track of the dozens of contracts we were working on at any given time, and over time, enhanced it so that with a single mouse click, we could each see our own tasks, organized by priority, with due dates and next steps.

But since MS Access was not supported formally, if I ever got stuck or my application broke, I was on my own. I spent many hours pulling my hair out trying to find or fix a bug, or trying to learn how to accomplish a particular task that would speed up our jobs.  And it didn’t take very much time to streamline some of our processes.  For instance, when sharing Outlook contacts between 3 of us proved fraught with peril (this was back in 2000), I took a few hours and wrote a phone directory database that had all the contact information for our vendors, so we could all access that information from a single source.  Then, later, I added a button to our contract management database so we could see the phone directory for the vendor of a particular contract with a single click.  Still later, I added a button to display the company’s name and address in a pop up form that we could copy quickly when we needed to address an envelope. Later, we wanted to know how fresh the information was, so I added a field that showed the last time the information had been verified, triggered by a single button click.  I hadn’t heard the term “agile development’ back then, but that’s what I was doing.

When I was introduced to Sharepoint in 2009, I was excited because here was MS Access on steroids, officially supported by the IT department, and with a very easy to use GUI.  However, although Sharepoint was formally supported by the IT department, I soon discovered that the sole Sharepoint administrator was a) swamped, b) hard to understand (he had a heavy accent) and c) had difficulty understanding what I really wanted (which was to learn how to design my own Sharepoint solutions, NOT have him tell me why I couldn’t do what I was trying to do).

After working with Sharepoint for only a short time, I instinctively knew that Sharepoint had the power to do everything I had ever done in MS Access and more — I just had to find out how to do it.  The built in security, the connection to Active Directory with automatic email capability, and electronic workflows all promised to make my efforts to automate business processes much easier than it had been in Access, not to mention automatic versioning and check in check out of documents, and the ability to email documents to a document library.

I just needed a little help understanding how to use the features, and especially, someone to show me how to get started building custom workflows.  I looked for someone who knew more about developing working business solutions in Sharepoint than I did to teach me.  Alas, I was unsuccessful.  The Sharepoint administrator didn’t seem to get what I needed.  I found a couple of dot net developers that had worked with Sharepoint to a greater or lesser extent, but the first just looked at me blankly and said “Huh?” when I asked him how to build a custom workflow. The other one immediately said “You can only do that in Visual Studio,” then proceeded over the weekend to build me a custom workflow without ever asking me what my requirements were.

Then I chanced upon an intensive training course teaching the core features of Sharepoint 2007.  While it wasn’t quite what I thought I needed (I would have loved a 4 day lab on building real world solutions using custom workflows), it electrified me, for it taught me Site Columns, Site Collections, Content Types, and so much more that I had not known before.  And finally, I had someone to show me how to create a custom workflow for Sharepoint using the (free) tool called Sharepoint Designer, and how to debug it.  And during the course, it became abundantly clear (especially after the instructor kept telling me so) that I knew far more about the power of Sharepoint to empower end users to automate their own business processes to speed their work (just like I had been doing for years) than anyone else around me in my organization.

At first, I doubted my abilities, until I reflected on the 11 years of preparation I had undergone to become a highly skilled Sharepoint Solutions Designer. No, I haven’t been working with Sharepoint 2007 for very long, but I have been analyzing business processes, designing a computer-based solution, implementing it, getting feedback from the users, and improving the solution on a continuous cycle, since before Y2K.  My gestation was 11 years long, but a Sharepoint Solutions Designer has been born!

Imagine being able to do the kinds of things I used to do in Access, that without having to wade through tons of VBA code!! Now, just about anyone with the desire to do so can become a business automation wizard.  And my mission is to show them how.

To your prosperity,

Keith O. Hudson