Staffing the SAP TSO: Rapid Deployment

The rapid deployment approach to staffing an SAP Technical Support Organization is based on a morphed resume-to-hire and staff-testing approach, with the following modifications:

• The human resources organization is neither responsible for developing technical job descriptions nor performing technical references; rather, the SAP support organization is (leveraging templates that I include on the Planning CD found at the back of the book).

• A technical phone screen takes the place of separate general and technical phone screens and interviews.

• Role-playing via customer simulation scenarios during a single “group” technical interview takes the place of testing and multiple technical interviews.

• This single role-playing technical interview allows for observing both technical and soft skills in action (more detail on soft skills can be found later in this chapter), including how well the candidate performs under real-world stress.

This approach also side-steps the risk inherent to try-before-you-buy, without sacrificing all of the value gained by seeing a candidate in action.

So, with the image of “rapid deployment” in mind, let’s take a closer look at a proven process used by more than a few of my own SAP customers (and partner consulting organizations, for that matter). Note, however, that I will be writing mainly from the perspective of the customer (or employer) implementing SAP here, not from the perspective of the technical staff seeking employment or a contract.

Best Practices and the Rapid Deployment Approach to Staffing

Before anyone is hired, before even a single interview is scheduled or offer letter is sent out, a process needs to be outlined and followed to support rapid deployment, like the one shown in Figure 8.1.

The Rapid Deployment SAP Staffing Process (RDSSP) is simply a documented set of steps to follow in support of the hiring/contracting process. What underscores the importance of the RDSSP as compared to other IT staffing processes is the fact that the SAP environment is nearly always “mission-critical.” This therefore impacts the quality of folks that need to be considered for positions in the SAP support team. And this in turn affects both the steps and overall timeline in the process, especially with regard to the following exceptions or differences:

• Pay careful attention to following the process. Side-stepping or unduly speeding up the hiring process will only get you into trouble—I have worked with these marginal hires, and it was no fun.

• The importance of technical and general detailed references cannot be stressed enough. Sure, many companies have a policy of not giving references. Approach it from a personal perspective, though (in other words, simply get the reference to talk to you), and listen and learn. In my experience, even in those companies that frown on giving references, it’s easy to find someone willing to talk—ask a candidate for the names and contact information of his former colleagues, and then approach your questioning from a “personal reference” perspective.

• Be prepared to spend time developing job descriptions, checking references, and performing phone screens, interviews, and other follow-up. These need to be handled professionally and thoroughly, in a quality manner. You get what you work for.

• The interview process itself needs to be much more rigorous than that utilized for most IT positions. Follow-up, and follow-through, in terms of detailed reference checks, in-depth technical interviews, and well-rounded group interviews utilizing role-playing and customer-simulation environments helps ensure that job offers are extended to “keepers.”

Given the nature of SAP implementations, the right candidates will be flexible, eager to learn, intelligent, and possess excellent people and communication skills. If in doubt, move on to the next candidate.

One final note, though—each candidate needs to be given the proper expectations as to the scope and timing of the review process. This benefits both parties; nobody needs to waste time on a thorough review and check only to find that the candidate has gone elsewhere in the meantime.

Next, let’s take a look at some real job description examples, an approach for comparing and shredding resumes, how to perform an SAP technical phone screen, setting up and conducting the face-to-face interview, and a method for ranking and evaluating candidates. So, whether you are the manager or a team leader performing these tasks, or a candidate presenting himself for an open position, the following sections will definitely be worth your time.

Step 1—Developing and Posting Job Descriptions

For each SAP implementation, there are literally hundreds of ways that different jobs or occupations can be combined into broad positions of responsibility, or broken down into smaller cubbyhole positions (which I generally frown on, but they exist nonetheless). Some of my SAP customers have created very interesting, and in the case of some very large implementations, very narrow positions. Creating job descriptions, then, relates directly back to how your support organization is laid out.

Because we’ve covered organizational issues previously in Chapter 4, I will assume that you have an idea as to the approach you are taking. Again, refer to the Planning CD for sample job descriptions.

