Roles in a medical software outsourcing project – what does it look like?
In the world driven by software development (and, quite honestly, this is exactly where we live), the process of software development has long been structured, and many guides have been written on this subject. However, if the IT environment is not your primary domain, some issues may remain unclear to you. For example: what is a development and partnership model like in the software outsourcing project? In this post I would like to share my perspective and tell you what it looks like in Future Processing Healthcare.
A little theory
In the basic development team that carries out an IT project, there is a certain number of roles:
- Team leader
- Lead Developer
- Lead Quality Assurance
- Quality Assurance
- Business Analyst
- Solution Architect
Names can vary according to the preferences of individual suppliers or simply: market trends, but regardless of the adopted nomenclature they must cover three very specific areas.
Although most people will probably say that the roles and responsibilities behind them seem quite obvious, it is worth spending a while on describing them – especially if you are considering your product’s IT development on the outsourcing basis or within your company and you’ve never done it before. A well-designed team, which covers with its competences all the important areas of software development, guarantees efficient project implementation and prevents unpleasant surprises on the way.
Managing people and tasks in software outsourcing project
At the very beginning it is worth noting that all projects we conduct in Future Processing Healthcare are divided into iterations (called sprints), during which subsequent elements or milestones are delivered, established at the planning stage – this is a typical model of software delivery, the so-called Scrum (Agile), which is now a standard on the market. However, Scrum requires proper navigation – you have to make sure that every sprint is properly planned and work moves according to the plan and priorities. Such navigation is to be provided by the so-called Scrum Master. Without getting into the intricacies of this role, it’s well worth focusing on one reason – process management, framing and removing obstacles are aspects you certainly don’t want to miss in your project.
In our Scrum teams, the role of a Scrum master is usually simply performed by the team leader. Of course, the team leader also has other responsibilities such as taking care of deadlines, employee motivation, the employee appraisal system, and all the management activities also rest on his/her shoulders. When the Scrum master’s and team leader’s roles are separated, then the Scrum master remains in the role of a so-called team leader, his/her main task is to remove obstacles which the team may be facing, so that they can work as efficiently as possible – this is very important. The team must be able to focus on their task, the number of distractions and potential obstacles that can (and do) appear inside each organization must be limited.
Requirements, usability, business processes and communication
How can you be sure that the Scrum master navigates the project team well? How do you make sure that the priorities are well understood?
Here a very interesting role comes on stage, that is a “product owner” or a “proxy product owner”, “system analyst” or “business analyst” – the roles’ names may vary but they are interchangeable in some way, although it seems that the trend nowadays rather promotes the BA person. Still, this does not mean that the remaining terms cannot be encountered or that they all imply exactly the same thing.
Who is a system analyst? It is a person who knows the technical specifications, is firmly rooted in the technical reality and at this level is able to contribute and understand a lot. A business analyst does not focus so much on the technical side of the project, but rather on the functionality of the solution – there are components, e.g. those related to usability, which are obviously extremely important, but do not require such a strong entry into schematics or technological parameters. Proxy product owner, in turn, is a role primarily resulting from the Scrum methodology – such a person in the development team is the link between the team and the Product Owner and makes sure that the vision of the latter is carried out at the level of software production and subsequent software components are delivered according to the priorities of the Product Owner. In practice we often use a solution where the proxy product owner is simply a BA.
To receive value on time
When it comes to a software outsourcing project, there is also the question of imposing such a network of responsibilities and competences on this framework which will ensure that the client receives value on time. In this case, a TL is usually responsible for maintaining the timeliness, and it becomes his/her permanent obligation to attend planning meetings with the client and take care of the priorities set, deadlines, milestones. It is the responsibility of the TL to organise his/her teamwork to achieve these goals while minimising the involvement of people on the customer side. At a lower level of responsibility, the person who maintains regular contact with the client is a BA – it is him/her who takes care of effective communication, gathers and resolves doubts that appear in the development team.
How to recognise if governance is working well? From this video you will learn how to plan the way the buyer and the supplier will work together and what to include in a contract to clearly define roles, responsibilities and expectations towards each other.
In practice, objectives and priorities are determined with the client and the outsourcing partner “get down to work” and it is up to the client to arrange the project work in such a way as to ensure its achievement. We live in a dynamic world and many priorities along the way will change and adapt to new business realities. The right communication enables a smooth and flexible response to them. In fact, this is the heart of Scrum – regular teleconferences or meetings guarantee that what the team is working on at the moment still remains valid, does not need to be modified. This allows the client to monitor progress with minimal involvement on his part.
Of course, none of the software projects could have been successful if it hadn’t been for the engineers working in it. In Future Processing Healthcare we make sure that in our projects, apart from developers, there are also testers on permanent basis, although in other companies I have already encountered situations where QA were not involved in the software outsourcing project from start to finish. From my perspective, our model simply makes sense. Depending on the complexity of the project, the so-called Lead developer or Lead QA may function in the team. In practice, they are simply people with the highest competence in a given team, who support the Leader Team in planning and distributing tasks, and serve as an advisory role for other team members.
In more demanding projects there is also the role of a “solution architect” – an engineer responsible for the technical solution of business problems. Such a person looks for the best, most appropriate technological solutions that would help to address the needs. A good design of a solution not only allows to achieve the desired business value later on, but can also have a decisive impact on the budget and delivery of the solution on time.
Software outsourcing project – a little practice
I have been involved in development of software outsourcing projects for nearly 10 years, during that time I had the opportunity to get to know it in practice from the perspective of many roles. I realize that the above text is not completely comprehensive, but I hope it will help you to better understand the process at the end of which there is good and useful software. If you would like to exchange your experiences or you haven’t found the answer to your questions above, please feel free to contact me @LinkedIn.
Contact us if you have any questions!
See the previous post by Marek: Medical project estimation – what is worth remembering?