IT Staffing

In a recent study by  Techserve Alliance and Inverno  one of the questions asked was What is the most important criteria for selecting an IT Staffing or IT Consulting firm?    The top ranked answer was the Firm is on my company’s approved vendor list.  Yet finding high quality talent is what keeps managers up at night.  See my previous post about that here.

As we can see on the chart at the right, the most important thing overall  when looking at 2^nd and 3^rd rankings was can the firm provide highly skilled, quality talent.  So what if the firms on your preferred list, can’t or don’t provide you the talent you need?  I recently met with an IT manager that complained that his current vendor would send over about 20 resumes and of the 20, 18 were not even close and the two remaining were  dubious at best.   I encourage you to ask your vendors about their processes and about their metrics.  I willing to bet the firm the manager was complaining about had a performance measurement around how quickly they could get resumes sent out. 

Maybe I’m confused, but it seems to me we have a disconnect when managers says finding talent keeps them up.  Yet when they look at selecting a firm to get them the talent, the first criteria  they use is the firm on the vendor list.  Our goal at STAR BASE is 1, 1, 1.  One candidate submitted, one interview, one hire, anything else is a waste of resources.

Techserve Alliance and Inverno released the results of the first of its kind study of IT Staffing firms, clients and candidates.  This is the first study of its kind to examine the flexible IT workforce from three distinct perspectives: clients, candidates and staffing firms. The findings, based on the responses of more than 700 survey participants, provide an in depth analysis of the state of the IT staffing industry.  The survey was conducted online between June 11, 2012 and October 4, 2012.

Many companies feel that engaging a staffing firm is not a preferred method of finding IT talent.  According to the study, almost half the IT professional hired were the result of a search done by an IT consulting firm.  Companies that have some sort of preferred list found talent from firms that were not on the list 27% of the time.  A conclusion that one could draw from that is that preferred vendor lists limit the talent an organization has access to.

One of the top things that keep hiring managers up at night is finding highly-qualified talent.  One has to question why companies’ put so many barriers in place when it comes to finding IT talent?  If the IT talent is secured, the biggest worry is how to retain them.  Its like trying to drive with one arm tied behind your back.

The results are in!  Techserve Alliance and Inverno released the results of the first of its kind study of IT Staffing firms, clients and candidates. 

In my previous post we got a candidate perspective.  Today we will get an end client perspective.   According to clients, the hardest positions to fill are project manager, programmer/analyst, ERP/CRM Packaged Software Specialist, Network Engineer and Java Applications Developer.  I think in the Cincinnati / Dayton market, I would substitute Microsoft .net developer for Java. 

While most IT skillsets are in high demand, these five are particularly difficult.  As is the law of supply and demand, if the demand is high and the supply is low, the compensation levels will rise, so plan accordingly.

The results are in!  Techserve Alliance and Inverno released the results of the first of its kind study of IT Staffing firms, clients and candidates.  This is the first study of its kind to examine the flexible IT workforce from three distinct perspectives: clients, candidates and staffing firms. The findings, based on the responses of more than 700 survey participants, provide an in depth analysis of the state of the IT staffing industry.  The survey was conducted online between June 11, 2012 and October 4, 2012.  In the next few posts, I will be sharing some interesting points from the survey. 
 

This first point is from the candidate perspective and mirrors our own recent experience with a C# candidate.  Almost 1/3 of IT professionals found their most recent position in two weeks or less.  Most candidates, (84%) accepted a position within 3 months.  This means if you are hiring and you have a very qualified candidate presented, you have to move fast or you run the risk of losing out on the talent.
 

How do you know if the person is qualified or not?  One way is to work with a reputable IT Staffing firm.  You can find reputable firms by searching here.
 

We recently had a situation where one of our candidates was working with more than one firm.  This is not too un-common; I have touched on this subject before in this post here.  The other firm did not do a very good job of presenting this person.  They probably slapped their logo on his resume and sent it off to the client along with a number of others that “looked good”.  The candidate did not hear anything from the other firm. 

We, on the other hand, took time to understand this person and used our Now you know^TM assessment to get an un-biased gauge of his skills.  We found him to be very strong in the skills that several of our clients were looking for.  We talked with him on where we would like to present him and that’s when we learned of a potential conflict.  A quick call to the client confirmed the client was working with another firm as well and if he was submitted by them, they would get the credit.  BTW, what’s his name?

