Thursday, June 21, 2007

Controlling IT Costs; Enterprise Architecture (EA) strategy, a shared lexicon, and enforced change

Tree on the beach. Golden Gardens Park, twilight, Seattle, Washington, USA
To control Information Technology (IT) costs we think about and act within the enterprise as a whole, in part because we sell enterprise and mid-level solutions. We apply an Enterprise Architecture (EA) strategy which at the top level is comprised of infrastructure and communication considerations. This is not just about technical infrastructure, defined or designed by IT, because it is highly likely that such individual solutions (one offs) will not align to core business strategies (vertical needs verses horizontal needs spanning the whole company).

It is not really possible to do this, that is consider the entire company's needs, without significant participation by the business for which we use terms such as Solution Delivery or Product Management. Product and program managers from a solution delivery framework gather information, report back to the business, and return to apply the business strategies to align with short, medium, and especially long term business goals.

This business and implementation strategy focus is a change agent, to reduce siloed thinking, and achieve more horizontal capability across units. We reduce multiple applications, which take time to manage and maintain, and where it makes sense, fold them into one. Because we take security and privacy of our customers very seriously, any applications which may be at risk have been identified and are brought up into our standards. The process of combining risk management goals, application and data reduction streams saves money, although the process of so much change at once can be stressful at the unit, project, and personal levels.

We seek to empower self-service among our partners, customers and employees, for access to all kinds of information they need, and internally reduce redundant data stores, for example referring to customers by one identifier if possible. This is especially challenging in our partner relationships with multiple data stores that contain similar information about customers which are identified in completely different ways. This is the reason for serious data modeling and tight or loose coupling where needed – to retrieve and move information back to the partner systems. We leverage Microsoft software, and then buy, build, minimize or reuse existing systems.

In order to be more successful in our efforts to control IT costs we strive to increase flexibility among existing staff and provide rewards for strategic thinking – this strategic thinking aligns along company-wide goals. We need people with the right skills who work in efficient methods, only including the people who need to be included to make decisions or act. In fact we need to change confrontational and passive aggressive behaviors internally to collaborative personality styles – changing the organizations culture is doable but difficult. For more information I recommend reading "The Heart of Change" by Kotter and Cohen.

The technologies we invest in to help control IT costs are our own. We custom write stuff served up on Microsoft servers and plan to use SharePoint as the UI for our new change request tool. We are substantially reducing and eliminating the number of different applications (SQL stored procedures or XML Blobs mostly) we use and maintain on a daily basis. We are moving from C++ to C#/.NET (C Sharp and .Net technologies).

We use Microsoft software as our strategy to control IT costs - it is easy to manage, and has great support. Some team members keep an eye on relevant Open Source software as competitive analysis.

Our company is getting the maximum value from its data center investment because we have not invested to the level we need for our infrastructure. We expect to remediate this lack of investment after deploying skilled, thoughtful product managers with the right combination of education and practical experience to assist in this effort through the next couple of years.

What is our organization doing to maximize the value from its data center investment? In addition to the other things mentioned we outsource development and support to India, Israel, and developing countries, etc. We also are making use of tax advantaged locations for large savings in transactions.

We are adding metrics and measurements by which we evaluate not just personal progress but internal and external customer satisfaction with our IT initiatives on a project by project basis to self-improve.

The practices which enable us to maximize value from our IT investment are varied and multifaceted. To maximize ongoing investment we are adding solution delivery strategies, planning ahead, and aligning IT with company-wide goals. Of course in our space we have some unique issues, and as a public company even more so. One thing that may surprise you is some of our projects we do end to end locally because of how critical success is. We leverage our best, most successful local managers to produce projects and design larger scale solutions if we determine it is the best strategy – so in this way we are flexible – we don't just out source everything.

We are in the process of reducing the number of applications we need to maintain, and where it is appropriate fold one into another so long as the user interface or back ends do not become unmanageable. We are making over our change request platform from top to bottom which we feel will enable quicker turnarounds on change requests – it is both loosely and tightly coupled where it needs to be. For the presentation layer we choose Microsoft SharePoint.

Conversely, what factors are inhibiting our organization from reaping the maximum value from its data center investments? The factors inhibiting the maximum value include a lack of foresight in strategic planning for long term goals –

1. Putting temporary things together to just meet immediate needs.

2. Focusing on small details and not seeing the big picture.

3. Lack of metrics to evaluate progress, process, and client / customer / partner success.

4. Unwillingness of team members to change or promote change even when it is in their and the companies' best interest.

