Collaboratively Creating a Complex GDPR Software Solution22 June 2018 ‐ 6 min read
Senior Business Analyst, Dale Hockly, shares on one of our most recent projects, DataE. Read how we solve complex problems, create great software, and offer unrivalled business value for startups and corporates.
With a simple brief to a complex problem, DataE was a challenge we hadn’t faced before, a SaaS self-help GDPR solution. After weeks of acquiring an in-depth understanding of GDPR, its governance and its implications when not adhered to or implemented correctly, our team slowly started understanding why GDPR was such a big deal. We started the project in February this year, knowing GDPR laws were coming into effect on May 25th and the solution needed to be market ready to cater for the thousands of global companies who hadn’t yet made provision for this new governing law. 5 months later and we can see the impact first hand, from receiving hundreds of emails informing us that “your information will be removed from our database and we will no longer send you any communication”, a blessing in disguise!
Nonetheless, although 4i is great at developing software with a great proven track record, we are not data privacy nor law experts, neither do we pretend to be. We gladly took on the task and assembled a great team made up of designers, a BA, a product owner, software engineers and a really supportive client. To date, the project is still in the early stages of completion and already proving a major success, where the client has already signed a few large scale partnerships.
This is how we solved a complex problem by establishing space for ownership and creativity;
Understanding the Why, not the How
DataE started off with a high-level specification document written and produced collaboratively by myself and the client, which then translated to the business requirements document (BRD) which is a 4i hybrid combining industry standards and our very own way of solving problems. We call this answering the why. Instead of listing and defining features, we focus on core business requirements defined by the clients’ end goals, which are then critically evaluated and rated according to ‘value add’. In order for the creative juices to start flowing, the team needs to understand what we are trying to create and why we are creating it, not necessarily how it should be created. The issue with traditional software development, regardless of the methodology used, is that teams are generally given a brief and told how the product should look and how it should work rather than why they are creating the solution. Sure, this model contains some room for creativity, but within too many boundaries.
The dream-team developing DataE were limited by only two constraints; time to market (time frame) and budget. However, because the team understood why DataE was being created and why it would cater for a large gap in the market, they could become creative on how to best utilise the time allocated to the project, and how to best solve business requirements in order to get to market as soon as possible. By focusing on the why, we have personally seen major improvements in the way we create products, and the level of innovative thinking has increased substantially over the last year.
So, we get the why, what happens next?
By priding ourselves as being a creative digital agency, we simply cannot believe that one individual, be it the client, the business analyst or the product owner, is able to make decisions or dictate how the product should be developed or solved. Sure, business requirements remain business requirements, but how they are implemented or by which means they are solved should not be a prerequisite.
It’s collaborative problem solving, but from an individual place of understanding, reasoning and contributing. What I mean by this, is that if each team member genuinely has the freedom to take ownership and contribute to the solution, we naturally create a space for collaborative thinking which is competitive, creative, and where the best idea always wins. This form of ownership also means that the project is always the key beneficiary.
For DataE, we gave the team a deadline, defined number of sprints, and complete freedom of ingenuity to develop a product which best solves the business’ requirements and adds the most value to the product, within the specified time frame – once again, the best idea always wins!
We understand why the solution is needed and we have created the space for team members to take ownership. The only missing piece of the puzzle, is trust.
Trust is the foundation of project success
It should be said though, internal trust differs vastly from external trust – we know what our team members are capable of, the client does not. Trust is the foundation on which all successful projects are built, but it is something which needs to be gained over time. This type of trust goes two ways; one, building trust with the client, and allowing the client to believe that you have their business’ interest at heart, which also builds certitude, and two, trusting that the developers understand the business, its processes and its requirements.
Why is trust such a key component? Because the solutions we often create are not just an addition to the business model, they are the business model. This was especially true and accurate for DataE.
So, how is trust gained?
Communication as a success factor
Although communication is traditionally done solely by the product owner or project manager, it is usually not the most effective way to communicate. This way of communication often unintentionally creates a broken-telephone type of back and forth, where feedback is often perceived differently each time the message is conveyed. By encouraging direct and constant communication with developers, BA’s and designers, the client is able to detail their thoughts, and we are able to let the team creatively brainstorm solutions with the client.
Naturally, there was a lot on the line for DataE; we had never worked with the client before, she was based in Paris, and French was her first language. However, after effective communication from all team members, and genuinely taking all the clients feedback and requirements into consideration by constantly offering alternative solutions, trust was gained in no time.
In order to build trust, the client needs to be confident in your ability to add value to their business, but also see that alternative recommendations have a sense of ingenuity. What happens if we make a mistake?
Trial and error are key to figuring out what is best for the project. In software, especially when creating a once-off solution, products are very rarely perfect first time around, even with all the research and market insights in the world. And that is okay... It is of utmost importance to try new things, test them, understand actual market appetite and make iterations where required, until we have sufficient evidence of audience approval. In fact, making mistakes is just as important as getting something right, and it should be embraced in the effort to test new boundaries and explore unknown territory.
As with any project, we admittedly made mistakes with DataE. Mostly small, unnoticeable mistakes which allowed us to rethink and game-plan how things could be implemented differently. Mistakes cause companies like ourselves to shift our egos and pride to the side, admit them to the client, and make iterations where required. Interestingly enough, this approached often allowed the client to think more resourcefully and even came up with ideas better than our own – where again, the project was the biggest beneficiary.
Should this model be used for all project?
The simple answer is no. Although this model has worked well for many projects over the course of the last year, it is not always the most effective way to develop. Startups differ from corporates, and often with corporates, the brief and boundaries are defined by many factors such as legal, consumer and stakeholder requirements, changing the way collective creativity is applied. The nature and beauty of software development, regardless if it is for a corporate or a startup, is that no matter how basic, there is always a sense of uniqueness. Therefore, I personally believe that a single model or methodological approach will not be sufficient enough to uncover a projects true potential. To do this, and to effectively maximise value-add within the specified timeframe, teams need to be flexible, creative, collaborative and adaptive in the way they approach problem solving.