Tag: Methodologies

Assessing Requirements in Requirement Gathering Sessions

Written by Poorti Mehta on January 25, 2018. Posted in Articles.

For a Business Analyst a project begins with requirement gathering or eliciting requirements (a popular term used to describe this task).

Workshops, interviews and brainstorming sessions – the more a Business Analyst conducts these methods of requirement gathering, the clearer a picture gets to him / her. Amidst these exercises, how important is it for a Business Analyst to simultaneously analyse a requirement or rather weigh a requirement? In other words how necessary is a requirement?

Although a thorough analysis is undertaken once all the requirements are gathered, it does help if certain requirements are assessed at the time of requirement gathering.

In one of my recent sessions certain high level requirements were discussed. These requirements were for an application that was requested to be developed for an internal sales team. Post the overview began the requirement gathering. I had my set of questions ready and took up one module at a time. A couple of minutes into the session, just as I was about to jot down one requirement, there came an opinion from one of the stakeholders. An experienced IT professional who has been associated with the organization for about 15 years and who is an SME on Financial Technology, begged to differ with this requirement. He posed some very important questions:

Is the requested feature really required?
What if there were an alternative? What if the purpose could be solved with a slightly different form of the feature?
The time effort and cost analysis if this requirement were worked upon and the time effort and cost analysis if an alternative were developed.

Now it took some solid ideas for the SME to convince the stakeholders to alter the requirement. All the stakeholders dug deeper into analysing the actual ‘requirement’ of this ‘requirement’.

To sum up an alternative was agreed upon. This alternative served the purpose of the business stakeholders, was economically feasible and could be developed in lesser time all without compromising on the quality of the application and the purpose of the feature.

Not all the requirements that are put across have the same nature. But there could be times when the business users are hell bent on having a complex feature in the application or they may want to implement a module on an existing application just because they happened to experience a fancy feature in the application of a competitor. While some requirements may be very helpful to the business, there may be certain requirements that can be optimally altered.

Requirement Gathering shouldn’t be about just jotting down requirements – Some requirements may not be needed at all or there may be better alternatives available. Such alternatives should be put on the table and discussed. The following questions can be asked:
- How purposeful is the feature / requirement?
- If the requirement is essential but it will take a lot of time to develop what can be done to deliver an alternative?
Stakeholders may come from either a technical background or a non-technical background – Some of them may be from a non-technical background but may possess a sound technical knowledge. However, if a stakeholder is from a non-technical background and doesn’t know the development process thoroughly, chances are high that a Business Analyst will have to discuss a requirement in more detail. They may not know the development process thoroughly. But you do. You know how much effort goes into developing the smallest of module of an application.

A stakeholder may not be completely aware of the time taken for development or the cost involved in undertaking the development of a module and making changes. In such cases, a Business Analyst has to dive deeper and ensure that the requirements serve the purpose of all.

In most projects, requirements undergo frequent changes – Stakeholders expect to go live with a product with almost all the requirements raised by them; even the changes. However given factors such as cost time analysis, project development time frame, priority of the project and availability of the resources deployed, it may not be possible to involve all the features during the launch. The requirements thus need to be prioritized keeping in mind the interests of all the stakeholders. While the major requirements can be taken in the first phase, the remaining can be put into the subsequent phases.
Requirement Gathering along with simultaneous analysis helps to save time during documentation and consequently project planning – If a doubtful requirement is discussed then and there and the alternatives are weighed, the stakeholders can reach on a consensus and consequently the requirement can be clearly documented and closed. This saves a Business Analyst from consequent follow ups required for requirement clarity or discussing changes.
A project may seem to be a simple at first however it’s only when these requirements are thoroughly analysed that the complexity of the development can be understood. Thus questioning a requirement in the interest of project development is important.

Weighing requirements is as essential an activity as requirement gathering. If done in the initial requirement gathering sittings, the subsequent processes – requirement documentation, sign off and planning can be smoothly accomplished.

7 Tips for Working with Product Users

Written by Frank Drucker on January 9, 2018. Posted in Articles. 1 Comment on 7 Tips for Working with Product Users

Disclaimer: I’m not a usability expert. I have no formal training in this area. My learnings have all been empirical.

My tips come from having spent a good deal of my life field testing products and managing teams that have field tested products. The products range from electro-mechanical devices to software tools and applications. These products were tested in environments that range from hundreds of feet beneath the ocean (Submarine Weapons Delivery Systems), to Retail Point of Sales (Electronic Article Surveillance products).

Usability Tip 1: Listen to Users

