Transforming how we perceive digital projects
- Posted on July 25, 2017
- Estimated reading time 3 minutes
Recently, a client asked me a confronting question about a project: “what is the one thing that will make this project fail?”
My answer had nothing to do with budgets, time, or resources. Nothing to do with whether we use mobile-first design or use a certain type of software.
The one thing that will make your digital project fail is if you treat it as exactly that: a digital project.
Instead, we encouraged them to think of it as a transformation of the business — for both their people and their customers.
We’ve explored the idea that as an agency, we’re moving away from the idea of “catching briefs” and adopting a holistic view of a client’s requirements. We want to be invited into their thinking process so that we can identify the drivers that sit behind the business need and deliver the right digital roadmap for those needs — rather than just delivering “a website” that ends up being useless two years later.
This process often requires speaking with clients who have no idea how we (or tech consultancies in general) work, and what it would mean for their organisation to be successful in partnering with us to deliver it. However, these are challenges we must embrace as an agency if we believe we can enact the scale of change that’s required for success. Below, we look at some of the cultural and operational considerations we encourage our clients to undertake, and work with them to solve.
Firstly, we sometimes find teams within a client who feel as though their jobs are in question purely by virtue of our presence. For some, having external expertise come in to your organisation implies some kind of shortcoming internally. This particular effect can be exacerbated when speaking with different parts of a business, which can be quite siloed from one another. It’s almost as if you’re working with multiple businesses within the one entity — some or none may work in perfect alignment with one another.
Secondly, many organisations outside of our industry have never worked within an agile structure, so the concept of iteration is fairly new. The effect of that mindset shift shouldn’t be underestimated. Once people get into a rhythm of working, it’s difficult to move into a new structure and still feel confident about your work. However, all of a sudden, we come in and start suggesting work in two-week sprints and with daily stand-ups, feature prioritisation sessions, backlog grooming, and a meeting every couple of weeks to figure out what we could have done better whilst we’re still in the middle of the project! It’s shocking. It’s a massive change, and change can derail a project more than a lack of resources can.
These are a few of the reasons I believe our projects are as much about change management as they are about the code we deploy.
So how do we do it?
When dealing with a client who has no experience, we always just say straight up: who has heard of agile? You might see a few hands go up, at the most. That’s a perfect opportunity to explain what agile means, what agile is to us in this engagement, and what it’s going to look like in a day-to-day sense.
Often, we might find even in an organisation that uses “agile”, there will be differences in the details. Everyone has their own version, understanding or belief of agile, so clarifying those expectations straight away is crucial (the same can be said of UX/CX/Design Thinking, too). The upside is, there is a degree of flexibility in how much you take and leave from these frameworks (very few, if any, run pure agile). So long as everyone agrees and it serves the project, then it can be altered.
Disarm and educate
One key activity we encourage is to develop the capabilities within with our clients. We hold lunch&learn sessions where we talk about design thinking, agile, product management and operational excellence (ensuring that what we’re building continues to thrive in BAU), but in a manner that’s divorced from the project we’re engaged to deliver. We’re workshopping, not pitching, and there is no hidden agenda. Our agenda is plain and simple; the fact that the more our clients know about why, what and how we do what we do, the more likely they are to trust us. Without trust, none of our projects would be successful.
One thing that tells us this works is that we’ve never cancelled a lunch&learn. Despite being a bit of an unknown for our clients as to how many people (if any) will take it up, we have consistently found it overbooked, and more often than not, holding a follow up session. This, in conjunction with our drive to build trust, will see us continue to recommend these to our clients.
However, the opportunity to develop the capability of our clients presents itself continually throughout a project.
Develop a culture of iteration and feedback
Feedback is such a critical part of the process that we ask for it throughout a project, even weekly. For people who have worked in waterfall environments, feedback generally comes right before sign off, so it can be jarring to have that constant need for feedback in a rapid manner. Initially, there is also a hesitation that whatever feedback is given will be enacted in to law, overruled only by a dreaded change of scope.
However, over time and with nurturing, our clients begin to gain a sense of involvement in the feedback process. The nature of the conversations change, in the sense that they become just that; conversations, rather than feedback spreadsheets or bullet points outlining what to change. Ideas start to flow, other players come in to provide their expertise, we can take it to customers and see what they think. There is less pressure and apprehension in giving feedback. People can throw out ideas, knowing that if they don’t work out, the process is there to act as a safety net to ensure the project will still succeed (and often only succeeds by virtue of needing the ideas that didn’t work out to get to the ones that did).
Why does this matter?
At its core, our projects are about the people we work with. About understanding their needs, motivations, fears and expectations, and making sure we maintain a high level of awareness to recognise when things are going well — and when they aren’t. Key to this, and why we take the approach we do above, is to be open, clear and consistent in our communication, and to challenge ambiguity.
I don’t like unnecessary challenges, and making sure people are all on the same page and trusting each other is the best way I know to get around that. Once we have that, creating a website, or a platform, or an app, or a portal, isn’t work — it’s scarily straightforward and genuinely rewarding.