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

Stated Requirements vs. Actual Requirements

In the beginning of my business analysis career, I struggled a bit understanding the true difference between stated requirements and actual requirements. It seemed that the majority of conversations I heard at the time was along the theme of "that is JUST a stated requirement." It sounded like it was being treated as a second class citizen and its value shouldn't be given that much weight. While exploring a couple other pillar requirement topics, I gained a deeper understanding of stated requirements. 

From 2010, Bogie and I take a trip to Mount Dickerman on a fantasic day hike.

From 2010, Bogie and I take a trip to Mount Dickerman on a fantasic day hike.

In short, the difference can be about an evolutionary process. I realize that this might sound like a hot mess of a thought string but perhaps the point I’m trying to make will become more clear via the below narrative. 

One of the main components of active listening is paraphrasing what you hear in your own words. This technique allows a stated requirement the ability to evolve into a more defined state. This concept really takes form in situations such as: 

- stakeholder states a requirement
- the BA restates that requirement
- the stakeholder restates the BA restatement
- (wash-rinse-repeat as necessary) 

and finally a stated requirement has evolved to the point in which everyone has a shared understanding of its true nature and personality. 

Requirements, although they look amazing at the time, may not be actual requirements until they have been modeled. This is another transformation that is evolutionary in nature. The act of modeling the requirement(s) leads to a greater understanding and this process changes them from the original state to actual requirements to be baselined for project implementation. 


© 2017 Dwayne Wright

Three Good Subheadings To Put Into Your Elicitation Documentation Templates

Some days, all I want to do at work is fill holes in a project documentation template and listen to something catchy on my headphones. We have all been there and this practice can yield some amazing results. One of the predecessor steps in achieving that level of success is quality focused preparation of those templates. My opinion about template usage varies from positive to much less positive mostly on the motivation of the person that is going to use that template. 

My old buddy Bogie, always opent to the idea of taking some time to let me snap a fun photo!

If your approach is based upon finding the right template to provide aid in what you want to say, I have a super positive viewpoint. If you craft your own templates, can communicate to others your vision and it is accepted by them, I'm impressed. 

Lets take a slice out of the BABOK v3 and see how it might apply to a personalized business analysis template. According to the (all powerful and wise) BABOK, there are three common types of elicitation. These are collaborative, research and experiments. So the section of the template that covers the elicitation approach could look something like this:

COLLABORATION: <state situations in which elicitation will be accomplished with direct interaction with a stakeholder(s)>

RESEARCH: <state likely candidate resources in which you expect to find elicitation information for the endeavor and how you will leverage this information in your approach>

EXPERIMENTS: <state endeavors in which information or insights cannot be gained any other way than a prototype, proof of concept or other low level product creation method>

The following are three business analysis documents that could easily leverage value from such grouping your elicitation approach:

Approach documentation comes handy in situations where you have a large team of business analysts tackling a huge endeavor or when you have a junior business analyst that may lack elicitation experience. In both cases, you want to mitigate the risk of elicitation inefficiencies. Additionally, it is likely there will be a senior business analyst that will review and ultimately be responsible for the overall elicitation efforts. Being able to review information related to the three types of elicitation can be very appropriate here.

The word "charter" literally does not appear in the BABOK and this is a bit weird, when you reflect on how big of deal it is in the PMBOK. In most charters, there is a section to include requirements related information that may play a factor in an approval decision. Instead of putting "boilerplate" requirements here, you could include approach information. This can easily be valuable in obtaining the correct "go/no go" decision from leadership. 

The business requirements document or the requirements traceability matrix should have some form of traceability. It can be helpful to pencil in how requirements will be traced before you gather them. For example, you can add sections in a RTM spreadsheet for the three elicitation types and then fill in requirements right under those sections. 

So there you go, just another potential way to leverage classic BABOK content in the real world! Feel free to add your comments or email me your thoughts on this approach!

© 2017 Dwayne Wright

Estimation As An Elicitation Technique