Most clients find advertising for SAP-specific “generalist” positions the best use of advertising budget and space. For example, a company advertising for an “SAP W2K Server Administrator” or “Network Technician supporting a mission critical enterprise” or “Oracle Database Administrator for SAP” will tend to yield more qualified candidates than similarly described non-SAP-explicit positions. On the other hand, too much detail might scare away applicants who don’t feel they meet 100% of the requirements. For example, advertising for an “Oracle 8.1.6 database administrator to support a clustered Windows 2000 environment running SAP 4.5B” might inadvertently imply to prospects that only this specific solution stack combination is desired; others need not apply.

Step 2—How to Evaluate SAP Technical Resumes

When the pre-qualified resumes start coming in from HR, it’s time to take action quickly for a number of reasons:

• The “best of the best” in the SAP job market will find a home somewhere; if you sit on their resume too long, it won’t be your home.

• The hiring process takes time. From posting to technical screening to interviewing, and then negotiating to sending out an offer letter and setting up start dates, the process can take months.

• Even those candidates who are not qualified deserve respect for the time and effort they put into responding to your advertisements. Besides, the SAP job market is still small enough such that word travels quickly of clients who are difficult or irritating to work with. The junior consultant today could very well become the star expert you need next year!

Resumes need to be grouped into job positions, and then reviewed against the basic requirements of those positions. A matrix is handy at this point, as it forces an even comparison between all candidates vying for a single position. Further, as shown in Figure 8.2, it gives you a single source document, which you can begin using to track candidates seeking a position within your SAP team. Such a tool is especially useful over the Web, too, as it facilitates sharing this information anywhere, anytime, across the SAP TSO, the human resources department, and other teams.

I like the term “Candidate Status Matrix,” or CSM, and have included a sample CSM on the Planning CD. The Candidate Status Matrix serves many purposes. First, it is an excellent tool for ensuring that timelines are adhered to throughout the hiring process. For example, when a resume hits HR’s inbox, there should be a time limit set for how long the resume sits unattended. The CSM helps everyone understand who is responsible for the next step in the Rapid Deployment SAP Staffing Process, and how long it should take to move the candidate from one step to the next. The CSM thus imposes work flow and forces accountability.

The CSM also allows for tracking all vital data on each applicant, from their name to contact information to the results of phone screens, interviews, and more. The CSM becomes your tracking system, in essence a single point of reference. And in the beginning of the staffing process, the CSM provides a way to start comparing candidates simply based on their resumes—professional appearance, written communication skills, completeness, all-important spelling/grammar skills, and so on—all of this is basic information that must be maintained.

Finally, the Candidate Status Matrix helps you manage closure on each candidate. In the end, a candidate is either hired or sent a “Thank You For Your Interest” note—the CSM assures you that no candidate falls through the cracks (in the sample CSM found in Figure 8.2, the absence of any more scheduled activity triggers a “Thank you but no thank you” response from HR).

Don’t make the mistake of underestimating the power and value of the CSM. Its use is obvious during the staffing process itself. But the CSM also provides the following compelling benefits:

• The left hand will know what the right hand is up to. If you have already interviewed and documented your staffing process, you will not make the mistake of (or waste your time) phone-screening or interviewing the same candidate twice. It happens!

• Even if it’s six months down the road, and you are looking for a position similar to an old one, and happen to see a familiar resume in your inbox, the CSM provides a easy way of “going back through your notes” to determine whether another conversation is worth everyone’s time. For example, if you passed on a candidate the first time because he hadn’t bathed in a week, or “exaggerated” too much on his resume, there is little reason to look at him again.

• The CSM can be used by a company’s corporate Human resources organization to document that the staffing process does not discriminate against any particular race, creed, color, and so on. It’s your way of ensuring that you are complying with self-imposed or otherwise governed hiring practices.

There are many ways to deploy and use the CSM. Historically, I have seen it deployed in the form of an Excel spreadsheet shared between one or two managers. Problems with this method of sharing data exist, though, especially in terms of version control. Better methods of sharing and accessing this data exist, and include:

• Create and maintain a true candidate database (that is, SQL Server Personal Edition, or even Microsoft Access, if that is all that is available).
  
  
• Make the database accessible through company-internal file shares, to facilitate access and data-sharing.
  
  
• Even better, provide Web access to the database, to allow home-based and remote parties access to a single repository of pre-employment data.
  
  
• Scan and attach all resumes to their individual candidate records.
  
  
• Tie your Internet or intranet posting process into the database, such that the resume and other posted information is automatically included for each candidate’s record.
  
  

