Why effective collaboration is the key to project success
Every project manager and online business knows that teamwork is key to delivering a project. When you start working with Software House, it becomes an integral part of your business. Therefore, it should be treated as a de facto part of the team. Anything that Software House fails to deliver will affect your business. Anything that is not communicated to Software House will not be produced by it. Every Team Leader (or Scrum Master) can say that three things are needed for effective team cooperation: communication, communication and communication. But what does this communication mean in practice when working with Software House? Let’s consider some examples.
Translated with DeepL.com (free version)
Before starting work
Define clear goals and expectations
As with an employment contract or a contract of mandate, it greatly facilitates communication to specify the goals that should be achieved within the framework of cooperation. In the case of a software house, the situation is slightly better, because a good software house – unlike an ordinary employee – understands the business context of the project. This means that a good software house can also advise on design solutions, taking into account the business effectiveness of the project.
Of course, in order for communication at this level to be clear, the software house should be familiar with the business environment of the project it will be working on. It is therefore important not only to present the project itself, but also the business environment, the expectations of end users, and the operational strategy of the enterprise or company itself. It is also a good idea to set certain KPIs before starting cooperation – they will allow you to measure the effectiveness of the solution after its implementation.
If we assume that our goal is to improve KPIs, then we can expect to see specific improvements in selected indicators. Of course, this is a high-level operational understanding of the issue. However, this does not necessarily have to be the case. For a start-up project, the most important expectation in cooperation with Software House may be the quick delivery of the project. For a start-up that cares about good customer service or operates in a highly volatile industry, post-implementation support may be crucial. Your task as a business owner is to define which aspect of such cooperation is most important to you – and to communicate it very clearly and explicitly. The task of Software House is to answer whether and to what extent – and in what way – it is able to meet this expectation.
Choosing a communication model: tools, meeting frequency, reporting channels
Communication channels are a recurring element. From the very beginning, from the first contact to the very end and post-implementation support. These communication channels can be completely different for the first stage. Different for the development stage, and yet different for the post-implementation stage.
For example, at the very beginning, communication will most likely take place via email and telephone. However, once the scope of work and contract have been agreed upon, communication with Software House may take place on project management platforms such as Asana or Jira. Alternatively, communication with developers may also take place on Slack if a direct communication model with the developer is envisaged. However, after implementation, if an SLA agreement has been signed and response times have been specified, it will most likely be necessary to use specific channels that utilise automatic assignment of responsible persons. Such channels most often support the monitoring of the status of reported issues.
The frequency of meetings will depend on the chosen software development methodology. If SCRUM is chosen, the client should be introduced to all artefacts and made sure that they understand them. If Kanban is chosen, it is still worth introducing certain organisational meetings, for example every two weeks.
The role of the discovery phase: workshops, prototypes and idea verification
The discovery phase is an important stage in the software development planning process, as it allows you to verify whether there are any potential problems with the idea at a low cost. This phase can consist of several elements. These include market research, user behaviour research, technology verification, strategic planning, and organisational or scrum workshops.
Each of these elements can be either rejected by the founder or treated in a special way. Although I generally advise against rejecting the discovery phase, if the basis of the project is very well thought out and prepared, it is sometimes possible to skip this stage. An example of such a situation is building an internal tool for a company to streamline document flow. In this case, it is certain that the target group will use the solution (top-down mandate), so researching demand may not make sense. If, in addition, the scope of work is described in great detail, the views and database structure are prepared, and the technology is selected, then you can basically move on to the valuation of such a project. In this case, the communication aspect will be a well-prepared scope of work.
However, if the founder is unsure about the value of their solution, this phase can be treated as an element of communication with potential recipients of the technology. In this case, the prototype of the solution becomes a communication channel. The prototype may be a partially functional website or a landing page that collects potentially interested users. As a result, this also provides market verification and allows for the calculation or estimation of the return on investment.
Start of programming work
Setting the scope of work and priorities in the backlog
If the Discovery phase has been carried out correctly, the project should have been discussed, so the scope of work should already be known and described in detail at this stage. Therefore, simply enter all the elements needed to complete the task into the project management tool (i.e. Jira or Asana). Entering all tasks into such a system is also part of communication. The client should have access to a board with all tasks.
In particular, when a project can be launched in stages, work should begin with the element with the highest priority. This is understood instinctively, but it is not always clear what has the highest priority. Without prior discussion of priorities, it may turn out that the business owner understands priority differently than the software house. Another problem may be defining what can be launched into production. Usually, this scope is defined as MVP. According to SCRUM and the approach I always recommend, the system should be launched into production as soon as it provides any value to users. This way, early feedback can be collected and potential problems can be identified earlier. This is what the next paragraph is about, namely change management.
Effective change management: handling change requests
In my career, I have yet to encounter a single project whose scope did not change during development. Such situations probably occur in public procurement, where the scope of work and the expected outcome must be described in detail by the client from the very beginning. Therefore, under normal circumstances, in order to cooperate effectively with Software House, it is necessary to discuss change management.
If the Software House contract is an Agile contract, i.e. in practice a subscription for a specific number of hours per month, the change is usually not a problem and simply needs to be reported to be included in the next sprint. A slightly bigger problem arises when the contract is a fixed price contract. In this case, any major change requires the signing of an annex to the contract. In the case of minor changes, it is up to the parties to agree whether the change can be included in the scope of work, for example by replacing another element or using the margin of error provided for. We normally include such a margin in Hybrid contracts.
Progress monitoring: metrics, demos, and retrospectives
Monitoring progress is also part of communication. In the SCRUMM methodology, it is sufficient to present a demo of the product and discuss issues at a retrospective meeting. More advanced metrics, such as burn down charts, can also be used to measure the pace of work.
If the project has a fixed budget, it also has a fixed price and probably a fixed deadline. In this case, you should simply monitor the pace of work on a weekly or biweekly basis, for example, and check whether it is in line with expectations. Any discrepancies should be reported and discussed immediately to maintain full transparency about the stage the project is at. On the other hand, the development team should also be transparent when there are delays, for example due to illness or an element being more complex than anticipated.
Other programming-related elements
Quality assurance: testing, code review, and CI/CD automation
In all projects we undertake, automation and CI/CD are always included in the quote. This approach requires full access to production servers provided by us or by the customer. We consider this element to be an essential foundation, but this may not be the case for everyone.
When it comes to writing automated tests and code reviews, a lot depends on the client’s requirements. On the one hand, these two elements ensure high code quality and minimise the risk of errors, but on the other hand, their implementation always increases the project budget in some way. At Sailing Byte, we always recommend that at least the critical paths be covered by automated tests.
However, in the case of systems that process highly sensitive data (e.g. medical data, personal data, PESEL numbers), security tests should also be conducted in addition to unit tests. SAST tests should be the absolute minimum. If the client does not understand the importance of security tests, unit tests, and code reviews, it should be explained to them how this will affect the stability of the project. Sometimes in start-up projects, stability may be sacrificed in favour of faster and cheaper launch of key functionalities, which is understandable to me from a business point of view.
Cost transparency: budget, hourly rates and reports
As I mentioned in one of the points above, there are practically no projects in which the scope of work does not change – that is why setting hourly rates or a project budget is crucial to be able to prove the business value of the project. In addition, transparency of hourly rates is key to calculating additional fees – for example, work outside standard hours.
Some billing models also require reports on the amount of work broken down by hours. In my experience, the usefulness of such reports depends on the client’s approach (whether it is partnership-based or exploitative), so they can either provide value or be a source of dispute. However, in my opinion, a software house should always keep track of hours, as such reports can also serve the purpose of internal team improvement. In the vast majority of projects we work on, such reports are not necessary, as clients understand the value we deliver at Sailing Byte.
Building partnerships: trust, feedback and a culture of continuous improvement
This point concerns more internal elements of the Software House, but if you are a customer, it is worth being aware of it. The absence of elements that would indicate the existence of a culture of continuous improvement can be an alarming factor. Such a Software House will ultimately not be interested in becoming better and better, so cooperation with it will never improve.
This element can take various forms, such as retrospective meeting surveys, private one-on-one meetings, or adapting the software development process in response to identified problems. It is important to remember that constructive feedback processing can only take place in an atmosphere of mutual respect and trust, so if something is not working out in your collaboration with your Software House, simply point it out to them and observe what they do with this information.
Maintenance and support after implementation: SLA, maintenance and further development
Project maintenance can take various forms – it can simply be signing a contract for the next stages or switching from a fixed price contract to a time and materials contract. However, in the case of systems where response time is important, it may be necessary to sign an SLA contract. Since this type of contract is already a legal obligation to respond within a specified time, it is normal for the Software House to require additional payment for maintaining and providing such a service.
In most cases, my experience shows that switching to a subscription contract without signing an SLA is sufficient. This is probably because at Sailing Byte we are able to deliver reasonable response times even for non-critical systems.
Summary: 5 key principles for effective collaboration
Effective cooperation with Software House is crucial for the success of a technology project and should be treated as seriously as cooperation with an internal team. The foundation of successful cooperation is clear communication – from defining goals, through selecting cooperation models and communication tools, to change management and progress monitoring. Key stages of the project, such as the discovery phase, setting priorities in the backlog, and testing, require the involvement of both parties and transparency – both in terms of costs and decision-making. Equally important is building partnerships (which is the motto at Sailing Byte) based on mutual trust and continuous feedback.
If you want to see how we put all this into practice, write to us – describe your project and we will help you implement it in a spirit of partnership!