Really listen. Listen actively. Ask open ended questions. Avoid questions that are designed to confirm your previous beliefs. This I’ve found to be the most difficult. We all want to be right. We all want to affirm our pre-conceived notions. This is not the point of listening. The point is to learn new information that can help make your product more successful.

I believe Mark Cuban hit the nail on the head when he said, “Your customers can tell you the things that are broken and how they want to be made happy. Listen to them. Make them happy. But don’t rely on them to create the future road map for your product or service. That’s your job.”

Usability Tip 2: Observe Users

This is an important, often missed, and sometimes expensive to capture data point. It’s critical though. If nothing else, this is where you learn what your users are actually doing. It’s been my observation that many users don’t know why they do what they do. In some cases, they’re even too embarrassed to tell you what they do. So guess what? They don’t. This means if we only listen to them, we can miss out on what actually is happening.

Several years ago, I made an emergency visit to a customer retail site where a handheld point of sale device was breaking at an alarming rate. I watched from a couple of checkout lanes away as a Sales Representative took our electro-mechanical handheld device and began using it as a hammer. Lesson learned: If you don’t want your product used as a hammer, don’t make it remotely resemble one. This would have been an almost impossible failure mode to troubleshoot over the phone.

Visual observation also allows pain points to be more visible. It can become obvious when something is confusing or difficult to use when you can observe a user’s hesitations, facial reactions and emotions. These can be tricky to collect via other methods of interviewing.

Usability Tip 3: Mine User Data for Gems

Especially for software web-based products, there are a host of tools that can be used to gain valuable insights into your users behaviors. There’s a wide variety of data tracking solutions ranging from free products like Google Analytics Event Tracker, to paid options like Heap and Pendo. These can help you answer questions about your own software products such as:

Which features are most popular among your customers?

How much time are they spending interacting with your software?

How frequently are they using your software?

Usability Tip 4: Don’t Do What Users Say

Users are exceptionally valuable and usually well-qualified at knowing that problems exist. Frequently, okay, almost always, they will not only tell you the problem but they will be compelled to share with you a solution. Depending on the level of influence that the user has, they may even demand that their solution is implemented. Resist this temptation at all costs!

Besides risking sub-optimal solutions, if you implement what a user tells you to, you are potentially trading off fixing a problem at the expense of creating an even more serious problem. Remember that the user is only trying to get their problem fixed. They are usually not thinking about any problems that their “fix” could create. That’s the design team’s job. Therefore, it’s imperative that instead of communicating solutions, it’s important to be stating the problem clearly so an optimal solution can be developed. You’ll find that when you allow your Designers, UX experts, Developers and Engineers the ability to come up with the solutions, they will find more robust and usable answers to the problems being reported.

Usability Tip 5: Pain = Opportunity

When listening and observing your users, look for the pain points. Pain means opportunity. Opportunity means there’s a need. Solving customers’ needs usually has value that can be monetized.

Sounds simple? I’ve found this is one of the most difficult principles to put to practice. Why? Once again, people don’t want to be wrong. More particularly, smart people who’ve been working tirelessly on developing products that may be difficult to use really hate being wrong. How often have you heard these responses to reported usability problems? “They’re using it wrong.” “It wasn’t meant to do that.” “That’s not how it works.” For product development companies, those responses should actually sound like a cash register ringing because it means there are opportunities to make your products better.

Usability Tip 6: Empathy is the Secret Sauce

At every step of the usability communication process, empathy is a key factor to success. Users want to feel that you not only understand what they’re experiencing but also what they’re feeling. Try to take into account all of the pressures and constraints your users may be under. Perhaps they’re being measured by some quantity or time-based KPI. By showing genuine empathy for their struggles, it’s been my experience that they’ll open up and share more freely. Even more important, they’ll welcome you back. This can be critical in the case of an important customer who has to make some concessions and even inconveniences to participate in your test processes.

Show empathy with your design team as well. No one wants their baby to be called ugly. Share the facts with your development teams but frame the problems that you report positively as the opportunities that they truly are.

To quote Maya Angelou:

“I’ve learned that people will forget what you said, people will forget what you did, but people will never forget how you made them feel.”

Usability Tip 7: Change for the Better and Continuously Improve

Listening, observing, studying, and empathizing with users won’t make your products any better unless you follow through and act on what you learn. Prioritize opportunities and implement changes to improve your products. Close the loop when possible by thanking and showing users that their feedback and participation has made a difference.

Planning Workshops Using the 7Ps Technique

Written by Ryan Hewitt on January 2, 2018. Posted in Articles.

