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:

1. First, identify the event/problem. The event in this situation is the fire outbreak in the towns.
2. 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?”
3. 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:

1. Why are we doing this project?
2. How does this project fit into the organization’s strategic goals and long-term vision?
3. How will the solution I recommend or help build meet those strategic goals or long-term vision?
4. 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.

“Those who cannot remember the past are condemned to repeat it”.
– George Santayana

Project completion reviews or post-mortems are often seen as an essential best practice that enables organizations to learn from their experiences. However, all too frequently, the insights gained from post implementation reviews are lost to posterity.

There are a ton of books, periodicals and articles that address project management, software engineering and management of change disciplines and practices. But the rate of success for major business and technology changes is still well below 50%? Why? The bottom line – we lack a common mechanism where findings can be stored, examples cited and recommendations for future undertakings recorded and accessed. And, we lack the structure and discipline to ensure that our knowledge is managed and referenced consistently and rigorously.

According to Nancy Dixon in her conversation matters blog, “NASA learned its lesson about losing knowledge early in 1990. They experienced the sad recognition that much of the knowledge about how to build the Saturn V rocket that took the astronauts to the moon, had retired along with the engineers who had been encouraged to take early retirement”. In response, NASA created the NASA Engineering Network a knowledge network to promote learning and sharing among NASA’s engineers. The Network includes the NASA Lessons Learned data base, “the official, reviewed learned lessons from NASA program and projects”.

Most stakeholders involved in a change aren’t aware of all the best practice information out there and aren’t inclined to spend the time and money to find out. They’re business people, financial types, actuaries, engineers, marketing folks, business analysts, IT practitioners. They’re not project management or management of change experts. They don’t really understand the role they need to play and the information they need to ensure success! They just want to get the job done.

So, what do you do as a sponsor, stakeholder, PM, BA or other interested party to leave a legacy of lessons learned? There are five critical steps:

1.     Identify and confirm accountability for managing lessons learned

Somebody needs to own this practice, to establish the goals and objectives, to measure performance, communicate to stakeholders and establish and drive initiatives to increase organizational value. Even open source software groups, which counts on thousands of interested volunteers to deliver and enhance functionality, have managing entities to oversee progress. Find an owner and hold him or her accountable. More on this later.

2.     Build or acquire a framework

Even with lots of great experiences, insights and findings, without some kind of organizing structure, a collection of project post-mortems will pose an unwieldy and perhaps insurmountable barrier to leveraging collective lessons learned. Fortunately, PMI, ISO, ISACA, SEI and many other organizations have developed frameworks and a wealth of best practice information. I personally developed the Project Pre-Check Decision Frameworkto bring together the best of project management, management of change, software development and other practices and provide a Lessons Learned framework in my consulting practice. Select a structure you and your organization are familiar with and build it up with real world experiences and examples to facilitate effective use and enable real performance improvements. Or build your own framework.

3.     Enforce usage

Having a comprehensive, easy to access, easy to use facility for mining best practices adds absolutely no value if no one uses it. So part of the Lessons Learned challenge, and a critical responsibility for the owner, is to ensure that everyone uses it, on every assignment, for every project. That use needs to involve a thorough review to identify and leverage applicable best practices and contributed learnings in a form and structure others can use. I can hear the groans already! More bullshit! More red tape! Get over it! If your organization wants to improve its ability to deliver major business and technology change successfully, a certain level of rigor and compliance is essential. What would you rather be, a sponsor, PM, BA or architect with an incredible track record of successful project deliveries, enabled by an organizational ability to leverage lessons learned, or an incredible individual contributor with a mixed record of project successes? Your choice!

4.     Manage the transformation of project experiences to organizational Lessons Learned

A key challenge is gathering the experiences and insights of each project participant and the collective wisdom of project teams and abstracting that information into the selected framework. Don’t leave it up to the BA or PM to post the project learnings to the Lessons Learned framework! The owner needs to assume that responsibility and establish the analytical mechanisms and quality and usability standards that will ensure that others, in different circumstances and on other assignments, can quickly and effectively gain value from the information.

