Tag: Planning

The Art of Getting Things Done

Written by Jon Derbyshire on July 4, 2018. Posted in Articles. 1 Comment on The Art of Getting Things Done

As a business analyst, we are often working on multiple projects at the same time.

Balancing priorities is something we must do as part of the daily role to meet both project and business deadlines.

As the business analysis function often forms part of the early and middle stages of work, we often find that although deadlines are not always looming, other people in the project team rely on the work we do and the analysis we provide as a precursor to their part. Therefore, the importance of delivering as early as possible is vital to ensuring the critical path is as efficient as possible and not held up by the analysis work we do.

For some of you, none of the following will be revolutionary. But for those new to the field, or those finding themselves overwhelmed by workloads or delivering results the following could pay real dividends for you straight away.

Focusing on what really matters

Charting a path is often thought of as the key driver to delivering success. As the saying goes “failing to plan is planning to fail”. For me, however, there are 2 stages to this.

Firstly breaking down all the activities required and creating a to-do list is a vital component, but where the real value lies, is in a time management and value delivery technique called the ‘Power List’, but more about that soon.

We are often brought onto a piece of work or project once the business already has the desired outcome in mind. The end goal is known and we are brought in to help understand how we will get there. As a business analyst, it is often our expertise which forms the catalyst for how we achieve the results.

Analysing the current state and its strengths and weaknesses, the new requirements to achieve the desired results, the change planning, the scope of testing, and how we will measure success, are all vital components of what we do. I won’t go into these but sufficed to say each one is as important and as critical as the next.

We break down each stage of our project delivery work into a list of things we need to deliver and these form the business analysis plan regardless of the methodology (agile or waterfall) or framework (Prince2, PMI etc…). Each day, each week, each project all have their own unique lists of tasks to do. Sound familiar?

The Power List

The ‘Power List’ is a simple and effective way to deliver what is really important. Each day you take your to-do list and regardless of its size you choose 1 or 2 of those items that provide the biggest value to the project. These are the tasks that you MUST get done and are the tasks you start with straight away regardless is how painful or complex they may be.

The key thing here is to not be distracted by other less important tasks. Those quick wins or small trivial tasks should all wait until your ‘Power List’ is done. The Pareto principle (also known as the 80/20 rule) states that 80% of results come from 20% of the effort. The ‘Power List’ is the driver for delivering the 80%. It ensures that you every day you are working on delivering the most vital component of the project.

You probably have those days in which you leave the office wondering where the time went and feeling like you achieved almost nothing despite being busy the entire day. By applying the ‘Power List’ it is almost impossible to feel like this as you are guaranteed to always be working towards the real value in your role.

Brian Tracy wrote a fantastic book on the subject entitled ‘Eat that frog’ in which he states that

‘Your “frog” is your biggest, most important task, the one you are most likely to procrastinate on if you don’t do something about it’

I often think back to my student days at university and remember getting stuck on an assignment. Rather than break it down into smaller pieces and work my way through each I would end up procrastinating and feeling overwhelmed. They when I’d be up against the clock and I’d finally got stuck in (because what other choice do you have when a deadline is fast approaching?), I realised that by just starting I would naturally overcome the barrier I had made up in my head. I’d kick myself for not doing it sooner.

I wish I had applied the power list principle back then as I’m sure I would have avoided many late nights in the library as the deadline approached.

Delivering

The ‘Power List’ is the solution to delivering the most value in the shortest amount of time but without action, a plan is just a plan. The following techniques when paired with the ‘Power List’ can really make a difference and allow you to get the right things done.

Pomodoro

A favourite technique of many and something I will often do in my daily life to ensure I’m focused on delivery and avoiding distraction is to use the Pomodoro technique. For those of you not familiar with this time management technique, it basically involves short periods of intense focus interspersed with short breaks.

For myself, 20 minutes is often the right amount of time for focus, especially in the office as being available for meetings with stakeholders or to answer questions the development teams have is vital.