It’s difficult to plan for a workshop. There’s so many things to consider, sometimes it’s hard to know where to begin!

The best technique I’ve used for planning workshops is called the 7Ps. I found it in an excellent book called “Gamestorming”.

I use the 7Ps to create a clear agenda & make sure I’m prepared for a workshop.

How’s it work?

The technique asks you to consider the following areas for planning a workshop:

Purpose – why are you having this session? I tend to write 3-4 bullet points to summarise the purpose. This is the most important question & worth starting with
Product – what artifacts do we want to come away with from the workshop? You can think about this as outcomes or deliverables
Process – what will the agenda be? This should tie back to the purpose. The process needs to ensure you achieve the purpose & come away with the products you want
People – who will be in the session? And equally important – what role will they play? What kind of questions will they be there to answer? Will one person represent the technical side of the business. Will one person be there to sign-off the scope?
Pitfalls – what are the risks of the meeting? E.g. a particular question that might blind side you, that some people will want to delve into detail. Think about these pitfalls & write down how you’ll mitigate them
Preparation – what do you need to in advance of the session? E.g. do you need to create a presentation deck. Do you need to bring information to the meeting?
Practical Concerns – these are things around logistics. Where’s the meeting? Do you have a TV? Who will meet the visitors etc

Working example

Below is an example of how I recently used the 7Ps.

I was planning for a workshop with a new vendor. We wanted an all day session to convey our initial requirements & allow the vendor to feedback on what they could deliver in their first release. It was also our kick-off session for agreeing how we’d work together on delivering a service.

I sketched out the below 7Ps and sent it to our team for internal feedback.

Purpose – 3-4 bullet points felt like the right level of detail. The above purpose was what I wanted to get from the meeting; however I also considered what others / the vendor would want to get out of
it. It’s always worth thinking about other people’s expectations. I start on this section first – because that drives everything else
Product – I find this to be the hardest section. In this example the product was a collective agreement of scope & how the scope would be delivered. The product was a NOW/NEXT/LATER roadmap which would be updated in the session. Sometimes the product isn’t tangible (e.g. getting everyone to understand why you’re making a change)
Process – this was the next section I filled in. After identifying the purpose & product, I thought about what an agenda might look like / a typical running order. Each item here contributes to the purpose – and ensures we come away with the right products. Tieing the process back the above ensures that agenda items are necessary and add value
People – this is always really useful. Sessions shouldn’t have more than 10 people. It’s useful to think about who needs to there – and what their role with be. A role might be: to answer technical questions, to represent the product team, to answer any questions around operations, or it can be a job title
Pitfalls – I try to think about likely pitfalls. For our session, it was that that we would be drawn into the detail, and that we’d be asked a specific process question which we didn’t know the answer to. We actually invited the SME to mititgate that pitfall. And we created a question board where very specific questions could be parked
Preparation – who will create the assets before the workshop? What will they create & bring? I put names & deliverables in this section for our workshop
Practical Concerns – these are often things that people forget about. For our meeting it was: booking people onsite with security, checking the room has a TV, booking a room all day so that we could setup ahead of time. This became a checklist to make sure we were ready to run the workshop

Summary

I find the 7Ps a really good technique for conducting focussed workshops.

I typically use the 7Ps on my own to create an agenda, then take a picture and get people’s thoughts. This way attendees can feedback on the agenda. I find the “Process” & “People” sections are particuarly valuable for getting feedback & co-designing an agenda.

I find creating a physical version of the 7Ps means I can cross things out & move between sections easily. I often move from one section to another – and back again – as its all interconnected.

Hopefully you found this article interesting. And it’s a technique you would consider when planning for large workshops 

Business Analysts Embrace Non-Functional Requirements

Written by Rohela Raouf on December 26, 2017. Posted in Articles.

It is often argued that business analysts like functional requirements, so, therefore, they tend to naturally gravitate towards these.

On the other hand, the humble non-functional requirements are left in the shadow and rarely given a second thought until the last minute. Doing, this causes many issues when you are about to go live with a system. While the system/product may look great, if the performance is not there then no one will use it. This will impact the business a lot more than if a nice to have a feature is not included in the final product.

Differences

Functional requirements fall into ‘WHAT’ the product is trying to do while the non-functional requirement falls into ‘HOW’ it is going to do it. So, it is naturally understandable why BAs like to focus on functional requirements- you can show the users, customers, and managers what the product is going to be doing. It is a lot more difficult to get the managers or the customers excited about non-functional requirements.

Coffee cup

