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:

Maintaining a positive culture

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.

Investing in training and development

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.

Committing to innovation

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.

Celebrating success

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.

Working as one team with our customers

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.

Understanding from the outset what ‘good’ looks like

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.

Managing time pressures

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.

Rigorous testing – after every small step

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.

Scalability and future-proofing

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.

We think a lot about risks – so you don’t have to

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.

The three principal kinds of risk

In every software development project, there are usually three major types of risk to consider, as follows:

1. Scope

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 .

2. Technology

This could involve, for example, incorporating new technologies and new practices, or changing the platform on which we are working.

3. Dependencies

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. 

Mitigation plans and measuring risk

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.

Turning short-term risks into long-term opportunities

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.

The main causes of scope creep

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.

Strategies for avoiding scope creep

Here are our four main approaches to keeping a project on track:

1. Everyone takes responsibility

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.

2. Working closely with customers

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.

3. Agile processes with regular feedback loops

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.

4. Value-focused prioritisation

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.

How customers can play their part

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