Helmes is capable of using nearly any cooperation model a client desires with only one caveat: every critical role and competence of software development project must be covered, so that the team can take responsibility for the whole.
The critical roles on a software project are illustrated below. Some roles are required continually, while others kick in upon demand. It doesn’t really matter who fulfils a role as long as the requirements of the project are met.
It sounds like common knowledge, but this rule is often ignored. Projects fail if skillsets are missing, specific roles not covered or commitments not taken. At Helmes, we review the operational setup of the team during the project kick-off. Our Working Agreement template navigates us through the delicate issues of mapping competencies and motivations. When something’s missing, we’ll find a way to compensate.
On the client’s organization side, the role most critical to the project is that of the product manager. The product manager’s responsibilities include developing a higher-level product strategy, articulating the product vision, communicating with stakeholders and end users, sharing and interpreting the business needs to the technical team, helping prioritize, and getting the answers to team’s questions from within the client organization.
If the client lacks a product manager, it is crucial to compensate. In order to get the project started, we’ve developed the QuickStart method: Helmes appoints a top gun analyst to spend 3 intense days interviewing the stakeholders in client’s organization and digging into the relevant data, the functionalities and technicalities of existing systems and existing user research.
If the need for product manager resource during the project is more extensive, we can appoint a full-time business analyst to carry out the role. The critical consideration, however, is the necessity to transfer knowledge back to the client in order to keep the relationship balanced. Nobody wants a vendor lock.
Often companies rely on the software analyst of the technical team to carry out both – the role of an analyst and a product manager. This can only work in a very small team of senior experts, who can meet the analyst halfway and conduct their own analysis of requirements. An analyst who has to cater to 3-4 developers with well-prepared tasks won’t be able to carry out the role of a product manager in addition to their own.
While getting people to fill missing roles is relatively easy, the opposite problem of overlapping people can go unnoticed. Having two super architects or designers can cause confusion for the team if neither of them seizes the initiative.
When it comes to leading the relationship with the client, we similarly gravitate toward the driver’s seat, but if we’re sure the client has people with the right skills and commitment, we can adapt and build our team around these people.
The same goes for third parties – we’re happy to lead them and take responsibility for the whole if our values align. It‘s not uncommon that we help our clients to find those third partners – often they‘re people new to us and our clients alike.
That‘s actually the ultimate thrill for us – to find solutions for the problems never encountered by anyone before. A client with an unconventional need is a challenge successfully met when you hear the satisfying “Click!” of the joint team coming together. Our kick is definitely in the click 😉