- 02.08.2019 11:30 am
- 03.05.2019 11:00 am
- 18.10.2018 01:30 pm
Development teams, and by that I mean the cross functional team of all individuals involved in building the product, tend to be kept quite a distance from customers.
We often see the customer at the start of the project, such as the bidding and offer stage. The next instance when we meet the customer is when the project begins the User Acceptance Testing (UAT) phase. It is quite disappointing that the effort development teams have put in may not be recognised when the end result does not fully satisfy the customer. Some parts of the project do not match expectations, for instance, and it reinforces the idea that dealing with the customer is difficult.
The purpose of this paper is to highlight some suggestions to help development teams ensure they deliver what customers want.
Need to satisfy customers
Ensuring customers are satisfied is important because happy customers become loyal customers. They return for more business, it may be to enhance or upgrade their current products, or to enquire for another product or service. In addition, satisfied customers will recommend your products and services to others. They will write testimonials, participate in case studies and it helps to be more competitive in the market.
In addition to increased revenues, such outcomes will enable colleagues to be motivated. It is no surprise that when we are motivated, happy and enjoying what we are doing, we produce more and better and may achieve some wonderful things.
The Manifesto for Agile Software Development – known as Agile Manifesto – provides tools to achieve this objective. It suggests the following:
prioritising individuals and interactions (over processes and tools),
having a working product (over comprehensive documentation),
having a customer collaboration (over contract negotiation),
the need to responding to change (over following a plan).
The Agile Manifesto also includes 12 principles, three of which are particularly important and can really help us move forward. Satisfying the customer through early and continuous delivery of valuable software must be highest priority; welcoming changing requirements, even late in development and applying agile processes harness change for the customers’ competitive advantage; and collaboration between business people and developers must work together daily throughout the project.
Those three key principles provide a mechanism to learn which allows us to gain knowledge. Knowledge is power and the answer to the risks. When starting a project, it is important to recognise that we don’t know everything. The world changes very rapidly, particularly in today’s climate of ever-advancing technological developments. The most relevant answer to such challenge is to keep learning and to consistently keep addressing any issues.
This mechanism to learn will bring us something tangible, something that triggers the thought. Showing a customer a solution that they can see, feel and understand. It triggers thoughts, opens up discussion and enables feedback. In turn, this new information and dialogue helps projects move forward towards completion of the project.
Relationship between product development and customers
The question then becomes how to gauge if the product you are currently building is fit for purpose and matches the customer’s objectives? I would like to make five suggestions.
To split deliveries into iterations.
What typically tends to happen is at the start of the project we have a lot of visibility when we come together and have our best people involved. Business development teams will then ‘disappear’ for months and only re-engage with the customer for the UAT phase.
In contrast, by splitting the delivery into iterations and having regular interactions with the customer, teams can demonstrate progress to the customer, discuss ongoing activities and understand the risks and the position with those risks. That in turn allows the customer to make any required adjustments.
Another benefit to splitting deliveries into iterations is that it makes technical projects more understandable to customers. For example, a mobile app project which might involve the development of nine Applications Programming Interface (APIs). The suggestion is to take one API to begin with, ideally the simplest one and make it even simpler. This will be more understandable to a customer and therefore the customer will be more informed to ask important questions such as - is the technology fit for purpose? Do we have the right versions of licenses? Are the fields using the right format? Lessons learned during this first iteration can subsequently be applied in the second and subsequent iterations.
Plan projects that are ‘risk based’ and ‘value focused’.
‘Risk based’ means recognising and tackling the risks as early as possible. Risks are varied and can include business risks (will the project satisfy the business objectives); social risks (do we have the right people to deliver this project?); technical risks (having the necessary technical expertise and knowledge?); and cost and schedule risk (an estimation by itself is always wrong and will need to be adjusted).
It is also important to plan ‘value focused’, which means thinking in terms of return of investment (ROI) and the fact that all the points to be delivered via releases need to be usable in some shape or form to generate valuable and tangible feedback. Releases are a common planning tool within Financial Services. They benefit from the lessons learned from iterations. In other words, iterations enable refinements and improvements to be made to a project via successive steps. By continuously collaborating with the customer, development teams can make sure that the product matches their desires and make adjustments when necessary as they go.
Continually work with the customer to define and refine the requirement.
The only way to stay as close as possible to the customer is to keep them involved through the process. Inviting the customer to share their business pain points and objectives helps the development team to understand what the customer is trying to achieve, this information makes the solution more in line with the real needs over the theoretical ones.
Early in this process the customer and the development team also build rapport and understanding which strengths the relationship and communication, which destroys the idea that dealing with the customer is difficult – it actually becomes very rewarding
Defining an effective and efficient communication strategy that will entail the full development team.
Typically, within companies in the financial and banking services sector, there are many people involved with customers (business delivery managers, client delivery managers, operations delivery managers, project managers, product managers, business analysts, development team members, and many more).
An effective communication strategy will use all these people as a network, rather than an organisational structure which will avoid delays and minimise the risk of the message being distorted or misunderstood.
Consistently asking the customer for feedback
Inviting them to reviews gives the customer the opportunity to instantly share their opinion and play an important part in the overall process. Showing the customer every iteration gives 100% transparency, the opportunity to inspect the working product and adapt the next steps in the development. This is will give both the customer and the development team the opportunity to eliminate waste. A win:win.
These five points can help deliver the customer’s objectives and help alleviate pain points. It also will keep products and services more maintainable to ensure we are really building the things that the customer needs.