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.

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.

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.

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.

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

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/

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.

'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.