More than anything, companies should be considering how they can achieve a better balance in their workforce. UK-based businesses will always need to have employees in this country, especially those who are in customer-facing roles. However, when it comes to other positions, such as software engineers, it’s even more important to take a carefully considered view on where to base them.
Near-shoring – or, partner-shoring, where a client and near-shore partner work closely together as a single team to achieve common goals – is a solution that can not only help to keep costs down, but also reduce your risks and increase flexibility when it comes to resourcing.
It’s not just about the money…
One of the most obvious and immediate benefits of partner-shoring is financial, which can be a huge upside, especially when a lot of businesses are just beginning to emerge from some challenging years.
What’s more, partner-shoring can offer a greater degree of certainty, where your labour costs are fully known. Any company that has just hired a lot of UK-based employees will now be reeling from the shock of the Budget, as few anticipated the NI hike, or for it to be quite so extreme. And, of course, there’s no certainty that the costs to employers will stop there – there may well be further increases in taxation to come.
By partner-shoring, it’s possible to agree costs in advance and only pay for the work that is produced for you – so, for example, not having to cover people’s sick leave or parental leave which can often be an unknown quantity.
Having clarity on costs in this way makes it a lot easier for companies to plan ahead, particularly in these uncertain times when a wide range of external factors beyond mere NI rises – such as volatile market conditions – can create significant challenges for businesses.
Added to this is the enormous benefit of flexibility. The ability to scale up and down relatively painlessly is a valuable attribute for many businesses, and having a near-shore partner allows you to do this seamlessly, while the responsibility of employee protections remain the concern of the business you’re partnering with.
Acting responsibly for maximum value
That said, it’s important to emphasise that outsourcing some of your company’s labour requirements shouldn’t mean acting irresponsibly or turning to an unethical supplier that exploits its workforce.
In the outsourcing sector, there are undoubtedly bad actors in relatively deregulated markets who will underpay their employees and offer them few, if any, benefits in order to keep costs as low as possible.
In my experience, there is no value in this for anyone involved. Companies that do not invest in their workforce will earn very little loyalty from their employees. This can lead to not only lower productivity and poor outputs, but also high attrition rates that result in large amounts of key knowledge being lost on a regular basis.
On the other hand, near-shore firms that invest in their people and constantly work hard to ensure they have good employee experiences will always deliver fewer risks and greater benefits – and therefore greater value – to their clients. And that’s exactly what we believe in, here at Damilah. We invest heavily in training to ensure we enable our people to reach their full potential, as well as offering an attractive benefits package. By doing this, our employees pay us back many, many times – and our clients also reap the rewards of this.
In particular, we are proud that our annual staff turnover rate is just 2%. This saves on the expense of recruitment and onboarding (thus helping to keep costs lower for our clients), ensures that essential knowledge and experience remains within the company and is there for our clients’ benefit, and increases the quality, consistency and speed of our outputs.
Look before you leap
One final point to make is that, although the severity of the measures regarding NI may have come as a shock to many, you should avoid making a knee-jerk reaction.
It may be tempting, for example, to immediately cut your UK workforce or instantly put a freeze on recruitment, and transfer as many roles as possible overseas. While this may ultimately be the wisest course of action for certain businesses, it’s important to take a considered approach to finding the optimum balance in your workforce, rather than immediately jumping to the first solution that springs to mind. It’s also worth taking the time to find the right partner to work with.
Here, the benefit of experience and expertise can really pay dividends and help you to deliver the value for money and flexibility your company requires.
At Damilah, we have decades of experience that we are happy to share, as well as a team of highly skilled and motivated near-shore employees who partner effectively with our clients to deliver outstanding outcomes.
To find out more about how you can minimise the impacts of the Budget on your business, get in touch now to discuss our range of services.
Iain Bishop, founder and CEO, Damilah
But these aren’t just heads. These are people – and because you’re a good manager, you care about them. You’ll have spent time helping them develop their careers, improving their technical and other skills; and you’ll have got to know them as individuals and maybe socialised with them, their partners and families.
When the scale-down happens, in the first instance you may need to put a lot of roles at risk, creating widespread uncertainty as people worry about their livelihoods. Then you may have to lose some outstanding colleagues whom you’ve nurtured over the years and may count as friends.
It’s really, really hard.
What’s more, you may get away with this once by explaining it’s a one-off situation that won’t happen again. But what if it’s not? Rarely will you be able to go through a similar process again without risking the best of your team quitting and leaving behind a demoralised group with whom you’ve destroyed all trust and the great working relationships you once fostered.
I’ve been there myself several times. So, over the years, I’ve developed a highly effective strategy for avoiding this kind of problem, that allows you to scale up and down quickly and painlessly. It involves a three-pronged resourcing strategy: your own on-shore team, a partner near-shore team, and your own near-shore team.
Rather like the way in which we all use cloud-based services to expand and contract the tech resources we need as and when required – and only pay for what we use – this strategy enables you to grow and reduce your team in a flexible way while optimising costs.
The difference, of course, is that we’re talking about people here – humans who have feelings, livelihoods and dependents – meaning the stakes are so much higher than when we’re dealing with tin and wire.
So, here’s my advice on how to make this strategy work to everyone’s advantage.
1. Establish your core on-shore team
This is the obvious place to start. This team will tend to be comprised of people who may have been with your organisation for some time. They are likely to have deep domain knowledge and a lot of the technical skills and understanding required to build and maintain your products.
2. Work with a partner to integrate a near-shore team
Here at Damilah, we call this ‘partner-shoring’. This means leveraging the cost benefits of near-shoring by partnering with a firm that can provide a high-quality team capable of collaborating with your own in a seamless fashion.
The costs won’t be as low as with your own near-shore team (see below), as the partner firm will need to take a margin. But the advantages of using a third-party to help you navigate the challenges of near-shoring are many.
First and foremost, it allows you to scale up rapidly with people who are known entities and ready to go from day one. And you don’t need to worry about aspects like recruitment, HR, career development and so on, as the partner firm will deal with those. You’ll just need to manage the projects.
It also gives you the flexible bandwidth to handle the peaks and troughs of workloads in a cost-effective way, as you can bring people on- and off-line as required. As well as giving you the mechanism to scale up quickly, it protects you from the risk of having to scale down in the future, as this is the first team you can cut, and with the least amount of pain. In general, their jobs are more likely to be safe as they can be deployed on other accounts within their company as it seeks new clients.
Additionally, it enables you to build an understanding of the different culture, legal frameworks and myriad other challenges of running a team in an off-shore location – which leads onto the final step…
3. Build your own near-shore team
This may be less expensive than working with a near-shore partner, but it’s far harder to do.
The big advantage, beyond cost, is that it can give you access to the kinds of talented people that are more challenging to find in your own country. For example, it may be easier to recruit a team that is younger, with a better gender balance, and with technical skills that are harder to hire back home.
This kind of team can add a huge dose of energy and enthusiasm to your home team – and a smart blend of mature, on-shore experience with youthful, off-shore passion and determination can be powerful.
Building up a strong near-shore capability can be time-consuming – think nine to 12 months minimum to become established. But once you get there, it can add a lot of value to your business.
Making it work
The key to success is to ensure all three teams blend effectively. And the way to do that is to foster a culture of transparency and collaboration, where autonomous teams with the same goals and mindset will work closely together to deliver outstanding outcomes aligned to your business requirements.
It’s therefore important not only to look for compatibilities in ways of working, but also in ways of problem-solving.
Face-to-face contact is always helpful here – both in the office and outside. If two people have shared a beer in the past, when there’s a challenge it’s always easier for them to pick up the phone and thrash it out than if they’ve only ever communicated by email or Slack.
Put simply, your near-shore teams should feel like extensions of your home team.
We can help you learn more about the best ways to plan, implement and maximise value from this three-team strategy. To find out more, get in touch now.
And the following articles in this series will help you build a greater understanding of the challenges of near-shoring and how to create maximum value by doing it:
• The future of near-shoring: ‘partner-shoring’
• The challenges of setting up a near-shore team
• How to select the right near-shore partner
• How ‘partner-shoring’ can support a scale-up
Iain Bishop, founder and CEO, Damilah
But how can you tell one potential partner from another? Here are some key questions to ask during the selection process:
How do you know you can trust them?
Nothing matters more than this. If you have any doubts whatsoever, walk away. A good first step towards finding a reliable partner is to seek recommendations, demand references, and ask their customers questions like: What are they like to work with? Have they delivered the right outcomes for you? How have they dealt with problems? How collaborative are they?
How good are their technical skills really?
Every potential partner will tell you that they have amazing technical skills. Really, really talented people. The best in the industry. But how do you know how good they are in reality? It’s important to talk to the technical leadership to see if they genuinely understand your technology and what good looks like. It can also be worth interviewing the people who’d be working in your team.
Do they understand how to build secure systems?
Today, all systems need to be secure – and by using tooling as part of the build process, teams can ensure security is embedded throughout the development process. So, are all the people in your partner’s team security aware? And are they given appropriate training on the subject?
Are they focused on delivering value?
Too many near-shore teams will prioritise billable hours over delivering genuine value to their clients. However, for both you and your potential partner, value – rather than actual cost – should be top of mind. In particular, going with the cheapest option might not always result in the best value for your organisation. If your partner doesn’t have the right technical or collaborative skills, for example, poor outputs and delays could end up costing you dear in the long-run.
Is there a commercial awareness right across the business?
The advent of the public cloud has introduced a completely novel dimension to designing new systems. Architectures must be cost-effective in their use of cloud services, which means those designing them must have a current knowledge not only of the services available, but also the pricing implications which may depend on usage patterns.
Are they in a suitable near-shore location?
Here, you’ll need to consider issues like cultural alignment and time zone differences. It’s really hard to make agile development processes work well if your teams’ working days barely overlap or your potential partner doesn’t have an ethos of close collaboration.
Do they have good English language skills that run deep in the business?
Check that everyone speaks good enough English to enable peer-to-peer contact between your team and theirs. If all communication has to go through a project manager, as they’re the only one who speaks your language, misunderstandings and delays will become inevitable.
Do their people collaborate easily?
Having a naturally collaborative culture will make communication at all levels much more straightforward. Everyone needs to be able to communicate easily and transparently so that issues and opportunities can be discussed openly.
The best way to find answers to all the questions above, and reassure yourself that you’re selecting the right partner, is to spend time with them. Find out if they’re happy for you to visit their offices as often as you wish. Insist on meeting the people you’ll be working with – and not just the senior management and sales team – and ask them some tough questions. The more time you spend doing this, the more you’ll find out what the business is really like to work with.
Finally, once you’ve selected your potential partner, or drawn up a shortlist, it’s often a good idea to put them to the test before committing to a contract. For example, you could give them a problem to solve – and even if it’s not a live issue, the way they go about finding a solution can be very revealing as to the way they operate.
Alternatively, you could engage them on a small, live project and measure them on how they handle it. This is a very low-risk way of assessing whether the potential partner is likely to be a good fit for your own organisation. Here at Damilah, we’d be more than happy to discuss any of the above questions with you and explain our ‘partner-shoring’ model to you – where our near-shore team will collaborate seamlessly with you to deliver high levels of shared value.
To find out more, get in touch now to discuss our range of services.
Iain Bishop, founder and CEO, Damilah
Here’s how you can make it work:
Often private equity-backed owners will be looking to invest in the product to significantly grow revenue. Typically, this may involve transforming a monolithic on-premise software product to a modern SaaS offering, or extending the product into other markets.
Whatever the plan may be, it’s likely to create a need to rapidly expand the engineering team. This could be in terms of head count, and potentially also to bring in new expertise if the scale-up involves a significant technology shift and the necessary know-how doesn’t already exist within the business.
A highly effective way to solve this problem is to bring in expertise from outside, as hiring and building a team internally can be time-consuming, costly and risky.
That’s why turning to a near-shore partner, with flexible teams and talented people who have done this many times before, can reap big rewards. They will be able to offer, for example, experience and understanding of how to use public cloud in a cost-effective way, how to build cloud-native SaaS products, and so on – while maximising the benefits of modern standards and approaches, such as automation, continuous testing and rapid delivery cycles. This can be a very cost-effective way of putting an outstanding final product into users’ hands as quickly as possible.
An added advantage can be the way in which you can easily scale the development team up or down. For example, a private investor may often begin to reduce their levels of investment after year two or three as they look to grow their bottom line prior to exiting after five years or so. In turn, that may require a scaling back of the engineering team, which is harder to do if it involves laying off internal employees.
None of this is likely to work well unless you create autonomous teams that remove as many dependencies as possible – as dependencies are the biggest productivity killer when it comes to software development. If completing a task depends on input from another team or individual, working at pace frequently becomes impossible – which is exactly the opposite of what a major scale-up needs.
Instead, an autonomous team will have all the skills and experience necessary to forge ahead successfully and at pace. They will be able to handle everything from talking to end users about their needs, and creating a roadmap and product strategy, right through to production and deployment, with all the necessary DevOps, engineering, testing, and product people in between that are required to get the job done.
In my opinion, autonomous teams are the only way to scale rapidly – and using the Spotify model is an example of a good way to build and maintain such teams.
At the top, there is a tribe leader, who may be responsible for multiple teams, each one containing all the skills necessary to complete a project. The tribe leader is empowered to make decisions and move people around their teams as necessary.
Then, across those teams, there are special-interest groups called guilds. These are collections of people who have the same areas of expertise, and they are used for sharing knowledge and advice across teams. Each guild will have a leader, who is a specialist in their field, but may not be from the management team.
And there are also chapters, which are a way of managing and mentoring individuals, without the need for multiple layers of line management.
Overall, this model is an effective way of running large teams, because the CTO can focus on supporting the tribe leaders and then only managing by exception – in other words, not having to focus too much on details unless there is a specific problem, in which case they can go in deep to help find a solution.
The crucial factor to bear in mind throughout all of the above is that it is not necessary for an team to be physically co-located. As long as its members have the necessary autonomy and the ability to collaborate seamlessly, they can be anywhere. This allows you to leverage the cost and flexibility advantages of partnering closely with a near-shore company – or ‘partner-shoring’, as we like to call it.
Over the years, I’ve helped many businesses to rapidly scale up and significantly increase their value by deploying these methodologies.
To find out more about how we at Damilah can help you to do the same, get in touch now to discuss our range of services.
Iain Bishop, founder and CEO, Damilah
Or maybe you’ve engaged a far-shore ‘partner’ in India who always says everything is fine and on time, but frequently delivers late and with sub-standard quality.
These are, of course, generalisations – but they have happened too frequently to me, and others I know, to be outliers.
Either situation is extremely frustrating, potentially costly, and will fail to produce the kind of results that you and your organisation require. That’s why, at Damilah, we have developed the ‘partner-shoring’ model – a different way of approaching near-shoring.
Using this model, the client and supplier work seamlessly together towards common goals. Some people in the team may be from the client side, some from the supplier – but to an outsider it should be virtually impossible to tell which is which. That’s because they collaborate as genuine partners to build the best possible product within the constraints set by the business.
The teams are also fully autonomous, containing all the skills necessary to deliver the products end users are looking for. This maximises productivity by removing as many dependencies as possible, which often tend to slow progress.
Here’s a good example of the collaborative culture we foster at Damilah. With one of our clients, the autonomous team is led by a triumvirate comprising a product manager, an architect and a delivery manager. One of those roles is provided by the customer, the other two by us. But they are all equal in status – and we call them the Three Amigos, as they work so closely together on projects.
The product manager aims to create the ideal product to meet customers’ needs. The architect works out how to do this, the challenges involved, and how long it will take. And the delivery manager looks after putting the plan together and ensuring everything is delivered on time and of high quality.
Above all, the Three Amigos are mature and experienced people, equals who are constantly working together on discovery, understanding what needs to be built, and prioritising work based on business needs, difficulty and time requirements – without the traditional ‘them and us’ client and supplier relationship.
We believe this gives our clients the best of both worlds.
In the first instance, you can leverage the cost benefits of working with an off-shore team. But, at the same time, this kind of partnership is hard to achieve when the teams are far apart in geography, time zone and culture. On the other hand, if the people involved can spend time face to face, working together, planning, resolving challenges – and even socialising – then positive working relationships will form and truly enable close collaboration and velocity.
If your European-based team has to travel for an entire day to reach a remote part of the world, then suffer from jet lag, they will probably be reluctant to visit their partners very often. And that’s not to mention the difficulty of getting expensive travel costs approved. As a result, the kind of closeness and effective teamwork that comes from frequent contact is unlikely to arise. On the other hand, if the partner is just a few hours away, with a one-hour time gap, it can make all the difference.
Furthermore, although there may be some minor cultural differences between teams in the UK and, say, Eastern Europe, these are likely to be far less pronounced than between the UK and South or East Asia.
Working with a partner whose team feels like an extension of your own, and is fully aligned with your own business requirements and goals, allows you to successfully leverage the advantages of near-shoring with a company that is already established in the overseas market.
That means your partner can ensure people are rewarded appropriately while you also benefit from their deep market knowledge and understanding when it comes to aspects such as local regulation and cultural differences. In other words, you can build confidence in the process, the people and the location with minimal risks.
There are also the benefits of reduced churn that tend to come from a well-run near-shoring operation. In many Indian off-shore firms, for example, it’s common to see annual employee turnover at rates as high as 25% or 30% – whereas our Damilah team in North Macedonia has a rate of around 2% on average.
And, last but not least, there are the advantages of transparency. If a development team works as a black box – where the client knows very little about what’s going on until the product is delivered – you’ll frequently hear that everything is going well… until the day of delivery. And then you might hear that there’s been a problem – and delivery will be delayed for a month or three.
Such issues are common among teams in geographies like India, where culturally people are reluctant to deliver bad news. On the other hand, European teams tend towards more transparent working practices. This makes it easier to be aware of problems as they arise, allowing you to find a solution – such as prioritising certain features or narrowing the scope – while still hitting the delivery date, rather than being trapped in a last-minute situation where you have no way out.
If you’d like to find out more about the ways partner-shoring could benefit your business, and how Damilah can help, get in touch now to discuss our range of services.
Iain Bishop, founder and CEO, Damilah
Delivering great software on time for our customers comes down to effectively managing four key elements: scope, risk, quality, and talented people. In this series of articles, which accompany our Tech Talks video, we take a closer look at each one individually.
Here, we tackle the important matter of managing people…
If you’re a follower of English football, depending on your allegiance, you’ll have either been enjoying or lamenting Manchester United’s recent failure to live up to their previous high standards.
There are many possible reasons for the club’s relative lack of success, and we wouldn’t claim to be soccer experts who can fully explain its problems. However, one thing is clear: there has been no lack of talent when it comes to players on the pitch, with world-class footballers such as Cristiano Ronaldo, Casemiro and Lisandro Martinez in the squad, either now or recently. But individual talent is one thing, and team performance is another.
United’s troubles go to show that success relies not solely on hiring talented people. It’s also necessary to manage and motivate them in the right ways, so they perform as a team with a shared goal, constantly improving, and always working hard for each other.
The same is true when it comes to software development. You can’t produce great software without great people. But you also need to ensure you create the right conditions for those people to succeed.
We therefore believe it’s always worth the time, effort and expenditure of investing in all our people. By showing we care, and helping them to reach their potential, they will always go the extra mile and produce better quality work for our customers. So here are some of the ways we enable this at Damilah:
We strive to create a culture that is open and supportive, where everyone is clear on what success looks like and how they can find the right path towards it.
Our line managers are ultimately responsible for an employee’s growth and development, but it’s not limited to them. For example, someone might need support for a particular skill that is not within the line manager’s competence – in which case, we’ll ensure they are connected to the right person in the business to help them develop in the desired way.
In other words, we’re constantly supporting each other and growing together.
What’s more, it’s important to us that our people are prepared to take risks in order to develop and innovate. If they are afraid to, they will usually struggle to advance. Of course, that doesn’t mean they’ll take silly or unnecessary risks – but, rather, in a measured way with the right support.
Software and technology are always changing and we constantly need to try new things to stay ahead of the game. We’ll usually do that in close consultation with clients, and often ‘spike’ technology – that is, test something in a controlled environment. If it works, then great: we can roll it out. And if it doesn’t, we’ll learn from this and move on.
We’re currently doing exactly that with one of our clients. This approach allows the client to be reassured that what we’re suggesting will work, while also allowing everyone to feel in control. What’s more, we all learn together in an environment built on mutual trust.
I’ve worked in businesses as a CTO where the first thing to go when budgets are tight is training. But that’s always a false economy that ultimately impacts on the quality of the work delivered and the success of the business. So we will always continue to invest in training, because we know we’ll get a return on it, tenfold or more.
Therefore, every employee has a development plan, and that can include both technical skills and the ‘softer’ skills, such as communication or presentation. Doing this, we believe, delivers the obvious short-term benefit of upskilling our team – but also the long-term benefit of an increasingly knowledgeable, committed workforce that chooses to stay with us.
With the rapid pace of change in technology, it’s important for us to stay abreast of new innovations. We do this by providing opportunities to all our people to initiate or join specific innovation projects, which allow them to invest time in trying out new technologies that enhance our capabilities and ensure their skills remain at the forefront of the industry.
There is no greater motivator than success – and it can be addictive. We therefore ensure we celebrate those successes at every opportunity, for example by having annual awards for both individuals and teams.
It’s important that these are not subjective. Instead, they’re based on performance and also the way in which our people uphold and emphasise the values of our business. We find that’s a really powerful way of encouraging further success, which of course will always lead to additional benefits for our clients.
We believe strongly in the value of teamwork, and our commitment to this extends to our customers. We aim to avoid the traditional customer-supplier relationship, opting for collaborative, transparent partnerships from the outset.
We encourage customers to feel as if we’re all part of the same organisation, working towards the same goals. Quite simply, that’s our culture – and the culture we encourage from everyone we work with, both internally and externally.
If you’d like to find out more about any of the points raised in this article, and how we can deliver great software for your business, get in touch now.
Iain Bishop, founder and CEO, Damilah
Delivering great software on time for our customers comes down to effectively managing four key elements: scope, risk, quality, and talented people. In this series of articles, which accompany our Tech Talks video, we take a closer look at each one individually.
Here, we tackle the essential topic of ensuring quality…
It’s easy to fall into a trap when it comes to managing the quality of software: an over-reliance on quality assurance (QA) at the end of the process.
While QA is vital, we strongly believe that quality is pervasive, and there needs to be a constant focus on this throughout a project. That also means always paying attention to a customer’s or user’s requirements. After all, there’s no point in building the best product if it doesn’t do what’s needed.
Because we always take this approach, we believe that quality is everyone’s responsibility all the time – from the developers writing the code, to the project managers, and even the customers we’re working with.
Doing this is not easy, and it requires a high level of commitment. But by operating in this way, as a single team, we can deliver outstanding outcomes together. Here are some of the most important considerations we always keep in mind when it comes to ensuring we create great software.
Quality starts at the very beginning. That means the first discussion with the main stakeholders and really understanding their requirements. We then need to ensure the requirements are described in a way that’s testable, so we can validate whether the finished product meets the correct criteria.
We’ll then work with our development teams to check the written requirements are achievable and can be implemented with the right level of quality. Only once everyone is satisfied with this will we be ready to start work on a product.
It’s rare to have a project without some kind of time pressure – and of course that can compromise quality if not managed properly. So, as well as defining ‘Ready’ before we start a piece of work, we also create an agreed definition of ‘Done’. This will include the types of tests and reviews which must be completed before a feature is considered finished.
But, of course, unforeseen problems or scope changes do happen during a project, meaning that things can take longer than expected or need to be reprioritised. When this happens, it’s important to be open and transparent, and also to have courage – for example to explain to a key stakeholder that a change in the delivery schedule might be necessary.
I’ve seen organisations that have a very top-down way of working where people are too afraid to give bad news to their superiors, so they’ll do whatever is expedient to avoid it. Unfortunately, though, the upshot is usually that the management will eventually discover that the delivered product is not good enough – and they’ll wonder why. The answer, of course, is because of the culture in their business. Therefore, transparency and honesty are vital. After all, everyone is ultimately working to achieve the same goals.
Although, as we’ve stressed, quality needs to be baked in right through the process, effective testing is still crucial. And it’s important to test early and regularly, otherwise a nasty shock may arise at the end – for example, realising an entire project is built on code that doesn’t work properly.
We use agile processes, breaking a project down into sprints that usually last two weeks. At the end of each sprint, we’ll carry out tests to ensure the software is fulfilling its requirements, working effectively, and conforms to the highest security standards.
We employ tooling to continuously conduct vulnerability testing and ensure software complies with OWASP Top 10 security standards. We put these tools into the build pipeline to ensure they are always running and developers know immediately when code is non-conformant.
We also use static code analysis tools to ensure the code we produce conforms to quality, reliability and maintenance standards.
And while our most experienced, senior developers are involved in these processes, again we also look to automate as much of it as possible. That way, a test can be rerun on a frequent basis – as software will always change during an agile development process – with no backlog building up.
Scaling needs to be considered from the get-go – but there’s always a balance to be found. It’s easy to end up over-engineering a product so it can scale when that may not be needed for several years, if at all. But ignoring scalability can lead to its own problems if it turns out to be necessary.
It’s therefore essential for us to truly understand our customer’s needs so we can ensure the right level of scalability is built in. We’re also finding that public cloud gives us the option of scaling a product easily and rapidly, if required.
In addition, it’s crucial to consider the future maintainability of a solution – and this is often more important than the initial cycle of development. If quality is compromised during the build phase, maybe for cost reasons, it can quickly become a false economy as maintenance of poor software can be expensive and greatly increase the total expenditure.
In our opinion, automation is definitely the way to go when it comes to maintenance. But it’s incredibly hard to automate if the product hasn’t been built to high standards in the first instance – which further emphasises the need for stringent quality control during the initial build phase.
If you’d like to find out more about any of the points raised in this article, and how we can deliver great software for your business, get in touch now.
Iain Bishop, founder and CEO, Damilah
Delivering great software on time for our customers comes down to effectively managing four key elements: scope, risk, quality, and talented people. In this series of articles, which accompany our Tech Talks video, we take a closer look at each one individually.
Here, we tackle the tricky topic of risk…
Whether you’re developing software or sending a person to Mars, there’s always a fine line to tread at the start of every project: between optimism and pessimism.
Naturally, everyone involved will be hoping and working for the best possible outcome. But unless there’s a keen awareness of what could go wrong – whether you want to call that pessimism or realism – it’s highly likely that some poor outcomes will result.
This is why effective risk management is vital when it comes to delivering great software on time. And, as with many other considerations – such as managing scope and quality – doing it well means taking a holistic approach from start to finish, and beyond.
It’s important to point out that, if you continue reading this article, you may end up with a sense of foreboding, worrying that every project is fraught with dangers waiting to derail it. And it’s true that even the simplest undertaking can have inherent risks that threaten to compromise quality, cost or delivery times.
However, we spend a lot of time predicting and assessing those risks to help avoid problems before they occur; or, if they do materialise, to ensure we can mitigate against them in a way that will result in minimum impact for our customers.
In other words, we spend a lot of time thinking about risks, and how to manage them, precisely so our customers don’t have to.
In every software development project, there are usually three major types of risk to consider, as follows:
This could include changes to the scope, or adding new requirements, once a project has already begun. For more on this, see our article on this topic .
This could involve, for example, incorporating new technologies and new practices, or changing the platform on which we are working.
This generally revolves around the interdependencies between teams, and is an area we focus on strongly. We might have, for example, a dozen or more teams working on a single project, so frequent and clear communication is essential to avoid blockers. We’ll therefore sequence and synchronise our schedules so they are complementary to each other, while constantly keeping the lines of communication open.
At the start of every project, we’ll create a risk mitigation plan based on a combination of our own experience and empirical data.
To do this, firstly we’ll identify the risks and assign each one a score – assessing its possible impact on a scale of one to five, and the probability of it occurring on a scale of one to four. Multiplying those two values gives us a risk score from zero to 20, with 20 being the highest possible.
That gives us a clear idea of what to focus on. Then we’ll plan how to avoid those risks and also pinpoint the signs that help us to spot a problem at the earliest possible stage. Our overall aim is to steer clear of situations where people just hope for the best because they want to report good news to the management – maybe because they’re under pressure to deliver by a certain time.
In our experience, it’s always better to have the risk discussion at the beginning of a project so we can develop a realistic plan, rather than end up making excuses for failure throughout. That’s why it’s so important to think through risks early on, and to keep updating the risk assessments, as risk management is an ongoing process throughout any project.
A good example is the introduction of new technology, which often carries its own risks. A proactive approach, such as ‘spiking’ – in other words, taking a couple of people aside and testing it well in advance of the project deadline – is an effective way of managing it. I’ve worked on many projects in the past where our first choice was wrong and the tech we were planning to use just wasn’t going to work for us – which is exactly the kind of risk that spiking can help to avoid.
The phrase, ‘There are no problems, only opportunities’ is a cliché – because, we believe, it’s often true. In many cases, when it comes to risks inherent in a project, we can also identify an opportunity hidden within.
The methodology we use to assess levels of risk allows us to calculate both negatives and positives. For example, making certain technical changes may pose a short-term risk because we need to alter the scope of a project to accommodate them. But in the longer term, those changes may help us to build a solid platform that will accelerate the development of additional features.
By using the same methodology for opportunities as for risks, we can gauge how one is balanced against the other – and if the gain score is higher than the risk score, it’s probably worth considering.
As always, the great benefit comes from close collaboration with our customers so we can truly understand their requirements and how we can create value for them. Then we can effectively measure the risks worth taking and ensure we deliver the best possible outcomes.
If you’d like to find out more about any of the points raised in this article, and how we can deliver great software for your business, get in touch now.
Iain Bishop, founder and CEO, Damilah
Delivering great software on time for our customers comes down to effectively managing four key elements: scope, risk, quality, and talented people. In this series of articles, which accompany our Tech Talks video, we take a closer look at each one individually.
Here, we tackle the thorny topic of scope and scope creep…
We were recently working on a project for a customer that required us to re-architecture a solution to help deliver some key mid-term goals for their business. The project had been carefully scoped, and a roadmap produced.
However, our customer received some important feedback from their prospective customers. The solution would need an additional feature in a short timeframe to enable them to secure a contract. That immediately shifted the scope of our project, as this new requirement suddenly became a top priority.
In many cases, this kind of pivot may cause a significant problem by adding a large amount of additional work which could jeopardise the success of the entire project.
But it didn’t for us. We were able to quickly re-prioritise the tasks involved, allowing us to complete the essential elements on time and extend the deadline for the rest. That meant we delivered the most essential value for the client, fast, and the project was still completed in a satisfactory way.
Such a scenario, where scope changes are required mid-project, will be familiar to anyone involved in software development: scope creep can be one of the biggest risks. Left unmanaged, it can result in delays and unsatisfactory outcomes for both the client and the developer.
We therefore believe it’s vital to pay close attention to managing scope, from before a project even starts, and right through to the end and beyond.
In our experience, scope creep – or ‘gold plating’, where unnecessary features are added to a product – usually comes from one of two places.
The first is the product manager or evangelist. Understandably, they always want the best product they can have – that’s their job. And, to achieve this, it’s important that good ideas are thrown in during the development process. But the constant danger is that, if you add something in, you don’t take something out. When that happens, and we’re working to a fixed delivery timeline, quality is likely to be compromised or, worse, the whole project is likely to fail.
The second is on the technical side. There may be a desire to create a technological standardisation – for example, a new way of accessing data in a program – which invariably creates more work. That’s often for very good reasons, and it might also be the case that this has to be prioritised ahead of everything else, because of the value it could bring to the business and customers. But the effect it will have on the project has to be acknowledged, as there is usually only a finite amount of time and effort available.
Here are our four main approaches to keeping a project on track:
Managing scope is not solely a delivery manager’s job. We believe everyone needs to play a part – and that includes the customers with whom we work in partnership. If everyone involved has a transparent and honest relationship, and keeps the lines of communication open, scope issues can be kept to a minimum.
If we can create a clearly defined scope with the customer from the outset, we are usually able to hit the ground running and very few issues will occur. When the scope of a project spirals out of control, it can nearly always be traced back to a failure to recognise changing priorities in a project and adjust the plans accordingly.
We use agile development processes that involve working in short sprints, usually two weeks at a time. That’s because, at the end of every cycle, we’ll share our progress with the customer and obtain their feedback, allowing us to make small, incremental improvements. It’s an excellent way of ensuring the customer is getting what they really need – and nothing they don’t need.
And, best of all, it ensures we don’t miss any gems. Our experience tells us that if you wait until everything is completed, you miss the chance for domain experts to share their knowledge and ideas along the way. The more collaboration you have, and the more feedback you gather, the better the product you end up with.
Truly understanding the value of each part of a project for our client and their end users allows us to deliver the best possible outcome in the shortest time available. This necessitates working closely with key stakeholders to ensure the most important aspects, from a business or commercial perspective, are prioritised.
We believe our customers have a huge role to play in helping us. Our advice, therefore, is to always engage fully throughout the process, as this will result in the best possible final product that precisely matches their needs – delivered on time.
If you’d like to find out more about any of the points raised in this article, and how we can deliver great software for your business, get in touch now .
Iain Bishop, founder and CEO, Damilah
When it comes to thinking about new products, we often wish for more time to conduct interviews, analyze data, and explore competitors. But these tasks take up a lot of time. That’s where ChatGPT comes in handy—it can save us time and make our processes more efficient.
Let’s dive into the world of product discovery by tapping into ChatGPT’s vast pool of data and capabilities. This guide will walk you through how to use ChatGPT for a more efficient product discovery process, helping you prepare for the development of innovative products.
Prompt you can use: “I have a business objective and I’m looking to identify potential customer needs aligned with my goal. My objective is [specify your goal]. Could you please investigate the potential pain points experienced by this specific target group.”
Prompt you can use: “Can you please act as a Product Manager and explore the actual problem underneath these pain points? Please use the ‘5 Why’s’ method to find out why this problem is happening. Once you figure out the main reason, summarize your findings in a clear problem statement.”
Prompt you can use: “Could you please identify the top 5 crucial tasks (JBTD) that my target customers need to accomplish when dealing with the problem? I aim to gain a better understanding of the key activities customers will undertake, when facing the problem.”
Prompt you can use: “Could you please outline the three user personas who are likely to be my most frequent customers?”
Prompt you can use: “Would you be so kind as to create an empathy map for my target customers? I’m eager to gain a deeper understanding of their thoughts, feelings, what they see and hear, and what they say and do.”
Prompt you can use: “Picture yourself in a room with your team, including Software Engineers, UX/UI Designers, QA Testers, a Product Owner, and a Scrum Master. During an ideation process, what would be the three standout ideas as potential product solutions for addressing this customer’s problem?”
Prompt you can use: “Can you please define our value proposition for the first product solution? Describe how it meets customer needs, its unique benefits, and what makes it better than similar products on the market.”
Prompt you can use: “Can you explore other companies in the market selling similar products? Summarize their strengths and weaknesses and identify areas where we can gain a competitive advantage.”
Prompt you can use: “Please outline the key features for the product solution. Consider functionality, user experience, and any unique aspects that will set our product apart in the market. “
Prompt you can use: “Can you now please define the features and functionalities that are essential for our Minimum Viable Product (MVP)? Focus on the core elements that will allow us to deliver value to our users quickly and efficiently.”
To show that these prompts truly make a difference, we put them to the test in a real-life example. In this case study below, you can follow how we turned an idea into a possible product solution, with a clear explanation of our thought process.
At the end we’ll say that ChatGPT can be a really valuable asset in product discovery, helping us save significant time. However, it’s important to remember that while ChatGPT and AI, in general, can be incredibly helpful, they don’t guarantee the automatic success of our products. Success still relies on thoughtful execution and a comprehensive approach beyond the capabilities of AI alone.
Olgica Strezoska, Principal Product Owner at Damilah