The Sync: Alexei Miller & Allan Wellenstein Talk About the Role and Principles of Solution Design

Allan Wellenstein, the founder and leader of Solution Design at DataArt, in his interview with Alexei Miller, Managing Director at DataArt, shares his opinion why Solution Design practices and process actually benefited from switching to a remote mode.
26/05/20
ALL articles
By Allan Wellenstein
Solution Design
ALL articles
By Alexei Miller
Finance Practice
Share
The Sync: Alexei Miller & Allan Wellenstein Talk About the Role and Principles of Solution Design

In this episode, Alexei Miller, Managing Director at DataArt, interviews Allan Wellenstein, the founder and leader of Solution Design at DataArt, about the goal of Solution Design and the value it brings to businesses. Allan Wellenstein explains how not to pay an expensive price for an error discovered too late in the course of a project and consider risks of both technical engineering and program management upfront.



Alexei Miller: We're on with Alan Wellenstein - the founder and the leader of the DataArt Solution Design practice, which does a lot of work helping clients form their ideas and plans for new systems, new solutions that we then proceed to implement. Hi Alan, how are you?

Allan Wellenstein: Very well, thank you.

A.M.: Braving the virus, everyone is safe, I hope?

A.W.: Everyone is safe, and one of the virtues of being the only one in this office is that I still get to go to an office.

A.M.: Well, some of us envy you for that. Let's get started. We wanted to ask you to explain the role of solution design and the value that it brings to the client and to briefly explain the method that you guys follow and for what type of client situation you find this most applicable.

A.W.: Sure. So the role of Solution Design is typically upfront for some of our larger, more complex engagements. And simply put, the goal of Solution Design is to help ensure the success of the project. When I'm talking to the clients that I interact with, and I start with the statistic of 40% to 60% of IT projects failing, I have yet to be challenged on that statistic. In fact, most of the time, the people I'm speaking to nod knowingly and sadly because it's happened to everyone.

IT projects and transformation projects, in particular, are incredibly risky, and there are all sorts of reasons why they might fail. Some of them are on the technology, but even more of them are on the process, program management, alignment across stakeholders, etc. So, simply put, what we do in Solution Design is number one - make sure that we crystallize the objective - what is it that we're trying to do, what are the pain points we're trying to alleviate, the opportunities we're going after, and then let's make sure that everyone sees those objectives in the same way, and then let's look at all the things that likely will go bump as part of this process.

It's not about preventing stuff from blowing up, it's actually acknowledging that they will and trying to get them to blow up as early as possible in the process and in as contained a way as possible. So that you still have plenty of runways to adapt and course correct and ultimately make sure that the program is a success at the end.

A.M.: I know you often talk about two elements to this - “technical engineering”, “human engineering” which sounds intriguing. Can you confirm what you mean by that?

A.W.: Some of my UK colleagues have said that “human engineering” sounds creepy, so I sometimes say human or program management. But yes, when we think about risks on projects, we think about them from those two dimensions. So technical risks tend to be assumptions being wrong about what you might be able to do, either you know this tool out there is going to give us the functionality we need and work the way we want it to work, or this API is going to be performant enough, and it's those kinds of assumptions that if you get wrong and you discover too late can torpedo your project.

And then, on the human engineering side of the equation, it's misalignments across stakeholders. So, typically, in some of the larger transformations that we do, it’s across departments, across stakeholders within a company. And if you get that alignment wrong, if this group and this group don't see the universe in the same way and you discover it too late, it's one of the main reasons why so many projects fail.

And so we make sure that not only are we at the beginning understanding the objectives, which, by the way, sometimes involves a healthy amount of reverse engineering requirements into objectives. We often hear “oh we need to replace our CRM with something that's better”. Okay great, replacing the CRM is a requirement, but let's unpack why we are replacing the CRM in that instance, what are we trying to do, etc?

And then let's make sure that all the people across the company who that is going to affect are on board and aware of this transformation and that you take their input, needs, concerns, risks into consideration as early as possible so that you don't reach a situation where you're 60% of the way in and you discover you got something wrong, but by then it's too expensive to course-correct.

A.M.: I imagine this sort of work is best done when you're all physically in the same space, which is not the luxury we can all afford in times like this. But I'm sure you have advice and tips and tricks and some observations on how it can be done in this new virtual world we are inhabiting right now. Can you share your observations in the last few weeks? What has your work been like and how do you see it evolving going forward?

A.W.: So I actually don't know how critical it is for everyone to be in the same room. It's useful, I think, for getting to know people. When I do on-site, I get more value out of dinner and drinks, getting to know people with their guard down and hearing about them from a different perspective other than the work - that, of course, is helpful at the beginning of a project.

But in terms of the actual doing of a project, in solution design we do a tremendous amount of prototyping and building proofs of concept and iterating, it's a very iterative process, and one of the problems of on-site, especially when you have people traveling, is that you try to get everything done in that one week or two weeks when everyone is there.

And that in and of itself can sometimes be a problem because it doesn't lend itself to the, what would otherwise be, an iterative process. So one of the things that I've actually found to be a benefit of the work from home is that we are able to democratize participation in these meetings. Remote participants and on-site participants have equal footing, equal square footage, if you will, in the zoom grid, and we're able to actually get more time from the people we interact with because we're able to do it an hour here an hour there over several weeks.

And when we iterate, and we show them our prototypes, we're actually able to meaningfully show them the result of the last conversation. Whereas when we do this on-site, and everything is one week, you miss this opportunity to get more time with all of the stakeholders who we typically want to talk with, and then to show them the fruits of the iteration process of taking some ideas, thinking about it, going to our UX experts or our technical experts, trying something and then coming back with what we've learned and adjusting together.

A.M.: I know you've recently completed a very large and mission-critical solution design effort for a large client in retail, which was interesting because it started when everyone could meet in person and ended well into this quarantine time, so it's a perhaps a unique project that started one way and finished the other. How did your experience change over the course of that one effort?

A.W.: Well, the clients’ priorities shifted. They are in retail, as you mentioned and what was important before quarantine and what was important after quarantine shifted in a meaningful way. And one of the nice things about the solution design methodology, because it is iterative and agile, it wasn't an issue with us. So some of their priorities changed, but it was not an issue to our program and helping them figure out how we were going to optimize the solution given the current state and their requirements, etc.

In terms of the mechanics, it really was much more effective in terms of the number of people we needed to interact with and the time that we got with them, especially given that they were super busy. They're in one of the few industries with a problem of keeping up with demand. These people were incredibly busy, but because we were doing it remotely, we were able to still get time when people could fit it into their schedule and iterate with them and show them the fruits of our prototyping process. So I think in this particular case, it did not hurt the process at all.

A.M.: Excellent thanks very much, Allan.

Sign Up for Updates!

Subscribe now to receive industry-related articles and updates

Choose industries of interest
Thank You for Joining!

You will receive regular updates based on your interests. No spam guaranteed

Add another email address
Read more
Sign Up for Updates!
Choose industries of interest
Thank You for Joining!

You will receive regular updates based on your interests. No spam guaranteed

Add another email address
Welcome
We are glad you found us
Please explore our services and find out how we can support your business goals.
Get in Touch