Business IT Outsourcing

Obamacare  is a topic that is usually not discussed in most IT (Information Technology) departments.  Unless your business is healthcare related, why would you?   I’m sure there is going to be more discussion about it in the coming year. 

Most people know that Obamacare will be fully implemented next year.  What most do not know is that this year is the look back year.  The look back year will determine the number of employees an employer has. This number will determine what is mandated by the law.  There is a lot of discussions going on right now in the executive suite about head count, specifically how to reduce it.  I was just in a meeting this morning where the topic came up.  IT departments are not immune to the discussion.  So Mr. IT Director, what are you going to do when you have to cut X number of FTE’s? 

Fortunately, we have some solutions like Talent on Demand and CIO on Demand

Most application software development team members are aware of and work within the framework of Project Scope, but few are aware of the importance of Solution Scope. Project Scope is usually defined by the Project Manager and defines the boundaries of the IT business solution project. It defines what areas will be in scope and what is out of scope for the project. Project Scope may also document the assumptions and constraints noted for the project. For example, an organization, with manufacturing facilities in Cincinnati and Dayton, is considering an enhancement to its customer invoicing application; the project scope could state that “this enhancement is to change the cosmetic look of customer invoices produced by the customer invoicing system”. It could state that this enhancement will affect only one, or a set, of customers and not other customers. The project scope statement should also declare what is out of scope for the project. Such as, “this project will not consider Order Entry and other Customer Service or customer complaint systems, as well it will not consider Accounts Receivable and other financial systems”.

The Solution Scope defines the new capability that the IT business solution will contain. The purpose of the solution scope is to conceptualize the recommended solution in enough detail to enable stakeholders to understand which new business capabilities an IT business solution will deliver, or in other words Create Shared Vision. By creating shared vision concerning the IT business solution at this point in the project you can decrease focus of the project to that solution scope, reduce scope creep, that can reduce project timelines and free up project resources sooner, increase stakeholder satisfaction at the end of the project. This increases the probability that the project will be deemed a success.

Take our example above, the solution scope will state exactly what is changing about the cosmetic look of invoices, such as “the company logo at top of the invoice will change to the newly adopted logo, the bill-to customer name and address will print to the right of the ship-to customer name and address on the invoice as well as the date printed will change to Day, Month, Year format (i.e. 15 August 2011) from its current Month, Day, Year format (i.e. August 15, 2011)”. Just as Project Scope declared what was out of scope for the project, the solution scope declares what is out of scope in relation to the IT business solution. “This enhancement will not change any calculations as to price or discounts that customer receives. This enhancement does not change how data is displayed on the invoice or how it is retrieved from the database except for the changes defined in this enhancement, meaning that item descriptions, quantities, unit of measures displayed will not change.”

So engage the Business Analyst early in and throughout the project to define and manage solution scope to keep the focus of the project, This helps the organization gain the many benefits stated above.

We have been discussing the value a Business Analyst (BA) brings to the table in the area of Solution Validation.  Another often overlooked and underperformed task of Solution Validation is “Assessing the Solution Performance”.  Cincinnati and Dayton organizations do not take advantage of the benefits that can be received by performing a Solution Performance Assessment.

This task is performed after the IT business solution is deployed and working.  It can be done very shortly after implementation or over a period of time following deployment.  You cannot assess performance if the solution is not in use by the business.

First the BA must determine the criteria by which the solution will be measured; these are often called “key performance indicators” (KPI).  To determine correct performance criteria the BA must understand the intended value that the IT business solution was designed to deliver to the organization.  Understanding this value the BA may determine criteria by which the solution may be measured to determine if the business is receiving the anticipated value from the solution.