While it can be argued that non-functional requirements are not glamorous as functional requirements. I am just not sure really why non-functional requirements are left to the last minute. When I purchase a takeaway coffee, I want the company who created the container to have paid the same amount of attention to how it was going to be transported as well what is going to be in the container. Let’s, take this further I regularly access BBC website, the reason I use this product is not only because of the content but also how well it performs i.e. how quickly the pages load.

Twitter fail whale

There have been many high-profile cases where the business has not paid full attention to non-functional requirements. You will frequently hear about how a website has crashed because the business had not fully anticipated the capacity required. If you used Twitter in its early day you would have come across this whale, when Twitter was over capacity and therefore was unable to handle the demand. This naturally caused a high level of frustration of the service and they were very vocal about their unhappiness. Twitter fail whale is a great example of what happens when the business does not forecast correctly the level of capacity or understand the scalability of its product.

Key things to look for :

If you are new to non-functional requirements, the following are different areas of non-functional requirements that you need to look at when you are eliciting these requirements.

Performance: What should system response times be, as measured from any point, under what circumstances?
Volumetric: what is the volume of users that are going to be accessing the system?
Scalability: what is the peak transaction volume? Peak user levels?
Capacity: what is the volume of users that are going to be accessing the system?
Availability: what are the hours and days that the system is going to be available?
Reliability: what reliability (excluding planned outages) is needed?
Maintainability: how is the system going to be maintained? Who is responsible for the maintenance
Security: how is the system going to be protected from hacking? What will happen if it does get hacked
Auditing: how long do you need to retain the data? Do you need to who is accessing the system and what they are accessing?
Recoverability: what is the disaster recovery policy if the system goes down?

There are other non-functional requirements that I have not stated above that you may want to look at; Interoperability, regulatory, serviceability, usability

Eliciting non-functional requirements

Eliciting non-functional requirements is not easy as asking the business what do you think are the ‘maintainability requirements’. You will need to speak to other members of the project team, for example, the technical architect should be able to help you with most of these requirements.

If you do not or unable to speak to technical architect then speak to the end users of the system to get a baseline to what is current ‘As is’ situation. By getting a baseline you will be able to categorise the information. For example, a sale assistant has bring up a sale order screen when talking to customer

Objective: what is the objective behind this scenario
Process requirement: retrieve customer details
Non-functional requirement: how quickly should the screen load

By categorizing the information in the above manner, it allows you to analyze and assess whether there is a need for a requirement and what the priority is this for the requirement.

It is important when you are looking at non-functional requirements that you do not elicit them in isolation.

Documenting

Dependent on the type of the project methodology that you are using will depend on the artifact that you are going to use for documents. For waterfall projects, you will use requirement catalogue to document the non-functional requirements. In Agile, you should document them on the back of a card.

So, next time when you are about to elicit requirements, start with the non-functional first.

3 Things Business Analysts Must Know About the Digital Organization

Written by Xin Li on December 13, 2017. Posted in Articles. 1 Comment on 3 Things Business Analysts Must Know About the Digital Organization

Digital Organization has been a popular term when talking about reforming the Organization with IT technology and exploring the new Business Opportunities.

Here are the 3 things Business Analysts must know about the Digital Organization.

1. What does a Digital Organization mean?

In a Digital Organization, not only the digital capability but also the digital mind-set is enabled and practised through Organization model: 1) Strategy & Leadership; 2) Daily Operations 3) Research Innovation 4) Product & Services, 5) Resource Competency.

Figure 1 Digital Organization Model