Fortunately, we are members of Techserve Alliance and industry best practices in this case call for the candidate to decide who should represent him at the client.  We have a Right to represent form that we had the candidate fill out for this client.  That way there is no conflict. 

The moral of the story is this: If you are a candidate, make sure the firms you are working with are doing a good job of representing you and know where they are sending your resume.  We recommend that you work with no more than 2 firms.  If there is a conflict, then you should decide who is doing a better job of representing you.

If you are on the hiring side, and hiring for IT, then hire an IT staffing firm, not someone that does several types of jobs.  Don’t let them sell you on how deep their database is, according to the latest Techserve Alliance operating metrics report, less that 30% of the positions are filled from their own proprietary database.  (Ours is over 50% because we are focused on IT in the Cincinnati and Dayton areas).  We all have access to the same internet resources.  If all you needed was a stack of resumes that has been poorly scrutinized, most staff augmentation firms would be fine.  But you don't have time to cull through 20 resumes to find the person with the real experience.  Isn't that what you're paying that staffing firm to do?

One of the critical roles of the Business Analyst (BA), or Enterprise Analyst (EA), in the area of Enterprise Analysis is to identify business need. There are many factors, or many ways that the BA can identify what the business needs. It can be a result of market research or an identified new opportunity brought about by actions of a vendor or competitor.   It could be derived from a strategic goal or initiative of the organization.  It could have come from a business user complaint about a current system issue and/or the subsequent Root Cause Analysis. It could also be derived from an Enterprise Analysis activity that the BA performed, such as Capability Gap Analysis, SWOT Analysis or Product Feasibility Analysis.

If this vital role is not performed than the organization in Cincinnati, Dayton or other business community would not realize the benefits of identifying some business needs that need to be addressed, possibly gaining greater competitive advantage, possibly achieving strategic goals or taking advantage of an opportunity presented by the market.

Once identified, the business need should be documented in the Business Case of a project to develop a solution for this business need. The business need defines the problem for which the business analyst is attempting to find a solution. The way the business need is defined determines which alternative solutions will be considered, which stakeholders will be consulted and which solution approaches will be evaluated. One pitfall that many business analysts fall into is trying to define the business need by the solution. They start with the solution first instead of the problem first. This reduces the solution alternatives that receive consideration and may bring a lesser valuable solution to deployment than what could have been achieved. So starting with the business need (problem) and solution scope, then developing alternative solutions will bring the most valuable solution to the organization, and the business analyst’s recommendation, to light. 

We all learn from our mistakes, what pitfalls to developing the Business Case have you encountered in your career?

Last week I began to demonstrate the value a Business Analyst (BA) brings to the table in the area of Solution Validation by talking about how they bring value by ensuring the thorough testing of the solution prior to implementation.  Let’s continue in this area with an often overlooked and underutilized task of the BA “Assessing Organizational Readiness”.

It would be unfruitful for an enterprise application development team to take a project through the project life cycle (PLC) and implement the solution if nobody in the organization is going to use it.  I have witnessed many times a solution gets implemented and the business users don’t like the new process and often times find ways around it.  Business users try to continue on a path of “doing it the way we have been doing it for years”; which makes the job of the BA more difficult as he/she is the Agent of Change within the organization.  To get the business users out of that mindset and accept new, more efficient, ways of doing things is one of the goals of assessing organizational readiness.  This task is centered on identifying whether the organization, and the people in it, is ready to effectively use a solution ready for implementation.  The Business Analyst should identify the forces that support and oppose the proposed change to the organization.  In this way the BA can work to mitigate the opposition of the change, by identifying any training needs or other techniques that will make implementation of the solution go more smoothly and be effectively used for its intended purpose.

Some of the techniques that a BA may use to assess the organizational readiness are Data Flow diagrams and Process Models, to show the change the proposed solution will have on the organization and business users; Organizational Models to help identify stakeholders or groups of stakeholders that will be affected by the proposed IT business solution; Focus Group, Interviews and Surveys can help identify business users’ concerns about the proposed application solution; Risk Analysis helps identify all potential risks to the organization for implementing the proposed solution and develop a mitigation strategy for each risk; Force Field Analysis to identify the forces for and against the IT business solution; and SWOT Analysis to identify the organization’s Strengths, Weaknesses, Opportunities and Threats in preparing for the proposed change.

