Comments On "The Art of the Business Workflow Diagram"

Today I read an article in BA Times called "The Art of the Business Workflow Diagram" ( and thought I'd jot down some comments as I go. I was drawn in by the first paragraph of the piece that says ...

"In many organizations, a business analyst is often assigned to a project where they may have little to no background on the actual business process they are supposed to analyze."

 Bogie and Tanner back in 2014

Bogie and Tanner back in 2014

I've had mixed feelings if the above situation is a good thing, something to avoid or just a thing. When you look at job postings for business analyst positions, you see many that think that the business analyst must also be a subject matter expert. I've also seen other business analyst feel that if they don't know the domain perfectly, they cannot move forward with getting their deliverables (business cases, use cases, BRD, etc..) until they are a SME. 

As I read the rest of the article, it seems they author feels along the same lines that the business analyst needs to evolve into a SME and I'm not saying he is wrong. I am saying that he isn't necessarily right either. The second paragraph of the piece describes the realities of project schedule deadlines. Although, the true nature of this reality cannot be captured which such a short narrative. Project schedules, particularly on complex projects, is an intimate dance that can shift from a slow rumba, to a swing and then into one of the world's fastest tap dances. It can slow down until it is just one person is involved until their thing is done and then the floodgates are open and the project dance transforms into a flash mob of activity. 

It can be very frustrating for the project team if they are waiting for the business analyst to finish a backlog of workflow diagrams in which the rest of the team know the associated workflows by heart. In use cases as described above, the business analyst may need to shift the importance of their activities from "knowing" to "facilitating." In other words, the business analyst may not need to KNOW about a thing as much as they make sure that those that need to know are connected with the correct subject matter expert. That the associated documentation is good enough to validate that knowledge transfer and help the project manager with their demanding scheduling constraints. 

In closing, I really like what this article is saying and how the author is saying it. I’m just commenting that a business analyst should make sure they are not one dimensional in how they deliver value to a project. 

BTW: The article doesn't actually talk about the art of business workflow diagraming. I can imagine a book that really examines different approaches to workflow diagrams, how different techniques can present different value propositions and perhaps a nice big tips section! That would be particularly awesome and I assume their may be some books like that out there already. 

© 2018 Dwayne Wright

User Stories And The Structured Walkthrough

Although requirements documentation is important in a lot of areas, it is probably the most important as a communications facilitator. By its nature, the creation of a software product is essentially a communication problem. This is, in part, due to the fact that you're creating something fresh out of nothing more than a good idea. Another contributing factor is the diversity of individuals that will create the software product  and the diversity of the experiences they have to bring to the table. In many cases the conflict between these talented individuals creates a atmosphere where someone must win and someone must lose. This is more noticeable for teams that have just been formed and less noticeable for teams that have worked on projects together in the past. In almost all cases if one of the divisions of a software product completely dominates the other, the software product loses.

 Our little puppy Tanner, quite the bed tunneling expert!

Our little puppy Tanner, quite the bed tunneling expert!

In the most basic set up,  you will have a technical team and a business team on the project. It is common that the business team will try to exert what they consider are the technical elements on a project. This, of course, will start a natural conflict because the technical teams know more about technology than the business teams. The reverse is quite often true as well. The technical team may not see the sense of a business need and look to eliminate it from the technology implementation. In many cases, having teams work together on requirements documentation lowers these levels of conflict. If you have a requirements methodology that helps the business units focus mostly on the business communications and the technical folks communicating mostly on the technical implementation, you may have the beginnings of a healthy requirements phase. Here is one method that I have used with successfully in the past, that helps facilitate that type of arrangement.

Have your business units start the documentation ball rolling, a great place to start is defining user personas and scenarios. You may have to monitor business team members to ensure that they are not implementing technical recommendations within these narratives. However you do have to afford them a degree of flexibility, because they are actually trying to visualize a software product.

After you have these personas and scenarios defined, even if just at a high level, then a great addition to that is the user story. Although I think it is proper to have the business unit create the majority of the user stories, the game incredible value once the technical teams get to work with them as well. Much of this value comes in the fact that the technical teams do not know that much about the business, so they bring up questions and help fill in gaps that were created based upon the intimate knowledge the business unit may already have about a particular scenario. 

When the technical teams bring at these questions, you can see the business units begin to scratch their head and look at the issue in a new light. This is one of the values that you can have in a structured walk-through. I like the structured walk-through better then email exchanges in regards to clarify and user stories. Using email to clarifying user stories can be a timesaver however many times they just simply get the attention they deserve when done this way. 

It would be easy, although inaccurate, to say that you will have all your user stories validated in one structured walkthrough session. However the reality is that you will probably end up creating new personas, scenarios and even business rules during your first few passes. Although everyone on the team may want to groan when they come across something that simply isn’t good enough in one persons eyes, this is a good thing. It is better to get it correct now than have to rework the tasks associated with this “not quite right” requirement. 

Additionally, the overall process (although I admit can be tedious at times) facilitates a greater degree of communication between diverse project individuals. If all goes well, this entire process will become a bonding agent between the team members. You will find that you have longer enduring shared knowledge between the project team members and all the stakeholders that they may influence.

© 2018 Dwayne Wright

These Assumptions Must Be Identified And Clearly Understood

Some projects, both great and not so great, are launched based upon little more than a vague desire about reaching an idealized future state. The fact may be that leadership (or even just a single leader for that matter) has a vision of a future state and a whole bunch of assumptions. This project might be that vision, a component of that vision or just a stepping stone towards clarifying the vision. The thing is that leadership is moving forward because they have assumptions. 

 From a 2010 hike of Gothic Basin - Simply Inspiring!

From a 2010 hike of Gothic Basin - Simply Inspiring!

What the business analyst may need to focus upon (BEFORE ANY THING ELSE) is identifying those assumptions, understanding them, validating them, analyzing the results and then compiling them into a course of action. Not a course of action for the organization or even the project, the course of action for the downstream business analysis activities. 

As an experiment, I decided to GOOGLE the word assumption and see what was returned. Wow, I was taken back by what appeared to be subtle results but applied to the narrative I've already shared with you thus far.

1. a thing that is accepted as true or as certain to happen, without proof.
2. the action of taking or beginning to take power or responsibility.
3. the reception of the Virgin Mary bodily into heaven.

or translated for my (potentially lame) effort to make a point

1. An idea supported by things (not yet proven to be true)
2. Turned into related actions (via the power to do so)
3. To reach an idealized future environment


© 2017 Dwayne Wright

Documenting Constraints For Both Current And Future States

Constraints are aspects of a organization that hinder progress and many organizations don't really like to have the business analyst point them out. A natural thought process is that a constraint is something we should be able to fix and someone is to blame for them. This is often not true, many constraints are in place to serve purposes that may not seem apparent until they are removed. 

 A partially hidden constraint on my side of the bed.

A partially hidden constraint on my side of the bed.

The BABOK v3 has a nice little section ( about current and future constraints that may merit your review. Here you can see that there may be benefits for logging current constraints, future constraints, the constraints that were removed between the two and the ones that will continue to be in place. 

Exploration of the persistent constraints may have value to the business analyst because they are often associated with business rules. That may allow the business analyst to fulfill one of their highly under appreciated tasks for the organization. That is how a business analyst can often be a strong contributor to transforming tacit business knowledge into explicit knowledge that can then be leveraged by the entire organization.

© 2017 Dwayne Wright

How Business Analysis Work Will Be Approached And Prioritized


How important is it that the business analysis work be planned, communicated, documented and governed? Some may argue that the sheer number of unknowns about a business analysis effort requires more flexibility than process. Additionally, some may argue that a business analyst that follows a disciplined approach puts too much strain on the rest of the project team and leadership decision makers. Another popular argument comes from the agile world and the popular tidbit from the Agile manifesto stating "individuals and interactions over processes and tools."

Thoughts? Please feel free to email me at!

© 2017 Dwayne Wright

The Product Owner Role - The Business Analyst

If you are looking for a nice summary of the product owner role in a Scrum environment, I recommend checking out an article on ( ). As I type this, I literally haven't read the post beyond the product owner description section because I wanted to jot down some thoughts. In particular, the potential parallels between the product owner role and the business analyst role. 

 Snapped this at the Jim Henson exhibit at the Seattle MOPOP (formerly the EMP). I loved the Count as a kid!

Snapped this at the Jim Henson exhibit at the Seattle MOPOP (formerly the EMP). I loved the Count as a kid!

As early as the first sentence in the product owner role description, you see where the two roles differ. The author states "The product owner is the one in charge of the business side of the project." I agree with this and some people might think this holds true for the BA role as well. Fortunately or unfortunately, the business analyst isn't in charge of squat. In many cases, we struggle to control the methods we use to do the job, the work products we use, what tools we can use or the acceptable format of our deliverables. I literally had a project manager tell me once that she wasn't sure she would allow me to speak in a requirements meeting she was driving. This is not uncommon when a BA is assigned to a project that is underway and that project is perceived as struggling. All of this isn't necessarily a bad thing, it is just part of being a business analyst in a competitive workplace filled with capable people that might have strong personalities.

After that first sentence in the narrative however, the authors description of a capable product owner can easily match the same criteria for a capable business analyst. A business analyst that transitions to the product owner role may need to shore up their "take charge" skills. Although, taking charge of something on a Scrum team is normally quite different than taking charge of something in a waterfall environment. I would have to say that a business analyst is better suited for "taking charge" in a scrum environment than in a waterfall one. It all comes down to three words why this is true, “the product backlog.”  

Any business analyst that is capable of managing a robust requirements package should find product owner backlog management an easy transition. They are not the same but they are really close! A well crafted requirements traceability matrix (RTM) can often be directly imported into a product backlog, particularly if that was the intention all along (hybrid environments). A business requirements document (BRD) is basically a product backlog with chunks of narrative in between. 

Now I would like to pivot to the last sentence in the articles discussion on the product owner. This is because this sentence could be lifted directly out of the product owner context and placed into the business analyst context without a quite little modification. 

That sentence reads, "To effectively function in this role, it is paramount the PO come equipped with great business skills as this is pertinent for decision making and profitability actions."

© 2017 Dwayne Wright 

Vendors And The Business Analyst

It was a long time into my business analyst career before I became a critical part of the vendor selection and vendor assessment process. In fact, I discovered that I was under prepared when it happened because I assumed this area was primarily nestled within the project manager role. This assumption was reinforced because many project managers feel the same way about it. 

 A selfie we took during one of the stops on the Woodinville Wine Ride last month. Weekend group bike rides are becoming a staple for us!

A selfie we took during one of the stops on the Woodinville Wine Ride last month. Weekend group bike rides are becoming a staple for us!

Although the word "Vendor" appears just once in the BABOK table of contents (10.49 Vendor assessment), the BABOK does include plenty of areas that touch on vendor relationship related topics. For example, 

2.4 & 9.5 - Vendors can be considered stakeholders and therefore linked to many stakeholder related tasks and techniques. A BA may need to have strong vendor interaction skills, particularly in cases where a "throw it over the wall" RFP process is NOT being used.

5.3 - Vendors can be linked to costs and costs can be used in multiple prioritization processes. 

6.1 & 6.2 - The vendor(s) related to a process can often be the subject of the "as is" state analysis. In fact, the poor performance of a vendor(s) can be a driving force in finding a superior "to be" state.

7.5 - Vendors and the services they can provide are often included in the design process to model requirements. A vendor may have their own requirements and that often translates into a constraint to be noted on the business analysis side.

8.1 - Vendor performance can often be a strong factor in measuring the performance of a solution. In some cases, it can be negative but it can be a positive consideration as well. Think of the common "build vs. buy" decision, a strong vendor can often swing the decision into the buy fork in that decision branch.

11.3 - The information technology perspective discussion in the BABOK is obviously full of vendor related topics and the business analyst should take into consideration on all IT related endeavors. IT is a true ecosystem and vendors are a big part of the overall health of that environment.

So if you are a business analyst that hasn't had a lot of vendor related tasks come your way yet, it certainly could be part of your future!

© 2017 Dwayne Wright