4 Steps for Considering Project Context-EN

When you ask an analytical person a question, you will rarely get an answer. Instead, their response will likely be in the form of another question. Why is this? Answers depend on context. Context refers to the framework of a situation or event. Even a simple conversation requires context to be understood. Consider this dialogue:

Friend: “Would you like to go see a movie?”
Me: “When are you going?”
Friend: “Friday”
Me: “What movie?”
Friend: “The new Star Wars.”
Me: “That sounds great, I want to see that! What time?
Friend: “Late. Pick you up at 8?”
Me: “Perfect.”

All of those questions refer to the context. Once the context is understood, there is eventually enough information to make a decision. This concept is easily applied in everyday life. However, it can seem uncommon in our work life! Teams struggle with this concept and often make important decisions without first considering the context.

Why is context an elusive concept? I have pondered this and concluded that with the fast-paced delivery expectations common in today’s development environment, it seems there is no time for the analysis steps. Teams trust the business knows what they need and rush ahead filling the order. It’s a common mistake, one I am sure every business analyst has made at least once! When we are close to a business area, it’s easier to skip analyzing project context. Our internal dialogue can justify forging ahead. Thinking, “I worked on something similar a few months ago. I know the players. I know this problem,” or “I trust this business area. They know what’s involved,” is dangerous! Anytime this dialogue starts to play in your mind, do four things: Stop, Organize, Think and Confirm.

For a business analyst, any assignment should involve a quest for project context. Context is king and rules over everything. No matter how familiar you may be with a project, business area, or problem, do not skip understanding context. The analyst needs to understand the context, and every stakeholder involved needs to understand the context. A business analyst that knows this, practices this, and teaches their teams this is a valued leader! I offer these four steps to help develop this habit.

Stop.

When an opportunity is presented that needs your talent, the first thing to do is stop. Stop and ask yourself, “Do I understand the context I am working in? Do I understand the people, the systems, the data, the processes, the timelines, and the regulations involved?” Make a list of what you do know and what you need to know. Also, list out your assumptions that you think are true. Read everything you can find that relates to what you’ve been asked to do. Put your document analysis skills to use! Search the kingdom far and wide for information. Start scouring for information are:

• The project charter, idea document, or scope document (if you have).
• Ask other analysts what they know about the subject.
• Reach out to your network and see who else has information you can learn from to help you understand the context.

Don’t rush forward thinking you know the project context without stopping and asking more questions. This quest for information may seem frustrating, and people may become impatient with your questions. Don’t let this stop you. Be vigilant, and don’t give up the discovery. To help settle the frustration, do as much research as you can on your own, then ask questions to confirm.

Download our free Ask the Right Questions Checklist for a listing of questions to get your project started.

Focus on 10-minute conversations to validate your understanding rather than 30 minutes of conversation to discover what you could have found out on your own. Business analysts are part blood hound detective; use those investigative skills as you are discovering context. Once you have elicited the information you need,  organize your discovery.

Organize.

There are many ways to organize context. I find the best way to organize context is using a context data flow diagram. This is a visual scope technique, which is included in the BABOK® as part of technique 10.13. This model depicts the sources and destinations of data as external agents with the data flows in and out of your area of study (shown as the Data Process in this diagram). The Data Process is the project you are working on. At a high level, this diagram maps the context for your project in terms of processes, data, people, and systems involved. I recommend using this technique as the starting point for any effort to organize your project context.

Teams appreciate this diagram’s simple depiction of complex projects. It allows for a high-level understanding of what is involved in an effort, and it makes the question of, “What am I missing?” easier to answer. It clearly represents what you will be eliciting requirements for, and if something is missing, this is the point in time you want to see it. Business rules are implied in this diagram as well. Going through this exercise will help to capture rules that might be otherwise missed.

For a comprehensive instruction on building and using this diagram, see our Scoping Your Area of Analysis class.

With practice, this is a quick diagram to complete, and it helps when asking more specific questions to capture context. Soon teams will no longer be frustrated with the questions up front; they will expect this work and appreciate the picture to keep them on track with scope! In addition to using this technique, include a stakeholder list to ensure you have the right people to confirm results. Be sure to ask yourself, “Who else needs to understand this context?”

Think.

Now it’s time to think about the project context from different perspectives. Use scenarios to consider different stakeholder viewpoints. For example:

• As a customer, how do I interact with the business? Is there any system, process, data or business rule I have neglected to consider in my context?
• As a customer service representative, what is my interaction with my customers? Are there any other departments I interact with or need to notify as a result of my interactions?

Continue this line of questioning with all stakeholders to help think through what you know and what you might need to consider. Think about the additional pieces of context that are necessary, e.g., timing to find a solution, regulation, external vendors, etc. This thinking task is not for diving into the details of the information, but it’s done to determine possible features or tasks that should be in your business analysis plan. Be careful not to go too deep since it can be particularly difficult for analytical minds that want to track down the details right away! Remember to stop your thinking at enough information to make a placeholder. Stop your business partners from diving into the details as well. It becomes easier with practice. This habit saves teams! Get a good foundation before moving forward. Update your diagram to include the additional pieces from your thinking.

Confirm.

After you have captured the context in a diagram and considered different perspectives, confirm your understanding with all the stakeholders you have identified. Through confirmation, your understanding becomes shared understanding. Have a collaborative discussion to involve them in owning the project context.

Confirm your assumptions as well as the sources and destinations of data and data flows. Confirm the timing expectation, regulatory impacts, etc. Teams that are familiar with the diagram can easily confirm understanding. For those that are new to it, they will appreciate the simplicity for understanding project context. Soon, stakeholders will expect this context picture in addition to other context attributes not shown in the diagram.

Most of the time, something will change as a result of these conversations. Once someone else on the team offers updates to the diagram, it becomes ours and is no longer yours. This is a powerful position for a team to be in. With a shared understanding of the project context, the team is ready to move forward on the same foundation. Confirmation is an important step in the process to create the buy-in necessary for any change success. Once that is understood, move into the elicitation for the detailed requirements and then to the design phase and explore alternatives.

Repeat after me: Context is king and rules over the rest of the solution!

Thank you,

Heather