Non Human Stakeholders? (is that what we are coming to?)

In business analysis tasks such as use cases, user stories and diagrams, the term actor is normally associated with the term stakeholder. Many believe that the term stakeholder/actor has to be a human and cannot also relate to systems, subsystems or functional groups.

 Our dog Tanner on watch duty!

Our dog Tanner on watch duty!

I haven't seen that many user stories that start with "as a CRM system" but I cannot say that such a user story is wrong. If such a user story has value to the project team and doesn't disrupt the overall requirement package, I'm thinking it could be the new normal.

I went to a business analysis conference in 2017 and all the talk was about AI (artificial intelligence systems). The term was used so loosely by many of the presenters, it boiled down to the acceptance that any complex system could/would fit the AI category. My point that I'm trying to reach is that if all/many/some systems are considered AI, it seems to me they could be called stakeholders.

After all, if the CRM system benefits from the proposed changes more than a person (Bob, in accounting for example), why shouldn't the CRM system be listed as a primary stakeholder? If you look at a foundation description of the stakeholder (has some skin in the game), does that not include a system that is critically dependent on how a new feature is implemented?

Requirement Elicitation = A Perpetual Process

For many years, requirement elicitation tasks have been misrepresented as having a traditional (plan-execute-close) workflow. This assumption about elicitation didn't come about after a detailed analysis of the task itself. It was a byproduct of traditional thinking about project management tasks. Even with the emergence of iterative agile workflows, stakeholders still tend to think of requirement elicitation as a linear process performed and completed before the "real" project work takes place. 

 Brenda and I doing the "rail ride" just outside of Tillamook Oregon. (loads of fun!)

Brenda and I doing the "rail ride" just outside of Tillamook Oregon. (loads of fun!)

As wonderful as a business requirements document (BRD) can be to adequately setup a project for success, its value potential is diminished (if not completely removed) when it is excluded from iteration efforts. The real danger is that once the requirements have been completed, many project teams completely ignore the remainder of the requirements lifecycle.

This comes about because the needs, wants, constraints, risks and related scope components can often change as projects execute. The "requirements" tend to become the "suggestions" and the project manager, technical teams and even quality assurance make undocumented ad hoc decisions about what is best for the project. 

Why do they do this, you might ask? My best guess is because the illusion that the project is moving forward because the team continues to report (verbally) how busy they are.

Another valid question you may have is, “where is the business analyst during all of this?” Typically, they have been assigned to work on another project to build a business case or BRD that will ultimately have the same fate as I described above.

Instead of the BRD being a document that is stored in some seldom visited location on a network shared drive, it should become a “living” resource in which all project work is managed. This is why project components such as Kanban boards, user stories and managed iterations are so effective in guiding complex projects to success. No one person has the ability to "jump the shark" in regards to what is needed for the project. 

I have to say that my confidence in the traditional requirements process in waterfall environments is eroding quickly. Unless waterfall project management is strictly enforced by the leadership within the organization, it seems that the requirements lifecycle tends to struggle and projects suffer because of it. 

© 2018 Dwayne Wright

People, Agendas, Value Propositions and Communications

In the business world and especially in the technical domain, being a good communicator requires constant adaptation to the environment. The communication techniques that earned you praises in one environment can be shunned in the next one. If you are a fantastic writer, you may be considered a poor communicator by someone that doesn't like reading documentation. If you are more of a conversation type, you may be considered a poor communicator in situations that require a great deal of written correspondence. 

 Nothing like a great hike with a great dog!

Nothing like a great hike with a great dog!

One of the obvious needs for communication adaptation is in the area regarding the people the business analyst will have to deal with on a project. A linked but separate area is the associated agendas of those people and how all those agendas may conflict with each other. Eventually, you will need to communicate a message that hampers the progress of one persons agenda and helps the agenda of another. Almost immediately, the business analyst will be seen as having their own agenda's and taking sides in areas of conflict. 

To be perfectly clear, the business analyst does have an agenda (delivering value to the organization) and occasionally does have take a side (when a recommendation is part of a deliverable). However, the business analyst will have lost their way if the immediately side with people instead of value propositions. 

© 2018 Dwayne Wright