When doing these techniques to identify the organization’s readiness to accept the change required, the BA needs to be aware of the Culture of the organization and the impact the proposed solution will have on it; Operations and how the IT business solution will change how the organization accomplishes its processes; Security, physical and electronic, how the changes the solution will bring about affects the security of the organization; and Stakeholders, stakeholder groups, locations, functions, processes and concerns in relation to the enterprise application being affected.

An organization of Cincinnati, Dayton or other business community can benefit by effectively utilizing a BA for assessing the readiness of the organization to accept and effectively use an IT business solution by enabling necessary change management practices, decreasing solution implementation timelines, freeing up other project resources to move on to other responsibilities, identifying training needs and assists in identifying transition requirements necessary for solution implementation.

Do you do any type of Organizational Readiness Assessment prior to IT business solution implementation?

This week we began talking about the role of the Business Analyst (BA) and how that brings business value to the organization. This is not limited to Cincinnati and Dayton.  There are many roles and tasks that a BA performs for an organization.  Yesterday, I talked about the value of identifying all stakeholders, and thereby all requirements, for a project.  Today, I will talk a little about Stakeholder Analysis.  Now the question has been asked, how does a BA perform Stakeholder Analysis?

There are multiple ways a BA can perform Stakeholder Analysis, two of the most common are the RACI matrix and the Stakeholder Map.  The RACI matrix identifies each stakeholder’s responsibility(ies) for a given task or deliverable.  Each stakeholder will be (R)esponsible, (A)ccountable, (C)onsulted and/or (I)nformed for each task or deliverable.  You would have one and only one stakeholder responsible for a given task or deliverable, but multiple stakeholders could be held accountable, consulted during or informed as work continues.

A stakeholder map is a visual diagram of relationships of stakeholders to the solution or to one another.  The stakeholder map can be in one of many forms, including the target diagram, onion diagram, stakeholder matrix and others.  The diagram depicts interrelations and sometimes communication lines between stakeholders.

Other methods of identifying stakeholders include interviews or brainstorming with known stakeholders could identify other stakeholders, organizational charting, Process Modeling, Requirements Workshops, Risk Analysis, Use Cases/Scenarios and User Stories.

This is how the BA performs Stakeholder Analysis.  This identifies all possible stakeholders for a project at the beginning of a project; thereby reducing unnecessary rework and frees up project team members to move on to other work.  This can sometimes be traced to reduced headcount within the organization.

I have outlined the common methods used in Cincinnati and Dayton companies.  These methods are used outside our area as well.  So the question is: What other methods of Stakeholder Analysis have you used in your BA career?  How did that add value to the organization?  I invite you to respond with any comments or other ways BA's bring value to an organization.  Reason number two:  Stakeholder Analysis.

Attention Cincinnati and Dayton IT professionals:  The IBM Tech Trends Report is in.  You can view a copy here.  Over 4000 IT professionals from 26 countries participated in this survey.  It should be no surprise that the top application development areas are in business analytics, cloud computing, mobile and social business. 

Specific skills needed by application developers were java, .net, xml, php and html5.  Not any real surprises here either.  Fortunately, STAR BASE is a leading Cincinnati IT consulting company and can provide IT staffing for any of those areas and skill sets.  

We recently closed a deal that was a real team effort.   What was really special about this team effort was that it included our client.  They worked with us in a completely collaborative manner (as partners should).   Our search was for an IT job that required knowledge of PHP and SQL.  In addition, the person had to be a cultural fit in our client’s organization.   We do not bombard our clients with resumes and hope something sticks. Having been in IT for over 30 years and interviewed thousands of people, we can do a pretty good job at narrowing the list down.

We found a couple of good candidates, one whom we have worked with before on a project who was a very senior person and the other was more of a junior person. The junior person was interviewed by the client first and the feed back was that we absolutely nailed the cultural fit, but there was some concern about the technical skills.  We are able to validate technical skills very quickly with our Know you KnowTM process, so we had to convince the client that their evaluation was off the mark. 