Some of these solution performance metrics may be quantitative, measure of time, volume, revenue, errors or other hard numbers; or qualitative, user satisfaction and use, recommendations, concerns or other subjective opinions of the stakeholders using the solution.  When a new enhancement to the Order Entry system in deployed, but you soon find that the Customer Service Representatives or Order Entry Clerks have developed a manual workaround that circumvents the enhancement, then your qualitative analysis would show a negative response from the stakeholders.  Such response should be investigated by the BA or Subject Matter Expert (SME) to determine the root cause of the business user’s dissatisfaction with the solution.  This may lead to enhancement, reversal or replacement of the IT business solution.

Collecting solution performance metrics are not only negative, but the BA should also collect positive metrics to assist in determining if the solution is delivering the expected benefit to the company.  This can assist in early detection of a “bad” solution, proving the success of an IT business solution and can lead into other business capability gap analysis.

Does your Cincinnati or Dayton company collect solution performance metrics following project implementation?  What other ways have you found to validate the performance of an IT business solution after deployment?

I have been asked from time to time what a Business Analyst (BA) does, or what is the value of a BA to the organization? That is question is not limited to Cincinnati and Dayton Companies, so let’s explore further. Not just to dictate all the many tasks or ways a BA serves their organization, but make note of the role within the organization and how an organization may get value add from that role. Many people know of the work of a BA within projects, the tactical role, but aren’t as aware of the work of a BA in preparing for projects and their Enterprise Analysis role, the strategic role. So we will start with some of the more known and common duties of the BA and progress to the less common roles.

It is common knowledge that approximately two-thirds of all projects fail. The most common cause of this issue has been attributed to incorrect or incomplete requirements. However, in some cases, the cause can be traced back further to incorrect or incomplete stakeholder identification. Sometimes requirements are not included because the stakeholder that would benefit from that feature or aspect of the solution, or has the business need, is not included in the project scheme of stakeholders. So identifying all the stakeholders of a particular solution proposal or business need can significantly increase project success.

Take the example of a manufacturer who is implementing a new Order Entry system. They may identify Order Entry, Customer Service, Manufacturing, Shipping and Accounts Receivables as all stakeholders for the project. However, if you miss the Customer Complaint, assuming shipping and Receiving departments as stakeholders then you do not have a full picture of the impact of a new Order Entry system on the organization. Data can be made available to the customer complaint system, but if that is not identified at the origination of the implementation project then it would have to implemented at a later date on another project; and the original implementation project may make a decision that would make the availability of data to the customer complaint system more difficult and add cost to that implementation.

So identifying all stakeholders for a project, and thereby identifying all requirements for a project is one role of a BA within an organization. This reduces the number of projects, follow-up work and re-work necessary on projects. This not only frees up the BA, but other project team members as well, to move on to more important projects.

Each day I will be sharing more about the value of a BA.  If you have something that you want to share, please post your response.   Today's BA value proposition is: Identify Stakeholders. 

Weary Cincinnati/Dayton IT job seekers hope it’s true. Politicians declare that it should be true. Parents of young graduates with Computer Science degrees need it to be true. So is it? Are businesses beginning to backsource (bring IT services that they had offshored back to the U.S.) in significant ways? What about outsourced jobs? Are those moving back in-house?

This month, STAR BASE invites you to help us answer these outsourcing and backsourcing questions by participating in our 2011 Pulse Survey. This brief and confidential survey will go a long way in helping us all better understand the outsourcing/offshoring strategies businesses like yours are embracing today.

And, if you are motivated by swag the way I am, here’s another reason to take our survey. All participants are entered into a drawing for a Powermat wireless charging station. So take a moment, take the survey and share your backsourcing story with STAR BASE.

As a Business Analyst (BA) we are often asked to help design a new user interface and the supporting application to perform a required function in the Enterprise Resource Planning (ERP) system. If you are talking about a web interface you may work with a graphic designer, or perhaps not.  You go off with your business application development design team and create a mock-up of the interface and write a design specification describing how it is to be built. Often the business is not represented on the design team. The design team may pass the mock-up and design specification by a business Subject Matter Expert (SME) before attempting to get it approved; but then they are often approved by a business manager without ever being seen by the end-users that will actually use the new application. Often, features and function are primary concerns when the design is being created. What if we change focus of our design team?