I use a free app on my phone called ‘goodtime’. Although there are seemingly hundreds available, I really like the simplicity of the ‘goodtime’ app. I set the timer for 20 minutes, tap the screen to start the timer, and for the next 20 minutes, I will focus solely on one of the ‘Power List’ tasks. I won’t check my phone alerts or emails or work on anything other than the task at hand. Yes, there will be distractions as someone will come to ask a question, but the timer makes refocusing on the task much easier.

The Pomodoro technique puts an end to procrastination and overthinking. It allows you to get something done immediately leaving more time to refine the work, and often simply increases motivation as mental blocks are removed simply through the art of starting.

Binaural Beats

The other technique I will use when I really need to focus is the use of binaural beats. Binaural beats are a way to use sound frequencies to put the brain into a concentration state. It works by playing two different frequencies, one in each ear. Your brain will make up the difference in frequency putting it into what is often referred to as an alpha state. For concentration, a difference of 8-12hz between two frequencies is optimal for a concentration state. There is a lot of science behind the technique but sufficed to say, it is something I have found really useful. Especially so when concentration is proving difficult due to the surroundings or tiredness. It allows your mind to get back into a focused state and helps ensure your stay productive and focus on the task at hand.

There are plenty of sources for these tracks. YouTube has thousands for free. Pop on a set of headphones and give one a try.

Summary

If you have made it this far I hope this article has proved helpful. So to summerise:

Breakdown all your tasks into a to-do list
Take 1 or 2 of the items on your to-do list. Those that will prove to add the most value regardless of how complex, difficult or unappealing they are.
Work on these straight away and don’t let yourself be distracted from delivering them.
Repeat steps 1-3 every single day and soon you and those around you will realise the incredible amount of value you are delivering.

If concentration is proving difficult or your environment often leads you to suffer from distractions that keep you from staying on track:

Use a Pomodoro timer to help you focus intensely for short periods of time (just ensure you are taking short breaks in between).
Use binaural beats (via headphones) to actively help your brain regain its focus on getting things done.

Getting things done is good, but getting the right things done is great, both for you, your career and the projects you are delivering.

Requirements traceability: What, why and how

Written by LN Mishra on May 31, 2018. Posted in Articles. 1 Comment on Requirements traceability: What, why and how

Traceability is one of the lesser understood aspects of business analysis. It is indeed quite hard to maintain good traceability unless automated.

This is why BABoK® warns us being theoretical about traceability.

In this article, I would like to explain traceability concepts with help of an example.

BABoK® definition of traceability:

Traceability is the ability to look at a requirement and others to which it is related, linking business requirements to stakeholder and solution requirements, to artifacts and to solution components.

Traceability identifies and documents the lineage of each requirement, including its backward traceability (derivation), forward traceability (allocation) and its relationship to other requirements.

Traceability ensures that the solution conforms to the requirements. It also helps in managing scope, risk, time, requirements changes, cost and communication. It can be used to detect missing functionalities or to identify whether the implemented functionality is supported by a specific requirement.

Reasons for creating traceability are:

Assist in impact analysis for requirements changes.

Ensure requirements coverage: Understand how business objectives are implemented. Business objectives not traced to detailed components have not been analyzed and hence not included in the solution.

Requirements allocation.

Relationships

Derive

When one requirement is derived from the other. Stakeholder requirements are derived from business requirements. Solution requirements are derived from stakeholder requirements.

Depends

One requirement can be implemented only if the other has been implemented or easier to implement if the other is implemented.

Satisfy

Relationship between an implementation element and the requirements it is satisfying.

Validate

A relation between a requirement and its test case to validate whether the solution fulfills the requirement.

Let’s take a practical example of a requirement to list all products on an eCommerce store (such as AdaptiveUS.com/eStore)

Requirement

To list products in the ecommerce portal with their price

Derived from (Parent requirement)

Enable e-commerce for business

Dependent requirement (Prerequisite)

Payment gateway to collect payment from customers

Satisfied by (Allocated to Solution component)

Store front end

Validated by (Tested by test component)

Test cases to test store functionality.

