Enjoy this snippet from Just Do THIS – Chapter 2: Understand
Understanding the Understand Phase
There is a bit of irony in the order of my methodology in which people are exposed, because it tends to happen in reverse. Most start in a helping, monitoring, or administrative capacity—the Maintain phase is where their job is focused. Engineers, on the other hand, tend to be focused on the Change phase for their daily tasks. Architects and Consultants are typically tasked with the Plan phase and may also need to be the driving force in the Understand phase. So, your exposure to a proper methodology happens naturally, but in reverse.
Much like a soldier following orders, however, if you do not have a good grasp of the process, you are more likely to fail. This concept is talked about in the excellent book Extreme Ownership (by Jocko Willink and Leif Babin—see https://it.justdothis.net/bl#1). Teams that do not understand the mission cannot take ownership of it. Therefore, I encourage you to pause where you are in your career and consider what is happening outside of your area of focus. If you are in a role that is focused on either of these first three phases of the methodology, I encourage you to consider other roles that will fulfill the vision and support it. Are you creating systems that can actually be maintained? Can your vision be maintained? Or are you taking enough actions to meet long-term needs so that another team won’t be “stuck with the bill,” so to speak? In other words, I want you to begin with the end in mind. So, with the vision of having a well-maintained and well-designed system or result, the first phase in our methodology approach is UNDERSTAND.
Understand, sometimes called Assess in the IT world, is the process of observing what the current needs, configurations, systems, and risks are, and reporting them in a standardized way that leads to the next step of the process: Plan. The result should always be a conveyance of the fact that you understand and can describe something properly, which can take many forms, depending on the overall initiative and what deliverables are desired. Nonetheless, in all cases, Understand focuses on what is needed. In some cases, the Understand phase makes suggestions on how to improve or focus.
For example, say a company would like to do an overall Infrastructure Assessment to identify any deviations from leading practices and any risks that exist in the environment. The deliverables for this type of project would consist of a focused presentation to upper management and a detailed document describing the findings and suggested courses of action.
An important aspect of this kind of undertaking is fully understanding your audience. In considering our audience, we must think outside of a single scope of maybe a group of engineers or Information Technology staff. We must make recommendations that address the company’s interests as a whole. This means being intentional about the tasks and data presented (and not presented), as well as being consistent in your message. If you are primarily going to be addressing a technical audience, keeping the findings as straightforward as possible is best. If you will be addressing a primarily management-focused audience, you will want to shift your content to explain things in a very conversational way (which we will discuss soon, in another chapter). In either case, it is of crucial importance to make sure you get the same message across where it matters most.
Tools and scripts are quite often used during assessments. However, it is very important that you understand that not every assessment will have a tool to make things easy. A lot of the time, you will be required to get into the systems and manually document their configurations. Quite often, this will mean having a good idea of the overall project scope.
In the event that you are assessing as a precursor to a design, you will be gathering information but may not have an existing design to reference. In those kinds of projects, your goal is to define the success criteria and requirements that will feed into the design in the Plan phase.
In the next portion of the book, we build out a standardized structure of how to document observations made in the Understand phase. The document structure introduced in the Understand phase will be followed, more or less, for future documents, so it will be the largest topic discussed herein.