I would like to introduce two concepts to which I have been recently introduced—Personas and Usability Testing. These two concepts are the main concepts of User Experience Practices. The purpose of User Experience Practices is to change the focus of the design team from features and function to the users the new application is to serve and usability of the application. Have you ever rolled out a new application and user interface to find out that the users hated it or even worse refused to use it? Have you heard of times new applications were rolled out but they did not make the user’s job easier or save them time or have any added benefit to the organization? Designing for User Experience would have changed those outcomes. Let’s look at these two components and see how they are used.

A Persona is an artifact (written document) that consists of a narrative relating to a specific user group. It should include a picture and an abstract name that you can live with.  So don’t name your Persona Mickey Mouse, name it Stan, Ned, Alain, or Liza instead. You don’t name them after actual people in the organization but use an abstract name that represents a group of people. Say you are a BA working with a design team that has been charged with designing a new Order Entry system. So what user groups (customers) is your new application going to serve—Order Entry/Customer Service clerks. Yes, the company has six manufacturing locations with at least two Order Entry clerks in each location; the larger facilities have as many as eight Order Entry clerks. So what Personas do you have—one local Order Entry Clerk, let’s name her Emily and she represents eight order entry clerks. In some instances you may find it necessary to have two Personas to represent this one group. The remote site Order Entry clerks will be represented by one or more personas. Who else—what about Sales Representatives that can enter orders as well. The Company has 16 Sales Representatives; 13 of which enter orders on a weekly basis, one who will enter an order or two every month and two who never enter orders. Sounds like three more personas, maybe more. Not considering reports that Sales or Upper Management will want out of the system, as these are often pulled out of the database after the Order has been entered; what about Inventory Management/Purchasing. If an Order Entry clerk enters an order that uses any extraordinary large amount of a raw material if Purchasing is not aware of it until tomorrow’s report comes out, in a day or two the manufacturing plant may be out of that raw material. Therefore, my Order Entry system must send an “alert” message to Purchasing for extremely large orders so that they can account for that material used and keep the manufacturing plant working. How about external customers who have to get the order to our company, they have to call the Customer Service Representative (CSR), how long do they have to stay on the phone with the CSR to get the order in. What if the customer sends their order in via EDI; so an IT persona is needed. Fax, email, XML file—all acceptable ways of receiving a customer’s order; these are often handled by a CSR or IT, but we may want to build an automatic process to enter these customer orders. These methods of order entry need to be specified on the external customer, CSR and IT personas.

The Persona Map—now that you have written all your personas, we need to focus on the important people that our new interface and application will be used to support. So take a very large cardboard poster and draw a target (bulls-eye). In the very center will be our Primary Persona. The one most affected by our new interface, probably the CSR/Order Entry clerks; but you can only have one, so we select Emily. In the inner ring of the target you can place two to three Secondary Personas. In our example, this most likely will be other local CSRs and remote CSRs.   In the outer ring of the target you can place three to four Tributary Personas. For our example, possibly Sales Representatives Personas and possibly IT personas. Now this Persona Map should be hung in the room where the design team will work, or if necessary duplicated and given to every design team member. Now we have changed the focus of the design team from features and function to the people who will use the new interface and application.

This is the first step of designing for User Experience. In my next post we shall explore the second step—Usability Testing. Even without knowing about Usability Testing, can you see the power that Personas can have?

Still a very timely topic of discussion, from the person who wishes to transition into a Business Analysis career who wants to know what skills they must have to be a successful BA, to the new BA who wants to know what skills they need to add to their repertoire, to the Senior BA who wants to know where to go next in their career; everyone wants to know how to improve their skills to get to that next level of their career.

