Implementation consulting is often about arbitration. It's about being in the middle. It's about lobbying. It's about communication. And, ironically, it's about leadership.Implementation consultants are not usually in top leadership positions within their companies. But by virtue of representing the supplier to the customer and representing the customer to the supplier, ICs are often in the thick of things when it comes to determining what works and what doesn't work, both from the customer perspective and the supplier perspective.
That's especially the case if the supplier is a SaaS (software as a service) vendor. In a SaaS environment, implementation consultants don't need to be as concerned about the hardware and software infrastructure or publishing of applications to the desktop as those outside the SaaS universe. Their concern is more about guiding customers in the proper use of the system, discovering gaps in business processes, relaying opportunities for service improvements back to the supplier, and keeping the deployment on time and in budget.
Use Cases and Use Scenarios
Successful implementation of SaaS solutions to customers depends on many things, one of which is having an arsenal of use cases available to describe the precise steps in accomplishing a task, whether those steps are part of the core functionality of the system or workarounds designed to accommodate gaps in the feature set.
I have mixed feelings about use cases. On the one hand, they're useful abstractions of what to do in specific situations. They detail precisely the how of getting specific tasks accomplished in a specific environment. But they aren't so good at the why. The reason why one might follow these precise series of steps is usually not documented in a typical use case.
This is where use scenarios come to the rescue. Here is where an implementation consultant can lead by example. Instead of abstractions, the use scenario employs a narrative giving the entire context from the customer perspective. There can be several scenarios for a particular use case depending on the actor involved, their motivations, time constraints, knowledge of the system, and other constraints. Clearly, use scenarios are more like screen plays, while use cases are more like "some assembly required" instructions for "do it yourself" retail products.
When the implementation consultant documents use scenarios, he/she is taking the lead in making the use case more useful to the customer as well as explaining to the supplier the full customer experience of the software. Leading by example in this situation is obviously very useful to both interest groups.
Scenario Exercises
Something else related to scenarios has landed on my radar screen recently. Business schools are starting to add another tool to the standard case studies used to teach business analysis. In an environment where foresight and agility are as critical success factors as the ability to analyze a market or campaign, scenario exercises may be just the ticket required to help SaaS suppliers further develop leadership potential in their employee ranks.
One example is the Compass Exercise mentioned by Paul Bracken in his excellent article, "Futurizing Business Education". Taking staff members through the north, south, east, and west compass points as symbolic representations of your superiors, your staff, your colleagues, and those with whom you work outside your company is just the start of the exercise. Then you intentionally encourage those present in this brainstorming type session to break out of standard North-South, East-West thinking patterns. For example, adding features to a SaaS offering is sometimes best accomplished by talking to your customers directly, encouraging them to talk about specific issues with other colleagues in your organization, then using that context to make your pitch to upper management for those features that you want in the next release. This is just one more example of "leading from the middle".
"Seeing the elephant" is another brainstorming scenario exercise in which the point is breaking down silos between departments. The idea is to assign people to break-out groups that examine a scenario from the perspective of a particular set of actors - investors, analysts, managers, executives, etc. Then when they reconvene with the larger group they make their pitch for that particular perspective. The object is to encourage participants to move outside their narrow departmental focus, to acknowledge other perspectives, and then to attempt to align those perspectives in achieving a corporate objective.
I have the good fortune to work in an organization that encourages leading from the middle. But even in the best of situations, it's smart to remind everyone about scenarios, to encourage agility and foresight, to tackle ideas and perspectives outside ordinary day-to-day duties. The great thing, as Paul Bracken argues, is that these skills can be taught.
