Cisco’s 8-Step Problem-Solving Model

Cisco General Problem-Solving Model

When troubleshooting a problem a systematic approach works best because the opposite can result in wasted time and resources, and can sometimes make symptoms even worse.

The following is Cisco’s 8 Step Problem-Solving Model:

Step 1:  When analyzing a network problem, make a clear problem statement. You should define the problem in terms of a set of symptoms and potential causes.
To properly analyze the problem, identify the general symptoms and then ascertain what kinds of problems (causes) could result in these symptoms. For example, hosts might not be responding to service requests from clients (a symptom). Possible causes might include a misconfigured host, bad interface cards, or missing router configuration commands.

Step 2:  Gather the facts that you need to help isolate possible causes.
Ask questions of affected users, network administrators, managers, and other key people. Collect information from sources such as network management systems, protocol analyzer traces, output from router diagnostic commands, or software release notes.

Step 3:  Consider possible problems based on the facts that you gathered. Using the facts, you can eliminate some of the potential problems from your list.
Depending on the data, for example, you might be able to eliminate hardware as a problem so that you can focus on software problems. At every opportunity, try to narrow the number of potential problems so that you can create an efficient plan of action.

Step 4:  Create an action plan based on the remaining potential problems. Begin with the most likely problem, and devise a plan in which only one variable is manipulated. Changing only one variable at a time enables you to reproduce a given solution to a specific problem. If you alter more than one variable simultaneously, you might solve the problem, but identifying the specific change that eliminated the symptom becomes far more difficult and will not help you solve the same problem if it occurs in the future.

Step 5:  Implement the action plan, performing each step carefully while testing to see whether the symptom disappears.

Step 6:  Whenever you change a variable, be sure to gather results. Generally, you should use the same method of gathering facts that you used in Step 2 (that is, working with the key people affected, in conjunction with utilizing your diagnostic tools).

Step 7:  Analyze the results to determine whether the problem has been resolved. If it has, then the process is complete.

Step 8:  If the problem has not been resolved, you must create an action plan based on the next most likely problem in your list. Return to Step 4, change one variable at a time, and repeat the process until the problem is solved.



Software Development Methodologies

Much like various areas of study, or activities, there are methodologies in software development that a good developer should be familiar with. These methodologies describe a process or framework for planning, creating, testing, deploying, and maintaining an information system.

Methodologies I relate to: 

Agile Methodology

Agile promotes adaptive planning, evolutionary development, early delivery, continuous improvement and encourages rapid and flexible response to change.

Described in the Agile Manifesto as:

We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value:

Individuals and interactions over Processes and tools
Working software over Comprehensive documentation
Customer collaboration over Contract negotiation
Responding to change over Following a plan

That is, while there is value in the items on the right, we value the items on the left more.[1]

Scrum Methodology
A subset of Agile Methodology:

“Scrum emphasizes the idea of “empirical process control.” That is, Scrum uses the real-world progress of a project — not a best guess or uninformed forecast — to plan and schedule releases. In Scrum, projects are divided into succinct work cadences, known as sprints, which are typically one week, two weeks, or three weeks in duration. At the end of each sprint, stakeholders and team members meet to assess the progress of a project and plan its next steps. This allows a project’s direction to be adjusted or reoriented based on completed work, not speculation or predictions.” [2]



References: has a great reference that describes the principles, strengths, weaknesses, and use-cases for the Waterfall Model, Prototyping, Incremental, Spiral, and Rapid Application Development (RAD).

[1] Beck, Kent; et al. (2001). “Manifesto for Agile Software Development”. Agile Alliance.

[2] What’s Unique about Scrum?