Two of my colleagues take on this subject, Kupe in BA Times discusses soft skills vs. hard skills. He notes the importance of soft skills in being a successful BA. Kupe is not suggesting hard skills are not important, he notes that hard skills is what is going to get you noticed, stand out in a crowd, but it is the soft skills that will land you on that next level and keep you there. After all, nobody wants to work with a jerk.

Laura discusses whether Project Management is the next step in the career of a Senior BA at Bridging-the-Gap. She discusses how this use to be the case years ago but is no longer the only option. In fact, we now see the reverse happening where Project Management professionals transition into Business Analysis careers. For those who have reached the pinnacle of their BA career, besides Project Management, they could move into BA Management, creating a BA Office within their organization, Enterprise Analysis, Management Strategic Consulting, Business Consulting, Business Subject Matter Expert or external IT and Business Management Consulting. There are as many paths as there are people willing to forge them.

Elizabeth Larson will be taking on a similar topic at the Southwest Ohio Business Development Conference in April. She will discuss whether Business Analyst and Project Manager should be one or two roles within the organization. At this very same conference I will be presenting the topic “Improving Your BA Skills: From Self-Assessment to Self-Improvement”. This is where I will discuss the many ways you can gain new and improve current BA skills.   This is a conference not to be missed if you are in the Cincinnati area on April 29, 2011.

This topic has been around for many years and as you can see is still a very hot topic today, getting a lot of press. There is no one way to build your career, forge your own path. Remember you are in charge of your career. Unemployment, downsizing or IT outsourcing may derail your plans for a time, but don’t allow that to stop you permanently. For some general guidelines, as Kupe suggests, develop the hard skills necessary to accomplish the tasks of a BA and get you noticed. Then develop the soft skills that will land you on that next plateau of your career. Remember, that your current job is not your career, it is just your current position in your career; you decide where to go next.  Let your passions guide you. If Project Management doesn’t excite you, good; now you have other options to continue your career.

One of my fellow Techserve Alliance members sent out an article that I thought was pretty interesting.  You can view the original article here.  It reinforced the idea that local talent is important.  STAR BASE, Inc. has always focused on Cincinnati and Dayton IT talent, so I felt validated.  Some of you may think I’m crazy for talking about a Talent Battle while unemployment is still so high.  I don’t think so, because some IT talent is already hard to find.  Here are some key points from the article in winning the up coming Talent Battle.

1. Eliminate Past Biases.  Many companies don’t consider candidates who they have interviewed but declined previously. There is often a strong bias against them, as in, “We interviewed that guy in January, and he wasn’t any good …” Given that most companies don’t have highly refined selection processes; this is an error in strategy.  Most companies’ selection process is very subjective.  For companies to win, they will need to revisit local talent who they may have interviewed previously for other roles.
2. Don’t Overweight Experience and Technical Skills.  Most companies routinely overweight years of experience and technical skills through the interview process.  A question that needs to be asked is, “Is it possible for someone with five years of experience to outperform someone with ten years of experience? How is that possible?” Smart IT service providers will help their customers select on the portfolio of attributes that drive success in a job, being careful to not overweight less-predictive candidate attributes such as years of experience. Doing so will increase the candidate pool that is available locally.
3. Map your Internal Talent.  Now more than ever, developing internal talent is a smart strategy, as it also correlates to reduced attrition. So for those jobs that can be sourced internally, organizations will be well served by doing so, provided it supports the local search strategy.
4. Measure the Opportunity Cost of Key Vacancies.  Understand the business case for paying relocation. There could be a good argument for what jobs might warrant a rich pot of relocation dollars. This will put you ahead of the game.
5. Focus on the Local. Now would be a good time to look at your suppliers and choose ones that are local and focus on the local.  (I think I may know of one…)
6. Outsmart Your Competitors.  Smart companies will quickly recognize that improving the value package offered to employees to attract and keep more local talent carries far greater ROI than buying someone out of their underwater mortgage, or letting a key role in the organization sit vacant.
 7. Keep Your Best:  As always, the best local talent to attract and recruit are the strong performers who are already working for your company. But most companies have cut bonuses, reduced merit increases, and kept job promotions to a minimum in order to control costs during recent challenging economic times.

