Approaches to “Filling in the Final Holes”

Don’t let the fact that we’re staffing again midway through the project fool you into thinking that these final additions to the SAP TSO are anything but critical. They are! As you can see in Figure 12.2, these positions support key solution vendors, tasks, and essentially the fundamental layers of the SAP Solution Stack.

The skillsets that will be brought to the table during this round of staffing will take us through the remainder of the SAP project, and position us for Go-Live and beyond. Some of the positions will exist from this point on through the life of the SAP implementation, as I said earlier. But perhaps even more importantly, some of the short-term positions actually represent critical must-have skillsets, needed to simply make it to Go-Live. Regardless, both long- and short-term posts will be subject to their own unique challenges in regard to staffing, transitioning into the SAP TSO, and so on.

Before we discuss approaches to filling these positions, let’s take a quick look at the keys to successfully expanding the TSO.

Keys to Expanding the SAP TSO

In my experience, five fundamental keys exist to bringing new members into an existing SAP Technical Support Organization. In no particular order of importance, these include the following:

• People skills—the ability to build and maintain professional relationships—represent key #1. The presence or absence in SAP TSO newcomers of other “soft skills” also plays a key role in how the overall TSO will perform during the last half of the project. However, a team not ready for a newcomer, or a newcomer not ready to work as an integral component of an existing team, will have that much more difficulty to overcome. Often, the key to a good relationship relates directly to simply understanding and working well within the established hierarchy—respecting everyone on the team, and treating everyone well, will go a long way toward cementing relationships that last. Respecting the hierarchy with regard to senior and junior folks, mentors and those being mentored, and where the newcomer fits in, is critical too.

• Attitude toward communication is key #2. No one can afford to be aloof or “go it alone” during these precious last months before Go-Live. That is, the importance of communication becomes crucial and cannot be overstated. Consider the following example. A new member of the team has been brought in as the eCommerce guru. His job is to tie together SAP’s Enterprise Buyer Pro system with a Requisite catalog capable of being securely updated by vendors and partners. He must also establish a process for maintaining the catalog. This newcomer will therefore work closely with the folks in the company’s security group to ensure that all firewall, DMZ, and other such intranet/Internet concerns are addressed. And he will work closely with the business folks and SAP Infrastructure/Basis team as well. Naturally, if our newcomer is not a team player, or not comfortable communicating his decisions and configuration requirements, everyone will fail.

• Key #3 is this—everyone needs a backup. A single person, no matter how good he is at his job, becomes a single point of failure if all knowledge of a particular piece of the solution is known only to him. Take again our SAP EBP newcomer as an example. If this guy keeps everything to himself, if he does not share the knowledge obtained through implementation, the project’s risk grows. For every position, task, or responsibility, a second person needs to be trained and able to “step up” should the need arise. This is especially critical with contract personnel—beware of providing your consulting folks with key knowledge that is not being regularly transferred to employees or long-term contractors. For such a no-brainer statement, I have seen this time and time again at client sites. And it works both ways, as I feel that it is the client’s responsibility to ensure that a staff member absorbs a consultant’s knowledge as much as it is a consultant’s responsibility to ensure that he proactively shares his knowledge with the client. In a perfect world, I would require every consultant to “tie off” with an employee on at least a weekly basis, with the goal being to share expertise, knowledge, and insight gained that week. This would be followed up with a weekly written report indicating the same, to be archived in the project’s Knowledge Repository. For short-term projects (that is, a few weeks or months), I would simply pair up each consultant with an employee tasked with knowing how to “do” or support everything the consultant does when the consultant is finally out of the picture.

• Building on key #3 is my next key—documentation. This is without a doubt the most important component of providing “backup” to other team members. Unfortunately, the job of enforcing the creation and maintenance of good documentation is often put on the back burner, becoming important temporarily only when a crisis occurs (like when our SAP EBP newcomer winds up in the Emergency Room after falling asleep at the wheel because he hasn’t slept more than four hours a night for the last week). Key #4 needs to be pushed from the top echelons of the project all the way down to the guys installing software and turning the screws—without documentation (processes, procedures, and practices), your SAP implementation will never achieve the highest levels of availability otherwise possible.