5.     Manage Lessons Learned value contribution

There is no point in doing anything beyond individual project post-mortems if you’re not willing to manage the organizational value contribution. Getting a return from Lessons Learned means measuring usage, compliance, value derived and contribution frequency and identifying gaps and discrepancies in content and application. The measurement results provide the fodder to develop and implement continuing improvements to the practices, increasing the value delivered to the organization.

Where should Lessons Learned be managed? The PMO is an obvious suspect. The PMO mandate is usually very compatible with a Lessons Learned program. It typically has a broad view, encompassing enterprise or organizational initiatives, programs and projects. It should be tracking and reporting on aggregate project performance and taking steps to improve that performance, very compatible with a Lessons Learned program.

But, implementing a Lessons Learned practice across an organization is another change that has to be sold, prioritized, funded, initiated, staffed, managed and monitored. It is still very worthwhile but there is another option – the individual Lessons Learned practice. As a professional, you have undoubtedly committed yourself to a program of continuous improvement. An individual Lessons Learned practice starts and ends with you. You need to follow the same five steps reviewed above but you don’t have to sell anybody else on the idea. You are the decision maker. As you gain value, and confidence, you’ll build a track record and reputation others will notice. Also, share your experiences with your peers. Chances are you’ll find an enthusiastic audience and perhaps an attentive sponsor in waiting. Good luck.

Don’t forget to leave your comments below.

Drew Davison is a former IT practitioner, project manager and system development executive, the owner and principal consultant at Davison Consulting, a senior consultant at The Manta Group and the author of Project Pre-Check: The Stakeholder Practice for Successful Business and Technology Change. He works with organizations that are planning or undergoing major business and technology change to access the power of the Project Pre-Check building blocks; an effective stakeholder group, defined and proven processes and the decision framework, a mechanism for quickly leveraging industry best practices. Drew can be contacted directly at [email protected]

Following through from the previous articles on changing jobs (see Part 1 and Part 2), what happens when the universe gives you what you asked for, the job you have been hoping for, holding out for? Whether your new position is a small change, such as moving from one group to another in the same department in the same company, or a major change, such as moving across the country to take a position with a different company, along with the new job comes a learning curve. This learning curve can be anywhere between a gentle slope to a climb up a nearly vertical wall. “Learning” – that’s such genteel term; so analytical, so detached; it conveys none of the spine-tingling, ear-ear-to-ear grinning excitement that I feel when it is time to “suck up a new domain”.

How do we business analysts build the connections from our knowledge and experience to incorporate a new domain? For example, I have previous work experience in shipping, as in ocean transport of those big thirty-foot containers, and in expedited freight, which you know as DHL, FedEx, and UPS. My new position is with a company that provides information management services to the rail industry. I know nothing about the railroad business, but I do know that the fundamental business activity in transportation is to be able to move something from point A to point B and bill for all the services involved in that movement.

My learning curve isn’t a vertical wall, but it is pretty darn steep. The stakeholder community is fascinating. There are hundreds of railroad companies in Canada, the United States and Mexico, but there are the “Class 1” railroads that dominate the business landscape. In addition, there are railroad car owners who lease cars (a train is an assembly of cars and at least one locomotive) to the railroads. There are also component manufacturers who manufacture parts; suppliers who are distribute those parts, and car shops who consume those parts as part of performing maintenance and repair on the cars. There is also government involvement at the federal, state and local levels – just think about it, transportation is essentially a leading indicator of the health of the economy. If trains are moving, that means goods are moving. In order to be able to map the railway industry equivalent of the Quote to Cash business process, I will be inhaling noun phrases, absorbing relationships and concepts through my pores and trying to map all this new information onto my previous experience so that I can make sense of it as fast as I can. As each of us grow in our careers, we will all experience this terror and joy of having to perform while incorporating new knowledge on the fly.

Have you ever wondered how you do it? Is there a model? You betcha! There’s a nifty, keen learning model called Bloom’s Taxonomy, published by Benjamin Bloom in 1956. Below is the graphic model, called Bloom’s Rose, a nice play on his name as well as the shape of the representation. Do click on the graphic to see a readable version on Wikipedia.