Only Validated Requirements Are Considered In Design Options

Note that the statement "Only Validated Requirements Are Considered In Design Options" is found in a rather obscure area of the BABOK under the inputs into the Design Options task. (BABOK 7.5.3)

IN MY OPINION
The statement is incredibly short sited and largely incorrect. I understand the concept, that execution of design work on non-validated requirements has risks. What the statement does not reflect is that it can have strong benefits as well. 

 A bitter sweet picture for me - Bogie (on the left) passed a week later and our boy Tanner still misses him.

A bitter sweet picture for me - Bogie (on the left) passed a week later and our boy Tanner still misses him.

Designs can come into play as part of the requirements definition process due to things such as prototyping and building initial visualizations of the final product.  Sometimes, you need designs created in order to gather, document and even validate requirements. 

Designs, specifications and requirements can become so entwined that many stakeholders do not see the difference. This "can" be an issue because it reflects a break in the shared understanding of the individual components. However, the quote of "culture eats process for breakfast" comes to mind. In some cases, a business analyst needs to teach and sometimes they need to adapt.

If an organization puts design tasks before requirements (and many do), they are NOT doing it wrong … if the final product meets/exceeds stakeholder expectations. If the practice is adopted in the work group and it works for them, I wouldn't be so quick to criticize it. 

© 2018 Dwayne Wright

Comments On - The Importance of the “Unhappy Path”

Today, I thought I'd jot down some notes on an Andrian Reed blog post titled The Importance of the “Unhappy Path”. 

http://www.adrianreed.co.uk/2018/04/16/the-importance-of-the-unhappy-path/

I had an assumption going in that some of the narrative could be on project sponsors and/or project managers that don't want the business analyst to spend much effort looking into exceptions. Exception discover and analysis are often shunned because they tend to link to issues, issues tend to lead to conflict and conflict can easily lead to personal/career risk. Additionally, documenting and analyzing paths other than the one most traveled takes time and most projects have some level of time sensitivity. 

 Last weekend, lucky enough to take my wife to Orcas Island and part of her birthday celebration!

Last weekend, lucky enough to take my wife to Orcas Island and part of her birthday celebration!

Instead, the article focuses on other aspects of process documentation that is more clinical and less political. I really like the pair of sentences that make up the end of the second paragraph. "Just because something occurs infrequently doesn’t mean that it isn’t important.  In fact, some very ‘infrequent’ events might represent real ‘moments of truth’ where we have the opportunity to impress or frustrate the customer."

That is a viewpoint I would expect from someone working in a QA role and not a BA role. Although many of us know the roles are quite similar but they tend to focus on opposite ends of the project endeavor (BA / Front - QA / End). A business analyst that focuses too much on the exception discovery and analysis may expect to receive feedback such as "paralysis by analysis." Again, both the project sponsor and project manager might put pressure on the BA to hurry up and ignore exception discovery, documentation and analysis. This article can be used to effectively communicate the need for exception analysis. 

I was also impressed with the opening sentences of the six paragraph. "I suspect most organisations consider the frequency of the event or scenario when making this decision.  This is useful, but it is also important to consider the severity, strength of feeling or outcome." 

Anyone that has studied for a PM and/or BA certification has come across the risk analysis components of probability and impact. Project sponsors and project managers tend to focus primarily on probability, although a project sponsor that started on the ground floor and worked their way up is a notable exception. This is one of the many areas in which knowing more about your project sponsors background can be helpful in determining how far down the exception documentation rabbit hole the business analyst needs to explore. 

In summary, I really liked reading Adrian's take on the topic and enjoy his regular article posts. The topic of "the unhappy path" could easily be expanded to book chapter or even book section size. I'd even be interested in seeing some benefit realization analysis on the topic of documenting outside of the happy path. How much of the effort that was put into exception analysis, turned out to have significant value to the organization? The organization would have to have some way to establish measurements and indicators in order to adequately compare the former "as is" state and the post project state. Again, this would add another layer of effort to the overall endeavor and potentially tip into an actual "analysis by paralysis" position. 

© 2018 Dwayne Wright

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" (https://tinyurl.com/ychqj52z) 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. 

THE BA 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