We all know how damaging—not to mention downright uncomfortable—it can be when the wrong consultant is picked to fill a role on a project. Timelines are delayed. Tasks need to be done over. Money is wasted. Other team members have to start filling in the gaps and covering for the mistakes of their misplaced peer. Resentment builds. Communication among team members suffers or stops. And the customer’s trust is lost.

That’s obviously bad for everyone involved, including especially the consultant who not only must live through this awful experience and may be marked as a failure—but who probably could have successfully contributed somewhere else. But it’s also bad for those consultants who are not involved. That includes consultants—either not considered for the assignment or passed over—who could have been successful in the role. They may have missed out on a real opportunity to advance their career.

Which is why almost no decision on a project is more important to get right, and get right the first time, than the decision about which individuals will work on a project. That has always been true, but is even more true now in agile environments. Agile relies much more than waterfall on informal communication and trust among team members and between team members and customer stakeholders. For frequent (or any) communication and progress to occur, people must trust each other and also trust each other’s competence.

The solution to the problem of how to avoid SAP hiring mistakes is to find and hire people in a way that aligns with today’s work environment—a way, in other words, that is agile. It is wrong to think we can run our teams in an agile way after they get on projects if we do not adopt an agile hiring practice before they arrive.

Agile Teams Call for Agile Hiring

What do I mean by an agile hiring practice?  Here are four key principles:

Agile hiring is not top-down. Waterfall projects are very formal and hierarchical, and yesterday’s hiring practices reflect that orientation. Today’s SAP job market is much more agile, however, and successful candidates will play a much more active role in making sure they get into projects that are right for them. One key indicator is how engaged successful consultants have become on networks like LinkedIn, SDN, and other community forums. Socially networked consultants aren’t passive. They create relationship with colleagues across the SAP ecosystem that are much more interactive and peer-to-peer, regardless of formal titles. So alert project stakeholders are more likely to know who these engaged consultants are—and alert consultants are more likely to find out early about appropriate opportunities—effectively short circuiting resume reviews and other old school practices.

Agile hiring is outcomes-based. Today when we run projects we think in terms of value streams—in other words, in terms of outcomes, not process. We’ll pick and choose the specific functionality we need from a module rather than simply adopt the module as a whole, just because that is how the functionality happens to come packaged. That’s the thinking behind solutions like Guided Configuration in SAP Activate. Likewise, when it comes to hiring the right consultant, project leaders should consider candidates who have achieved actual outcomes—not just amassed experience—and, in particular, outcomes that align with the project customer’s specific business goals. That will require looking deeper into a candidate’s background than just a resume’s topline summary. Senior leaders need to ask, “Where are the actual outcomes in here, or is this all just process?” By the same token, consultants need to communicate loudly their own personal outcomes, including the outcomes they wish to achieve in, and for, their careers. And they need to be very up-front about it.

Agile hiring looks across silos. When agile consultants speak with business stakeholders, frequently and iteratively, as they are required to do, they must reach outside their technical domains. Agile also demands they reach across technical domains, like when programmers interact with testers even before code is formally released to QA. The same logic applies to hiring. Agile consultants need to demonstrate the ability to converse in different languages (technical or otherwise), and they do so best by actually conversing in those languages in public. A good place to do that is—again—in key industry forums, both online and at real-world conferences, like SAP Sapphire. Likewise, hiring managers should take notice of consultants who demonstrate that kind of multi-domain fluency.

Agile hiring is about hiring agile skills. The most obvious point is that agile teams require consultants with agile skillsets. So if those are what you’re looking for, look for agile-certified consultants. Certification is no substitute for actual experience but it at least demonstrates both a skills baseline and a self-starter attitude. Also, obviously, look for backgrounds that demonstrate success at applying agile skills. But remember—just because a project is not formally called “agile” doesn’t mean that consultants on the project can’t demonstrate agile skills. They can deliver functioning deliverables rather than just code. They can organize their work into small chunks (whether called “sprints” or not). They can interact frequently with customer stakeholders. They can collaborate a lot with colleagues across technical silos. So look for that. And if you are a consultant, don’t wait to be asked to adopt agile methods. Look for opportunities to do that in the project you are already engaged.

Here is the takeaway: When an SAP hiring mistake gets made, there is responsibility, and consequences, on both sides. To avoid those mistakes, both senior leadership and potential hires must take into account the new consulting environment. Following the same old rules, in the same old formal, hierarchical way no longer works.