The more available the CSM is, the more it will be used. And the simpler it is to update, the more valuable it will become as a tool for truly managing your SAP staffing process. Be careful, though—this is truly confidential data and needs to be treated as such, as issues associated with maintaining this database potentially impact the whole corporation from a legal perspective. Plus, it’s important to understand network and other bandwidth requirements when you begin deploying databases over wide area network or dial-up links—a poor database choice can bring a network segment to its knees if not implemented correctly.

Step 3—How to Perform an SAP Technical Phone Screen

Although many companies perform both a general screen and a technical screen, I feel that combining the two is in everyone’s best interests. That is, if the only real purpose of a general phone screen is to validate that a candidate is indeed available, that he possesses sound communication skills, and that he seems to fill the basic requirements of a position, this can just as easily be addressed in the first five minutes of a technical phone screen.

Although collecting the responses to phone screen questions is critical, the manner in which the questions are answered is nearly as important. The following list of questions for the technical phone screen emphasizes these “soft” areas. Note that the items placed closer to the front of the list are more weighty—in other words, if you have concerns over the answers you are hearing to the first few items, you might consider cutting the phone screen short and simply moving on to the next candidate!

• Perform the tasks of a general phone screen, including assessing the candidate’s availability, communication skills, general experience and background, and perhaps short-term and long-term goals. Does the candidate meet the basic requirements of the position and seem to “fit” in to your organization?

• Next, assess the candidate’s preparedness for this phone screen. Does he have the answers to your questions? Does he ramble on from one question to the next? Is he trying to read from a resume or set of notes? Does he have a clue what your company does (has he done his homework), or what the project is all about? The answers to these questions should give you an idea as to the level of importance the candidate places on preparing in advance, and even in customer satisfaction. You are his customer; how you are treated and spoken to probably reflects how the candidate will treat his customers in the SAP project.

• Record the candidate’s attitude or level of respect toward this phone screen. Like his level of preparation, this too will likely reflect what you’ll see day-to-day from him should he join your SAP team. Is the candidate chewing gum or trying to watch the kids? Worse (I’ve heard of this!), is he trying to catch up on email while talking to you? Or maybe taking in a ball game? Pass.

• Note the candidate’s tone. Is he eager to both listen and talk, in a manner consistent with someone anxious to join your team? Does he answer your questions from a negative perspective, rather than a positive one? For example, when asked about why they want to leave their current employer, candidates might bad-mouth everyone from their team leader to the SAP project manager to their current company’s lack of something or other.

• Did the topic of salary or other compensation come up? At this point, it should not—the information you have shared through advertising the position should provide candidates with a general compensation range. I highly recommend putting off any conversation about compensation until both you and the candidate feel that there is a good fit for employment. A candidate who starts nailing down his salary and benefits requirements five minutes into a phone screen scares me, personally. He may simply be short on common sense or a lack of awareness in how interviews should be conducted. On the other hand, he may just be playing the rate game (those of us in the SAP field call these folks rate mercenaries or curious shoppers, depending on their motivation). In today’s market, there are plenty of SAP fish in the sea.

• Did the candidate ask any questions after the floor was opened up for questioning? Did these questions reflect that he was actually listening, or were they canned? Importantly, did the candidate ask for the job, or in some other way indicate that he is the right person for the position? These kinds of questions give everyone an idea as to how interested the candidate is in the position at hand.

I recommend intentional open-ended questions to encourage a candidate to talk. Specific questions may be key to a particular position, too. Regardless of the types of questions, ensure that these are also included in and tracked by the CSM.

Step 4—Setting up and Holding Interviews

Based on a candidate’s phone-screen performance and attitude, they may be asked to actually “put on a suit” and show up to be interviewed (parenthetically, if a candidate asks what he should wear to an interview, note this in the CSM! It’s always been my opinion that unless a company volunteers a different dress code, an assumption of business attire should be made). The interview is where you get to see the candidate shine. Here, he puts his best foot forward and proves to everyone that he not only has the experience and aptitude to do the job, but that the project simply can’t be successful without him.

Interviews take time to plan and conduct. In the interest of saving time, the following list describes a detailed process flow.