• A balance of first-rate experience in completing the tasks at hand, coupled with knowledge of why and how the business side of the project is affected by performing (or not performing!) these tasks represents my final key, key #5. In this area, being successful is all about achieving balance. The best newcomers to the project will understand how the business is run today, and how their efforts will bring the company up to the next level of integration or capability. Therefore, these folks need to have close to the same understanding of the business processes (that they are supporting via their position in the SAP TSO) as the current team does. And it goes without saying that they need to be up to the technical challenges they will face, too.

With these five keys in mind (reinforced in Figure 12.3), let’s drill down into the two approaches to staffing for these final SAP TSO positions—reallocating internal staff, and bringing in third parties.

Transferring in New Internal Folks

Even though it’s not a likely avenue at this point in the project plan, it’s worth mentioning that perhaps the SAP expert you are seeking is just a “few cubes” down. I say unlikely, though, because by this time you have probably pulled every SAP-literate Information Technology specialist or Business Analyst into the SAP TSO, either on a full-time or shared/part-time basis.

In larger companies, though, it’s certainly possible that the SAP EBP expert you need, for example, is hiding somewhere in an eCommerce or Internet Connectivity Support group. Perhaps he’s a newcomer to your company, or a recently appointed contractor—check with the HR organization to scour through recent new hires and other folks brought on board in the last year or so. A really good HR group (or IT manager) will also maintain something of a skill set or proficiency database of their folks, too—run a search against it, and you may be surprised at the talent cubbyholed away in some not-so-faraway place.

Finally, post the job internally on the company’s intranet or other job-posting system. Communicate open positions via weekly updates to the business and company-at-large, or the company or IT-specific newsletters that may be regularly published about the SAP project. Target your colleagues in the various IT and business support groups, too, searching for anyone who might fit the bulk of the job description.

After all of the prospects have been identified, evaluated, and ranked, pull out any clear candidates. At this time, it might also become apparent that other prospects could rise to the occasion with a bit of formal training or minimal on-the-job training—put these candidates to the side, too. Then I recommend going through the technical phone screen and role-playing interview process described in detail in Chapter 8, keeping in mind that an internal candidate will require less investment in some respects than outside candidates. That is, as you see in Figure 12.4, your internal candidates already have the following advantages:

• They know the company. This means they have contacts and relationships, understand how things get done, have some understanding of some of the business processes and practices germane to the company, and so on.

• They are easy to communicate with—they have a company telephone number, email address, pager/cell phone, and so forth. They are therefore instantly accessible, and presumably instantly “productive” future members of the SAP TSO. They are ready to go!

• They understand something about the impact that the SAP project will have on everything. Therefore, they should appreciate the fact that SAP will change the manner in which the company does business. And if they have sought out the project and you’re talking to them, it’s a given that these changes excite them!

In the end, though, check this step off your Master Check-Off List, and be prepared to go external with your job search. Of course, if the need is critical, and you wait too long, you’ll find yourself in trouble. I recommend that you start the external search as soon as you finish searching for internal folks, but before you start phone screening and so on. In this way, as you begin evaluating your internal “finds,” you will simultaneously be collecting qualified leads from the outside, which brings us to the next section.

Leveraging Third-Party Consultants Again

Assuming that the idea of bringing in an internal candidate is simply not feasible, the only real alternative is to leverage your favorite consulting firms again. I say “firms” because you need to give yourself not only choices in candidates, but also the ability to leverage pricing, terms, and conditions between different consulting organizations.

But should you go to the Big Five, your enterprise hardware/software providers, a mid-size SAP consulting firm, a Mom & Pop “body shop,” or the independent contractor route? That’s a big question, and like any good consultant, I have to answer it with a resounding “uh, it depends.” Each avenue has its own good and not-so-good points. Unlike staffing the bulk of the SAP TSO, where I tend to favor the larger consulting organizations to achieve your 80% staffing goal (to leverage economies in pricing, administration, and to minimize the number of players and so on), there’s much more to discuss at this level of staffing. Consider the following:

• The Big Five and mid-size SAP consulting firms probably have the mySAP-specific expertise you’re looking for, but do they have the niche expertise you need that is specific only to your unique SAP Solution Stack? Further, can you afford them? Finally, are these skills embodied in a single person, or will you need a team of “micro-specialists” to achieve your goals?

