Tag: Tips

5 Tips To Finding A Business Analyst Job In A Recession

Unfortunately, I was one of 200 people laid off by ConocoPhillips on March 18, 2015. After the layoff, I found it was extremely challenging to find work as a Business Analyst / Project Manager in Calgary.

I applied for many jobs through various employment agencies, and there were consistently 100 or 200 people applying for the same positions. Recently, an article in the Huffington Post indicated that Alberta’s Unemployment Rate Hits Highest Level Since 1994. I’ve written five tips for finding work as a Business Analyst during a recession.

Related Article: 7 Reasons I Didn’t Hire You for That Business Analyst Position

1. Get certified

A month after I was laid off, I earned my CBAP certification in April 2015. When I applied for multiple positions on http://www.indeed.ca, it has become increasingly common for employers to ask for Business Analysts with a CBAP certification. A Watermark survey in 2014 indicated that there are 4,049 CBAP professionals worldwide, and 723 CBAPs in Canada. A CBAP designation sets you apart, because only a fraction of experienced Business Analysts has taken the necessary time to go through the exam process.

2. Participate in your local IIBA chapter

After I passed the CBAP exam, I started volunteering as a Study Group Coordinator for the Calgary IIBA® Chapter. It was helpful to meet other Business Analysts in Calgary. Occasionally, people that I met would share information about various employment opportunities.

3. Expand your job search

Since it was difficult to find work in Calgary, I expanded my job search across Canada and the United States. Finally, after 15 months, I found work as a Business Analyst in Regina, Saskatchewan.

4. Talk to employment agencies

Currently, I work as a Business Analyst Consultant for Visionpool Business Services Incorporated. When a contract opportunity came up at SaskEnergy, Visionpool paid for my flight ticket from Calgary to Regina so that I could interview in person. I’m extremely fortunate that Visionpool was willing to take the risk to purchase my flight ticket in the event that I was hired by SaskEnergy.

5. Be persistent

In a 15 month period, I sent out 500+ resumes and had 20+ interviews. In my case, persistence finally paid off when the right opportunity presented itself in a different province.

Looking for a BA Job?  Check out the BATimes Jobboard – lots of new jobs, continually updated.  Looking for a Project Manager job?  We have a Jobboard for you, too!

Strategy Spotlight: 6 Ways the Business Analyst is a Management Consultant

I make no bones about it. Over 27 years ago, as I prepared to leave university, I wanted a career where I could do the stuff I did in post-secondary school but in the private sector.

Read, research, write, chat with people, create relationships, share ideas, improve organizations and occasionally attend beer and pizza events that were an opportunity to network or have fun, if you know what I mean, right.

As I skimmed my career horizon, talked to people, and took the time to work through the book, “What Color is Your Parachute” by Richard N. Bolles (recommend if changing careers), I realized I did not fit the normal get-a-job world. I learned that I needed to feed my entrepreneurial spirit, analytic abilities, and strategic thinking to make business better. Somewhere I learned about, ‘the management consultant’ (place dramatic music here, please) and started reading everything I could about the profession.

Related Article: The BA Competency Consultant Role

This week I did a career audit and review – something I recommend everyone should do from time to time. This brought me to 6 Ways in which the Business Analyst is a Management Consultant.

It’s a Problem to Solve: Many professionals work their whole lives to become a project manager or an executive. They want to climb the corporate ladder so to speak. Some professionals prefer to skip all that implementation and operational management stuff and get to solving business problems now. As a business analyst, while helping to expose challenges and opportunities, you get to work with all levels of the organization and develop your executive thinking and strategic abilities. You get to define the problem, ask the important what and why questions to unravel issues and develop solutions.

Do Many Things: This is something I love about the overall consulting field, being able to do many things, see many things, and be many things. I was once asked, by a CEO, what would a perfect week look like for me. I laughed and said, on Monday I write, connect with people and prepare, Tuesday, I attend a few meetings, do a breakout session and coach/mentor clients, by Wednesday I am keynoting at an event, updating key stakeholder status and designing a new system, Thursday and Friday are spent training and/or facilitating a session and then back to the office to debrief and prepare for the next week. Best part, many interactions, many cultures, helping many people and doing many things. You can specialize in an industry or a niche, even ride the wave of the next best thing. The business analyst and consultant do this. The choice is yours.

