Documented processes and innovation are not counter opposed to each other.

At the core of the figure eight feedback loop and other management methodologies such as Six Sigma, Agile development is the concept of iterations. The more times something is performed the more opportunity to find improvements and/or better a process or the end result of a process. It is Darwin concepts applied to humans, machines, and their interactions. For example; the first time you rode a bike, unless you were a child prodigy, you were not very good at it. But through practice (iteration) you eventually got real good. You can call it what you will… practice, iteration, evolution, improvement… the basic premise is something repeated will allow the person repeating it to get better over time. I’ve found the difference between practice and iteration/evolution to be knowledge of the end result. When riding a bike you want to be able to balance and not put your feet down. When shooting a basketball, you want that basketball to go through the hoop.

With IT you sometimes don’t have hard fast definitions of success. Or the definition changes over time. You may not know exactly what the end product should be until you’ve reach the end. This is one of the problems with long complex projects. The traditional method to develop software or install large complex systems has been a technique called waterfall. You document the requirements, create a project plan, and then execute over what may be years. At the end of this multi-year effort you achieve what you set out to do! Except in the meantime the world has changed. A lot happens within two years, in both IT and business. Disruptive technologies come along, or a recession could occur. In addition, the people involved with the project learn new techniques or change the way they think about something. All of these things in addition to complexity are what I believe causes IT projects fail.

So how do you avoid this cause of failure? Iteration and evolution. The old adage has never been truer. How do you eat an elephant? One bite at a time. The key is to break any effort into small chunks. Not only to allow you to claim success, but also to permit evolution. The creators of the Agile Manifesto knew this. The creators of Scrum believe in this. These concepts are not limited to software development. They can be applied to security and infrastructure as well. For example, incident response. Every time an associate leads or participates in responding to an incident they learn a few things and get better at it. Or risk management… Each iteration of risk management a company goes through to demonstrate to management that their risks are within the company’s tolerance for risk the team will add a few risks, implement and record a few new controls, or improve existing controls to better manage the risk. Business continuity is another example. Fake outage/disaster situations are staged to allow people to iterate the process before an actual business interruption event.

What makes these examples successful in their iterative methods? How do you create a process like these examples which provides feedback and the opportunity for innovation?

The methods to do this are simple but easy to overlook. They include instrumentation. If 5 widgets were produced in 1 hour last time, then possibly we can produce 6 widgets in 1 hour next time. However, you have to be tracking the number of widgets per hour to see this and create the opportunity to achieve 6. Another method to encourage these improvements is post issue reviews. Call them post mortems, review sessions, problem review or whatever. The intention is to capture things which were performed correctly as well as items performed incorrectly so this information can be used in future similar issues. IT systems can be used to dramatically reduce the overhead and improve the abilities of these efforts. A dashboard or a problem review application.

The objective of management is to create a culture of success and evolution by embracing and promoting these opportunities for iteration/practice. Experience has taught me that it’s up to the leaders to embrace this type of culture. It starts with allowing people to make mistakes by creating the safety nets which limit the risk of those mistakes. Processes like change management which allow the necessary parties to review a change before it’s implemented to identify and promote concerns before they occur. Back out plans add the safety of a defined method to return to normal. When combined in an effective way the recipe of iterative processes enables unavoidable IT success, business success, and associate success.

The best damn ship in the Navy demonstrates the final piece in this equation. The ability to receive feedback and utilize it to improve the process during the next iteration is a key concept in this book. The author, commander of the USS Benfold, goes to the people doing the work to determine how to improve his ship and then executes those recommendations. As a manager you must focus on providing the opportunity for improvement. Utilizing the information and turning it in to actions. This builds trust with your associates, enabling the improvements to occur and creating a culture of innovation and evolution.