As part of the Certified Essence-In-Use Practitioner training course an online forum is provided where course participants can share experiences, lessons, tips and get common questions answered. Below find a sampling of the questions and answers found on the forum.
Question 1: How are Essence checklists different from traditional checklists?
Answer: This is addressed in Part 1B of the course where numerous examples are provided. One particular example provided relates to the checklist, “Conflicting Requirements are identified and attended to” found in the Coherent state of the Requirements Alpha. The point that is made in the course related to this checklist (and many other checklists provided as examples in the course) is that Essence checklists are worded in a way that encourages conversation rather than a “check the box” mentality which too often happens with the way traditional checklists are developed. Essence checklists help teams focus on the goal of their practices, rather than on the steps of any given practice. Concrete examples from actual case studies where Essence was employed are provided in the course.
Question 2: My company uses the CMMI framework. So I would like to know more about how Essence compares to the CMMI. As I understand it, the purpose of the CMMI framework is to improve a team or an organization’s performance just like the Essence framework. So what what is the difference between these two frameworks?
Answer: One key difference is how the Essence framework is packaged and how it is intended to be used to improve a team’s performance. The CMMI framework is most often used by process improvement professionals or outside consultants to assess an organization’s current practices and identify needed improvements. This is done by looking at the organization’s projects from the outside. Essence, on the other hand, is intended to be used by practitioners directly on their project helping them make better decisions leading to timely performance improvements. Numerous examples and case studies of project personnel using Essence are provided in the course.
Question 3: What does “Stuck in the Demonstrable State too long” mean?
Answer: The discussion that refers to this occurs near the end of section 1B in the course. The Software System Alpha second state is Demonstrable, and the third state is Usable. The Demonstrable state means that key architectural characteristics and critical interfaces have been demonstrated and that the architecture has been accepted as fit-for-purpose.
Stuck in the Demonstrable state too long is what happens when we don’t accurately assess the real work to do to get from the Demonstrable state to the Usable state. A number of Essence practitioners have raised this problem they have observed. This situation often happens when teams are overly optimistic in how long it will take to get the work done to get to a Usable system. A usable system is one where the system functionality has been tested and the defect levels are acceptable. One of reasons teams get stuck in the Demonstrable state too long is due to a failure to adequately break the work down when estimating the work. As a result they fail to account for all the work that must be done to get to Usable. This, in turn, can lead to missed schedule commitments. In the training course participants learn common strategies in using Essence to isolate the root cause of this common situation and put timely improvements in place to help the team hit their commitments more consistently.
Question 4: Why isn’t there a risk alpha?
Answer: This question is answered in the course. However, if you really want a risk alpha you can add one. But the reason we didn’t add one was because the entire Essence model is a risk model. Many concrete examples are given in the course to demonstrate this fact.
Question 5: Tacit and explicit knowledge are referred to a number of times in the course. Is tacit knowledge something that can’t be written down?
Answer: No. Tacit knowledge actually could be written down, but isn’t. Tacit knowledge is knowledge that exists in an organization, but is communicated usually verbally or by observing the behavior of others in the organization. It is often part of the culture of the organization rather than specific explicitly defined information. A key point that is made in the course is that many organizations get into trouble by trying to make too much tacit knowledge explicit. All knowledge a practitioner needs to know is not best communicated through explicit documentation. In fact, when organizations go too far with explicitly defined information they can end up with practices that are not usable by human beings. This is because even if they have defined what to do in a specific situation the practitioners may not able to locate this information in the mass of documentation when they need it.
Question 6: Could you clarify what is meant in Part 2C of the course where you say, “if you can’t change the schedule, see if you can change the work.” Is this really about managing expectations?
Answer: Managing expectations is part of it, but what we are really getting at is looking at a different way to achieve the goal. As an example, when we keep our focus on the goal, or the intent of a requirement, rather than get too focused on the wording of the requirement, it may open up an innovative solution that you might not have thought about otherwise that actually requires less effort (work). As Henry Ford once said, “if I listened to my customers I would have invented faster horses.”