Although it might seem like common sense, it’s important to note that sometimes attitude, work ethic, and an ability to work with others can be more important than who has the best technical resume or experience. In fact, as more and more individuals join an SAP team, a new person’s ability to work with and on behalf of the team only becomes more and more critical.

And on the flip side, we have all probably heard of losing a good candidate because someone on the interview team blew it. In one unfortunate incident, an overenthusiastic colleague of mine actually had the gall to throw a telephone at one of our candidates when the candidate answered his question with “I would call one of my technical contacts” during a role-playing session. Needless to say, we made an impression; the wrong one. The interview team therefore needs to demonstrate that it is both professional and personable, presenting itself as an extension of an excellent team of potential future colleagues to every candidate interviewed. Doing otherwise risks losing much.

Step 5—Key Interview Techniques and Approaches

The phone screen got rid of the unqualified candidates, and most of the marginal players, too. Now, with a candidate in front of you, you need to determine whether this is indeed the best person for the job. I like the following real-world approaches:

• Getting the business folks engaged in business-focused positions, such as those requiring liaison-like responsibilities, makes perfect sense.

• Relocating high-level, high-visibility candidates, or candidates interviewing for high-communication positions, from formal corporate settings, to observe these candidates in more “real-world” settings. A lot of insight can be gained by noting their behavior, language, and opinions at places like the company factory, refinery, or distribution center.

• A self-assessment form can aid in determining whether a candidate has the right approach or best mindset for tacking a particular job. I include such a form on the CD—see Competency Self Assessment.doc.

• Role-playing with three or four interviewers, especially when it comes to hard-to-fill technical positions surrounding SAP Basis or integration positions, is one of the best methods of confirming hard-to-prove skillsets.

As I alluded to before, a quality role-playing scenario can bring to light lots and lots of really interesting traits and characteristics in a candidate. What each scenario takes in terms of planning and execution time is more than made up in the quality of the SAP team that is ultimately assembled. Refer to the Planning CD for a number of different role-playing customer simulation scenarios, including:

• The first scenario involves troubleshooting a performance problem in a productive SAP environment, and covers much of the SAP Solution Stack.

• A “solution vision” question appropriate for solution architects and other senior technical resources.

• An “availability” issue can help identify how well a candidate balances customer orientation with restoring a system according to procedures (excellent for support, help-desk, and similar roles).

• A “people” issue rounds out scenario number four. This is a good scenario for team leads and managers, to observe how they might handle a common employment problem—the habitually late worker.

Basic Sample Interview Questions

Aside from role playing, one of the most effective methods of basic technical interviewing revolves around leveraging the technical and business requirements identified in the position description (a job posting or advertisement, for example). This assumes, of course, that the position description or advertisement itself was descriptive and fairly comprehensive. In the sample that follows, we are looking for a person to fill the role of an SAP Infrastructure Specialist—the basic questions that follow are asked from the perspective of the interviewer:

• Tell me about your experience supporting other SAP projects.

• When it comes to availability, scalability, and performance, which do you believe is most important from the SAP end-users’ point of view, and why?

• Explain what you know about a standard three-system landscape for SAP, and how it differs from other system landscape approaches.

• How did you gain your experience designing high-availability network solutions for SAP implementations?

• What roles did you play in designing, installing, and supporting the servers and disk subsystems in past assignments?

• How do your current technical certifications and college education fit in with your experience on SAP projects?

• What would be your approach if you were asked to install a patch or upgrade into the SAP Production environment?

• How would your colleagues describe you in terms of your work ethic and ability to get things done in a team-oriented environment?

With the preceding list, it should become apparent whether the candidate understands what an SAP solution looks like from an infrastructure perspective, how changes are implemented, and how well he might work as part of an SAP team.

Advanced Skills Interview Questions

When it comes to determining whether a candidate possesses the deep or advanced skills required of a position, it is usually not enough to ask questions related just to the subject at hand. For example, an applicant looking to hire on as an SAP Security Specialist needs to be asked questions both specific to, and surrounding, SAP security. A team with which I once worked called this a Deep 360, as it implied drilling both down (deep) and around (360 degrees) a candidate’s experiences and education. Thus, in regard to the security specialist position here, SAP authorizations and policies have to be covered as they make up the foundation of the job. But so too do OS-level permissions and policies, and database-level rights and permissions as well. In fact, a quick walkthrough of the SAP Solution Stack will reveal a number of layers that need to be discussed during the interview.

