On proper business problem scoping
Here’s a story:
The Professor walked into the computer lab. I was in my second year of studies in IT. She took a pen and wrote on the board: “Human-Computer Interaction and User Interface Development”. What a mouthful, I thought. After the customary meet and greet, she took the pen again and wrote “project idea in less than 300 words”. This was our assignment for the next week; to come up with a project idea which we would have to implement throughout the next semester.
“And hey…”
she added, playfully.
“Once decided, no backsies.”
Predictably enough, hands were raised.
“Yes, John?”
“What software are we going to be using?”
“Doesn’t matter, focus on an idea which you would love to design and implement.”
“But we don’t know what the tools offer; the tools could help us understand what we want and what we could do.”
“John, I’d like to see you creating something you truly love and no tool can help you on that quest.”
Choosing the tech first tends to give a false impression of nipping in the bud when it comes to problem solving. It would be a couple of years later, after I started working in the video game industry when I realised how right my professor was. I would find myself re-designing a game over and over just because the tool and different components offered the opportunity. This showed a fundamental flaw in my thinking: I didn’t truly understand what motivated my development. But there was a more critical flaw, a preconceived flaw so deeply hidden in the basement of foregone development, that it would require a couple of failed small projects to realise.
Absence of solid, top-notch design and analysis. In the world of business, that translates to thorough and detailed problem scoping and requirements analysis. By the way, I’m a mind reader; I can hear you thinking: “Hey Stefanos, that’s obvious”. Firstly, you can call me Stef; I think we reached this level of intimacy. Secondly, it’s not about how obvious it is but how well you perform in a software-agnostic problem solving approach.
A salesperson can’t solve a problem without focusing on his/her sale. Neither can a software developer, without focusing on his/her backend requirements, available software and different components at hand. The better the sales person the easier it is to detach from the problem and focus on the numbers. At the same time and in the same spirit as the salesperson, the deeper the technical knowledge of the developer, the harder it is to detach from technology and focus on the problem. This is critical, especially for cases where the technology the developer has in mind doesn’t solve a problem out-of-the-box, making the developer focusing his/her thoughts on the question ‘I wonder how software X can solve this issue?’
As in many things in life, the best way of approaching a problem of this nature lies in the middle. I had the luck to work with exceptional project managers which proved to be a friendly reminder of the university story. I fondly remember the times I’ve been told “Le, le [“no” in Maltese] forget about [software name] ”, which practically and mentally is not an easy thing to do, gets you out of your comfort zone and truly requires lots of practice. As a developer though, I have to admit that reaping the fruits of assuming different points of view is a reward on its own.
To sum up, problem solving comes way before software development. Also, the intricacies that businesses have, requires knowledge on many different domains; Domains which are way beyond the scoping of technology and are closely related to specific business operations and human behavior. I wouldn’t trust anyone who doesn’t follow a software-agnostic approach when analysing a problem. Working with iMovo made me realize what ‘knowing your client’ truly means. It means sketching ideas in front of the client, being humorous and asking every conceivable question, until you fully understand the client’s state. It means using playful analogies and real-life examples to comprehend the current situation and be on the same page; And most importantly, it means dropping all assumptions and having a million queries, like a curious mind would.
Forget about software, focus on understanding and empathising with the client.