Many Hats to Wear: Recently I experienced the perfect fortuitous juxtaposition of interests. I was invited to a 1920’s themed volunteer appreciation dinner being sponsored and hosted by a client. I ended up sitting next to a university Associate Dean, senior board member, and business person. He asked the magical question, what do you do? Sitting there, in my 1920’s time period attire, wearing my fedora, with my strategic business analyst/consultant’s smile, I delivered my elevator speech. He looked at me and said, you are a man of many hats. I think he is correct, if you get to wear many hats and like it, you may be a business analyst turning consultant. You get to be many things, play many roles and with many responsibilities.

An Instant Business Network: You may not like to network, I get that. But as a business analyst/consultant just by the nature of the work you do you get to build a vast and valuable network. Just think about it. You get to work with internal and external clients due to the different projects you are engaged in. Your stakeholder list includes all levels in your organization. Externally you make connections with vendors of all sorts.

Recently a business associate of mine lost his job as a strategic business analyst at a major corporation. He was right sized. A week later, a vendor called him and asked if he would join their team. He would be working for a company with an office in Pal-Alto, California. He went from commuting to work every day to working virtually and going to California for meetings during Canada’s winters. The key point, you get to build relationships. That’s important.

You are Seen as an Expert: I learned this when I was with one of the big consulting firms. Consulting firms and the profession is about rapid learning. Even independently, you can focus on a key expertise and grow your abilities. The best part, you get to learn on the job. I have often said the business analyst is paid to learn and develop their expertise. This often happens due to the fast pace of projects and the teams you are working with. If you are with a firm, they will send you to training and develop your expertise for the various engagement/projects you work on. You learn to leverage and build your expertise. That is exciting!

Flexibility is a Survival Tactic: Years ago I worked for a very operational company (for a short bit). It was a good experience as it helped me understand the day-to-day needs of clients. I could plan my day and for the most part, I could do the things that were required.

For the business analysts as a consultant this might be a bit of a challenge. Sometimes your day ‘changes on a dime’. For example, a client calls and says “I have two people flying in today can you meet with them to get the new systems requirements from them? They are available this afternoon.” Your day just changed, and you need to adjust everything fast. The reality is as a BA you may be working on several initiatives (an IT assessment, a policy review, maturity audit, risk assessment or a process model) and you need to manage everything and adjust.

Final Thoughts: As I write this piece I find that I am becoming even more excited about the work a business analyst as the consultant does. I feel as if I want to share all the projects I worked on over 3 decades and the many lessons learned. But I can’t do it all at once.

Recently, during a podcast interview, I hosted (BA Times Podcast airs September 2016), my business colleague and guest, Bob Prentiss (Bob the BA), reminded me that not all business analysts become project managers. There are now many career avenues to pursue.

I am excited for you, the professional business analyst, about the future projects and initiatives you will work on. The ones you can’t even see coming yet. But they are there. Interestingly being a business analyst and consultant (internal or external) provides you a platform on which to develop many skills, to try new things and to boldly go with no-one has gone before. Good luck.

Do your best,
Invest in the success of others,
Make your journey count.

4 Prototyping Myths and Mistakes a Business Analyst Should Avoid

You live and you learn.
Make better mistakes tomorrow.
Fail faster.

Yes, to err is human. When done right, it’s also an important part of defining and designing great software. From conceptualization to final delivery, you’re likely to design and redesign your ideas countless times using some combination of wireframes, prototypes, and mockups. These tools allow you to translate text requirements into visual ideas, explore them quickly, and correct mistakes early before they get too deeply embedded in your designs and are too costly to fix.

Related Article: Bring Your Requirements Practices out of the 80s

Here’s a brief look at the similarities and differences between wireframes, mockups, and prototypes, and four mistakes to avoid when using them on your project.

Streamlining your design process

One of the best things teams can do early in a project is to level-set about what documents will be used, and what type of information each is meant to convey, so that stakeholders, designers, and developers share the same expectation about when they’ll review the structure and function of a website or application.