Strategy & Leadership
Real-time and meaningful information can form the basis for Strategy analysis and decisions. The Management Team would need insightful overview of the Organization performance and then steer the management effectively. Applications and Analytics Tools are the digital capabilities to support the Strategy & Leadership.
More importantly, the Management Team needs to have digital mind-set for setting up the Enterprise Digital Strategy which supports the Business Strategy or even part of the Business Strategy. A Digital Organization requires the steering and commitment from the Management Team.
Daily Operations
Digital and automated Business Processes do not mean taking off people’s job. It means everyone can access the information more efficiently and take actions more quickly. Everyone is the owner of a piece of information. If there is no Information available or accessible, it is everyone’s own interest to raise the improvement request and share it with others. Any digital issue identified at daily operations could have large impact on the performance of an Organization.
Research & Innovation
A Digital Organization can make more profit out of the Research & Innovation with the aid of new insight from data analytics. Research & Innovation is crucial for any type of Industry. Understanding the proper data and making use of it can create new business opportunities. A Bank might predict the investment risks by performing the scenario analysis and create new investment products. An Engineering Service company may provide data product in addition to the services. There is unlimited number of opportunities for R&D to drill down into the data and explore.
Products & Services
Each Organization provides Products or/and Services. How to achieve the Financial Goal is a strategic question to answer. The strategic analysis of Sales requires the support of all kinds of data: the Marketing Forecast, Competitor Analysis, Budgeting Analysis, etc. In a Digital Organization, from identifying the prospects, till closing the contracts, all the Sales Information needs to be available, accessible and reliable.
For the Product Production, the Quality Control Information and Production Process Information can be digitized and automated for efficiency improvement in a Digital Organization.
For a Service Provider, the Planning Information, Pricing Information and Logistics Information might be essential for the Business Model. How to optimize them and attract more Clients would require a thorough data analysis in a Digital Organization.
In a true Digital Organization, new Product or Service might be identified and explored.
Resource Competency
In a Digital Organization, the most essential competence is not the Computer skills, but is all about the mind-set and focus on the digitization improvement possibility. The Digitation Need can come from any role within the Organization and the awareness of the Digitization should be promoted within the personnel.

Every Digitization change will bring changes to Personnel’s daily work and demand on the new competence. The personnel will need to get trained for keeping up with the new Digital capability.

2. Digitization Maturity Level Of An Organization

Each Organization is nowadays digitized to a certain level. The maturity level can be rated based on the availability and complexity of the information analytics

Figure 2 Digitization Maturity Level

Leve 1
Various Business Applications are available to support standard Business Operations in a specific domain; such as a Finance Invoicing Application; a Customer Relationship Management Application (CRM); a Planning Application; a Document Management System.
Level 2
The analytics can be done for the individual Application and provides more insight of the Application Data. For example, the overdue Invoice list can be created based on the data in the Finance Invoicing Application. The acquaintance with the clients can be drawn based on the contact records in a CRM system.
Level 3
The information of multiple domains of multiple Applications can be integrated and analysed to provide Enterprise-wide insights. For example, the Financial Invoicing Information can be integrated with the Project Budget information to provide the insight of Cost vs. Budget. The Project Planning Information can be integrated with the Project Document Deliverable information to provide more insight of the Project Progress.
Level 4
More advanced technology, such as Machine Learning AI, Internet of Things, Big Data can reveal more insights from the huge amount of data, which could even trigger a new Business Model for the Organization. For example, Big Data of all the historical Project Planning information can be researched for identifying the general pattern of Planning, which can be used for automation or optimization.

3. Approach options for building a Digital Organization

First of all, building a Digital Organization is a Continuous Improvement strategy. However, “Rome was not built in a day”. Where to start and how to continue? There are different development-approach options in different dimensions:

Dimension 1 Organization Hierarchy Level: Top-down, Bottom-up

Dimension 2 Scope Complexity Level: Parallel or One-transition.

Top-down: This is the most ideal approach. The Management Team of the Organization gives full support and drives the Digitization development of the Organization. The Digitization Strategy and Roadmap will be part of the Corporate Strategy and Business Development Roadmap. The Digitization Maturity Assessment will be performed regularly to identify the Digitization Improvement opportunities.
Bottom-up: When there is no sponsorship from the Management Team. IT Department will play a very important role in providing Digitization advice to any role in the Organization; can be to Process Owners, or to a Subject Matter Expert. The ultimate goal is however to achieve the Sponsorship from the Corporate Management Team.
Parallel: For an Organization with a complex and huge IT landscape, it is not realistic to change the Digitization Maturity overall at one GO and it is not necessary either. For some Business domains, the Digitization Maturity might be high enough and nothing needs to be changed. To avoid big turbulence in the Organization, a pilot Digitization project can be carried out for applying new Business Strategy and Technology possibilities, while the rest of the Organization remains using the existing Business Process and IT landscape.
One-transition: For a small size Organization with limited number of IT applications, it could be more efficient to improve the Digitization in one GO. The most importance factor for a successful Digitization change is a clear definition of the Business Case with quantified Return On Investment.

If mixing the two dimensions, there are four options, actually three, because option 4 is impossible to succeed.

Option 1: Top-down and Parallel; Option2: Top-down and One-Transition;

Option 3: Bottom-Up and Parallel; Option 4: Bottom-Up and One-Transition

Figure 3 Digitization Approach Options

4. Conclusion

Digitization is not a new term at all. It is good to see that more and more Organizations are paying attention to it and most importantly gaining Business Benefits out of it. “A journey of a thousand miles begins with a single step”, just do it and we will be there.