In the BABOK v3 4.1.6, estimation is listed as a elicitation technique and I seemed to struggle with that concept initially. As I was staring at this line item, I thought that I might as well build a narrative to help fulfill my daily word count writing goal. So here goes ...  

This is from Sasquatch expresso stand and Zeke’s Drive In on Highway 2 in Washington state. A popular stopping place when doing all the amazing hikes in that area!

Estimation is one of the most flawed concepts in project management, particularly in software development. You have a better chance of bumping into “Big Foot” at the local Starbucks than find a project with a set of estimates that reflect what actually happens. Overall, you just need to assume that along the way you will loose ground on some tasks, gain ground on others and it will all work out in the end. If you have a project manager that is actually maintaining a project schedule, estimation could be a way to trigger a discussion about a task. It can be an indicator that an issue that needs to be resolved requires team attention. 

Regardless of how you feel about the cost-benefits of estimation, it seems to be a bit of a leap to include that as a method to "draw forth" requirements. I was prepared to write on and on about this anomaly until I remembered a time in which I used a planning poker session as a team building exercise. I could care less about what the estimates were that came out of that session. I just wanted to get a few silos in a room collaborating in a fun exercise and build a framework for ongoing shared understanding about the project requirements. 

I was stunned by how many hidden requirements came out of those sessions. As people began to defend their too low or too high estimates, all kinds of goodies came spilling out. Not just requirements, but also business rules, unidentified stakeholders, risks and a wealth of overall tacit knowledge.

So yeah, I’m onboard with elicitation being included as an effective elicitation technique. Still not a big fan of estimates though, just saying (grin)!

© 2017 Dwayne Wright

Techniques Specifically Suited To The Situation

When a business analyst needs to make a decision regarding which elicitation techniques to employ in an endeavor, there are many different aspects they may want to consider. The BABOK lists the following three but each workplace situation could have factors that add to this list. 

• techniques commonly used in similar initiatives,
• techniques specifically suited to the situation, and
• the tasks needed to prepare, execute, and complete each technique

From way back in 2012 ish, this is what you get when you have a wine tasting at a location that also has salmon run event going on.

ABOUT: techniques commonly used in similar initiatives
I'm not a big fan of this option for many reasons but the big one is the assumption that one initiative is similar to another. If you are basically doing the same thing as the last time, the value proposition the business analyst brings to the table is greatly diminished. Similarity is a slippery slope assumption that can lead to all kinds of issues such as missed requirements, unnecessary requirements and more. I believe you should factor similarity into your decision but it shouldn't be the primary one.

ABOUT: the tasks needed to prepare, execute, and complete each technique
I feel this is more about what techniques to EXCLUDE and less about what to INCLUDE. It is true that knowing what you are NOT going to do really helps in the decision making process about what you are going to do. However, we still have an assumption risk. You may assume that you cannot do a collection of stakeholder workshops because of the project deadline. Deadlines move all the time and you may have more time available than you thought. 

So you may adapt your approach to "lighter" versions of heavy techniques. I have found this to be helpful when I suspect a deadline or similar constraint is likely to become less relevant overall.

ABOUT: techniques specifically suited to the situation
This one can fall into " the chicken or the egg came first" situation. How can you know what is “best suited” until after you have started elicitation on the situation itself? Here you can see that you don't have to be locked into a technique or be linear in your approach. If a project can have pilot releases, then the business analyst can certainly have pilot elicitation activities. This allows the business analyst to learn know more about the situation AND ”draw forth" some requirements. Immediately thereafter you analyze the elicitation results, add the requirements you found to your gathered requirements repository and pivot your elicitation approach if necessary. 

© 2017 Dwayne Wright

Analyze Performance Measures WITHOUT Project Management Girth

According to the BABOK Third Edition, "The purpose of Analyze Performance Measures is to provide insights into the performance of a solution in relation to the value it brings." As I was reading this the other day, I thought of two use cases for this task that could be outside of the confines of project management. 

My buddy Bogie, one truly great dog and I was very lucky to have him in my life for 14 years! RIP my old friend!

