By Boris Kontsevoi,
President & CEO, Intetics Inc.
The article was published on CIO.com
Whenever launching a new software project, one of the first decisions every executive has to make is to choose the right software service provider and to define its integration strategy. This is always a difficult decision coupled with multiple challenges.
For decades, I’ve been on the side of those who expect the client’s final decision. I’ve also been on the side of decision makers. I realize how much it takes to set all things right since to choose wisely, it is important to consider various criteria. In fact, there can be so many of them that eventually you may get snowed under the list of them. Trying to optimize this process within our company and help our clients we created a matrix of software service provider integration. Using it, top managers can precisely define the necessary set of functions for a provider. What is more important, it allows deciding how deep the provider integrates into the processes of the client company. Having tested it myself, I can say it is really a magic approach allowing to see the big picture.
For that reason, when you start developing an ideal provider integration strategy, do not rush into provider assessments. Take your time and think of the kind of software service provider you need. In what role would the service provider act?
What kind of partnership do you need?
World business experts provide various types and descriptions of the roles software service providers may take. Having analyzed those, I came up with the list that, I think, suits IT industry best. For the purpose of integration into a software development initiative, I suggest dividing providers into four common types: doer, assistant, adviser, and partner. Each type of a software service provider offers a different level of integration. Doer acts on the resources level, assistant operates on the delivery level, adviser moves up to management level, while partner performs at the business level.
Before choosing the type that suits better for your project and business, ask yourself these questions:
- Do you need a software service provider to possess domain knowledge?
- To what extent do you want the provider to be involved in your business?
- Do you need the software service provider team to be involved in the decision-making process?
- Do you need a custom development strategy or want the team to recommend and follow the industry proven frameworks?
- Do you want the provider team to align with a task backlog or work as per your requests?
- Do you need a dedicated QA team on the project?
- Do you need a production support team?
- What level of team engagement in product management do you prefer?
With the answers in your mind, get down to the matrix creation. Use the questions as the major points. Put them simply like domain knowledge, (engagement into) decision-making process, project management, development of client processes, worklog planning, testing activities, production support and product management. Add the requirements to each level going upwards from the minimum to the maximum. Remember, the deeper integration you need, the more sophisticated the partnership you will get.
Your matrix may look like a chart, a table or an infographic, choose whatever you like. Make it visual, this is what matters. Do not leave any point in your mind, use paper instead.
The next step is to fill in the requirements. Consider the details though try to put it simply. For example,
should the provider have domain knowledge? If the answer is “No”, seems like the doer can be sufficient at this stage. Since all other roles require sufficient domain knowledge. Then think of whether the provider’s team should make decisions? If there’s a need for them to make tech propositions, it’s a deeper level of integration than the Doer. There can appear a question of whether the vendor should manage all the project activities themselves? It can be critical for the provider to follow the instructions without initiating new tasks. According to this little research, looks like in this case, the doer will be a reasonable option. To get a more precise picture consider the factors like project management, development of client processes and testing activities.
Defining the desired level of a service provider integration is not the last step in the journey. You need to decide upon a contract type and business model. Of course, you may discuss it with a provider when you choose the one you need. But I prefer having a full scheme in my mind, otherwise, it seems like I stopped halfway.
If we use the previous little research and choose the doer, for example, the Time & Material type of contract would go best. For the Adviser, the offshore dedicated team will be a proper option. If the project requires the Partner, the deepest level of integration possible, Remote In-Sourcing /Output-based type of contract can be the most suitable.
Finally, when you get it all in the list and set the priorities correctly, the choice is obvious. To round it up, making the right choice was never an easy task. However, if you endeavor to build the matrix, things become clear shortly. You will understand to what extent the provider should be involved in your processes, product strategy, and overall business. These are straight A’s – research as the first step, doing as the second one. These are the things the literally suitable for any business and industry.