5. Having too many data centers, identifying customers in too many ways.

How important is productivity within the IT function in our efforts to control IT costs and maximize our data center investment? Functionality, capacity, and reliability far outstrip productivity, but that is only because we have already hit very high productivity goals and exceeded them. Here are some of the metrics we examine:

Metrics
  • Percentage of project budgeted costs
  • Scope requirements
  • Total cost of ownership
  • Traceability
  • Defects rate (sev1, sev2, sev3 bugs - zero tolerance for sev1)
  • Completed requirements
  • Customer satisfaction scores (cust sats)
  • Schedule slippage
  • Flexibility of management styles
  • End-to-end throughput time per client-side user request
  • System extensibility
  • Scalability
  • Maintainability
  • Defects per thousand lines of code (KLOC or by function)
  • Support functionality and documentation availability, and completeness prior to launch
  • Rates of failure
  • Restoration (emergency)
  • Availability
  • Test effectiveness
  • Business acceptance
  • System acceptance (signoff)
  • Average turn around time for service and change requests
  • Number of security or privacy defects (last two should be zero tolerance in launch candidates)
  • Number of post freeze change requests

Among the mandatory metrics used are peer review effectiveness of code, and post mortems and overall customer satisfaction. In other words we do not consider just ontime delivery of products, enhancements, or new functionality.

What is our organization doing to improve productivity within its IT function?
Getting the right people – some people grew with us or came to us with deep knowledge from the school of hard knocks – work experience – we seek to capture the most knowledgeable and either increase their education or find those with both practical work experience and advanced degrees. Good thing this is Seattle with its heavily educated population. New programs at the university level such as Informatics and Information Management are producing the people we need – not just MBAs or Master of Comp Sci - because so much of our development work we outsource to India and developing countries, and IT is not traditionally closely aligned with marketing or sales. We do outsource much of the development work as is possible.

The undergrad Informatics and Master of Science in Information Management programs at the University of Washington are housed in Mary Gates' Hall, renovated and named in honor of Bill Gate's late mother, it's headed by Mike Crandall (Dublin Core, Microsoft, Boeing). So you can see this is the direction we are going regionally, because that is where the spend is. Another great information school is at the University of California at Berkeley, housed in one of the oldest and most architecturally beautiful collegiate buildings on the west coast, South Hall. On the physical level all Berkeley had to do is add wireless. Excellent academics such as the seminal thinker Dr Michael Buckland are there at Berkeley, and business leaders such as Mitch Kapor. Industry wide I think iSchools are having an effect, adding a more well rounded, even playful culture to high tech operations.

Improving and opening the culture is important. Having a shared lexicon is one of the benefits of educated people; those with MSIM (master of science in information management), Informatics, technical MBA degrees can comunicate effectively with highly technical people - this can produce enormous savings and long term cost benefits. Increased, clear, enthusiastic communication saves IT costs.

In strategy meetings, for example, we often include Enterprise Architects to assist in stack ranking program and project development, because this helps reduce redundant systems.

Our organization's ability to measure the return on investment (ROI) or success of its IT investments is “Fair but mixed,” we want ROI to be easily measureable and this means evaluating the correct things, asking the right questions in the first place, not following other organizations techniques, although we examine them as examples.

We are adding ways to evaluate our ROI – we do use business analysis methods. There is always an identifiable way to analyze and measure the relationship of what something costs even if it appears intangible such as Brand protection.

Considering the strategic and tactical stuff we are doing, at the core, creativity is what drives our success. Creativity is always a very difficult thing to measure. In fact it could be said that if you try, you are barking up the wrong tree. However creative thinking around practical goals has provided us success. This is where the ideas around flexibility and being very responsive come to play.

We have found very very high ROI around outsourced projects because they must be clearly defined within the Software Development Lifecycle (SDLC) and Sarbanes-Oxley Act of 2002 (SOX) compliance.

Those people who actually think out of the box are oftentimes not recognized by co-workers and management. Change is perceived as negative among full time staff. We seek to show support for both full time employees and consultants, and change this view and enhance their ability to communicate ideas. That is why our management keeps an open door policy. Unfortunately like any other policies the hazard is that individual managers must believe in our policies around openness and creativity; such self-selecting polices are impossible to enforce.

Our organization uses balanced scorecards, Six Sigma and other types of internally derived quantitative value measurement methods to measure the ROI or success of our IT investments.

