Tag: Tips

Project Managers: 7 Things They Want Their Business Analysts to Excel At

Written by Brad Egeland on January 4, 2017. Posted in Articles. 1 Comment on Project Managers: 7 Things They Want Their Business Analysts to Excel At

I decided to perform a bit of a survey or experiment or whatever you want to call it.

I decided to ask several career project managers I’ve personally worked with and a few that I’ve connected with online as to their thoughts on what they wished, wanted or were grateful that their business analysts excelled at on the projects they managed with them. After rummaging through their wishful and rambling responses, I’ve come up with these 7 general themes…

Customer interaction.

The project manager is the key customer facing individual on the project. No question. The PM leads the initial project activities with the customer including kickoff, weekly status calls, and ongoing – potentially daily and sometimes hourly – communication with that project client. But having a business analyst who knows their way around the customer is a huge benefit to the project manager, the team and the project in general. When I’ve had business analysts who felt comfortable conducting meetings and requirements definition sessions with the client on their own, it’s freed up my time and mind to handle other activities on the project, charge less to the given project thus keeping the budget in good health for when issues need to be addressed (and there will be issues!), and perform other work on other projects.

Being technical.

This could also read “being familiar with whatever processes necessary given the industry the project pertains to.” I said “technical” because I’ve really only ever led technical projects. Having the right industry and technology knowledge will smooth the communication process with the project team that the BA really needs to have in order to be properly effective.

Tech documentation.

When the project manager has a business analyst who knows their way around a good project document deliverable, it is truly a great thing. I realize experienced PM’s and good BA’s probably take this skill for granted, but it is not a given. Nor is attention to detail which can lead to error-prone deliverable documents. I know, I’ve had it happen. It resulted in me and my team going to peer reviews on every deliverable going forward due to one business analyst producing three consecutive error-prone versions of the same documentation deliverable.

Being organized.

The organized business analyst contributes greatly to the project engagement without needing close supervision and oversight that a less experienced and less organized business analyst otherwise would. When the PM has confidence in the BA’s ability to just take the ball and run with it on decision-making, project team communication, and customer interaction, the freeing affect for both is incredibly productive.

Handling project budget issues.

I think most business analysts are pretty smart when it comes to expenses on the project. They think more like PM’s who are accountable for such things than tech team members who expend the hours that are in the budget and need to show 100% (or close to it) utilization. In other words, most business analysts – unless they are tech leads dually acting in the business analyst role – know they are considered more “management” than not. I’ve always said that keeping the project budget within 10% of target makes it much easier to stay on track in terms of dollars and budget. Staying in the 0-10% range means you’re always in the zone of “acceptability” and it isn’t likely to go crazy and leave you with a 50% budget overrun to try to fix…which you won’t likely ever be able to do. Having the business analyst who can understand that and help manage that budget and keep it on track is win-win.

Leading meetings.

This one is more than just customer interaction, of course. The business analyst, in many cases, is like the team lead. Interacting very, very closely with the tech lead on the technical projects in the requirements definition process and translation of those requirements into functional design documentation and a technical design document from which a viable project solution can be built. The BA must be, then, a trusted and accurate and effective project communicator. One who knows how to plan for, facilitate and followup on meetings with the team – and the customer, of course. Knowing how to run a status meeting, take notes, put together a meaningful agenda and project status meeting goal and how to follow up afterward with participants to ensure everyone has landed on the same page. Also, as important, is knowing how to put the right people in the seats at every meeting they conduct. It doesn’t do any good to call the right meeting to discuss the right topic if no one shows up. if you can run a good meeting that makes people want to attend and participate in rather than avoid, then you are golden. Someone who can get 100% attendance and participation is critical to project success.

Understanding PM processes, practices and tools.

Finally, yes…they may not be dually acting in the role of the project manager, but knowing how good project management executes and delivers is very helpful. That way they understand what the project manager is doing, is responsible for and probably will need help with. The more the PM and BA know about each other’s roles, the easier and more productive that relationship will be. And that’s a good thing. Think Batman and Robin. And the PM is not always Batman – it depends on what the responsibility is at the moment. They work well together and help each other out. Not quite like completing each other’s sentences…that would be weird. But close. BAM! POW!

Summary / call for input

The project manager and business analyst should work hand in hand together in a perfect world. Nothing is perfect, but my most successful projects have certainly been spent working with a business analyst who could take the ball and run with it. And most I’ve ever worked with have been able to do that – it seems to be in their nature and work ethic and it certainly makes the project run more smoothly and has always resulted in a more confident and satisfactory delivery team to project sponsor relationship.

Readers – what’s your take on this list? If you weren’t included in my small survey…and yes it was a very small pool…then now is your chance to share your thoughts and experiences. Do you agree with this list? What would you change about it? Please share and discuss.

5 Tips To Finding A Business Analyst Job In A Recession

Written by Englebert Lau on September 8, 2016. Posted in Articles.

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.

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

Written by Richard Lannon on August 30, 2016. Posted in Articles.

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.

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

4 Prototyping Myths and Mistakes a Business Analyst Should Avoid

Written by Dominic Infante on July 28, 2016. Posted in Articles. 1 Comment on 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

Written by Richard Lannon on June 7, 2016. Posted in Articles. 2 Comments 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.

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.

Richard