Author: Paula Bell

Understanding the Whole and Not Just the Parts

Written by Paula Bell on November 1, 2011. Posted in Articles. 1 Comment on Understanding the Whole and Not Just the Parts

I was very intrigued with this concept when I read it in the Business Analysis Body of Knowledge (BABOK). This concept is defined in the Underlying Competencies (chapter 8) of the BABOK. This concept is so powerful and if used more in organizations, it can produce remarkable events; however, I have found that Systems Thinking can only be utilized to its fullest potential if the culture of the organization allows for it. However, as business analysts this is a concept that we should have in our arsenal of tools as this concept can help to clearly identify the root cause of problems that need to be solved.

What is Systems Thinking?

According to the BABOK, Systems Thinking is defined as “Systems theory and Systems Thinking suggest that the system as a whole will have properties, behaviors and characteristics that emerge from the interaction of the components of the system, and which are not predictable from an understanding of the components alone. In the context of systems theory, the term ‘system’ is much broader than an IT system — it also includes the people involved, the interactions between them, the external forces affecting their behavior, and all other relevant elements and factors.” Most of the times, as business analysts we think of systems as an IT system as we are typically writing requirements either to build a new system or enhance/alter an existing system. A system consists of interaction, interrelated and interdependent parts, I remember these are the three “I’s” that form a complex unified whole. To break that down more granularly is that a system consists of inputs into the system, resources and processes within the system, and outputs produced from the system. These are you interacting, interrelated and interdepending parts (refer to Figure 1 below).

Please click the image to view it’s full size.

Systems Thinking is not just about focusing on the parts of a system but rather focusing on the complex unified whole. This way of thinking is taking business analysts to the next level because it’s not just about meeting deadlines to produce a result but rather how does that result you are producing fit into the organization as a whole?

Every system has a purpose, consists of parts that are arranged a certain way, can effectively react to change and for a system to be effective it must be stable. Systems Thinking is not just focusing on one part of the system but the entire system to ensure that it is a well-oiled machine. The danger of focusing on just one part of the system is that there is a potential of negatively impacting other parts of the system though the part being focused on is being improved. For example, in many of the industries I have worked in there are a lot of systems that have Band-Aids or some may call wraparound systems. Essentially what has happened is something has changed in the organization and in order to accommodate that change a temporary system is built. The system built solves the problem at hand as a temporary solution; however, this solution becomes permanent because it’s doing its job at hand. Therefore, no one goes back to the temporary solution to make the necessary changes to make it a permanent solution. After a while you end up with clusters of temporary systems to solve a permanent solution, which really doesn’t solve the problem at all. Then you sit back and wonder, “How did we get to this?” Well you got to it because no one thought about the consequences of not changing that temporary solution, the only thought was, we have a need now and we have to solve for it now. Systems Thinking is getting out of that way of thinking.

Systems Thinking allows organizations to:

understand the strategic vision of the organization as a whole
understand how the organization works and fits together as a whole
understand the problems in the systems and understand the consequences of how solutions to those problems can affect the whole system.

Systems Thinking is a wonderful way to understand the root cause of the problem. For example, if there is a town that continually has fire outbreaks, just putting out the fires each time is not solving the root cause of why fires break out. The root cause could be that the town has no fire codes or the houses may not be equipped with smoke detectors. Putting out the fire is just a temporary solution but let’s say the town implements fire codes; this could potentially eliminate the fire breakouts. This is the beauty of Systems Thinking. It allows business analysts to determine the root cause of the problem and nip the problem at the root opposed to building out temporary solutions.

How can we apply this concept?

Let’s take the example of the fire outbreaks:

First, identify the event/problem. The event in this situation is the fire outbreak in the towns.
Second, identify the patterns. By asking a series of questions, patterns can be determined. For example, “What similarities in the house are causing the fires?” “What sections of the town are the fires breaking out?”
Third, once the problems and patterns have been identified, then determine what solution can rid of the problem.

Sounds pretty simple but it’s amazing how often this is not done.

This is a powerful tool for business analysts to help implement better solutions. Start thinking about the projects you are working on and ask yourself:

Why are we doing this project?
How does this project fit into the organization’s strategic goals and long-term vision?
How will the solution I recommend or help build meet those strategic goals or long-term vision?
Am I solving for a temporary need and implementing a temporary solution; if so, what can I do as a business analyst to ensure that temporary solution doesn’t turn into a long-term solution? Or better yet, why are we doing a short-term solution for a long-term goal? What’s driving that need?