Now is a good time to think about your Talent Strategy.  Don’t get caught short in the up coming Talent Battle.

 

This month I have been exploring the IT and Business working relationship.  It is a hot topic these days getting a lot of press.  STAR BASE Consulting is conducting a pulse survey asking what is the relationship like in your organization.  BA Times notes that your “Customers Don’t Want to Work with You!”  A couple of weeks ago, I looked at the relationship and how BAs could reduce the rivalry, if there is one.  Last week I took the relationship to the Organizational level and described how the Organization can build a unified, collaborative team.

You say Organizational Structure, Seating Charts, Enterprise Analysts (EA) and Business Analysts (BA) are all find and dandy, but what about me and my small IT shop?  I don’t have enough people to split into EAs and BAs.  How do you split one person?  Small-to-Medium Sized Businesses (SMBs) usually have an IT shop of 10 people or less.  Maybe at most 2 of them will be BAs.  I even had one CIO recently tell me that in his small shop he doesn’t really have full-time BAs, but five Programmer/Analysts that do their own analysis.  So we will assume these are the hybrid Developer/Business Analyst role within the organization.  So in this kind of structure, how can we improve the IT and Business working relationship?

In SMBs, where resources are scarce, it is not uncommon for people to perform multiple roles or “wear many hats” within the organization.  In today’s economy, where IT spending and salaries have stalled but the workload has not: IT is getting even more squeezed.  In this situation, when the SMB cannot make one of its BAs the strategic role (EA), or perhaps the organization does not need full-time enterprise analysis activities going on, it becomes even more crucial for the BAs to assist in building a unified, collaborative working relationship between IT and the business.  So let’s look at some of the key points I have discussed in the past two weeks.

Seating Chart - Two Desks

When looking at this seating chart you realize that there is only one person, so you only need one desk, correct?  Allowing the BA to have a desk in the IT Department and one in the business unit of the organization allows them to build a working relationship with each team.  By spending part of the day or week with each team, the BA can understand the challenges each team faces.  Even if the BA can spend only part of his/her time sitting with the business unit that they are suppose to support, it helps build awareness of the daily challenges that the business people face on a daily bases.  This helps the BA identify business needs to improve business processes and make the business run smoother.  This also makes the BA approachable by the business people to assist to work on problems and will help get buy-in from the business people when the BA has analysis tasks that require business input.

Communication is Key

Communication is a key skill for a BA, but becomes even more important in this situation.  The trap that the BA must avoid is the business feeling that the BA is approachable only when he/she is sitting at the desk in the business area.  Or that the BA is available for IT project work only when he/she is sitting at the desk with the IT business solutions development team.  The BA must communicate to both teams that he/she is available whenever they need assistance; it is their goal to assist.  The BA also must represent the needs, desires and limitations of each team to the other.  Make the IT application development team understand the business requirements and why these requirements are needed.  Make the business understand the time involved to make “a simple change” to an enterprise application.  By representing each team to the other, and making each understand the work at hand, whether that is requirements or solution testing, they are creating a shared vision across the organization.

Build the Bridge

Through effective communication of the needs and limitations of one team of the business to the other and representing the each team to the other the BA can build a bridge of understanding between the two groups.  By making each side realize that we are all in this together and desire the same outcome, you can build a relationship of trust and get rid of the “Us vs. Them” scenario and replace it with a collaborative working relationship that brings about better IT solutions to business needs.

Whether in a large organization or SMB, business must go to IT for technology solutions.  Even in an IT Outsourcing situation, there are on-site IT people to directly talk with the business people.  In SMBs, where resources are less and people “wear many hats”, the BA role of liaison becomes more important to overall IT business solutions success.
 