To some, that idea is a new concept. Some project professionals are so wrapped up in a project management mindset, they do not realize that a business analyst can deliver strong value without the need of expensive downstream deliverables such as a project charter, requirements, project plan, project schedule and so forth. There would be no need to worry about scheduling resources such as a project manager, quality assurance, compliance SMEs and the like.

A sponsor can ask for a business case on the side, they do not need to order a project entree. 

The business case, an early document used to justify a change, often contains a section regarding the evaluation of available options. So an organization could request a business case deliverable but not the project. When the sponsor reviews the business case recommendation with associated content to support that recommendation, they can make a variety of decisions such as:

- do nothing, the business case confirms that a change is not needed
- do nothing right now, set a future date in which a change decision is needed
- make changes but not ones that would require the effort of a project
- use the business case to justify the launch of a full project effort
- combination of the last two
  - little changes can be done internally outside of project scope
  - big changes are professionally tracked inside of a project

Whenever a contract is due for a product, a service or a combination thereof, an organization may want to assess the value of that contract and explore available alternatives. The business case is a perfect fit for this need and could even be a mandatory deliverable for contract renewals above an established value. 

You may want to analyze the performance of a solution because there is a possibility it is being under utilized. This is another situation in which the business analyst would do a performance analysis and there is no expectation of a linked project downstream. However, a project could certainly be created based upon the business case recommendation.

So there you go, a business analyst and even common project management deliverables can have use cases that do not require the constraints of project management. This can even be a strong proposal to help overall PMO throughput because now projects are better aligned to efforts that get the most value from them. 

Love to hear your thoughts!

© 2017 Dwayne Wright

Risk and Root Cause

This narrative was born out of a question I missed on a CBAP practice exam and this source might actually fuel all kinds of different content for me to write about. This one in particular seemed to indicate that root cause analysis techniques have nothing to do with risk management. They told me that risk deals with uncertainty and root cause techniques do not. 

I do not believe my answer was wrong but now see that my choice wasn't the best one for the context of the question. The question did describe root cause and my risk related answer was a bit of a small stretch. However, I do not believe that root cause techniques and risk management are necessarily separate. I also do not agree that risk management deals only with areas of uncertainty. It would be hard to have a risk without uncertainty but risk isn't just about uncertainty.  

This is Roo, a sweet little miniature greyhound we visited, along with family, on Christmas holiday.

When someone brings up a project risk, I think the Five Whys technique is a very valid response. The uncertainty aspects of a risk may become less uncertain if the business analyst digs a little deeper. The risk might not be a risk at all but the fountain head for a set of requirements. 

Lets say that a business owner communicates a risk regarding vendor availability. I believe there is an information opportunity lost if the business analyst writes that risk down and asks for additional potential risks. Actually, I will back peddle on that one. It is fine to do that, as long as you circle back and do a root cause technique. For the sake of discussion and my article word count, how about employing the Five Whys technique here. 

BUSINESS OWNER: I see a significant risk regarding the vendor availability, we have had problems with them in the past. 

BUSINESS ANALYST: (WHY 1) Why do you think their availability issue in the past would affect us here?

BUSINESS OWNER: Because the project manager they have assigned us was never available.

BUSINESS ANALYST: (WHY 2 & WHY 3) Why were they unavailable? Did they ever communicate why this was a problem? 

BUSINESS OWNER: First off, she was sick all the time. In fact she was sick an entire week and we were counting on her supplying her project schedule to align to ours. 

BUSINESS ANALYST: It sounds like we might need to document a requirement that the vendor needs to identify a proxy for their project manager for critical areas. (WHY 4) Why do you think the vendor wasn't able to handle this situation better?

BUSINESS OWNER: That project manager is a command and control type, she probably felt it wasn't necessary. I'm not even sure she was actually sick. 

BUSINESS ANALYST: (WHY 5) Why do you think that she might not have been sick?

BUSINESS OWNER: Because she seems to get sick a lot around critical deadlines. 

So you can see that the Five Whys root cause analysis technique being used here identified a set of vendor management requirements. Take a look at your current or past risk registers and see if a 5 Whys root cause analysis technique might provide some value for you!

© 2017 Dwayne Wright