I do have to add that sometimes the answers to these questions are out of our control due to company culture but it never hurts to ask if your culture allows for that. In the long run you will be thanked.

Even if you have doing business analysis for years, it’s always good to step back and look at the projects you are working on and determine if the solution is really solving the root cause of the problem or just simply putting a Band-Aid to get past an immediate need. Even if you have to put on a Band-Aid for an immediate need it’s good to go back and ensure that Band-Aid has been removed and the long-term solution is implemented.

Let’s step our thinking up to the next level!

Don’t forget to leave your comments below!

Paula Bell is a Business Analyst, mentor and coach known for consistently producing exceptional work, providing guidance to aspiring business analysts (including those that just want to sharpen their skills), as well as providing creative and strategic ways to build relationships for successful projects. With 14 years in project roles to include business analyst, requirements manager, technical writer, project manager, developer, test lead and implementation lead, Paula has experience in a variety of industries including media, courts, carpet manufacturing, banking and mortgage. Paula has had the opportunity to speak on a variety of topics to include business analysis, project management, relationship building, diversity and software methodology.

History Repeats Itself, But It Doesn’t Have To!

Written by Paula Bell on July 25, 2011. Posted in Articles. 1 Comment on History Repeats Itself, But It Doesn’t Have To!

Why does it take an ‘Act of Congress’ for some organizations to realize that what they are doing is not working? I have been in many industries (media, manufacturing, financial and the judicial system) and no matter what industry I’ve been in, I’ve seen some of the same themes. I’ve come to realize that common sense is not that common and some organizations would prefer, for whatever reason, to continue to do things the same way even though it has been proven that the current way DOES NOT work. So you may ask, “What are some of the common themes that I’ve seen?” Well, I’m here to tell you and I’m sure some of you are experiencing, or have experienced, the same thing. I am not pinpointing any industry over another.

No time for planning – What I have witnessed is that someone comes up with a great project idea; however, no one wants to spend the time needed to effectively plan the initiative and truly understand what the initiative is about. There is an expectation that the idea will go from an idea to a reality in an unrealistic timeline. Someone of influence in the organization has committed to an objective without consulting those that will have to bring this idea to fruition. Then when the project team advises that the timeline is unrealistic as they start to look more into what is being asked for, they are told to make it happen because the promise has already been made. In a lot of these cases, the amount of resources needed to complete the project effectively is under estimated, if even committed, and this means burnout for those few who will have to work on the project.
Choosing solutions before understanding the business needs – Let’s take this one step further. Most organizations have vendors that they have built relationships with over the years. What I have found is that “someone of influence” in the organization has a vested interest in maintaining a certain vendor relationship. This maintenance could be because they are the more cost-effective vendor (this doesn’t mean they have delivered projects successfully by any means), personal relationships that have been established over the years (you rub my back and I’ll rub yours sort of thing) or other reasons. This particular individual has been sold on an idea regarding some additional functionality that the organization can possibly use, conversations occur and the vendor makes commitments without truly understanding what is needed. This “someone of influence” sells how this particular vendor can solve all of the needs of the organization, and since this someone of influence has credibility, they are told to go forward with their suggestion. This project is then funneled down to the project team, who finds out the exact depth of what is being asked of the solution, people start having heart attacks, aneurisms and heart burn because it is determined the system won’t meet the business need. So instead of the requirements driving the solution, the solution is driving the requirements.
Politics – Politics to me equals personal agendas and ulterior motives. I have not come across an industry in which I worked yet that didn’t have some level of politics. We have projects that evolve and people have their stake in the projects, which is to be expected, and that is why we have stakeholders. However, that doesn’t mean bring in your own personal agendas or ulterior motives to bring unnecessary negative energy to the project. Half the time politics is a waste of time. Projects are hard enough so why complicate it with politics? It’s a waste of energy and that energy could be utilized positively to build better solutions opposed to fighting among ourselves and everyone getting so frustrated or focused on the politics that work can’t get done. There are realistic reasons to have hard conversations to build better solutions, but I’ve actually been in elicitation sessions where I have individuals intentionally throwing wrenches into the project process because they may feel they are not getting their way. I’ve seen people trying to save their job so they make things more complicated on the project than it really needs to be. I’ve also seen the business; project team and technology teams point fingers to ensure neither look bad in front of the sponsors. All of this is a waste of energy because no one knows the future, and believe it or not, maybe the way you present yourself in these meetings may save your job if you have a fear of losing it.
Lack of honesty and integrity – People are not stupid. If the project that is being executed is going to eliminate jobs, people tend to figure that out during the requirements elicitation phase. I have had SMEs admit to me that based on the requirements being gathered, they can tell that the system will replace their job. I’m by no means saying you shouldn’t be sensitive to the situation and handle the business partners with care, but I have been[G1] parts of organizations that just flat out lie to people to ensure they get what is needed for project success (because they have to look good of course) and then these same individuals are kicked to the curb as if they weren’t even valued when the project ends. This also puts those who are part of the project team in a bad and uncomfortable position.
Lack of learning – Every organization that I have been a part of has conducted a ‘lessons learned’ session after the entire project is complete or during project phases along the way. I am convinced that some of these organizations only conduct these to mark a task complete on the project schedule because nothing has changed from the way projects are run going forward.

