A practical approach to formalising IT contract details and procedures, based on high-quality feedback

Motto: Knowing the rules of how to play chess does not make you a world-class chess player.

Assumptions:

I wish to summarise my recent set-ups I have had over the past years when working with the JCommerce team (www.nearshore-it.eu) on providing software development and consulting services to Clients in Western and Northern Europe. Today’s article will concern mainly the Clients’ feedback tips related to their initial requests as well as the challenges associated with concluding contracts. I hope that what I am about to show below will help at least some of you better understand the perspective of the Client as well as that of the Vendor, and translate it into an effective and transparent working model in the near future.

Working on the Client’s initial request

There are many types of requests that the software Vendor receives from the Client. Some of them actually provide little context, whereas other ones are context-rich messages. Depending on the prospect’s input (materials, requirements, business knowledge, etc.), we are able to prepare our initial feedback.

Here is an example of a context-rich enquiry:

Hello team,

I am the VP Technology at …

We are looking for ways to expand our development capacity and I have been tasked with identifying near-shore and offshore opportunities to outsource development. I look forward to opening a line of communication to discuss this further.

I look forward to hearing from you to discuss the requirements and our potential business relationship in more detail.

Many thanks,

Mr. X

On the other hand, a low-context enquiry example is as follows:

Dear Sirs,

We are an established medium-sized Internet business, operating for x years in the y industry.

We wish to rewrite our website using the latest Z technologies to make it more stable and flexible, as well as to add new functionality.

We are looking to outsource this, in part, to a team of nearshore developers who can work with us using the SCRUM methodology. This would involve rewriting all layers of the application (the core solution to use as a starting point has already been created), using the following technologies:

.NET, C#, MVC, some AngularJS, Entity Framework, Identity 2.0, HTML5, CSS3, bootstrap.

…

Let me stop for a while and focus on the crucial word: Feedback

Feedback can have several dimensions. Let us focus on just two of them for now.

First: Feedback as an immediate reaction to what has been submitted to the software Vendor. It is not about what is our answer to the Client’s initial request. It is about showing our potential partner that we take care and are ready to talk about the idea — that we are committed and supportive.

Second: Feedback as a relevant info based on the Client’s request, which includes all the necessary info /the so-called: material pack/.

Third: Hybrid — as a combination of First & Second.

I am not here to judge which of the presented types of feedback is better and more effective. I am trying to make you aware that both of them are important and, in most cases, Hybrid (the third one) should be a kind of habit when approaching the Client’s initial enquiry.

We all know that first impression is crucial (and it does not matter if it is fast or slow). But what is more important (based on my observation I have made over the past years when approaching Clients with the JCommerce team) — is what happens next: When all the dust of the first contact has settled, all that matters is the quality of feedback, the quality of communication during the initial phase, the understanding of the Client’s needs, and being responsive and supportive.

How can we influence the quality of initial feedback?

Let me present you some practical tips below when approaching the first contact with the Client:

1. Arrange a direct follow-up call (Lync, Skype, Google Hangouts, etc.) with your potential partner.

2. When sending your calendar invite, please include a high-level agenda (this is a good moment to specify what you expect and what is missing).

Examples of high-level agenda:

• Introduction round (who is who)
• Overview of the Client’s organisation (business history, services, etc.)
• The Client’s expectations and current needs
• The Vendor’s overview
• Discuss the Vendor’s technical capabilities and references
• Discuss software development approaches
• Discuss the Vendor’s Human Capital Capabilities
• Discuss the Business Model and the Ramp-Up Phase
• Plan the next steps (a direct meeting, a formal arrangement, etc.)
• …

3. During the first video call with your prospect, listen carefully and make relevant notes (it is highly recommended to use Microsoft OneNote when using a Lync connection), as you will be able to send all of the notes and the agreed further plan of working together right after your call. One of great habits is to make notes in real time — and show them on the conference panel screen to your Partner — this definitely builds trust and keeps your communication at a very professional level!

4. Right after the initial call, send a note to all of the participants (include roles and plans for the next steps).

5. Based on the agreed steps forward — keep your promises (deadlines, materials you promised to send, etc.)

6. …

Formalising the collaboration — Contract & Procedures

If we are lucky :-) and we have managed to convince our potential Client to go ahead with us, the next big challenge is to formalise the collaboration — before we finally start to work on the software project together. And because this is not as simple as it may seem, let me share with you some practical insights into how we, at JCommerce, handle this process smoothly.

As reaching a formal agreement between the parties should not be a long and exhausting process, I would like to present here a high-level concept of a contract proposal that I think is clear and efficient when formalising the co-operation between two entities.

Assumption:

