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

The Documented Rationale Behind Performance Requirements

All to often, performance requirements are stated without including the rationale behind them. Although this isn't a front line risk when it occurs, it definitely can have an impact on shared understanding of what the performance requirement really means to the overall solution evaluation. 

A mobile system takes 13 seconds to load after the splash screen appears and the target requirement is less that 5 seconds. The actual measurement is almost three times longer than the specified performance requirement. That sounds pretty bad, doesn't it? How about looking at the same reality from a different viewpoint? The system takes 8 seconds longer to perform than expected. Now the very same condition sounds almost trivial and we should move on to more important things. 

Last Sunday (July 16, 2017) I finished my first Seattle to Portland bike ride. My single performance requirement was to finish.

Last Sunday (July 16, 2017) I finished my first Seattle to Portland bike ride. My single performance requirement was to finish.

Why does this requirement and the associated fulfillment of this requirement matter? If the target user opens this mobile application 10 times a month, they have lost a full 80 seconds of potential productivity that month. How many of us wait more than 80 seconds each day to get a cup of coffee? So can we say this performance requirement is unnecessary and has no real impact?

After all, how many development man hours would be spent to fulfill the less than 5 seconds launch to ready to validate this performance requirement? A developer would need to analyze the potential bottlenecks, research potential fixes, implement the fixes, test and then repeat this loop until they achieve success. Then that fix can be incorporated into part of the overall release cycle. This could easily run into 20 hours of overall development time and that is time that could not be used to fulfill other requirements. If we assume that developer time is $50 in house or $100 external, the fix will cost anywhere from $1,000 to $2,000. So we are investing $250 per second to improve screen loading time, is that right?

No, because where are not taking into account our full user base and so the cost per second value proposition is much more reasonable. However, this narrative is on its fifth paragraph and I still haven't submitted any real reason why this matters. In fact, we might have even forgotten about our "why objective" because we have been so caught up with the math.

Here is a potential definitive reason why the unusually slow load time for this mobile application matters. This is because the user might think to themselves every time they have to stare at the screen for the full 13 seconds, "this mobile application is a bit of a turd." "Why does it always load so slow, when all my other mobile applications load so much quicker?” "Doesn't this company know that I have better things to do with my life that stare at their company logo while this turtle of an application loads?"

The rationale behind a quick loading mobile application is that we want the users to have the impression we are speedy. If I finish 8 seconds behind you in a marathon race, the difference hardly matters. However, you don't want your customers to be reminded 10 times a month that you are slow. If we don't document the rationale behind performance requirements, they can easily loose their power and support in the development pipeline.

So this performance requirement is not about performance, it is actually about our brand image. Every interaction with our mobile application can easily modify our users future expectations of us. We want to build a consistent track record of exceeding expectations, do we not?  

© 2017 Dwayne Wright

Maryanne Struggles With Stakeholder Meeting Attendance

Maryanne is faced with a decision and she doesn't like most of her options. She is assigned a project that is very important from a compliance perspective but seems to have little operational value. In fact, some may consider it a threat to operational task velocity and would like to see this project fail. 

The Rain Run a few years ago, this is NOT Mr. Middlebottom in front of me but (well you know).

The Rain Run a few years ago, this is NOT Mr. Middlebottom in front of me but (well you know).

Maryanne is in a tricky position because she has limited freedom in building her requirements package. That limit has a name, in fact it has a first name, last name and she assumes a name that fits in the middle. The name of her constraint is Drew Middlebottom and he is the assigned project manager for this endeavor. 

Mr. Middlebottom not only doesn't understand the value of the business analysis role, he obviously considers it a low level threat. He has stated his viewpoints that the process of building requirements takes up to much time. He lobbies for agile methods but that is a smoke screen. He understands and appreciates agile approaches slightly better than he appreciates a business analyst. He uses this as a shield to do what he wants on projects and finds defined processes an irritant. 

The project manager decided that Maryanne would be allowed three workshops in the next two weeks to gather requirements and complete the requirements package. This is a horrible idea but Maryanne's options are quite limited. It is uncertain if Mr. Middlebottom's constant negative campaigning against business analysis activities to the project schedule was a factor in each meetings low attendance but Maryanne knew she couldn't focus on that distraction. She needed to find a way to build a valuable set of requirements and she would likely need to be creative in her approach. 

Maryanne looked at the list of options she had been struggling to create. She didn’t know which aspect of this endeavor was the most depressing. The fact that the list seems weak or that she had invested almost half a day building it. The list of her options she felt were reasonable included:

1. Escalate the issue to management, require mandatory attendance procedures

2. List low attendance as a high impact and high probability risk in the risk register

3. Assign tasks to people not attending the meetings and see if they actually read the meeting notes

4. Give up on meetings for now, downshift into one-on-one interactions

Only when studying for the IIBA CBAP exam did she come to a decision. It came in the form of the first bullet listed item in in the IIBA BABOK (Business Analysis Body of Knowledge). This section falls into the Interviewing task description and that bullet list is focused upon the stated strengths of interviews. It says specifically, "Encourages participation by and establishes rapport with stakeholders."

Rapport sounds like a tremendous asset to her right now, not only for this project but all the ones she may be assigned downstream. She now had a direction to go in, she just needed to find a way to get around Mr. Middlebottom's constant interference and execute a strategy.

© 2017 Dwayne Wright