Despite all of this, I do believe there is still hope and that business analysts are important to this hope. There are some steps we can take to mitigate what is listed above:

Plan upfront – Planning upfront is CRUCIAL to project success. This doesn’t matter if you are using a plan-driven approach (i.e., waterfall) or change-driven approach (i.e., agile); regardless, there needs to be some level of planning. Spend the time upfront to really understand what is needed opposed to doing little work and then realizing two months in that instead of a bread box of a project you have a submarine of a project. Utilize the business analysts in the organization to help with planning upfront. Good business analysts are equipped to do Enterprise Analysis (higher-level statements of the goals, objectives or needs of the enterprise) in addition to Requirements Analysis (statements of the needs of a particular stakeholder or class of stakeholders). Engage the business analyst upfront to have some of those critical conversations opposed to just filling out a template with a high-level scope that is so broad that almost anything can go into it producing your submarine opposed to your bread box.
Don’t jump the gun –- Opposed to choosing solutions due to past relationships or other reasons, again, leverage the business analyst to understand the true business need so the needs drive the solution opposed to the solution driving the requirements, which in turn limits the true needs of the business. I would strongly recommend that leaders of the organization go out onto the floor and meet with those that actually do the work to find out the true pain points they encounter day in and day out. Just because you are a leader, don’t get too disengaged from what is going on within your organization. I know this can be as challenging as schedules, but there is value in staying connected with those who are actually doing the work. If anyone understands the pain of the system or process, it’s the one using the actual system or process, so don’t take that for granted. This is also a great opportunity to leverage the business analyst as well. Maybe have the business analyst do some job shadowing as part of their planning to understand truly what the needs are. This will help leaders make more informed decisions.
Channel positive energy – Let’s take energy away from politics and channel that energy to producing better solutions. There are crucial conversations that may need to take place and hard conversations to be had, but those conversations should occur for the benefit of the project not because of someone’s ulterior motives and personal agendas. When a project is created, the end goal of everyone on the project team should be project success.
Don’t compromise – Character is the very fabric of who we are, and if we lose our character because of dishonesty or lack of integrity then how are we going to gain that credibility needed to become a person of influence, if you are not one yet, or a credible leader to those you lead? Be sensitive to projects that are eliminating jobs as you are impacting someone’s life, but don’t lose your credibility in the process. Fellow business analysts don’t fall into the trap of having to lie to do your job. In all things, be honest and kind. Don’t compromise your character to get your job done because sometimes we are put in that position. Once you compromise that you are compromising the business analysis profession based on perception.[G2]
Learn from your past – If you are going to do lessons learned then truly learn from them. If anything, to my fellow business analysts, learn what went well and what didn’t go well in requirements gathering and use that as your thermometer for other projects. Everyone on the project team should learn from the past, but if no one else does, business analysts I really encourage you to learn from your mistakes because this makes you a stronger business analyst.

With the themes above, someone of influence is driving the actual theme whether positive or negative. As business analysts, it is imperative we become someone of influence in our organization. This is not going to happen without credibility and proven success on projects, and I will be honest, even with this, sometimes it’s hard to influence due to company structure. However, if you take time to learn your organization’s culture, learn the key players in your organization, establish relationships where you can to start gaining credibility, you will become that someone of influence in the organization. We need more business analysts to be leaders and people of influence in the organization because we have the skill set to promote organizational cultural shifts that will make the organization stronger and better. Changing an organization’s culture can be extremely difficult; look at organizations that had to change from a waterfall methodology to an iterative methodology and the pain that came with that.