This is a simple template to capture requirements traceability. You may transpose the same to handle multiple requirements in the template.

Being a Business Analyst, carrying burden of expectations

Written by Jai Manral on May 10, 2018. Posted in Articles.

Business Analysts work across different teams. We expect a lot from them. They are the face of a company when traveling to the client’s site.

Account Managers expect them to leave a long-lasting positive impact on clients, after all, account managers are always looking to get more business from existing clients. Project Managers are often worried that Business Analyst may overpromise on anything which they may not fulfill. Developers and testers have their concerns regarding requirements. They want requirements which are detailed, clear and easy to understand. And as for clients, they want you to be more than a “Note Taker”, someone who can add value to the project. And yes, they don’t want to repeat things which have already been conveyed to you or your team.

So how can you fulfill everyone’s expectation? Below are starting points to help you in this regard.

Know about your customer and their industry. You should be thorough with the products, services and the market your customer has focused on. This will help you during the requirement and solution designing phase to clearly visualize the need of an application. If you know the business of your client, you will be able to make a more informed decision and can contribute more towards your clients’ goal.
Make sure you know the boundary of your work and structure of deliverables. The best way is to go through Request of Proposals or Statement of Work to extract the information regarding a project. You may also want to interact with your sales team to get firsthand information on your client. If this is an existing account where you are joining late, be sure to know about the processes, templates for documentation and system in scope.
Engage with your internal team from the beginning until very last. It’s imperative that you know your internal team, their expectations and any concerns they may have. Discuss on the expectations from the documents you will be preparing. Regular interaction with the team will make sure that all that is needed (i.e., the requirements) has been conveyed and understood by them.
If working with different vendors in a project, make sure you know what their role will be in the project, what is expected from them and any dependencies to you (or vice-versa). Ask for these information upfront and plan your work accordingly.
In summary, the key here is to know the customer and their industry well. Understand the need and objective of the project, know about the key success criteria, avoid asking everything about everything and start contributing.

Being a Business Analyst is just not documenting requirements from customers, it involves business analysis which is fundamental to any project. You should be able to convey your thoughts and understanding to the clients, help them to understand the implications of insignificant requirements, and make them aware or contribute in understanding their competition. After all, in this era of constant change and stiff competition, no one needs a note taker. Be a contributor!

Inheriting Projects

Written by Tom McIntire on May 9, 2018. Posted in Articles. 1 Comment on Inheriting Projects

Working in a corporate environment we are often asked to drop tasks and projects that we are currently involved in, so that our efforts can be concentrated on other initiatives within the organization that needs our attention.

We often need to transition these tasks to other individuals in the same or similar role as our own.

“One of the hardest things for someone working in Business Analytics is letting go of a project they are working on or transferring it to another Business Analyst.”

You have already put in significant time, effort, and energy to bring the project and stakeholders together and now you are being asked to transition it to another person. The first thing that comes to mind is a younger version of myself that says “I don’t wanna share! This is my toy!”. I was an only child, so I didn’t have to share a lot when I was younger, but when I did it was an effort for my mother to get me to do so. Thank you, mom, for teaching me this important life lesson early on, so that it is easier for me to share as an adult.

“It is perfectly acceptable to share our work with others when we need assistance.”

I have been on both sides of the coin (giving and receiving). It can be strenuous for both parties for different reasons, but the analyst receiving the project from another will have to perform more work initially in order to be brought up to speed on the project. Many times, you may not even know which questions to ask or what information you need as you have not been associated with the project in any role.

“Working in the field of Business Analytics, one needs to remain flexible and open to change.”

I have devised the below checklist to assist with the transition process from one Business Analyst to another. The checklist is meant as a guide or a talking point when creating your very own Transition Checklist. The Business Analyst should be thinking about the potential answers to each of the items during the initial transition of the project. Each project is different and working in the Business Analysis field, we need to be committed to change. Therefore, each Transition Checklist may be different. The checklist below is created from the aspect of the analyst(s) receiving an active project, however, the analyst(s) transitioning the work to another should be proactive and communicate as many of the touch points listed below as applicable to the project.

