The Art of Successful Doing is a simple yet effective approach to problem solving in the workplace. Because it is methodologically agnostic, this strategy can compliment Agile, Iterative, Waterfall or any other implementation process used at your place of business. The Art of Successful Doing consists of the following five steps which, when executed correctly, create a more effective and efficient work environment. These steps include:

Thinking

This first step seems obvious, yet it is the single most underutilized step in any problem solving exercise, especially with our young developers and architects. We are constantly asking our staff to solve problems; it's what we do! Clients are coming to us because they have problems they lack the skill, time or resources to solve. We are selling our services to them because we can solve those problems. How do we do effectively do that? Simple, we think the problem through. Here are some suggestions on how to maximize the effectiveness of this important first step:

• Consider the problem holistically. How does what you are doing effect the system in its entirety? See the forest.
• Ditch the computer. When thinking, a computer is honestly just a distraction. It is easy for an untrained mind to have a thought very early in the process and want to google it right away. This can take you on a wild tangent. Stay focused.
• Do have a notebook and a pen. Yes, it might sound old-fashioned to put pen to paper, but it works. Draw pictures, take notes, create user flows, process flows... use whatever aids you have available to make your abstract thoughts more concrete.
• Change your environment. Do not do this first round of thinking at your desk. Your desk is what I call a "DO" environment. It is where you DO things: write code, project manage, document, and other such tasks necessary to perform your job. It is too easy to get distracted by wanting to DO instead of wanting to THINK. Change your environment: go for a walk, sit outside, sit in a quiet room. Think the problem through to the very end. Get to the point where you believe you have a complete working solution, not a partial one.

Collaborating

Here is where you take the result of all that thinking and open it up to some good old- fashioned constructive criticism. You are kicking the tires of your ideas. Gather up some of your co-workers and present your solution to the problem you were tasked with solving. If you can't coherently talk about your solution, odds are you do not fully understand your solution. Here are things I find helpful during Collaboration:

• The first thing you present to them is the definition of the problem or challenge you have been tasked to solve. Make sure they fully understand why you are gathered together
• Take the discussion into a conference room, outside, into the hallway—keep it out of your DO environment. You don't want to get sidetracked by anything concrete such as a code block at this point. Keep the discussion on point. You are talking about your solution to a problem, not working on your collaborators' problems.
• Take notes.
• If needed, create visual aids. A picture paints a thousand words, just don't spend 10 hours doing it with a computer; a pen and paper or whiteboard sketch is good enough.
• Copy, photograph, or take quick notes of the results of the collaboration. You may have a brilliant mind but don't depend on it for remembering every detail of the meeting!

Re-thinking

Once the collaborative process is complete, take the feedback from your collaboration and incorporate it into your solution. Then, think the process through in its entirety to make sure it all still works. This is the part of re-thinking that people typically skip, which leads to ineffective problem solving. If a significant part of your solution has to be retooled based on the suggestions you were given, you might want to go through another collaborative process. You can cycle through re-thinking and collaborating a few times until you are comfortable with your solution. During this step, I recommend the following:

• Stay away from your "DO" space when re-thinking. By now, you know why.
• Don't be afraid to get a second opinion. If you feel the collaborators you selected didn't understand what you were trying to do, find others. If they do not understand as well, then you may have to look into a mirror and re-evaluate your solution. This is NOT a bad thing. It is a learning thing.

Documenting

Ah, the dreaded D word. Hey, simply put, it is important. This is where your flowcharts, user diagrams, and UML diagrams are brought to life. At this point you should not only be able to create a concise task list of all the steps needed to implement your solution, but you should also be able to give accurate timelines on implementing the tasks. But remember, documentation should be used in moderation. Do not document simply for the sake of documenting. Like everything, documentation should have a purpose and it should fit into your organization's development methodology. Consider the following during this step:

• If you can't successfully create tasks and time estimates for your solution, you exited the re-thinking phase to early. Grab your pen and paper, remove yourself from your "DO" space, and finish fleshing out your idea.
• You can safely create your documentation in your "DO" space. You have officially started doing.
• Before creating a piece of documentation, ask yourself if it is relevant to your solution. If not, explain to your management why you feel you should not be creating it. It may not be your call (business is not a democracy).

Finally! You now get to implement. You will probably notice you are creating things in record time. You are refactoring less. You are taking care of exceptions before they happen, instead of as an afterthought, which saves both time and money. Your actions are corroborated by your peers and justified through your documentation. In short, you're working smart and hard, and a business owner can't really ask for more than that.