Wednesday, June 17, 2009

Solving problems or creating solutions?

question markAs engineers we spend a lot of time solving problems. A customer has a problem and it needs to be fixed. The electronic boards you have just designed are not working and the problem needs to be fixed.

Problem solving has a certain mindset. A problem is narrowly defined and the focus is solving that one problem as quickly as possible. An analytical mindset is adopted and there is an intense search for cause and effect.

The are many challenges with adopting a problem solving mindset. Problem solving can be misguided and focussed on finding the cause rather than obtaining the desired result – has the desired solution been correctly identified before starting? Continuously solving problems can be draining. All you ever see in your product or service are the problems with it, particularly if you are isolated from the happy customers.

The flip side of engineering is that we also get the opportunity to create solutions. Creating solutions is about seeing the bigger picture and understanding the idea or problem within the context of a larger system. This requires more lateral thinking and gathering information from a far wider variety of sources then when we are "solving problems."

Solution creating can be too loosely defined and only slowly drift towards the eventual goal. It is also easy to be continuously finding new solutions (adding features) which are not even needed to achieve the actual goal. It is important to stay focussed on creating happy customers.

Each mindset carries its own set of paradigms so when we adopt a certain approach we close our minds to certain solutions and possibilities. Knowing that each way of thinking opens up different possibilities means that we switch between the two as a tool to help us solve problems and create solutions in a quicker and more comprehensive way.

How would your approach to your current challenge change if you switched mindsets? Adopting a different approach may even help you to find more satisfaction in your work.

Image courtesy of Ethan Lofton, published under a creative commons license.


8 comments:

Pieter said...

I believe that being an effective creator of solutions is a difficult skill to acquire. In my line of work where my responsibilities include business/requirements analysis and solution crafting, I've seen how counterintuitive it is for people. It seems like we tend to jump to a particular solution, before we've given the requirement some thought. Even worse, I frequently receive so called requirements that are already solutions. I find this particularly frustrating, but at the same time it gives me the chance to explore. It is my opinion that in order to create an effective solution, one first needs to abstract the requirement, because we are pattern seeking beings. It is necessary (and effective) to map problems to known domains (i.e. generalise the problem) and then map it to a customised solution (i.e. specialisation) and then implement it. This often becomes an iterative process. It is this abstraction step that I think most people find difficult.

As an architect, the "bigger picture" is of the utmost importance. In fact, referring to the "bigger picture" is for me kind of an elite term, so it might be more appropriate to refer to the "common picture". A solution for me is about a common understanding among al parties that effectively solves a requirement and that can be implemented.

In the end, I think there are various levels at which different people need to operate to effectively create and implement a solution: You can't let the dreamer worry about the technical challenges and you don't expect the builder to be creative.

The other issue regarding the crafting of effective solutions is scope creap. It is true that no product is static, but it is important too define stages and goals. It is necessary to fix requirements for a particular release cycle, before adopting new requirements. But no only product owners are guilty of this. It is common for e.g. developers to add features that they thought are nice, but never needed. Scope creap is probably the single biggest problem in software design.

Duncan Drennan said...

Scope creep is certainly an issue in hardware design as well, but what tends to reduce it (vs. software) is that there is often a more tangible cost associated with it.

I am a firm believer in hammering out the details early on and then sticking to them until you can get actual feedback on the product. What I have seen quite a few times is scope creep very late in the design which sets everything back significantly.

Thanks for reading, and thanks for your comments.

Fluxor said...

For most of the projects I've worked on (analog semiconductor circuits), having nailed down specs at the beginning is nearly impossible. The company is anticipating what the customer might want or where the standards may go or what the competition is doing. They also want to get things going as soon as possible to be first in the market. Thus, most project start with a fuzzy set of requirements that get refined over time. Unfortunately, rarely is it ever well documented.

BTW, well thought out post. I quit enjoyed it.

Matthew Brown said...

Going off of what Fluxor said, I try to take a different approach. I try to nail things down to as much as possible prior to the start of a project, at least to the extent that the customer's expectations have been managed properly. However, as an engineer I've noticed with my own projects that I don't always impose the same amount of discipline on myself.

Good post. Keep them coming.

kumar said...

The company is anticipating what the customer might want or where the standards may go or what the competition is doing. They also want to get things going as soon as possible to be first in the market

Ali Hassan said...

thanks for this great blog.

please can you visit my blog " free engineering school" for advise and comment?

my blog at :
http://alihassanelashmawy.blogspot.com/

Dan engineer said...

Different approach definitely works every time for me, when a project bumps into a dead end. Sometimes, it's customers expectations that are too high that creates atmosphere of underdoing. Keeping your team members focused on the project - that's the main thing people usually fail to accomplish.

Jamie Engineer said...

'look for the cause rather than obtaining the desired result'. For me this mindset works quite well. Finding the cause ahead of searching for the desired result can sometimes be a very big time saver.

Post a Comment

If you are leaving a comment with your Name and URL then make sure you put http:// in front of your URL for a correct link. You can use some HTML tags such as <a>, <b> and <i> in your comment. Thanks for your message - I appreciate it :)

Note: only a member of this blog may post a comment.