See Part One here.  These deadly sins are not limited to IT Consulting in Cincinnati, but everywhere.  I wish that someone would have shared the list below with me earlier in my career.  It might have saved me a few grey hairs and sleepless nights.  I have to admit, I have been guilty of a couple of these in the past, but that’s why it’s called experience.

5. Blame it on Rio.  And I am not talking about the movie, I am talking about pushing the mistake/error onto something else like, the Operating System, another consultant or worse, one of the client’s employees.  While the problem could very well be any of those things, your job as a professional consultant is to find solutions and to set an example in leadership and even diplomacy.  While you may see glaring errors or mistakes and perhaps your way would have been the better way to do something it is best to keep the criticism and commentary to yourself. (See #3 in Part One)

6. Bubble gum and baling wire.  Many times consultants are brought in to fix something.  The last thing you want to do is to take a shortcut that you aren't sure will last. Band-Aids are fine if you know you are coming back to make a more permanent fix. But eventually, those shortcuts will fail and will need further attention and the time to failure is an unknown. It could be the minute you drive away or months later. This is not the type of chance you want to take. It frustrates the client, and it makes you look bad.  You also don’t want to make the client totally dependent on you.  A client told me once that Peter (not the real name) is very talented; the problem is he is the only one that knows how it works and can manage it.

7. Showing up, Gotta Go. (AKA I gotta hangnail).  Once you’re on a gig, most clients want to see you on some sort of regular basis and some might have a “core hours” expectation.  It’s important for both the client and the consultant to know what each should expect.  I once heard a client make a comment about another consultant that went something like this: “Larry(not the real name) runs out of here all the time and uses sickleave for a hang nail!” 

Here is another list that has some similar ideas here.  I’m sure there are others.  So go forth and sin no more!
 

You have probably heard your parents or grand-parents talk about when they were younger and how they had to walk to school, up hill both ways.  When they shared this story with you it was to prepare you for times when things weren’t so easy and to provide you with their knowledge and advice from their hard earned experience. I wish that someone would have shared the list below with me earlier in my career.  It might have saved me a few grey hairs and sleepless nights.  I have to admit, I have been guilty of a couple of these in the past, but that’s why it’s called experience.

1. Bill for time not worked.  This will be the quickest way to end up out of a consulting gig. Make sure you bill the client only for the time you actually work. This can be tricky if your clients are friends. When you go to a job like this, you know there will be a period of time spent socializing, especially when you first arrive. Don't bill for this time. Start the billing period when you start working.  Sometimes clients will have celebrations during the day.  If you don’t want to appear anti-social, by not going, just don’t bill.  If there are any questions, ask the account manager to find out. If you are the account manager, ask your client manager at one of your one to one meetings if it’s ok to bill.  Some client’s have a culture where that is part of the expectation.

2. Negotiate rates and make deals with the client.  If you work for a consulting firm, you know there are channels for clients to go though to make requests..  Most firms have some sort of account manager to handle those issues.  Direct the client to the account manager.  I had one consultant that actually went so far as to look in the client’s AP system to see how much we were getting paid and then wanted to negotiate a higher rate with the client.  This particular action did not end well for the consultant and he has not been able to be considered for other assignments in this client even when his skill set was ideal.  Never, ever work out a side deal or moonlight with a client this can comprise your integrity and jeopardize the trust between  you, the consulting company and inevitably the client.

3. Act like a prima donna.  Yes, you’re good, that’s why you have been hired. I actually heard a consultant tell the client that their employees were stupid.  Hello? You are there to serve those employees.  You don’t know what kind of constraints they have had to work with.  Hind sight is always 20-20.  Its always far better to politely make suggestions. You may find out your brilliant idea was considered previously and there was a very valid reason for it not being implemented.  It’s much better to NOT have egg on your face or your foot in your mouth.

4. Miscommunicate or undercommunicate when engaged at a client I believe that the client should know what is going on with their project.  Many times I have had to be the bearer of bad news.  I also like weekly status reports to let the client know what I have worked on and what I’m planning on doing.  If at all possible I like to let them know a percent complete.  Years ago, I heard another consultant tell the client he was “unit testing”.  The client assumed that meant he had all the functionality done and was testing.  The reality was he had about 10% of the functionality done and was testing just that one small piece.  When the truth came out, it was not pretty.

Tomorrow I will finish off the last 3 sins.
To be continued……

“IT executives increasingly implement marketing initiatives to improve the communications with their business customers. But these efforts often focus solely on the brand aspects of the services under the IT’s control without understanding the business’ perception of IT. To maximize the success, IT must add business satisfaction assessments to its tool kit. Understanding business satisfaction requires qualitative and quantitative data that capture customer expectations and perceptions through different types of interactions such as interviews, panels, focus groups, complaint systems, and surveys. This report provides best-practice recommendations, survey templates, and questions to guide IT executives through the deployment of a business satisfaction assessment. It applies Forrester’s deep expertise in external customer satisfaction to the interface between business customers and their internal IT suppliers.” says a new Forrester report.

I have served on countless business application development teams within several organizations in the Southwest Ohio and Cincinnati Information Technology community, one thing I can say is that most IT organizations do not gauge business satisfaction with IT business solutions.  I have served in only a couple of organizations where the business serves on the IT governance committee.  An organization does not have to be “big” to have an IT governance committee.  No matter what the size of the organization decisions are made as to priorities in IT work.  IT governance does not have to be a long drawn out process or take great time commitment from the business or IT executives, but business involvement in IT governance goes a long way in gaining business buy-in as you roll out the IT business solutions to the business.

Involvement in IT governance is just one way that many organizations in the Greater Cincinnati area can improve the IT-business relationship.  The Forrester report goes into ways to solicit and gauge business satisfaction with IT business solutions.  Doing so should affect decisions concerning not only IT business solution delivery but also IT Infrastructure and IT outsourcing initiatives.

 

Seems like it has been a while since I have had a chance to do a post.  For the last 3 weeks things have been absolutely crazy in our IT consulting world, but in a good way.  We had a chance to go to the Techserve Alliance national conference in Las Vegas.  I have heard all the jokes, including the one about it staying in Vegas.   We did learn that just because you are pre-checked with the airline, does not mean that your bags are.   We got our bags checked with literally a minute to spare and fortunately all made it back to Cincinnati.

Upon return, we signed a support contract for a new customer.  They trust us enough to outsource their entire IT applications support to us.  We have a real life example of an IT Strategy that was discussed at the conference (See #3).  Not only was IT strategy discussed but business strategy as well.  Here are some highlights:

1. Market Differentiation - customers have lots of choices, how will you stand out?

2. Improve Systems and methodology for delivering service- excellence, efficiency, depth of service.

3. Outsource what you can-eliminate the busy work that does not add strategic value.

4. Deal with the economy being slow to recover till 2012, spend your money wisely, hire wisely, fire quickly, and refine what is working, stop what is not.           

5. Build Alliances with like minded providers in different industries and sell collaboratively to serve the customers' need.

My favorite of these five is number four.  Said another way, its takin’ the basset hound to the farm.  I’ll expand more on that in my next post.

• Network security specialist: A person familiar with intrusion detection systems.
• Penetration testers: Someone who can assess a system's potential vulnerabilities.
• Incident handlers: People who understand attack methodology and can apply critical thinking skills to respond to incidents.
• Forensics Analyst: The person who looks for evidence after an attack.
• Research Analyst: The person to keep abreast technological advances in incident response activities.
• Team Leader: Leads the team through crises and communicates to the business incident activities and cost to the business.

• Preparation and Training: for both prevention and incident response.
• Identification: fast identification of an occurring attack and its impact on the IT infrastructure can help in minimizing the duration and cost of clean-up.
• Containment: Once an attack has been identified, steps must be taken to minimize the effects of the attack.
• Recovery and Analysis: The recovery period allows analysis and lessons learned of What happened? Why did it happened? Was the response effective?