Most technical interviews are very subjective and if the candidate does not give the exact answer the technical person is looking for, they question his/her abilities.  Another common problem is where stump the programmer is played.  Our assessment was this person was proficient in the skills needed.  Since the client validated the soft skills, we just needed to demonstrate that we had given them the almost perfect candidate. 

After talking with our client, about our findings, we offered to give their senior developer (who was not convinced) an assessment.  They agreed and the results could not have come out better.  Fortunately, their senior developer scored better than our junior developer candidate, but not by much.  The results also showed that in the areas where their developer was not as strong, our candidate was very strong.  Our opinion was they would compliment each other very well.   Their senior developer said, “The test is very thorough, but at the same time it mostly avoids asking some of those “obscure” questions that don’t matter very much.  I appreciate the nice balance of questions that were asked.  I will re-review the test result information that you sent us…”

This is a new client for us and we were able to bring value to them and we all worked very well as a team in a very collaborative manner.   It’s refreshing!!

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?

My esteemed colleague, Kupe Kupersmith, wrote an article for BA Times last week stating that “Agile is a Fad”. Now I know that will get a few of my other friends’ up in arms ready to defend their approach to IT project work. I can see the smoke coming out of their ears now. However, if you read Kupe’s article he says that “the word agile is a fad, the agile movement is definitely a trend.” I think it is safe to say that Agile is the hottest trend in IT project work these days. Many companies have switched over to Agile over these past few years and many more companies are considering the move. It has prompted many training courses by education providers. So let’s take a deep, hard look at the Agile “movement” and see if it is a fad, or is it here to stay? Is Agile really any better than Waterfall? What is the next best thing that will come down the pike?

Agile came upon the IT application development and software requirements arenas like a wave, gaining support as it moved. As education providers developed courses to teach IT application development teams to “go agile”, it gained momentum. All this happened in these past few years in very much Fad style. A fad starts very abruptly and gains momentum as it moves, forceful and overpowering; like a wave. Will Agile be here with the wave reverses course and heads back out to sea? This is where the fad loses its zest, when people realize that this is no better than what we had before, or it is swept over by the bigger and stronger wave of the next best fad to come down the pike. The wave reverses course and heads back out to see and disappears as fast as it appeared.  

Is Agile better than what we had before (Waterfall)? I won’t even go there because depending on who you ask, you will get a different answer. You could ask 100 people and probably get somewhere near 50 yes’ and 50 no’s.   That is built quite a bit on personal opinion. The one thing I notice with Agile as it is used today is that it is misapplied by many companies. They talk agile and think that they are using agile, but in reality they have adopted some of the components of agile, such as sprints, scrums and the daily stand-up meeting, but they miss the boat on delivering a piece of working software at the end of each sprint. When your five minute daily stand-up meeting becomes 15 or 20 minutes, all you really have accomplished is keeping your application development team from doing actual work. There are other places that say they are agile, but their sprint is six months long. According to the principles of Agile a sprint should be a couple of weeks to a couple of months long, with a preference to shorter timescale. So a six month sprint is not agile.

The biggest downfall to the Agile principles that I have seen in my experience is the need for comprehensive engagement of the Product Owner. In my experience, Business managers have a business to run and helping IT develop software is not in their job description, they don’t want to talk to the geeks. However, the smart Business managers know that if you don’t talk to the geeks, hard telling what you are going to get out of them. They need more direction than one sit down meeting saying “here is what I need”; and we will not go into the language barrier. If you can’t make IT understand what problem you are trying to solve, then you probably will not get the best IT business solution out of them.

So, is Agile just a Fad? Through all its misapplications and shortcomings, I don’t see agile going away anytime soon. It will not whisk away with the outgoing tide. Is Agile the “Be All of All”? There are some things that you just cannot develop with an agile approach. Some companies have developed a hybrid of the agile and waterfall approaches, so Agile is not the answer to all of IT’s business solutions problems. What will the next great approach be that comes down the pike? My crystal ball is not working today, but it is sure to hit the IT project management world just the way Agile did a few years back. Will IT management be ready for it? Only time will tell.