In the center of the diagram above are six numbered skills; the numbers represent their position in the hierarchy where 1 is the most fundamental skill and 6 is the most sophisticated. The spiral in the center of the diagram indicates to me that Benjamin Bloom understood that the sequence was not strict; there was a lot of iteration.

A lot of research and discussion has been done on Bloom’s model since 1956 to reflect changes to an information-processing focus of modern Western education. Below is what the current model looks like. As you might guess, this model is still being discussed.

What does this model mean for a business analyst who is on a rapid learning curve? Think about the skills you need for knowledge of, comprehension of, and critical thinking about a particular topic. Let’s walk up from the bottom of the hierarchy. The titles of each section have old skill name in parentheses.

Remember (Knowledge)

The BA shows memory of previously-learned materials by recalling facts, terms, basic concepts and answers:

• Knowledge of specifics – terminology, specific facts
• Knowledge of ways and means of dealing with specifics – conventions, trends and sequences, classifications and categories, criteria, methodology
• Knowledge of the universals and abstractions in a field – principles and generalizations, theories and structures

After studying about eating a healthy diet, the BA can respond to questions like: “What are the health benefits of eating apples?”

Understand (Comprehension)

The BA demonstrates understanding of facts and ideas by organizing, comparing, translating, interpreting, giving descriptions, and stating main ideas:

• Translation
• Interpretation
• Extrapolation

The BA can respond to requests for information such as, “Send me a summary of your comparison of the health benefits of eating apples vs. oranges.”

Apply (Application)

The BA demonstrates the ability to use the new knowledge, solving problems to new situations by applying acquired knowledge, facts, techniques and rules in a different way.

The BA can respond to requests for information, such as, “Which kinds of apples are best for baking a pie, and why?”

Analyze (Analysis)

The BA examines and breaks information into parts by identifying motives or causes. The BA can make inferences and find evidence to support generalizations:

• Analyze elements, e.g., of a community or system
• Analyze relationships among those elements
• Analyze organizational principles

The BA can respond to requests for information such as, “List four ways of serving foods made with apples and explain which ones have the highest health benefits. Provide references to support your statements.”

Create (Synthesis)

The BA can compile information together in a different way by combining elements in a new pattern or proposing alternative solutions:

• Produce a unique communication
• Produce a plan, or proposed set of operations
• Derive a set of abstract relations

The BA can respond to a request to provide alternatives such as, “How can we convert this “unhealthy” recipe for apple pie to a “healthy” recipe by replacing the objectionable ingredients? Explain the health benefits of using the ingredients you chose vs. the original ones.”

Evaluate (Evaluation)

The BA can present and defend opinions by making judgments about information, validity of ideas or quality of work based on a set of criteria:

• Judge / Assess in terms of internal evidence
• Judge / Assess in terms of external criteria

The BA can evaluate a set of alternatives and make a recommendation, such as, “We want to serve apple pie as a snack to the kids in our after-school science program. We are trying to decide whether to serve freshly-baked apple pie using organic apples from a local farm, or pre-frozen apple pies, also made from organic apples but come from sources more than 100 miles away. The issues are cost, ease of delivery, and the community’s desire to support local businesses.  Please advise.”

Summary

Remembering, understanding, applying, analyzing, synthesizing/creating and evaluating – do these six terms resonate with you? When you learn something, did you realize you were doing all this work? I think this is why our brains hurt when we are on a steep learning curve; we can almost feel new synapses forming in our brain as the new connections form. What is even cooler is that by the very nature of the work we do, the opportunities to learn, both breadth and depth, are nearly without limit. We just have to seek out those opportunities and make them happen.

Don’t forget to leave your comments below.

Cecilie Hoffman’s professional passion is to educate technical and business teams about the role of the business analyst, and to empower the business analysts themselves with tools, methods, strategies and confidence. She is a business architect at Railinc in North Carolina. See her blog on her personal passion, motorcycle riding, at http://www.balsamfir.com.
 [email protected].