And for those business analysts that are consultants/contractors, you have a very important role as well because you can help organizations reach their optimal potential. Though you may be there for a temporary amount of time, you can still have massive impact on the organization as a whole.

Don’t let history repeat itself in your organization because it doesn’t have to. As business analysts, we have come too far to go backwards now. Keep pushing forward and help organizations realize the benefits business analysts bring to the organization.

Don’t forget to leave your comments below.

“Why?” Versus “Why Not?”

Written by Paula Bell on July 5, 2011. Posted in Articles.

I am a huge supporter of social network sites and I tend to browse Facebook, LinkedIn and Twitter daily. Okay, I will admit multiple times daily. One day I found that my husband posted an interesting status on Facebook and it made me think of how these two simple questions can produce different results based on the situations. My husband’s quote is as follows: “We can ask the question “Why?” or think of how to make it happen and say “Why not?”

Now, if you take this status and think of everyday life as far as career or dreams you want to accomplish you can interpret this as overcoming obstacles by asking “Why not” and the motivation to make things happen. Where asking the question “Why” could potentially make you second guess your dream or goal all together. My husband is a HUGE dreamer and I appreciate and love that about him because he sets his mind on a goal and figures out a way to achieve it, but when I started to think about this question from a business analyst perspective, I would prefer to ask “Why?” and not the “Why Not?”

How many times as a business analyst have you made things happen due to deadlines set for you or expectations set where you didn’t have control. So what did you do? You made it happen and because you made it happen it became precedence that if you can do it once you can do it again and again and again. It’s when we ask that question, “Why” that you truly get the answers to the end goal.

It’s important that when we, as business analysts, go into requirement sessions that we truly understand the following:

The purpose of the project. “Why are we doing this?” It’s amazing how many times I have been assigned a project but no one really understands WHY we are doing the project. Someone just had a great idea and for some reason someone believed it should have been a project. In actuality it shouldn’t have been a project to begin with because all there is, is an idea, not a vision or organizational strategic reason to do the project.
The stakeholders: “Why are you here and what stake do you have in this project?” – It’s very important to ensure you understand all the players, the roles of the players and the responsibilities of those players. If there are people there to just be there, then you need to find out, WHY they are there. What do they want to get out this project? If they don’t know and you don’t know then there is a problem. More investigation is needed. The stakeholders should have a stake in the project.
Requirements Management Plan – “Why are you taking this approach?” – It’s very important to have a plan on how you will gather requirements and the plan should make sense for that project. Some things to consider is what type of methodology you will use, what type of documentation will be completed and how the resource’s time will be spent for requirements elicitation to name a few. If you don’t know why you are taking the approach then maybe you should reevaluate it.
Documentation – “Why are we using this documentation?” – There have been many conversations in the industry lately about templates. “What template should I use?” is a question I hear quite often. It’s not about the template but more about what adds value to convey the message to the audiences which will consume the information. If the template or artifact does not add value then you need to ask “Why are you using it?” Our job as business analysts is not to fill out templates but to create documentation that will add value to the project.
Solution – “Why are we selecting this solution?” – No one understands the requirements better than the person who wrote them. As business analysts we spend a lot of time with our business partners and we have to ensure that we communicate their needs effectively for the developers (providing it is a software development project) to develop the needs of the business. Though the requirement may be met not exactly the way it was communicated because there was a better way to meet the requirement through the design that is being created, as business analyst we have to ensure that the solution is truly meeting the business need and the solution is not driving the requirements. I’ve been in situations where a solution was picked ahead of time. That led to the solution driving the requirements because no one really took the time to understand the business need prior to selecting a solution. This is another article for another time. J

These are by no means all of the “Why?” questions one could potentially ask as a business analyst but it is interesting to see how the same question, depending on the audience, can render a different outcome. For career development or fulfilling your life dreams asking “Why Not?” may be the best question to ask because that gives you the motivation to make it happen as my husband said. However, when you ask that same question when you are doing business analysis it may not be always be the best to say, “Let’s Just Make it Happen” because that may render very different results such as:

Setting a precedence on making things happen with unrealistic expectations upfront
Not truly understanding the business needs because you truly didn’t dig deep enough during elicitation
Not producing the most effective solution you could have

Take the time to ask “Why?” and figure out what the real business need is, it will give you, the business partners you are supporting and your technical partners less heartburn.

Don’t forget to leave your comments below.