The continued use of these methods we expect will substantially improve the management and measurement of our IT investments. Some of the metrics are at the discretion of the product or program manager, others are mandatory. In part we have some success- at issue is adopting metrics and measurement as well as Enterprise Architecture and engaging with open arms increased strategic thinking and planning.

Senior management must come together and present a unified strategy for the entire company – which is a top down management style but it must be embraced from the bottom up. This is within a framework of enforced change as we seek to achieve excellence in all of our business units, especially in core infrastructure – those units which either produce money, or cost money. Some of our key investments we know are lost leaders, but other research will more than make up for those. Enforced change in this context means business units receive minimum budget until they comply.

We are still feeling the effects of the changes the Web brings in enterprise directly and for our customers; we continue to learn from the effects of communities and communication via the Web. The opportunities for growth are so enormous that it is all the more important that we curb spending where it is not required and apply it as much as possible to grow in creative arenas which still have huge untapped profit potential. It is not just about money, among hard core technologists – those who really love it – money is secondary in many ways - it’s about the fun stuff technology can bring as well as the benefit to serve humanity that technology brings.

High tech, information technology, and software development have made some strides to maturity but we are still learning new things; it will be a learning industry, discovering and inventing stuff for a long time to come.

p.s.
Enforced Change is a radically different challenge, and promises different ways of looking at human-to-human, individual-to-corporation, corporate-to-corporate, human-to- computer interactions, etc, which I plan to cover in future articles, so stay tuned!

Saturday, June 16, 2007

Thinking - System Architecture