Identify:

Verify the tasks, goals, deliverables, and roles in the phase(s) owned by your team
Identify what methodology is currently being used: Waterfall, Agile, Agile-Waterfall Hybrid
Identify the project goals and scope
Are the correct resources on the project or are there resources missing?
Determine if it is possible for the previous analyst to stay on the project as a mentor for a short time period
Conduct a meeting to introduce yourself to the new project team. Make sure to cover the following:
Review established expectations
Review established ground rules
Review key decisions made prior to your assignment
Review Stakeholder roles and responsibilities for accuracy
Inform group of what they can expect from you moving forward
What is the current communication style?
Is there a communication plan?
Where is the project documentation stored?

Analytical Services:

Meet with the current analyst on the project and complete a knowledge transfer
Walkthrough of the requirements and project scope
Review the current BA Plan and complete any updates needed
Obtain written approval of updates from key Stakeholders
What are the deliverables (completed and outstanding)?
Project milestones
Change Requests
Requirements
What is the current phase of the project?

Project Details:

Meet with the Project Manager to cover the project timeline
What are the key milestones that will need to be completed and the dates?
Record the impact/risk of the transition of Business Analysts on the project
What is the current health check of the project: At Risk, Poor, On Schedule, Ahead of Schedule
What are the dependencies or relationships with other projects?
How many Project Managers are currently assigned to the project?
How many Project Managers have been transitioned off of the project?

Solution Details:

What are the Known Production Problems that are to be resolved as part of the project?
What are the details of the Release Schedule?
Who are the Third Party Vendors involved in scope, requirements, testing, or implementation?
What are the defects associated with the project?
What are the identified constraints?

Top 3 Activities for a Business Analyst in a Discovery Phase

Written by Nick Stowers on April 19, 2018. Posted in Articles. 92 Comments on Top 3 Activities for a Business Analyst in a Discovery Phase

In at the deep end

So, you’ve just heard you’re going to be the Business Analyst on an Agile team that’s going in to a Discovery and it’s your first one.
For my first Discovery, it was daunting let me tell you. I already knew quite a few tools and techniques a BA should use during the lifecycle of a project, but what ones do I use that are particular to a Discovery phase?
For this blog, I interviewed other Business Analysts, Scrum Masters, Product Owners and Developers to get their view on what the role of the BA is in Discovery and I will use their opinions (along with mine) to provide what I think are the top 3 tasks a BA should carry out.

Time is of the essence

You may be thinking, ‘surely you just apply the right tool or technique for the situation?’ Good question and I would say this is true. However. Unlike a traditional project where the BA would investigate, analyse and document literally everything, in Agile, Discovery phases are given quite a short amount of time before moving to Alpha and this is where as a BA (along with the rest of the team), you need to use your time wisely as you just won’t have the time to do all those ‘traditional’ BA activities.

Now, there is a process to follow in that you can’t start to create a backlog until you know what the user and business needs are, and you can’t find out those needs until you identify your users and stakeholders. So, this is where we’ll start.

Stakeholders: Don’t just identify, analyse

The top activity the other roles identified as a key role of the BA was to understand and define the problem. However, before we get to that stage, we need to identify our stakeholders and users. And perhaps more importantly, understand the stakeholder’s interest and their influence in your project.

For me, this is a critical exercise that I don’t feel is given the importance it should at the start of a project. They either get done and are left static throughout the project or not done at all.

While the BA might lead on this activity, it’s most definitely an exercise the whole team need to be part of. My tip here is to put a stakeholder interest/influence matrix on the team wall (hopefully you have one, if not, get some whiteboards!) and give yourself and the team a couple of hours for the session. There are plenty of templates online you can use or if not, just draw it on some flipchart. Give the team around 10-15 minutes to identify who they think are stakeholders and begin to plot them on the matrix.

There may be some conflict where these people sit on the matrix but as long as you agree on who are the highly influential or clearly fit in to a category, the borderline ones you can leave for now.