Let’s start with wireframes. They’re like the blueprint of a building. Although high-fidelity wireframes are used, most tend to be low- to medium-fidelity schematics that help you understand the layout and arrangement of all the things that must fit into the space. They’re quick to produce and share, and help teams focus on big picture basics versus detailed design elements. But a blueprint is not a house. As a static image, a wireframe won’t let you see how the thing you’re designing would fare when used by a human.

Mockups are a little harder to define because they often mean different things to different people. I’ve seen the term used for something that resembled a lo-fi wireframe, but also used for something much higher fidelity that resembled the final product. That said, the term is most often used for something that takes wireframes a step further, possibly adding color, type choices, images, and even functionality.

That’s where prototypes come in. They’re a powerful medium for testing perspectives and interactions–all the things that make the product really work. Since they’re meant as a testing device, having some detail makes sense to give users context.

Agreeing on how these tools are used in the design process helps us dismantle our first mistake:

Mistake #1: Treating them exclusively as a design tool

It’s a mistake to think that wireframes, mockups, and prototypes, should only document the contributions of someone whose title includes the term “designer.” Hold on, though. Before you get your pitchforks and torches, let’s be clear about what we’re saying. Text-based BRDs still have their place. And maybe that place is a bit closer to the design than it’s been in the past.

The most innovative companies in the world understand that design is a verb, not a noun. It’s not about creating design documents. It’s about designing a process that’s participatory and collaborative.

Couldn’t you say that a business analyst who is eliciting requirements is starting the design process? How about a developer who’s thinking about the script for a page load indicator? Neither fits neatly into traditional concepts of design, but they’re each crucial to the end result.

When designs miss their mark, it’s not necessarily because you have bad designers or business analysts on the team, or that your user stories were poorly written. It’s more likely that there was a communication breakdown somewhere in the line. Finding ways to integrate documentation is a way of approaching the human-centered design process so that it benefits not only the end user but also your project team.

Think about the value of facilitating collaboration and communication by allowing teams to view comments, annotations, and requirements in the same screen as the designs. It’s social and synchronous and eliminates a lot of the errors of passing documents back and forth and hoping details don’t slip through the cracks or get misinterpreted by other team members.

Mistake #2: Believing You Have To Give Up Speed Or Detail

As the old project management joke goes, when creating a project, clients can choose to have it done fast, good, or cheap. But they only get to pick two. The notion being that to get a project done fast you’d have to give up detail and accuracy. On the flip side, nailing down the details would take a long time and come at a pretty hefty cost.

The mistake in this scenario is overlooking the flexibility teams have in how much detail they’ll provide in each deliverable and at each stage of the design process. It also ignores the relatively new tools now available. Wireframes, mockups, and prototypes can work to help quickly define the layout and function of the application. The impact that these visual and interactive tools have on speed and detail can’t be overstated.

Which deliverable is most useful depends on your project and the problems you’re trying to solve. We’ve all used rudimentary wireframes to get through initiation, or rapid prototyping to walk through user flows, drive analysis, and find functional gaps. As more teams adopt Agile and Lean methodologies, it makes sense that the tools driving requirements, user stories, and design should evolve too.

When teams can use visually interactive tools, collaborate, iterate quickly, validate and build consensus, you’re actually able to get both more speed and detail.

Mistake #3: Focusing on the outcome instead of the process

It’s common for teams to concentrate mistakenly on using wireframes and prototypes to problem solve on already decided upon directions and ignore the value these tools offer in ensuring the right questions are being asked before answers are agreed on.

The danger in focusing too intensely on finding solutions is that it locks you into a certain way of thinking. That’s the opposite of innovation. In building any software application, you’ll find that using the right design tool can elicit requirements that hadn’t been thought of yet, and expand the number of opportunities for finding the simplest and best approach.

Rather than schedule reviews featuring big reveals, teams should embrace opportunities to walk through designs and requirements together and ask things like, “How would you expect this to work?” or “Where is the user taken after they click this button?”