I also think there is a lot to be learned about how well a candidate understands a particular technical area when they are asked to troubleshoot a specific issue. Consider the following troubleshooting scenarios as we try to fill an SAP DBA position:

• The performance issue previously outlined in Customer Simulation Environment #1.

• A network issue causes problems with an organization’s approach to Disaster Recovery—log shipping.

• In this case, a database simply stops working (because its logs become full).

• This final troubleshooting scenario details an organization’s lack of capacity planning.

It’s evident from these troubleshooting scenarios that a lot of real-world value is gained through this type of interview process. Of course, in this particular case depending on the scenarios that you choose, perhaps only a truly skilled SAP DBA might be in a position to intelligently administer these questions. I suggest that you use my scenarios as templates for creating your own.

Step 6—How to Rank Prospective SAP Candidates

After the interview is wrapped up, the real fun starts. Again, I recommend leveraging the CSM or some other kind of candidate assessment tool to help compare and evaluate each applicant in the following paper areas—paper refers to diplomas, certifications, recommendations/references, and so on, as evidenced through the phone screen, interview, reference checks, and other background checks:

• General experience

• College degree(s)

• Certification(s)

• SAP-relevant organization(s) and affiliation(s)

• Company-employee-based recommendation(s)

• Other references and recommendations

Next, a closer look at the area of hard technical or business-relevant skills is in order:

• Specific experience/skills related to the position

• Other skills that may prove complementary to the position

• Troubleshooting ability

• Verbal communication skills

• General intelligence

Although the aforementioned technical and business skills tend to help a candidate get a position, the items in my next list tend to help him keep his job in your SAP support organization. Use the CSM to compare and evaluate each applicant in the following soft-skill areas:

• Level of professionalism (range from high to low, reflecting the general feel of the interview or any specific events that either transpired or were discussed)

• Level of enthusiasm or eagerness (range from high to low, addressing to what degree a candidate seemed genuinely excited about the prospect of joining your SAP support team)

• SAP social personality (social skills range, from Team Player to strictly “Computer Room” personality)

• SAP skills personality (range from “new project/high stress” to “maintenance mode/low stress”—refer to the end of this chapter for more information)

• Level of adaptability (range from high to low, as evidenced in discussions of how the candidate managed long-term changes in his work or IT environment or career)

• Level of flexibility (range from high to low, addressing how the candidate reacted to short-term problems or issues, like the need to work over a weekend or stay late to resolve an issue, or the need to travel)

• Goal orientation (range from high goals to some goals to weak goals to unrealistic goals to no goals, where a candidate is really only penalized if they cannot fashion a response to specific questions like “what are your short-term and long-term goals?”)

• Overall potential (range from high to low, stating whether the candidate has potential to succeed in the organization beyond the specific position you are trying to fill)

Given everything in the preceding list, it’s apparent that both position-specific skills and soft skills carry a lot of weight in determining the best candidate for a particular SAP position. The ideal candidate tends to be “balanced” across both areas, being not only technically adept or business-process savvy, but also quite strong in many of the soft skills.

And I would be remiss if I failed to mention the following—any applicant who says he can do anything and everything you want is not someone you want. Why? Because he lies (and not very convincingly). Always beware of candidates who seem to answer each of your questions with “yes, I can do that”—if this becomes a pattern, simply start asking for detail surrounding where he has done such-and-such before. Drill down into the detail, pull it out of the candidate via role-playing, or whatever, and pay attention to whether a “yes” turns into a “well...uh...no” after a few minutes.

Interviews in the Real World

It can be amazing how often a lack of soft skills (and common sense!) gets the better of otherwise-qualified candidates. This real-world section is focused more on the candidates being interviewed rather than the organizations doing the interviewing—as we are all interviewed at one time or another, I believe there is value in this approach.

In this first true story, I vividly remember one case where an individual phone-screened with my team quite well for a senior SAP R/3 basis position, and an interview was set up for the next day. During an excellent interview over salad and pasta, the candidate impressed us with his experiences and troubleshooting abilities. We enjoyed dessert, and even sprang for cappuccino, as our future SAP star wowed us with stories of international travel and global roll-outs. We hated to see it all end, but eventually we had to head back to the client site, presumably with great news about our latest “find.” As we were all making our way out the door into the parking lot, the candidate casually tossed out the following question: “You guys don’t do drug tests, do you?”