Along with some very difficult challenges (which I won't go into) there are threads of joy in my new job.

One thing I love about my job as a Solutions Delivery Product Manager is hanging out with other System Architects - when we speak together, imagining and extrapolating about what doing this set of things vs that set of things we can jump into the future and understand what "that" and "things" means - it is so cool that we finish each other's sentences, or enumerate logical parameters to the next state without much explaining.

Man o man that is fun, for me it is the real juice - I just love doing abstract visualizations - just a fantastic stream of energy! Visualizing complex computer software systems is highly thought provoking and exploratory. One System Architect I work with just so gets me and I so get him. We were talking about the future of product activation and digital streams and speaking about digital watermarks and the value of credentials - and had discussed several options over an hour and 1/2 just like it was 5 minutes. From that thread my ideas around the IOS (Internet Operating System) have grown and become enriched. It's funny to think I am a fine artist by nature but the skills needed for visualizing systems are quite similar.

I have real confidence about the peace enhancing properties of the World Wide Web through ecommerce, so such conversations which may lead to that kind of worldwide success are engaging to me on a personal and professional level. I feel we have an effect in the world like a sonic wave of protection through productivity influencing more and more people, moving farther away from war and conflict.

Recently we were meeting about the tax and system implications of tax advantaged locations with our tax finance manager, when my System Architect friend said, "well Linda I don't think those business rules should be part of that software application no matter if the tax advantaged location will be in play a long time."

So the tax guy immediately launched into giving us some explanations and examples of various forms that the business rules were taking in other applications he has advised on - including more than 40 applications in 6 months. That's what we were there for, the expertise that well-thought-out even long conversations among subject matter experts bring to the table.

As I listened to our tax expert speak about the various requirements I visualized what this meant from a system wide point of view, and the future, I reasoned what the system implications were and how flexible they needed to be, how loosely coupled makes sense - as our tax man finished his sentence I leaned into the phone and said - "Sold!" - I swear I could hear my System Architect friend's smile break out.

Later as we wrapped up that same meeting the System Architect said, "so our advice will be to include the business rules within the applications not inside the key selling structure, if there are any objections - speak now or forever hold your peace - going once, going twice, sold!" echoing my sold! statement.

I feel such glee when I get to use that totally abstract part of my brain’s reasoning capacity in such a practical application, even if we will only see one application do this in the next few months (if I still have my job) for a worldwide ecommerce solution. Better yet is being recognized for that ability since so few people understand it.

The other folks in the room know that we are figuring something out, and occasionally, but thank heavens more rarely, someone will become jealous. There is a camaraderie among the System Architects because you have to possess an incredibly developed ability to visualize and extrapolate several functions and their implications, with the solution in mind all at once, finely tuned to what the actual results need to be, and what the capability, capacity, and through-put are. It actually feels electric.

In the past when designing an application as I completed the work, the other system designer /aka product manager I was working with came back with the business and functional requirements and asked me to glance through them gratis. So of course I could not resist and immediately found two logical conundrums with the UI, if you choose this, you will get to this location and that choice is not what you have documented. 'This here? see this is the wrong option here...' and so forth. All of this in my mind, not on paper, not in the flows, not in the writing. It's so fun.

System Architects tend to be sort of giddy when they speak they get so excited - their personalities tend to be somehow on both the sunny and sour side. Maybe there is a little tendency to be know it all but the best among us are very relaxed about this kind of knowledge and skillset.

Dealing with the opposite kind of person, with no visualization ability, and no big picture view whose mad-as-a-hatter level of attention to detail borders on comical and insane - those folks are a real headache and heartache; much harder to deal with because they are so literal and only see what is placed directly in front of them - they mean well but just cannot recognize the value of those with big picture world views. When a micromanager is standing on your dress, it feels exactly as if they are afraid of space, of something which is not in a box - of anything with wings of thought or ideas. Ideas are very scary for some people. It's a quality of change. Change is what brings those flighty ideas into reality.

I read some place this story - haven't been able to find the reference - Bill Gates was young, maybe high school or so, and from another room his mom asked him "what are you doing?", and he replied "thinking", so she asked him again, "but what are you doing?" and he said, "I told you I was thinking -- have you ever tried it?" or some similar statement, "you really should try it sometime".

I empathize with Bill. It's why I consider his use of the term "stuff" to be a technical term.

Monday, June 11, 2007

Phone Tree - just in time - self service safety

"Automated phone: Hello, and welcome to the Springfield Police Department "Rescue Phone"! If you know the name of the felony being committed, press 1. To choose from a list of felonies, press 2. If you are being murdered, or are calling from a rotary phone, please stay on the line.(Bart presses four numbers on the phone) You have chosen- "regicide!" If you know the name of the King or Queen being murdered, press 1.(Bart hangs up)" - The Simpsons

Sunday, June 03, 2007

Hiring Strategies for HelpDesk and Support

Reading four IT helpdesk support and hiring reflection papers (listed below) brought to mind several social issues regarding support that are rarely openly discussed but appear to be true from my own experience. Over and above setting up all the work flow and planning, tracking, and feedback tools for communication and all the myriad processes into the helpdesk and support structures you have to address who you are hiring to do support and what your goals are relative to those employees or consultants.

My recommendation for success is when seeking support engineers is to hire smart, ugly people with social problems, select those from middle class or lower middle class backgrounds who seek approval from others because they will be lifers in the support industry. Select those who may be physically odd but whose motivations are altruistic towards the company and the users. Writing something so harsh and politically incorrect is critical to do when you have solid motivations around it.

Some people who are bright and technical but not as fortunate to be well trained or to have higher levels of self esteem go into the Support industry for a multitude of reasons, not the least is to indulge their technophile passions, and keep their distance from other people while earning a living. They often come from middle class or lower middle class families. Those from upper middle class families often have abuse problems or unresolved self-esteem issues, and tend to be less friendly over the phone or in email. Both sets of people need to earn a living and their needs for social and career development should be integral to the Help Desk or Support managers' view of their staff.

Others find entrance into a technical support job or even customer support services as a stepping stone into development jobs. The structure of the helpdesk and support environment is similar to a development environment, and access to technical goodies is there too, such as the applications, computers, servers, documentation, and other highly technical people from whom they can learn and bounce ideas off, so it is a good career choice in that sense.While working at a large software company as a front line support technician handling anyone who called in on virtually any question, I supported an estimated 18,000 people in a two year time frame, often teaching the users beginner information such as what a menu item was, and that the file menu item was always located in the same place.

When I say we would support anyone, for example I taught an emotional distraught man who had just survived brain surgery how to import a Word document into Aldus Pagemaker over and over again as he sobbed loudly into the phone. I was glad I possessed the emotional fortitude to encourage him and the technical knowledge which made it easy to do. As long as customers had questions and did not swear at me, I answered them; it was not only company but personal policy. Simultaneously I supported accountants seeking to construct complex pivot tables, as well as Disney animation artists working out detailed timing mechanisms for film making, and rocket scientists from Los Altos trying to figure out why their fonts would not display properly in presentations.

So when people say "it isn't rocket science" I always think of that team of rocket scientists telling me that 6 or 7 of the smartest people in the world were in the room and they couldn't figure it out, so if I did, that put me ahead of their team. Of course I figured it out. Immediately I realized that having accomplished that, it was time for me to move on from product support into something else.

The point is I am speaking from experience. My resume reads that I was a technical engineer – it does not address much about what I engineered because I sought to distance myself from being pigeonholed in the support field. As soon as I began diligently looking for a new job within the large software company I worked for, I realized pretty quickly that there was no upward ladder in Support to anything else in the company. In fact if anything the system was unconsciously designed to prevent workers from moving into other groups at the company. Being in support interacting with actual customers was seen as a dirty job that someone had to do, and information collected from customers regarding their needs and wants had no real path for communication. There was no commitment from the company for support technicians or for the information they gathered.

Right about this time three events occurred that changed the way I thought, or you could say, reinforced what I was thinking. First the CEO visited, second we got a new Unit manager, and third - a random phone call from a development manager came in asking questions the company was not answering.

The CEO of the company came to make a rare visit to the Support unit, and he actually supported a DOS user over the phone. The end user was of course completely surprised and was handled the same way as anyone this famous executive dealt with, directly without pulling punches. On his way off to another meeting the CEO stopped and took a few questions. I asked him if he'd be building a new building to house the support staff now or in the future. At least he was honest- he thought about it for a few seconds and said, no, Support would never be housed on the main campus.

At about the same time a new manager was placed in charge of the unit, and not someone hired from within or promoted. This new unit support manager was female, which in a department where the men outnumbered woman 11 to 1 was very rare. Unfortunately we soon realized she had both things we did not need and want – she was technically incompetent and had severe emotional problems.

As a mentor I was often called in to resolve both software and hardware problems. She selected my co-worker and I to support problems she was encountering with her Macintosh, which even then was pretty easy to use. When we began troubleshooting the network issues she appeared in the doorway and bellowed "Don't touch my mouse!" and demanded answers from us on enough questions which lead us to understand she probably had never worked with any computer before, MacOS or WindowsOS. Worse yet, she was unsophisticated in working with people. I crawled out from under her desk and began searching the company for another job and as swiftly as possible.

Then, staying after work one night, I received a call from a development manager on the East Coast who was randomly dialing into the large software company's phone extensions and got mine. She asked me what the company's plans were because they kept investing in doing some thing, learning to code against some software just to be surprised by the large software company's direction, and also by the lack of communication. Immediately I realized that the lack of communication in our department with customers extended to developers and I knew the company had a problem - one that I could help fix.

All of these things, combined with the rocket scientist’s calls caused me to diligently seek a new job within the cutting edge firm – I had successfully graduated from support and moved into development documentation and communication.

Occasionally, now 20 years later, I run into people that I worked with in support and they still work there. Not the pretty ones, not the ones from excellent families with money, or that have an inkling about business, not those with all or straight teeth, but those oddly devoted people with hearts of gold who may be less than handsome characters but they actually care about users. I think that company is very lucky to have such loyal staff. They have jobs they are very competent at, even if repetitive, and where their rewards come in small incremental doses each time they help a member of the unwashed public figure out how to do something with software or at least why it won't.

The ladders for social development and growth are still individual in Helpdesk and Support – you have to help yourself to success or movement on the ladder – when you are ripe, you leave and find another job – Support will never help employees do that itself, because the need is great, the status low, and the need for support never ends. That's why it has been outsourced to developing countries, because as we know everyone is beautiful in this American paradise.


IT Help Desk
Clarke, S. and Greaves, A. (2002). "IT Help Desk Implementation: The Case of an International Airline." In Annals of Cases on Information Technology, 4, pp. 241-259.
Walko, D. 1999. "Implementing a 24-Hour Help Desk at the University of Pittsburgh." In Proceedings of the 27th Annual ACM SIGUCCS Conference on User Services: Mile High Expectations ( Denver, Colorado, United States). SIGUCCS '99. ACM Press, New York, NY, pp. 202-207.
Duhart, T., Monaghan, P., and Aldrich, T. 1999. "Creating the Customer Service Team: An Ongoing Process." In Proceedings of the 27th Annual ACM SIGUCCS Conference on User Services: Mile High Expectations (Denver, Colorado, United States). SIGUCCS '99. ACM Press, New York, NY, 51-55. DOI= http://doi.acm.org/10.1145/337043.337090.
Padeletti, A., Coltrane, B., and Kline, R. 2005. "Customer service: help for the help desk." In Proceedings of the 33rd Annual ACM SIGUCCS Conference on User Services (Monterey, CA, USA, November 06 - 09, 2005). SIGUCCS '05. ACM Press, New York, NY, 299-304. DOI= http://doi.acm.org/10.1145/1099435.1099504

List from Lee Dirks IMT520b, Week 5: Modalities of Information Delivery, iSchool, University of Washington, Seattle Spring 2007