The future of collaboration needs to include integrated environments where wireframing or rapid prototyping can happen in the context of mapped requirements, comments, and annotations–not separate from them. This approach holds the promise of stanching inefficient practices like blind handoffs that lead to broad interpretation or worse, back-and-forth email discussions that block progress or broaden the scope.

Reviews that include the right stakeholders and focus critique to specific problems tend to stay focused, productive, and on track. When all of that happens in the context of the design itself, it will help you identify problems and definitions as well as iterate ideas and test their validity. In short, you’ll get better answers, faster.

Mistake #4 – Elevating aesthetics over annotation and agreement

Better design does not mean most viewed on Dribble. As design programs continue to proliferate and become increasingly specialized and fine-tuned for UI design, it can be tempting for talented designers to spend hours nudging pixels to get a layout just right. But to what end?

Great design is as much about user interaction as it is about pixel perfection. Spend the time finding the right cadence to design, review, test and repeat.

Find a tool that allows you to review designs together, elicit feedback, and iterate on what you’ve heard in real-time. If they can integrate with your existing ecosystem, allowing communication and traceability with the tools the rest of your teams use, even better. This allows timelines to be adjusted immediately. If you’ve ever worked on a distributed team, you know the value of having teams work in unison and how hard it can be to implement.

Use prototypes as visual expressions of text requirements that help business stakeholders and development teams gain consensus on whether or not business and functional requirements have been met.

And keep in mind that the heart of consensus is a based on a cooperative process where everyone’s input is carefully considered to craft the best outcome. The more methods you use to compile and summarize that input, the harder it is to synthesize the information you’ve gathered into a solution that represents a commonly agreed and accepted set of features and functions for your release.

Getting to a single source of the truth

When one team owns requirements, another design, and a third workflow and timeline documents, it’s hard to agree on where you are or what to do next. Current design tools only exacerbate the problem, focusing on rendering images without providing enough context or connection to other project documentation. Lack of requirements integration is truly an Achilles heel of today’s software design process.

As the Agile Manifesto alludes, the primary issue with communication is one of understanding, not of documentation. The best approach to avoiding the common mistakes listed here is to base collaboration, not around documents that merely reflect design decisions, but around shared communication tools that offer teams a single source of “truth” to rally behind and shape decisions on.

Strategy Spotlight: Benchmarking & Baselining Your Organization in 6 Easy Steps

You cannot conduct strategic business analysis or project management without benchmarking and creating a baseline. That is a fact.

I have seen times where executives and professionals skip this part of the planning process, thinking that they have all the information they need to document the current state. I have seen a lot of incidences where these people have been wrong and engage in a form of blame-storming when something was missed.

Related Article: Strategy Spotlight: 8 Common Strategic Planning Mistakes You’re Making

When working on a project, whether a pre-initiative or post-agreed, you need to focus on your benchmark and create a baseline to ensure you are clear about your present situation. A benchmark is a standard point of reference within your industry against which things may be compared or assessed. A baseline is the starting point used to compare your historical performance. Both are connected in the world of business analysis, sometimes interchangeable. The definition can change based on context.

Benchmarking became an important part of business performance management and a key input into financial analysis and business process improvement. It is also a powerful tool in change and transformation analysis forcing executives to look at the reality of the business through the facts. This is a practice that can become extremely uncomfortable for some people at times.

When I was thinking about this blog, I reviewed some of the steps that I have taken to benchmark a client’s internal and external situations. I realized that for me, benchmarking and baselining followed a standard 6 steps of activities.

1. Preparation

You will often hear me say preparation is the key to the success of any engagement. That is the truth in facilitation and in benchmarking activities. In this case, preparation has to do with your initial interviews and discussions with the leadership team to help you understand where their thoughts are at present, focusing on finding out ‘what, why this and why now.’ As part of this preparation, you need to know to what level the stakeholder is invested in the situation. Is it an emotional connection, being dictated from elsewhere or are they just stepping through the steps? This is all important to know.

2. Research