We all had an uneasy feeling, as the senior managing consultant among us replied with something like “Yes—there’s a new-hire screen, and then the potential for random testing exists throughout your tenure with the company. No problem for you, I’m sure.”

The candidate was visibly affected. “Oh...no. Well, you know, a lot of technical guys like to smoke out a bit every now and then.”

They do? Then it was our turn to be visibly affected. “Uh, OK, well, then you have a great day and we’ll get back to you ASAP.” Thanks for playing. Next.

In hindsight, our senior managing consultant should have told our candidate then and there that he had disqualified himself from getting the job, that the interview process was over, and that we were sorry.

In another case, we were interviewing contenders for a position as a SAP Data Center Lead. One gentleman impressed us with his demeanor, intelligence, and what seemed to be great personal drive or motivation. He was the senior operator in a mid-size SAP shop across town, and breezed through our customer simulation scenario, well on his way to landing the job. In the closing few minutes of the interview, we sat around and generally got to know one another, and an associate of mine fired off another question:

“Describe your favorite thing about your current position.”

We could never have been suitably prepared for his answer. It went something like this:

“Sometimes I like to go into the data center late at night, and turn off all of the overhead lights. I seal the doors to operations, close off the tape room, and get it really good and dark. Then I just sit back and watch all the blinking lights. Man, it’s kick a@@!”

In retrospect, this guy was probably hanging out with the senior basis guy who asked about the drug test.

In my final real-world interview case study, I was wrapping up a two-hour interview process with a candidate who showed real potential. This individual had posted for an SAP technical support position advertised in the local newspaper, and in all respects he looked good. He met the qualifications and experience levels, his references checked out, a short customer simulation scenario went smoothly, and in general he interviewed well. My part of the interview, as the hiring consultant/manager, was to go over expectations, timelines, and eventually compensation. And I was going through his updated resume one last time, a resume that he had provided that morning.

Something caught my eye. In a different font on his resume, at the end of a list of technical certifications, were these four letters: MCSE, Microsoft Certified Systems Engineer. Today, that wouldn’t phase me, as there are tens of thousands of MCSEs around the world. But back in mid-1997, this was a big deal, and it really set him apart for the particular assignment I needed filled—supporting a growing Microsoft NT/SQL Server/SAP account. It seemed as though the MCSE designation had been added as an afterthought, however. As a relatively new MCSE myself at the time, I would have felt compelled to place this in a prominent spot on the first page, ahead of other less worthy certifications, had I been the one doing the interviewing. So I questioned him. Although I don’t remember my candidate’s precise answer, I do remember asking additional questions as to which core exams and which electives he took to achieve this then-premier Microsoft certification. And I remember feeling quite awkward as he fumbled his way through a certification process he obviously knew so very little about—in an attempt to land the job, he had falsified his resume at the last minute.

My point with these three preceding interview cases is simply that everyone needs to take interviews seriously and professionally. It’s important for interviewees to remember that the job is not signed and sealed until the day you start. Further, it’s the little “side conversations” that get candidates into trouble. If you’ve been looking for a job a while, you tend to have the “interview” questions down pat. Questions like “what’s your goal in five years,” “Tell me about your weakest personality trait,” and so on simply don’t phase a seasoned interviewer. What does get the best of many of us tends to be the elevator talk, the discussions “before” or “after” we think the interview actually starts and ends. Believe me, the interview does not end until you get in your own car and drive away. Our candidates could have done better if they had followed these guidelines:

• Do not ask stupid questions. Asking about the company’s drug testing policy during an interview is a stupid question (it will come up naturally after an offer is made).
  
  
• Stay away from profanity. Unless you are interviewing for a squad leader position in the Marine Corps, there’s little room for colorful expressions.
  
  
• Anecdotes or references to the strange little things we all do that make us “us” have no place in an interview.
  
  
• If unsure whether you should ask or say something, don’t. I call this the “Keep your mouth shut” policy. It works.
  
  

I am sure many of my readers could add a few more compelling items to the preceding list. Again, the point is straightforward: Be professional.