Sooner or later, everyone will touch the stove

If you're a parent, you remember when your child was a toddler and you told them not to touch the stove because it was hot. Like any good parent, you probably told your toddler time and time again but found that at some point, the toddler touched the stove anyway. Why? Because he didn't know what hot was until he touched it. Once he touched it, I bet he never touched it again, but he had to touch it to learn that lesson. Try as you may, as a parent you can't prevent this from happening as it will eventually. The best you can do is try to minimize the pain caused by doing so.

I mention this as a metaphor for architects. Effective architects know that eventually, people will touch the stove. It's frustrating to watch, as you know what the outcome will be, but oftentimes, you simply can't prevent people from touching it because like the toddler, they don't know what hot is until they do. This is an interesting phenomenon, and in learning theory, it's referred to as Constructivsm. "Constructivism is a psychological theory of knowledge which argues that humans generate knowledge and meaning from their experiences (Wikipedia)." So, given that you have experience some of the people on the project you work on won't, they simply won't learn until they gain the experience. This is obviously the way you learned the lesson as well, as you'll learn others in the future. Rather than being frustrated by this phenomen, effective architects realize that it exists, and have strategies for minimizing it's impact to projects such as:

1. They ensure that themselves, and optimally, each member of the project team thoroughly understand the Hersey-Blanchard situational theory (Wikipedia article) which details not only the development process individuals go through when executing tasks, but also what leadership style (directing, coaching, supporting, or delegating) leaders should use based on what development level an individual is at for a particular task. See the post Effective architects are leaders for further information on leadership as well. A key element of this theory is that the leader must apply different leadership styles based on the development level of the person being led on a task by task basis, not on an individual basis. Every individual has tasks they've done 100 times and tasks they've never done, thus leading them the same way on every task is a formula for failure. Most leaders have a natural style that they tend to overuse, and therefore they must be very conscious of not using their "default" style incorrectly. This is very prevalent in the technology industry as leaders often work with very smart people and therefore assume that individuals are proficient at every task. They're not, and neither are you. Effective architects accurately identify an individual's development level on a particular task and lead them with the most appropriate style. Conversely, effective architects also know how to identify their development level on a given task and appropriately ask questions of their leaders if they're being led with the wrong style.
2. Understand that nobody, including yourself, will possess all the experiences necessary to make a project successful, but if each and every team member understands the previous theory, they can more effectively serve as leader and follower. Having said that, staffing projects with individuals that have as many experiences as possible required for the project will obviously minimize the amount of project impact spent on stove touching.
3. Ensure additional time exists in projects to account for the phenomenon. It's not if it will occur, it's when.
4. Force earlier and more frequent deliverables. When people don't know what they don't know, everything sounds easy but unfortunately, nothing ever is. By forcing earlier and more frequent deliverables, you also force people to learn the lessons faster and earlier than they will if their deliverables are later in a release cycle. This is even more important for tasks which have dependencies on other tasks, particularly if those tasks are on the project's critical path.

I had a friend who years ago said "You can't cheat someone up the learning curve." That is a wise statement indeed. In addition to what's listed above, I enourage you to add a comment on other strategies you've found to be successful in minimizing the amount of "stove touching" that occurs on projects.