Getting the information you need is all about data collection. Information can be considered primary or secondary. Primary information is an account of the event from an original source. Secondary information is an interpretation of the account of the event.
There are many means of getting the information you need. I often use a three stage questionnaire process with the primary information holders and pre and post interviews to get a present state understanding for benchmarking. I expand my understanding by adding documentation reviews from inside and outside the organization.

3. Analysis

This is a key part of the pre-planning process often requiring information integration, leveling data and checking the sources and facts. You may need to normalize the data to ensure that a direct comparison is possible for operational subjects and issues. The analysis needs to provide comparisons, look at the gaps, cover all strengths and weaknesses, and be improvement focused. By this point you should have a clear state of the company, the project, the industry or application.

4. Presenting

This could be called reporting. It is just a matter of what the deliverable is. Prior to doing any planning type session (workshop, review, discussion), I do a summary of findings. This summary is laid out in such a way that the high-level stakeholders get a story of their present situation and is used for future planning. It is often delivered as a high-level, point form, executive summary with the supporting summary of findings behind it. It is not an extensive report – only a summary of findings. There is a difference. Accompanying a summary of findings might be a 6-slide deck using images to capture the data components.

5. Lessons

I have always liked the expression “forewarned is forearmed”. I think that is what lessons learned should be about, especially when we are doing benchmarking.

During the process, the business analyst should have gotten a clear picture of what I call the “truth”. The issues at play are known, and you should be able to pre-determine how things are going to play out and therefore plan more effectively. At a higher level, the best performing organizations share information and best practices for the benefit of all. If your baseline and benchmark are clear and honest, then you can start to focus on solutions and actions that need to be taken.

6. Actions

It is great to use the word “actions”, but it should not come before planning. In other words, “plan to act” with a well thought out implementation or action plan. This can only be done after the lessons have been accepted, integrated into the key stakeholders thinking (planning team) and the lessons learned can feed into the planning process.

The focus here is what you need to do to go forward based on your benchmark and baseline for your organization with all the common constraints. Dialogue should be forthcoming.

I can’t even remember the number of times that I have been part of benchmarking an organization or system through a combination of interviews, surveys, documentation, industry reviews, and workshop facilitation. I’ve participated in all of these activities just to get a clear picture of the state of things.

I do believe the process can be standardized and applied to any situation where getting clear on the present state is important and benchmarking to internal or external standards.

Developing good benchmarking and baselining skills is important. Chances are you will find yourself following a very similar process each time. I would encourage you to document your approach and share it. It is the place where good business analysis and planning starts. I hope this helps.

And remember:

Be your best, invest in the success of others, and make your journey count.


Requirements In Context Part 3: Scope = High-Level Requirements

The first article in this series established the context of requirements being addressed are those that relate to business information systems and that various contexts have an impact on those requirements. The second article addressed the first of these contexts – Functional. That context was further divided into three conceptual levels labelled Functions, Processes and Activities. An example high-level requirement was presented at each of these levels.

Project Scope

This article moves on to a different context – Project Scope. We will see how scope statements, when making reference to business functionality, leads directly to high-level requirements.

Gathering requirements for a business information system is most often done within the context of a project. Approval of a project includes its sponsors signing off on its scope. The scope of a business information system project is typically defined in functional terms. Items in scope make reference to (or should make reference to) business functions, processes and/or activities that are to be delivered.

Related Article: Using Feature Trees to Depict Scope

A Context Diagram Is Worth A Thousand Words

In addition to the bulleted item list of scope, it is very common for the project initiation document to include a context diagram. The objective of a context diagram is to illustrate what is inside the system and what is outside. Things outside the system represent sources and/or consumers of data. The original form of context diagram comes from Dataflow Diagramming (DFD). The top-most level of functional decomposition using DFDs was considered a context diagram. The Unified Modelling Language (UML) Use Case modelling also supports a form of context diagram. Both of these diagramming techniques represent ‘the system’ and both portray things outside the system boundary. The DFD term for these outside things is External Entity. The UML term is Actor. The definition of these two terms is virtually identical.

tasker part3

A DFD context diagram says nothing about the functions inside the system. That is left to subsequent levels of functional decomposition. Clues are provided by labels given to the data flows. The Use Case context diagram provides more of a clue to the functions within scope by including named use cases. Data flows in a DFD context diagram connect only to the system. Actor connectors in a Use Case context diagram connect to one or more specific use cases within the system.

