by John Jankowski, president and founder of JanCom Technologies
Driving along the highway, suddenly a sharp, loud noise startles an unsuspecting driver. As the vehicle begins to grow increasingly uncooperative, it becomes apparent to the driver they likely have a flat tire.
So what should the driver do next? When asked, most people would respond “Replace the tire.”
Though they would be right in the general sense, the response ignores quite a few critical steps in the process such as safely pulling the car over, turning off the engine or even determining whether a flat tire is indeed the problem.
Just like any critical path method (CPM) plan for a project, a sequence of tasks emerges, though simple and largely intuitive, that must be performed in a specific order, one right after the other, to ensure a successful result. So it is with many problems a project team is faced with on a daily basis. In essence, a critical path of steps must be taken to arrive at the proper solution to any given problem.
Any large scale IT project demands a very rigid, detailed means of solving problems. Designing a data center, for instance, requires a variety of experts including the project’s architect and consultants, the general contractor and subcontractors, and the client’s own technology experts. Each of these parties have a stake in designing and delivering a state-of-the-art data center, and each have their own perspective on how it should be done.
To focus on problem resolution, I have adapted an analytical approach I call the Critical Path Problem Solving (CPPS) method. Like CPM scheduling, this approach effectively frames the issue and presents a clear path to resolution to all of the stakeholders. More importantly, however, this method also helps to efficiently arrive at a consensus solution.
Assessing the problem
Though to many, identifying and defining the problem would be self-evident, it is also the most crucial step in the process that sets the foundation for everything that follows.
Returning to the example of a flat tire, there are a series of assessments that must be made to come to the proper solution. For instance, the driver needs to assess: what is the extent of the damage, can the problem be repaired on the road, is the vehicle in a safe enough location to attempt a roadside repair, is the spare tire in operable condition and does the driver have the necessary tools?
To answer any of these questions, the driver must get out and decipher what the vehicle’s issues really involve in order to assess the problem in more detail.
In many cases, when a specific issue or problem is inspected closely, more questions arise. For example, take the simple question: Can an end user install “x” number of servers in a particular row of cabinets? This question then yields a series of supporting questions such as is there adequate space, power or airflow? Although not exhaustive, these questions can help to produce an outline that can serve as a guide through the process.
Though the example above is very simple, a critical path of questions does emerge. Answering question A.1 provides an avenue to answer B.1 and C.1, and answers to B.2 and C.2 are simply mathematical extensions of B.1 and C.1 and so on. This is a good example how a very linear process of answering relevant questions begins to provide a very clear path to what is reality is a complex project with many interrelated components.
If we were to act quickly in an attempt to address the first problem that presented itself and ignored the tangential issues, it could take significantly more time and resources to install a series of servers within an existing data center. In essence, the critical path method of problem solving defines the problem not simply by evaluating a singular problem as much as it defines an entire situation that impacts the final solution.
Identifying questions and constraints
Once the problem is properly defined, it may be necessary to then define not only the questions that must be answered, but also what constraints or limitations will be faced while working to solve the problem. By identifying the questions that need to be answered, the direction of the critical path becomes clearer. There are a number of techniques that can help identify the questions that need to be answered within the problem solving process.
A common method utilized by many project managers is the program evaluation and review technique, better known as a PERT chart. Typically used in the context of scheduling, in our case, this technique lists out the questions that must be answered throughout the problem solving process.
Smaller bubbles connected by lines that are either “questions with dependencies” that are shown in sequence if one must be answered to progress to the next, or “stand alone questions” that diverge from the original path if they represent mutually exclusive questions, all of which lead to the eventual solution. This particular technique not only helps to organize any thoughts on the problem, it also provides a visual representation of the theory behind the critical path problem solving method.
No problem exists in a vacuum
There are always parameters that exist within a problem that not only affect the outcome, but also the way in which a problem can be solved. Two good examples that present themselves in most problems are money and time.
For instance, the unfortunate driver of that vehicle with a flat tire may prefer to have a mechanic in a tow truck help them with their problem, but they may not have the money to pay for the service or the time to wait for them to arrive. As a result, the driver of the vehicle is forced to fix the flat tire themselves. Conversely, if the driver has neither the skills nor the required tools, then waiting for a professional may well be the most efficient solution.
Identify dependencies and assumptions
In many cases, the answer to one question can provide the answer to others. To maximize the efficiency of the process, it is important to identify which questions in a given problem can help to answer others. This is an instance where using the PERT chart can really prove to be useful. By going through the exercise of thinking through the problem on paper and organizing the questions in the order they must be answered, it helps to identify exactly what the dependencies in a problem might be.
For the most part we are taught not to make assumptions. However, in context of solving very complex problems we do need to rely upon our expertise and experience. For instance, we know servers require space, power, cooling and connectivity. We also know it is necessary to verify these requirements before assuming a critical value. Though making the assumption is necessary, it is also important to verify each value as a small mistaken assumption will be a costly mistake in the context of a large deployment.
Check your work
Once the situation and questions are identified in previous steps, the critical path problem solving process truly begins to pay dividends. As defined earlier, the critical questions can be divided into “stand alone questions” and “questions with dependencies.” As many of the questions have been answered through establishing assumptions, dependencies and constraints, the questions that truly encompass the critical questions can be established and efforts can be focused.
Though it would be nice to assume the answers derived from the process of analysis are correct, this is certainly a time when assumptions should not be made. For instance, prior to a data center being turned over for the deployment of hardware, it is very important to test whether each supporting system has been properly installed, calibrated, and tested.
As new problems are discovered during this commissioning process we would be forced to go back through our process to identify what, specifically, the problem was. In the end, a very detailed and thorough problem solving process leads us to an equally thorough conclusion.
The true benefit to this process is not only the answers it renders, but also the fact that it arrives at the conclusion in a way that achieves a high level of agreement and consensus. In many ways, it is very similar to a mathematical proof. Not only is an answer established, but the work used to arrive at that answer is also very clear.
This is particularly useful when working with individuals who possesses very different and diverse areas of expertise, as we often do at JanCom. Because of their diverse base of knowledge and the perspective they are working from, the answers they arrive at tend to vary.
The critical path problem solving process helps to remove their varied perspective from the equation. By presenting the problem, the steps to solve it and the solution in a clear and concise way, we can achieve consensus to the more complex issues our clients face.
For over 15 years, John Jankowski has specialized in applying proven principals and processes resulting in the implementation of cost effective, manageable telecommunications systems and data center designs. With his extensive experience in telecommunications systems technologies as well as the design and construction processes, Mr. Jankowski has excelled in the programming, design, and implementation of mission critical telecommunications reliant facilities, cabling systems, data centers, and campus master plans.