• The enterprise hardware/software providers might be less expensive, but do the individual SAP consultants on their consulting rosters understand more than just their niche areas? And do they understand the ramifications that their niche areas have on your mySAP project holistically?

• The body shops and independent contractors may be less expensive from an hourly perspective or in the short-term, but are you assured of getting “the right person”? Also, if you lose this person to another SAP shop for an incremental few dollars an hour, what is your recourse? Will the body shop be able to backfill in a timely manner with an equally qualified resource?

These are all important questions. The right answer for many companies that have implemented SAP in the recent past amounts to taking a step back, though, and approaching the problem from a broader perspective. Let’s examine some of their real-world methods next.

Consulting in the Real World—Fewer Is Better

Two of my newest and very successful SAP implementations took the approach to staffing that fewer partners was better than more partners. In the first case, a combination of the customer’s internal people, HP, Microsoft, and SAP accounted for 95% of the project team. In another case, the customer, HP, a third-party mid-size consulting firm, and SAP accounted for 95% of the project team. Figure 12.5 illustrates this approach.

What did both projects have in common? They kept the number of “players” to a minimum. In effect, they

• Reduced time related to all of the overhead associated with bringing in lots of incremental partners—relationship building, negotiating pricing and terms/conditions, working out how interviewing/evaluating candidates is accomplished, invoicing/billing processes, and so on.

• Minimized finger-pointing. With fewer players comes improved accountability, simply because the lines of accountability and responsibility tend to be drawn more clearly. Like so many other things, I look at this from a solution stack perspective—one partner or vendor is held liable for each layer in the stack.

• Simplified organizational dynamics. Just as fewer players equates to less overhead, fewer players also tends to equate to fewer communications issues, simpler escalation procedures in times of trouble, and so on.

These two companies had another thing in common, too. They each leveraged best-of-breed partnerships to comprehensively address every layer of the solution stack. So, instead of trying to make a “Mom and Pop” peg fit into an “enterprise hardware provider” hole, these two companies pieced together a virtual support organization that worked hand-in-glove. And they didn’t need to engage 20 different consulting, software, and hardware companies to be successful.

Consulting in the Real World—Bigger Than Me

In another real-world example (not related to the two companies highlighted in the preceding section), my SAP customer shared with me a philosophy I now label “Bigger than me.” Their approach was simply to bring in organizations that are “bigger” (in terms of number of employees, level of expertise, annual revenue or something similar) than their competitors, for the following reasons:

• Bigger companies will probably be around longer, surviving trying times, downswings in customer purchases or spending, and so on. This includes technology and point-solution companies as well as consulting organizations. Closer to home, the bigger consulting organizations have enough work to keep a stable SAP workforce employed, rather than relying on 15–20 W-2 employees and a roster of “phantom” employees gained through relationships with independent contractors and partnerships.

• Bigger companies by virtue of their size have access to more people. Thus, should attrition take its toll on the project team, the bigger company could more quickly backfill with newcomers who are almost equally qualified. Worse case, the bigger company could leverage its partner base, which is more extensive than that of a smaller company, and satisfy demand in this way, too.

• Bigger companies tend to be mature; they leverage proven processes, utilize sound billing and invoicing systems, carry insurance on their consultants, provide their people with the tools and equipment to do their jobs, and so on. This all adds up to a mature organization, preferable to the alternative even if everything else is equal.

Thus, in this particular customer’s eyes, bigger companies were therefore “safer” alternatives to smaller organizations, generally speaking. My customer applied this philosophy to everything, going with the biggest players across the entire SAP Solution Stack arena rather than smaller specialty organizations. Looking back on their decisions and the number of smaller third-tier players that have disappeared or been swallowed up by others in the last year, it’s probably hard to argue much with their approach!

Of course, they acknowledged two primary disadvantages to this approach. First, the cost per consultant tended to be higher than what could otherwise have been pieced together through smaller organizations comfortable with less margin (or burdened with less overhead). Second, “bigger” still generally meant longer times in getting things done than perhaps a smaller, more nimble company would be capable of. But with the benefits already noted, I was told that the rewards outweighed the penalties for this particular company. And in the end, they were still happy with their decisions.

Speaking of decisions, now is a good time to take a look at staffing decisions as they relate to bringing in new experts, or specialists, into the SAP TSO.