17
Mar 2016

What actually is... Scoping: A look at the responsibilities of a BELLIN consultant

0

What exactly does a treasury consultant at BELLIN do all day? This question was raised here a few weeks ago in “What actually is a kickoff meeting?” where we attempted to flesh out the rather vague concept of the kickoff meeting. However, consulting doesn’t begin or end with the kickoff meeting. In fact, it sometimes starts far before that: in the so-called scoping phase which I would like to present in a little more detail today.

Before any consultant becomes involved, the customer must have our treasury management system. This may sound trivial but any consulting process is, after all, preceded by a sales process; and nowadays these selection processes are often long and detailed. Many, in particular larger businesses tend to use standardized procedures, e.g. RFPs, often even supported by external consultants specifically for the selection process. Once companies reach a certain size, this often also includes a so-called scoping, i.e. the detailed evaluation of customer requirements before they ever sign a contract. This is meant to illustrate just how our software can meet the customer’s needs. For us consultants, this means that we frequently encounter a customer in early stages of their projects – as early as the selection process and thus before the customer has acquired their own tm5.

Typically, a scoping represents the first point in a sales process where our consultants participate in discussions with the customer. At BELLIN, it is usually two consultants who join these meetings, sometimes accompanied by a member of the sales team. These meetings usually span several days and the scoping results are documented in an official scoping document that is then included in the final proposal.

So what do we discuss during a scoping?

Many questions have been raised during the sales process but the scoping represents an opportunity to discuss customer requirements in more detail. This often depends on how detailed the RfP (Request for Proposal) was: the less detailed the selection process, the more detailed the scoping. Ultimately, we’re looking at an analysis of “as is” processes and most crucially also the question of how these processes came to be:

  • Are treasury processes based on company guidelines?
  • Is the direction determined by legislation?
  • Or have processes “developed naturally” over time?

We’re not necessarily discussing how processes can best be represented but whether or not it is actually a good idea to reflect them 1:1. What makes most sense? Often, responsibilities and workflows have developed over time and don’t always represent the best setup. Sometimes they even include tasks that shouldn’t actually be performed by treasury – maybe because they originally came from controlling or accounting.

Once all of this has been discussed, everyone should have a clear idea of which modules and components are needed. Equally important is the assessment of the resources the client will have to bring to the table. Are they going to need support during the implementation? Do they have the resources to manage entering master data, deal history and documenting processes without external support?

Based on these deliberations, we draw up a draft project plan with the customer as part of the scoping; this plan provides detailed answers to the following questions:

  • Which resources and capacities are needed?
  • When will these resources be needed?
  • How many consulting days should be calculated for individual topics?

A project plan means diving right into the realm of project management. This is a very important topic, in particular when it comes to larger projects, which is why I’d like to look at it in a little more detail. Many customers simply don’t have the resources and capacities to manage the entire process on their own and still guarantee high quality. This is where BELLIN consultants can provide support. The project management scope in each case should be discussed during the scoping in order to ensure this is reflected in the proposal. It makes sense to discuss and determine as early as during the scoping which project management tasks will fall to the client and which will be taken on by the consultants. This ranges from meeting minutes during implementation, maintaining the project plan and the outstanding issues list to conducting trainings, creating manuals, chairing project status meetings or participating in steering committee meetings.

Ultimately, every customer is unique, and this is echoed in every scoping: we need to conduct an analysis for each customer that gives them the absolute certainty that our proposal meets their requirements. It doesn’t matter if processes are kept or adjusted; if the customer will be responsible for project management or the consultant; what we provide is a roadmap for every project, making sure we’re all on the same page when it comes to project specifics and the timeline. This way customers know 100% what it is they’re signing up to and we as consultants have made the first step to a business relationship based on trust.

Add new comment

Plain text

  • No HTML tags allowed.
  • Web page addresses and e-mail addresses turn into links automatically.
  • Lines and paragraphs break automatically.
CAPTCHA

This question is for testing whether or not you are a human visitor and to prevent automated spam submissions.