For the purpose of this paragraph, I have focused exclusively on a contract template for outsourcing, when the Client decides to build a dedicated software project team in the Team Extension Model. I have consciously omitted standard paragraphs in the contract template, such as: Parties, Confidentiality, IP, etc. My main goal is to outline and focus on things that matter the most to Clients approaching outsourcing Vendors, especially when forming an initial co-operation flow and setting up the procedures.

1. Defining the development approach (team extension, development outsourcing, project outsourcing, etc., as well as the methodology of working, e.g. SCRUM)

2. Explaining the pricing model (Time & Material, Fixed, Hybrid)
The Developer’s full name, experience level and rates (hourly, daily, weekly, etc.) — all in

Alert! It is very important to explain what the all-in rate of a developer includes:

• A company notebook (including necessary software licenses),
• A Lync-compatible headset,
• Usage of the Vendor’s office facilities, including meeting rooms and an Internet connection,

3. Defining the resource allocation (we all should define in advance the scale of utilisation of a developer engaged in the Client’s project)

4. A detailed explanation of the seniority level

Alert! It is extremely important to explain what we mean by, e.g. Senior .NET Developer, Professional .NET developer, etc.

5. Alternatives when replacing developers (defining the warming-up phase, shadow resources, etc.)

6. The period during which the rates are ‘frozen’.

Alert! Most of the companies forget about the fact that the rates are valid for a certain period only. It is good to define the from — to duration when a given development rate is valid and it does not change.

7. The issue of the exchange rate index.

Alert! Nowadays, a lot of vendor companies have issues with fluctuations of the exchange rate index. For that reason, when presenting the hourly rate to your Client, try to think on what basis you have calculated it, i.e. if you offer your British Client a rate of GBP 30 excl. VAT per development hour of your employee, then you should always refer to the value of your local currency index (in my case it is Polish Zloty), which keeps your business healthy. There are several solutions to help both parties weather the fluctuations of the exchange rate index. At JCommerce, we develop a very simple Excel formula that allows both parties to adjust the hourly rates (in a critical situation). I will be more than happy to share this solution with you in a separate, private email.

8. Additional costs of working on-site in the Client’s country

Alert! When the development is done in the Client’s country by an Employee of the Vendor, additional costs are involved, such as:

• Travelling,
• Accommodation,
• Daily allowance.

It is also important to define the on-site rate level as well as who will bear the on-site costs of development.

9. Notice Period

Alert! At this point, most of the vendor companies forget to specify what happens when the Client is in need of swapping/adding a new developer to work for them. It is crucial to outline this period in the contract as well

10. The Client’s Employee Regulations

Alert! It is so important to introduce the Client’s standards and expectations among the development team that the Client is provided with by the Vendor. It could be something like:

• A standardised email domain,
• A dedicated footer,
• Presenting the Vendor’s developers to a third party,
• …

Apart from that, there are also internal policies on the part of the Client, which the Employees of the Vendor should respect. It is important to set them forth in the form of a separate appendix to the contract and let the Vendor’s team read it carefully.

11. Evaluation & Rewarding (bonus) system

Alert! Some of the companies looking for long-term partnerships in the software outsourcing field define some kind of a rewarding system in co-operation with the Vendor’s management team in order to better control and motivate the quality of performance and overall commitment on the part of each employee of the Vendor.

This is one of the solutions owing to which [we can really influence the overall quality of the co-operation.]

For that reason, when signing a contract with the Client, JCommerce and the Client usually define the current team structure and performance as well as its future state. The parameters that help us to reward and analyse the Vendor’s team are presented below:

• Work quality (software/coding/documentation)
• Reporting accuracy (timesheet submitted on time, cases logged correctly, etc.)
• Communication skills (proactivity, taking initiatives, the quality of English, etc.)
• Productivity (meeting deadlines, expectations)
• Absences & being punctual (sick days, sliding hours commitment, etc.
• Telework Policy

Alert! It is important to include telework policy in the contract (which, besides, is not respected in many kinds of project engagement). But this is a part of the efforts necessary to achieve an optimum balance between the business interests on the one hand and the individual interests of the employee on the other.

Some of the practical arrangements in this area include:

• The request for telework must be made at least 2 working days in advance via email sent to the Team Lead
• Telework is limited to, e.g. 1 day a week
• The employee should be available online (MS Lync, Skype, Google Hangouts, etc.)

In my next post, I will try to share and break down the teams (Client vs Vendor) and roles (Client vs Vendor) during the first few weeks of collaboration (the most important weeks!) with international teams across different cultures. I will try to show you the mechanism, tools and practice that may help the Vendor and the Client gain better control over what is happening in the delivery process. More to follow soon!

Would like to share your challenge, feel free to contact me: https://twitter.com/pawelmikler | https://about.me/pawel_mikler

PS Please feel invited to leave your questions and comments below. Many thanks & good luck with your upcoming ventures!