High-Level Requirements From Project Scope

Examples of high-level requirements were presented in the previous article based on a high-level business function, a medium-level business process and a low-level business activity. We are about to present an example of a project and its scope. As mentioned above, the scope of business information system projects is very often expressed in functional terms. It should, therefore, be possible to derive high-level requirements from scope items.

Consider the following situation involving a large hypothetical on-line retailer we will call Nile.com:

Nile.com has a well-established purchase process for its on-line customers. The check-out portion of this process includes activities for identifying the intended shipping address and for providing some form of payment. What the process does not currently include is anything to do with tax on items being purchased. As the result of pressure from various tax authorities this needs to change.

In establishing a project to deal with this change in the business environment the following scope items were agreed by the business sponsor and signed off:

  • Maintaining tax-related details for designated tax authorities
  • Determining applicable tax on items being purchased
  • Including applicable tax with purchases
  • Accounting for tax charged

The Use Case form of context diagram for this example would look like this:

taster part3 2

Scope items will seldom be stated so conveniently that they can be converted one-for-one into the names of use cases. For the sake of brevity, please accept that the scope items in this example are “ones that I prepared earlier.”

The objective of this article is to show that it is possible to derive high-level requirements based on a project’s scope. The following are examples of such requirements from the scope in this scenario:

Scope Item 1 – Maintaining tax-related details for designated tax authorities

The system shall support an administrator maintaining tax-related details required to perform tax determination. This includes establishing tax authorities that are the source of tax rates and to whom collected taxes need to be paid. It also includes mapping of products to tax rates for each authority where there are product-specific rates or specific product types that are tax exempt.

Because charging tax is new to this organisation there may not be an in-house subject matter expert available when it comes time to sorting out the details for this requirement. Until more is known this high-level requirement acts as an appropriate placeholder for what is likely to be a number of business processes. One would likely be needed for setting up new tax authorities, one for setting up the tax rates and where applicable, one for specifying different rates for different product types. The requirement from a business perspective is fairly straight forward – maintain whatever details are necessary to be able to charge tax. The devil is in the detail.

Scope Item 2 – Determining applicable tax on items being purchased

The system shall be able to identify the appropriate tax that applies to the purchase of a given product based on the product type and the tax authority(s) that have jurisdiction where the shipment is to be delivered.

Where the previous requirement calls for wholly new business processes to be supported within the business information system, the functional context of this requirement would be somewhere within the “Identify the shipping address” activity within the “Purchase” process. At this point the product(s) are known, and the shipping address details can be used to determine any applicable tax authority(s). Subsequent detail requirements would get into how an appropriate tax rate is determined and specifics of where that rate is used in calculating the total charge to the customer.

Scope Item 3 – Including applicable tax with purchases

The system shall present to the customer all applicable tax amounts as part of the purchase process.

This statement should be sufficient as a high-level requirement from a business perspective. Part of the detailed requirements analysis would include identifying all of the places where the customer ‘sees’ purchase price details. Each of those places will require modification to include whatever tax applies, if any.

Scope Item 4 – Accounting for tax charged

The system shall report charged tax amounts as a distinct component of each purchase to the general ledger system identifying appropriate GL Codes and the designated tax authority.

Wherever money is involved the organisation’s general ledger needs to be kept informed. In this case it is unlikely that there will be any new processes or even activities required. Reporting to the GL will be in place for the current untaxed purchases. This reporting will just require an enhancement to include the tax amount and its corresponding GL Coding. There should also be an existing Accounts Payable process that handles making payments to suppliers for the organisation. The different tax authorities that are to receive payment of collected taxes should be covered under that process.

Next Time – Keeping High-Level Requirements High-Level

The four requirements derived from the project scope items would not be the only ones for the whole project. But it must be said that they cover the agreed scope of the project and that they are high-level (not slipping into detail). Next time we will look into how to keep high-level requirements high-level when dealing with stakeholders that are asked to participate in the context of “Gathering high-level requirements.”