Index finger points to a spot on a map using a magnifying glass.

In the second installment of our practical guide for clients, we bring you an explanatory list of the meetings that comprise the process leading up to hiring a software provider for the very first time.

Let’s get straight to business. From the moment you pick a software company to the point of signing a contract with it for a new project, a series of meetings unravels as follows:

New client company

Sales

Presales

Small series of workshops (optional)

Business proposal

Contract negotiation and sign-off

Project initiation

Kick-off

Sales. This first meeting should be a joyful, get-to-know-each-other-better business meeting. That being said, no tough decisions have to be made and no blueprints are laid on the table. Your to-be software company will do most of the work consisting essentially of its company and products presentations.

Given that your software providers want to know you better, they’ll be keen on exploring your business needs and how you invision the application you’re thinking about.

There are two paths you can go down at this point:

 

  1. Your company’s business need may be fulfilled by an existing product found in the portfolio of the software provider. If this proves to be the case, then the following talks will focus on pinpointing the implementation details. For example, if the software company determines that esFields is the application perfectly suited to your company’s needs, they will next try to extract from the info you provide, implementation details such as: number of users, number of locations, types of forms required, so as to integrate them in a demo These are also the main concepts of the application.
  2. The desired solution for the expressed business need can be achieved through custom development. One way of going about it is elaborating a document of business requirements specification – a very detailed analysis which allows both parties to foresee with fairly high precision the end result, estimate costs, deadline etc. This can be done by you, the client, if your company has its own business analyst, or, if not, by your software providers. Another way to do it is organising a few more meetings (or workshops). This is a more flexible alternative, applied if your business needs are not yet very well defined. The software company will now take charge of elaborating a lighter version of the mentioned document, rather an overview of what’s to be done which also allows for a clear projection of costs and time.

Best practices dictate the sales meeting described above should be broken down into two distinct meetings. Thus, drawing a high-level outline of your business need should be the final point included in the sales meeting. A more thorough detailing of this need (points a. and b.) would best follow in what is known as the presales meeting. Bear in mind, though, the “agendas” of the two meetings can very well merge, depending on how your company works.

*A small tip: for the comfort of knowing that your business is safe and to make the most of your information exchange, don’t forget to sign a non-disclosure agreement (NDA) before starting the discussions above! Do you have a standardised one? If you don’t, ask your software company to provide you with one.

The business proposal contains: the resources involved, the estimated time of execution, the projection of the end result, the estimated costs. From this point on, the decision rests in your hands. Once the client gives the green light, what follows closely is the contract negotiation and sign-off, then a project initiation meeting as an ultimate preparation of the project kick-off.

Now, what you mustn’t gloss over is the fact that every project involves risks and probably the greatest of them are these:

  1. The project is not completed within the agreed time frame and/or exceeds the allocated budget. You do have an avoidance strategy at your disposal and it must start at the analysis phase; be sure your business requirements are clearly defined and keep a tight control over how they are technically applied by the development team. Also, ask for intermediate releases!
  2. The new software application is met with resistance by its users. More of an internal challenge, this one, but with lower chances of occurring if the client company is able to manage the transition and the software provider has worked towards a smooth running, innovative and genuinely helpful application.

Left with questions after reading this article? Get in touch with us!

 

Article Rating Score
[Average:5]
Comments are closed.