Checks and Balances – How to Cooperate with a Software House? - Blog CSHARK Checks and Balances – How to Cooperate with a Software House? - Blog CSHARK

IT Ocean blog

Blog subscription

29/10/18

Checks and Balances – How to Cooperate with a Software House?

Checks and Balances – How to Cooperate with a Software House?

Customers have the right to be treated with professionalism and have all their challenges addressed in a timely manner. The problem is that it is never that simple. Miscommunication, cultural gap, lack of information about the NDA – these are all problems that organisations face when it comes to selling and buying products and especially services. How a software house should approach the conversation about possible future cooperation? How should a customer?

The relationship between a customer and a contractor resembles a situation in a democracy. In this model of governance no branch of government has the power over the other, all are equal and they check each other in order to balance the stakes which are the well-being of the people. In business, partners have to trust each other but first, they have to know each other better.

It’s good practice to check each other’s websites, review the technological, development and business expertise. But that’s just the beginning – it’s essential to be able to talk about case studies. Customers looking for a good technology partner for their project should be encouraged to ask for either references or projects realized by the software house.

What the company has done in the past, how it was able to fix a customer’s problem. The more details, the better. The more precise and astute questions, the better. It’s all about showing the customer how the company approaches them, thinks about their challenges, how it optimizes its work and finally – how much time it needs to understand the customer’s business.

A customer should be open during the cooperation with the software house’s representative. Michał Bartyzel in a book called ‘Conversation Patterns for Software Professionals’, noted that customers indeed know their needs, but they do not know what they want. And that is the key. The client needs to work on the articulation of his or her needs and how that need can be realized by the software solution. This reduces the uncertainty and likelihood of building a solution that will not satisfy the actual needs of the client.

At the same time, a non-disclosure agreement (NDA) document should not be a problem for a professional contractor. It gives necessary comfort needed in the process of gaining mutual trust.

There are some requirements (or ground rules) that need to be fulfilled in order to fully recognize the possibility of a mutual cooperation:

  • Openness of communication
  • Mutual agreement on priorities in conversation and negotiation process
  • Agreement on dividing a project plan into bite-sized pieces
  • Working on a project using visual mockups, graphs and mindmaps to speed-up the process and for better communication

The process of talking with a customer should go through several phases in order to assure better demand recognition and future quality of development.

The stages are as follows:

  • Lead research
  • Prospecting
  • Qualifying 1st round
  • Qualifying 2nd round
  • Demo
  • First proposal and technical demo
  • Workplan
  • Contracts
  • Pre-project meetings
  • Knowledge transfer

The next is development of the project:

  • Implementation
  • Testing/training
  • Customer success support and further key account management

After the partnership has been initiated, the realization of the project can start. In order to have a fruitful cooperation and project success, the collaboration between the customer and the software house must rely on trust and mutual accessibility within the whole project lifecycle.

Namely, from the perspective of the client, it is vital so they take an active role in the project and if necessary assist the software house with any clarification and doubts on the requirements during the project. In that matter, the delegation of authority and empowerment to a certain employee would be a good solution. Such a person often called an ambassador, is responsible for making the decision as to the requirement and their clarification to the development process. Secondly, during requirements elicitation and gathering sessions, selection of key stakeholders is necessary by the client. If some key departments have been omitted, the overall solution might lack the crucial functionalities. For instance, critical factors affecting the solution might come from the compliance unit. Thus, selection of stakeholders and key end-users of the intended software solution that do not change often in a project is one of the critical factors to successful implementation.

On the other hand, the customer is not alone in taking an active role in this relationship. Depending on the structure and methodology of work between the client and software house, the latter party should designate appropriate people to continue this relationship in the software development lifecycle. Typically, persons responsible for the customer relationship management from the software house are either a project manager, delivery manager or business analyst. These roles are instrumental during the initial stage of the project where requirement gathering and elicitation take place. They assist the client in articulating the requirements and transform this business language to the development team that further handle implementation of the certain future of the solution. In a general sense, the software house should also specify the initial cost of the project to the nearest increment of the solution. It is also necessary so both parties agree on the definition of quality of the service and the approximate timeline for the first stage of the project increment. The software house as a technical expert in the delivery process should inform the customer on the process of implementation of features, its needs towards the client within the whole project lifecycle and their constant readiness to help and clarify any doubts within the development process.

The whole process of ‘getting to know each other’ can take from 3 months up to 1 year and that includes the understanding of the customers’ business, negotiations, needed approvals and paperwork. This process is usually not linear, a lot of aspects occur simultaneously, are mutually dependent of each other.

According to the report by the Harvard Business Review about digital economy, 80% of business leaders believe their industry will be – a one way or another – be impacted by the digital. They also believe it will affect an 84% of businesses by 2020. Interestingly enough by the of 2016, only 16% of all organizations went fully digital with “only” 61% that went hybrid. Some products, services and operations depend on digital technologies, meaning that companies appreciate the impact digital economy makes on everyone, yet they do not participate in it. What industry will be “very likely” disrupted by the digital wave? According to the study, business leaders say that:

  • Media 67%
  • Financial services 62%
  • Technology 54%
  • Manufacturing 27%

This poll is a little surprising. Media is a first choice for everyone but the low position of Automotive (which is not even on the list!) and Manufacturing understood holistically, looks like an overlooked opportunity to understand and upgrade a business. Robotics and tailored software go hand in hand in securing the future of many companies in the manufacturing sector and are the only way to go forward for many of them.

Now… in any organisation top-tier specialists have to assess the most promising outcome when it comes to managing people, morals, budget and prognostics. The best way to do that is to ‘trust the ocean’, as they say. People don’t like to be told what to do; they respect the task, the opportunity, resources and trust they are given. They’re not crazy about periodical assessment of competence and micromanaging. People simply like to achieve goals. For this kind of employees and managers, Frederic Laloux made a solution. A method called Turquoise Management for more effective cooperation within organizations is a great example of how challenges can spark a brand new thing. Laloux externalized what we all internally know and feel – people who are appreciated and led through example of ‘stick and carrot’ method, work better.

As Michał Fiuk, a Team Leader at CSHARK says:

A flat structure gives everyone the opportunity to shine. Not every developer is built for this but if a company is organized that way, a specialist in question is simply a part of the culture and internalize what it ultimately will be their way. This helps the team to understand that challenges are a part of the job and everyone plays in the same team. Of course myself and few other developers act as team leaders but we play the role of stakeholders and ‘project shepherds’. We are not guys with fancy job titles. Due to our model people are active not reactive, therefore they immediately respond to challenges, as opposed to waiting for the fallout to reach the team and the whole project. That goes for bugs and for dynamic changes alike.

We have 3 company sites. One of our key values is openness – we talk, tackle problems together and work towards the best solutions. That would not be possible if people would not feel appreciated or professional.

So how to work with a software house in a nutshell? Bet strongly on externalizing your needs, internalizing what the developers’ feedback is and work closely with them to create your needed solution. No time like the present!

Related articles