In terms of analysis and potential time constraints you have, don’t go in to any particular detail and spend time creating stakeholder wheels or stakeholder management plans, the interest/influence grid is sufficient. In addition, use the matrix to create your communication strategy to define what methods you will use to show progress of the Discovery to stakeholders and how often you will communicate with them.

For identifying users, this will be something the User Researcher will lead on as they will be interviewing them but you as the BA should be involved in those sessions. After all, if you are going to be writing the user stories based on their needs, you need to get this first hand. You will also pick up good interview techniques from the UR.

Framing the problem to define scope

Ok, so we now have a list of stakeholders and users and it’s time to start engaging them. Before you start looking at things like defining ‘as is’ processes, pain points and setting up interviews with stakeholders to get this information, you need to have an understanding of what the actual problem is the team has been put together to fix.

You may have been given a mandate as to what the issues are but until you engage the people ‘at the coal face’, they are just perceived issues. The quickest way to get to the root causes is to get those key stakeholders in a workshop and identify the following:

• Why are we doing this work?
• Who are our users, clients and stakeholders?
• What outcomes might users get from this?
• What outcomes might the organisation get from this?
• What are our key metrics?

Now, a lot of information will come out of this session and I see the key role of the BA is to deconstruct all these thoughts and views and turn it into something meaningful……like a problem and a product vision statement.

These statements are short and provide an overview of the vision, problems and methods the team will use to address them. It should be no more than a few sentences which is a difficult task and one I suggest should be collaborated and created with the rest of the team.

Once you are all happy with it, you need to share it with the stakeholders. Not to get agreement or for endless reviews, but to ensure everyone is on board with what the team are trying to achieve.

As some (maybe most) stakeholders may not be aware what a problem and vision statement is, you may have to spend some time explaining its purpose to them. Point out it’s not a personal view, but a collective interpretation of perceived issues that need addressing.

The backlog

As with defining scope, starting a backlog of user stories is not solely the responsibility of the Business Analyst but is something the team are responsible for and should contribute to. That said, the BA does play a critical role in the creation of a backlog. And that is to ensure that what goes in to it is of an acceptable standard. After all, rubbish in, rubbish out right?

I’ve seen this so many times whether it be on a new product or one that has progressed in to Alpha and Beta where the backlog has become a bit of a dumping ground for every idea, whim or ‘wouldn’t it be good if’ thought.

For a start, everything in the backlog should either be related to a user need or part of the product roadmap. If it doesn’t, it shouldn’t be there. If someone does have an idea worth further exploration, put it on the user research/UX hypothesis board so they can establish whether there is an actual need for it.

Before you start creating a backlog, get the team together to agree ground rules. I suggest you hold a user story writing workshop with the team where you can begin outlining the backlog. This ensures the team are involved from the start and you can agree principles with them to stay clear of the ‘bloated backlog’.

Who might I be working with in a Discovery team?

Discovery teams can be made up of several roles, most commonly; a Product Owner, User Researcher, Business Analyst(s), Subject Matter Experts (SMEs) and a Scrum Master/Delivery Manager

I’ve worked on Discoveries where a Scrum Master/Delivery Manager wasn’t part of the initial team and I found the focus and cohesion of the team became lost at times due to a lack of discipline in setting and achieving targets (i.e. sprint planning). When time is the key factor, the team needs to stay focused on its goals which I think the Scrum Master brings.

You’ll start to get the impression now that the Business Analyst is not really ‘solely’ responsible for the outputs of a Discovery but is involved in all of them. One of the people I interviewed for this blog explained his view of the role of the BA in a great way. He said they are ‘decoders’. By this he meant they translate all the information gathered (and there will be a lot of it) in to outputs that not only the team understand, but any stakeholders.

I believe this is the primary role of the BA however in an Agile Discovery, you should be able to evaluate what you are doing is of value and that you’re not just ‘going through the motions’ because of pre-defined duties of the Business Analyst.

I hope this has been helpful and that if you are asked to join a Discovery team, you are equipped to get engaged in those top key deliverables to make the Discovery a success.