Maintaining a Knowledge Backlog

http://businessanalysisexperts.com/agile-analysis-maintaining-an-agile-knowledgebacklog/ At the beginning of any project, the one wearing the BA hat runs into a little thing called the Uncertainty Principle. If you happen to be knowledgeable about quantum physics, this may sound familiar to you, but you may be surprised about our take on this. For normal people (i.e., us non-quantum-physicists), our definition of the uncertainty principle might even be understandable.

Changing how your organization works is a very high-risk activity; it is almost as risky as not changing. As the person in charge of guiding the organization, you are responsible for deciding what changes are worth the risk. OurStrategic Business Analysis Workshops (SBAW) use the power of team facilitation, synergy . . . Read More We usually do not recognize it when we start something new, but uncertainty is generally the only thing we have in abundance. The process of doing a project is actually one of reducing uncertainty. Not to eliminate it, unfortunately, because that is impossible; there will always be some uncertainty. (According to a German saying, Theory is when you know everything and nothing works. Reality is when everything works and you do not know why!) There will always be some uncertainty, some of which you are aware and some you do not even know exists. The real problem is the pace at which a project reduces uncertainty. A project typically starts for you, the one wearing the BA hat, when your manager tells you that you are on the project. At that time, you may have no idea what the project is supposed to deliver. When you ask your manager, you soon discover that you are not the only one who knows so little about it. The first thing you need to know is who the Project Sponsor is (aka the one who has the authority and budget to fund the project). That individual generally has a very good idea of what he/she wants the project to achieve but in your initial interview, you recognize three things: 1. 2. 3. The Project Sponsors idea is a vision of the final outcome of the project. The idea is big and no one (including the Project Sponsor) really knows how big. You have a lot more questions after the interview than before.

Welcome to the Uncertainty Principle. Once you identify who the players on the project are and start to interview them, it seems like every answer you get generates new (albeit more detailed) questions. Your uncertainty is increasing. Over time, you interview more and more stakeholders and the

Knowledge Backlog

Page 1 of 5

answers you get start to make more sense in the context of the project based on your growing knowledge base. At this time, you start to get a good feeling because your uncertainty is decreasing rapidly. You start to get the feeling that you might actually pull this thing off. In your euphoria, however, beware of analysis paralysis. You can avoid analysis paralysis with a simple concept that says that all knowledge about the project falls into one of four basic categories. First off, there is what you know you know about the project, otherwise known as the Facts.

For high-priority and time-critical changes, our Requirements Discovery and Elaboration Workshops (RDEW) help you analyze your situation and define the most acceptable solution in a hurry. Whether you use an Agile or traditional (i.e., Waterfall or Iterative) System Development Methodology (SDM), RDEW sessions apply tried and proven techniques to . . . Read More Of course, we realize that there are different levels of facts and differing degrees of certainty, but for the sake of simplicity, we will stick with our original title. The next category represents what you know you do not know. What do you call that? Well, we call it Questions. When I formulate a question, I am expressing something that I know I do not know. Guess what; if someone would give me an answer to my question, I would have a new fact. Of course, that assumes that the answer was from whoever has the knowledge and the authority (either alone is not enough) to answer the question. That leaves us with the lower half of our box. First off, we have things that we do not know that we do know. Now, how can you not know that you know something? Well, there are things you have done in the past on other projects or in past lives that will help you on your current project; you just have not identified them yet. We call that category Experience. There is something else in this quadrant, something we call Assumptions. What happens if you cannot find anyone who has the authority and the knowledge to answer your questions? Maybe because they are unavailable for your project or maybe because nobody has ever tried to do what you are trying to do (at least within your organization). At some point, either someone will answer every open question or someone will make an assumption and act upon it. That is life, and we are not saying there is anything wrong with it per se. We are simply pointing out we need to recognize when we are making an assumption. If it is necessary, make the most likely assumption based on your experience and document it. Undocumented assumptions are project killers. What you do not know you do not know (or, as some prefer to call it, the unknown unknowns) is what we call Fate. Fate exists on every project, even the best run. There will always be things you do not know you do not know, so you have no choice but to live with it. It is, however, the number of factors that fall into this category that will ultimately determine the success or failure of your project.

Knowledge Backlog

Page 2 of 5

The challenge now has become, how can you manage what you know you know and keep track of what you know you dont know while using what you dont know you do know to combat what you dont know you dont know? (If you can say that one three times without stuttering, you might be a business analyst!) Enter the Fate File. The Fate File is one of the simplest forms of documentation for a project, but it just may be the most important document you create to avoid analysis paralysis. It starts life as a list of what you know you do not know about a project. Express your questions in a manner that any answer you get becomes a new fact. Date each item to keep track of when you recognized you needed to know something and did not. Who (by name or by role/job title) amongst your stakeholders has the knowledge and the authority to answer the question? This is not cast in concrete. You just think at this time that this person would be your most likely target for getting the right answer. Once you get an answer, document their response in the Answer column. In case you do not get an answer in time, document your assumed answer. Just make sure to document that this is an assumption and tell the world (or at least anyone who you think should have given you the answer) about your assumed answer. Consider a simple email that says, We need to know this and since we have not been able to get a definitive answer to date, we are going to work under the assumption that . . . The final Date column is to document when you got the answer (or made the assumption). Now, if you had a Fate File for your project, you could perform magic tricks. For example, you could sort your file on the Answer column and count how many questions you had answered and how many were still open. The ratio of the two shows you where you are on the uncertainty curve we talked about earlier. You could also sort the file on the Who column to determine who you should be interviewing next (maybe the person for whom you have the most open questions? Or not). If you browsed the Fate File and compared the date you identified the question with the date you got a response, it might even tell you something about the priority of the project from the perspective of the Who column. Finally, if someone new comes on to the project, it could just be invaluable as a tool for getting them up to speed quickly and without you spending time telling them everything that is in the file. Like I said, magic tricks.

Date

Questions

Who

Answer

Date

Knowledge Backlog

Page 3 of 5

Knowledge Backlog

Page 4 of 5

Knowledge Backlog

Page 5 of 5