I am often asked for advice on BA Career paths, Certifications, What technique to use, templates, tools, and so on.. It seems to me that everyone is looking for that “One size fits all” solution on how to perform the role of the BA. The one path up the BA Career Ladder, the one way to go about getting your certification, should I learn DOORS, RequisitePro or Composer?

One thing that I have learned in my many years of doing BA work is that there is no “One size fits all” way of delivering the BA role. Your BA approach will be different depending on the type of project you are involved in. It will differ for a COTS project vs. Capability Gap Analysis. Your approach and tasks that you perform will be different if you are doing enhancements to an ERP system vs. a Vendor Assessment. The techniques you use would be different as well as the templates you may use.

Robin Grace handled the template issue in her article on BA Times entitled “It’s Time for Template Zombies to Die”. Often BAs looking for a template to use will get one from a friend that works for a much larger firm, or a new hire BA brings one with them from a larger firm. The smaller firm uses the template as is, even though there are sections that do not pertain to the type of BA work that the firm does. It may be at times Management will ask “It took you three days to write a two-page document?” Sometimes the response is to make the document 10 pages, and all you have done is added a lot of fluff with no meat. Often, that fluff ends up in the template for the document. Instead of adding fluff, remind Management, “it is more than just writing a document; there is quite a bit of analysis done to make that document right”.  Often people go by what they see and forget about the work done behind the scenes to get to the deliverable. When you do come across a template to use remember this is just a guideline, it can be changed to fit your current situation. Feel free to remove, add or reword sections of the template to make it usable for your task.

I have written many times about the BA Career path. In my last article, I surmised that there are as many paths up the BA Career Ladder as there are people willing to forge them. Getting career advice from those that have gone before you is great and can help you forge ahead, but it does not mean there is one and only one way to climb the career ladder. Advice is helpful, but you are still in charge of your career.  

So in any given situation, instead of looking for the “correct” way to handle the situation, do what any good BA would do. Identify and consider all possible solutions, expand your knowledge so you can assess all possible solutions, identify the risks of each solution and select the best possible solution given the knowledge you have at the time. Remember, the “One size fits all” solution does not exist.

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.

 

In an earlier blog post, I wrote about the dangers of working in IT. It is very important for application development people and really anyone who has a desk job to get regular exercise. My shocking moment was when I went to London with my son, and I saw myself walking across Abbey Road. There I am, and my “overhang”! To put more fuel on my weight fire, my boss is doing P90X. He has dropped several pant sizes and is looking good. To figure out how I was to lose weight, I did what all good application development people do, I observe what works for others. I recently read (and saw his picture) that Drew Carey lost 90 pounds in 8 months. His secret for his weight loss was getting on the treadmill for at least 30 minutes everyday, and eating broccoli. I looked at people who run regularly, and they are skinny! So I decided to run and eat broccoli. My diet currently consists of an apple in the morning, turkey for lunch, a banana in the afternoon, a protein shake after my run, broccoli, a small dinner, and maybe some skinny cow ice cream. This may be too much for some, but try these simple things to start: drink water instead of soda pop. Swap out a candy bar with a piece of fruit. As for the running, I go six times a week. I created a “course” at an executive park by my house. My first time, I barely got through a half mile. It doesn't really matter how far you go, just set a goal for yourself. Every day I wanted to go further, and eventually my course became three quarter of a mile. I found this Android app that is my favorite and most useful piece of software I have used. It's called Cardio Trainer. It uses GPS and Google Maps to track your running. It keeps track of you distance, time, and calories burned. I save my workouts, and now I have a history of my runs! In six weeks I am up to 16.5 miles a week while running three 5Ks in my training. I have lost at least 12 pounds (I am sure I have added muscle to my legs). My “overhang” has dramatically decreased, I have more energy, I sleep better, and I feel happier. The point of my story is that we application development folk need to get up and do something. If you have bad knees, try swimming. Find something that will make you active. Set a reachable goal, achieve it and set another one. I want you guys to hang around and read my stuff!

• the job titles on your work history do not reflect your experience in business analysis (they include other titles such as programmer, software developer, financial analyst, etc.) and/or;
• you spent many years doing business analysis work for one company (perhaps even with the title of BA), but never obtained post secondary education, and is finding it difficult to get your resume noticed by other companies.