UX designers, check. QA designers, check. Developers, check. The list goes on… but most highly-trained dev teams are missing a vital piece of the puzzle.
Software development is an inherently technical activity but without solving a real human need a project has no purpose. So why are those with the most immediate needs, the arbiters of purpose in this instance, missing from the team?
Standard processes for software development demonstrate the issue (sometimes jovially).
Customers and end users, the foremost experts on the business and its goals, are the critical missing piece from software development.
Aren’t they included already?
Well, yes… but not enough.
Towards Customer-Centric Software Development: A Multiple-Case Study found that, even in organisations with a high level of customer focus, that customers were only present at the beginning and end of the development process.
The authors found four key challenges with this approach:
- Indirect access to end-users led to a lack of understanding of the reasons behind customer requirements.
- Feature prioritisation is done based on employees’ opinions and is not continuously validated with customers.
- Testing is seen as an opportunity to identify defects but not to validate mismatches between customer needs and product offerings.
- A lack of systematic ways to collect, analyse and incorporate customer data into the product development process.
What’s the real problem?
By omitting the customer and end-users from the delivery team you are working on hypothesis (and to some extent guess work).
Even projects undertaken with extensive and painstaking research are based on what a potential solution could look like. This hypothesis isn’t tested until the end of the development phase when complete features are presented to the users and customers.
And now for the grand reveal… The software has been built to the customer’s specifications, or has it been built to the team’s interpretation of the customer’s initial specifications? Without fully understanding the customer’s situation there is a high chance of building the wrong software.
This of course has a huge impact on budget, schedule and, worst of all, the trust between the client and team.
So how does putting the customer and users into the project team help?
Shortening feedback cycles is a central principle of Agile delivery. By embedding key stakeholders within the team, feedback cycles are reduced from weeks to days.
Developers can demonstrate early prototypes and benefit from the unique expertise and feedback that only customers and end users possess. Rather than thinking, “what would the customer want?” at key decision points they can be asked directly.
No grand reveals, no surprises. A product is developed in collaboration with the customer and ultimately the people that will be using it.
Customers and users are busy people – do they have two jobs now?
Obviously we can’t expect the customer to be turning in 40 hours a week, that would be slightly impractical (and rather unnecessary). Attending weekly team meetings and being able to respond to questions from the team is enough.
The point is to ensure the developer feels comfortable making a call to the customer or uses to clarify a requirement or gain feedback on an early version. Essentially, you remove the subjectivity and guesswork to ensure the right product is being built.
Sounds nice – does it really work?
Digital Village recently completed the first iteration of the Race Around Australia project and was rolled out for a successful pilot in NSW schools. Program manager Emily McLachlan was deeply involved in reviewing the work in progress and making critical feature decisions and prioritising application features.
Her involvement allowed the delivery team to frame technical decisions within the needs of the department, schools, teachers and students, which reduced uncertainty around the product to practically zero.
You can read about the project’s success here.
Next Steps
Convincing busy professionals to attend another meeting/ create time for the demands of a project team sounds, well, trick. In fact, the hardest part may be convincing people who feel somewhat out of their depth in a technical project to participate in delivering it.
With the right support, however, non-technical stakeholders like clients and end users can provide invaluable contributions to a project delivery team.
The first step, of course, is a conversation with project stakeholders. Luckily that conversation will be about how they can save money, reduce risk and enjoy the benefits of their new software as soon as possible. We have a suggestion…
Working closely with the customers means the team will share the customer’s disappointments and triumphs, and hopefully shifts the team’s mindset from focussing on feature delivery to customer success.
