Tag: Tips

Certify or Not to Certify – That is the Question

Written by Stewart Mednick on April 6, 2017. Posted in Articles.

I do not have a certification. I do not have a string of capitalized initials after my name.

I do not need to have the affirmation that I am knowledgeable, skilled, or experienced by having extra ink printed on my business cards.

However, perhaps you do have a certification; a string of initials after your name, and a deserved sense of pride that goes along with that accomplishment. After all, to be able even to submit a CBAP application you must have 7500 hours of BA experience that is verifiable. Yes, I can see how that certification can entice many toward that elusive “pot of gold” career game-changer.

A certification can be worth the pursuit as much as it cannot be. The variables to determine a value-added proposition to your career are many; are parabolic, and are personal. Many times, a certification is pursued under the guise of the qualification for employment. I will tell you this: if an employer states a CBAP as a requisite qualification for a job, then perhaps that company does not understand what they even want and why! I say this because it is all about the numbers:

There are approximately 6700 CBAPs worldwide.
There are approximately 2500 CBAPs in the United States.
There are approximately 120 CBAPs in Minnesota; 70 in the Minneapolis/Saint Paul metropolitan area (where I live).

There are no hardcore statistics, but there are estimated 1.5 million analysts in the US. There are an estimated 5,000 BAs in Minnesota. 120 CBAP certifications are 2.4 percent of the BA population. If an employer requires CBAP certification to be considered for a job, then their population sample to choose from will be very slim. The good news is if you have a CBAP, then you are a shoe-in for the job!

Does it matter to your career if you are certified? In the above example, it certainly could. But what about a break out of the ‘value-added variables’ I eluded to above:

How long have you been in this career path?
Do you have formal training?
Have you been mentored?
Is your experience industry specific?
Are you a member or an officer of a professional organization?
Have you been published, a speaker at an industry event, or provided training in your field?

I feel the above list of variables could certainly trump a certification. I say this based on the premise of the resume; what is the first section of a resume (excluding a summary)? It is work history/experience. The second section is education. The last section, typically, is professional certifications, awards, accomplishments. Personally, I have over 25 years’ experience in various industries. The pursuit of a certification would not be prudent since it will render me no value. I am at the top of my field in title, experience, and compensation. Should I choose to focus on a different industry, then perhaps a certification can add value, especially if that industry is in high demand of filling job vacancies, like in the field of security. If an individual with 5 years’ experience and that many years out of college ask me about certification, the conversation will be very different and very PRO-certification as well.

I have focused mostly on a CBAP so far. There are other certifications that can enhance one’s career if a BA is looking to diversify. Many BAs also pursue a Project Management Professional (PMP). Some look to Agile and pursue Certified Scrum Master (CSM). There are security certifications, business process certifications, change management certifications, IT specific type analyst certifications, and on and on and on.

To determine if a certification will help you or is worth the investment in time and money, you must perform a career assessment and lay out your future goals. Do you want to follow a career path of the technician or the manager? Is your current job title a stepping stone for a bigger goal or is this job title going to be prefixed with “Senior” or “Lead”?

One thing that may be a bit tricky is to acquire a certification as a means of entry into an industry. If I am a Senior Business Analyst and pursue a certification in security, a Certified Information Systems Security Professional (CISSP), will I be guaranteed a job in the security field? Considering that I have been in the healthcare industry my whole career, perhaps not. However, as stated above, this is a high-demand industry, so perhaps that will be the golden ticket for securing a job. These are all things to consider.

Some industries do require a certification as a requirement for entry; law, medicine, financial planner, for example. Until there is regulation, a certification will not be a mandatory requirement for entry into whatever that industry job world could be from project management, business analysis, or scrum. Regulation of business analysis will probably never happen, which means that the ones who are certified, may stand out as unique, and perceived as experienced, but certainly do not corner the market unless the certification process is abused, that is. I have seen the following in a LinkedIn profile (the name is changed to protect the guilty):

Joe Lunchbucket CBAP, PMP, PMI-PBA, PMI-RMP, CSM, ITIL, CRM.

If you were an employer, would you be impressed or not?

As an employer, I feel if you are going to spend all your time certifying, how can I trust you actually know anything on an expert level of any of those fields? Some people may be impressed with quantity; I say err on the side of quality. I would say pick one, two, perhaps three certifications and just do those well. It just looks like some people are really good at taking tests.

In every job, technology focused or not; there is a distinct path of the flow of information. When you start a job at a company, understand what the information being used is. Where is the information generated; the source? How does it pass to the users? How is it stored and where? How is it loaded into the storage?

Is it manipulated/transformed in any way? How do the users of the information use it to perform their jobs?

From my experience, a certification for a job in a company is not necessary because in some cases knowledge and experience trump a certification. Conversely, a certification at that point in your career where you have significant experience can be what it takes for you to propel to the next level in your career. A certification is not the silver-bullet remedy to acquiring the job you want.

Certification is a badge of honor to wear proudly. Regardless of the reason or motivation to certify, the bottom line is simple. Perform your job well, and you honor your certification initials at the end of your name. Perform your job poorly, and you tarnish your certification and your peer’s certifications. Once you certify, you are an ambassador for certified professionals.

To choose certification or not to choose certification – that is the question.

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.