Last month we talked about adding value. In truth, delivering value is everyone’s job. We are all here to add value. Some of us do that through thinking up new things, some through helping a customer over the phone. Some add value by selling things in a physical store and others by writing code. In the exchange between a company and an individual you deliver some value to the company and in exchange you receive value, such as vacation time, retirement savings, and maybe insurance.
As a Badass Business Analyst, I am keenly aware that there are always going to be difficult conversations to be had, opportunities to be seized, monumental influencing efforts to undertake, and times where I simply need to go against the grain or broach a difficult topic. I might just have to disobey normal conventions. We are about to have one of those “moments”. Have you intelligently disobeyed your leader or your organization lately? One can argue that if you are not actively and intelligently disobeying on a regular basis you are not progressing, evolving, and helping out your organization.
The Entrepreneurial BA Practitioner Part 2: Entrepreneurial Traits of Business Analysis PractitionersWritten by Richard Larson & Elizabeth Larson
In our previous article, What do Business Analysis and Entrepreneurship Have in Common?, we outlined some high-level similarities between business analysis and entrepreneurship. Now let’s explore some detailed parallels between the two.
In January we wrote an article like we do every year about the upcoming trends in business analysis and project management. In this article we want to discuss what these trends mean for practitioners of business analysis. Below are the seven trends we discussed in last month’s article and a short description of each.
It’s project kick-off time! February, more than any other month, tends to be the time when organizations transition from planning to action. New initiatives have been prioritized, dollars have been allocated and teams are being formed—everyone is ready to get to work.
Many financial organizations find that it’s easier to just keep patching old technology rather than to make the kind of major changes to their core systems needed to become the business they really want to be. So, they keep pushing major transformations off, until one day the risks of maintaining the status quo become overwhelming.
Far too often, implementation of business analysis (BA) as a valued discipline within organizations is elusive. Business analysts (BAs) struggle to form BA communities, share knowledge and best practices, and improve competencies and outcomes of their efforts. These improvements will only reap limited benefits. What is needed to respond to 21st century challenges is a disciplined, value-creating BA Practice. However, we often falter when attempting to implement a formal BA discipline withing companies and non-profit agencies. It is an arduous task, a cultural change, a complex endeavor.
Todd Olson was the VP of Products at Rally Software for a few years. I met Todd when he was the co-founder of 6th Sense Analytics here in the Raleigh-Durham area. Todd’s background is mostly as a software engineer, but after Rally acquired 6th Sense, he developed a wonderful sense for product evolution and management as well.
A healthy respect for the magnitude of what we don’t know
Every time I start to believe I’m building an expertise in something or starting to mature into an experienced “adult”, life has a way of smacking me in the head and reminding me that “I don’t know jack.”
In the old days, business analysts used to gather or collect or capture requirements, but all that changed in 2009 with the second edition of the BABOK® Guide. Now we elicit requirements and other business analysis information, and the term elicit was defined in the BABOK® Guide as meaning “to call forth, or draw out”.
It seems that the good folks at the IIBA didn’t tell us the whole story. However they were on to something when they said the term means trying to uncover unstated and implied needs, not just what the subject matter experts (SME’s) tell you they want. This proves that you can’t just accept what your SME’s tell you, you have to work at it to discover what they aren’t telling you.
…IF you can tell what the prize really is. Let’s consider a list of potential “prizes” and the meaning of each for developing requirements.
THE Prize (by definition): Meeting Organizational Goals and Objectives
This ought to be the gold standard for developing requirements. Is it the standard at your organization? Try carrying the organizational mission, goals and objectives with you to share at requirements meetings. Whenever a debate erupts about some requirement, pull the goals out. Ask the group if the existing goals offer direction to resolve the debate. If so, the organization is practicing “BA behavior”.
Last year I had the opportunity to attend a course by Penny Pullan called Creative Facilitation. It was a course with heaps of practical tips around how to add creativity to the way you facilitate and present information. It was during this course that I had one of the those light bulb moments; adding creativity to how I facilitated meetings was great, but it was the idea that I could also apply this creativity to other business analysis tasks that got me really excited.
Have you noticed lately that there are a lot of industry “buzz words” and “phrases” that seem to be driving your corporation’s strategy and your every day approach to work? “Agile”, “agility-minded”, “progress over perfection”, “fail faster”, “do more with less”, and “get stuff done” are a few of the common ones these days. These are all challenges that are being issued on a daily basis. You know what? I don’t disagree with those challenges. I think it is a natural decision for leaders to make as they strive to make the bottom line or find creative ways to increase profits, but is it doable?
Your goal is to get information. You want to get as much information as you can. You can always eliminate nonessential and irrelevant information when you analyze the information you have obtained after you have gotten it. Considering that the only way that we can be sure we will ask the Right Question is by getting the right answer, and the only way we know we got the Right Answer is by getting as many answers as we can. During the process of getting the information, we need to do everything we can to increase the flow of information and that includes preparation for asking as well as the actual act of asking the questions.
Recently I delivered a workshop on Risk Planning and Analysis for the Business Enterprise. I was asked about the various levels of risk within an organization. In response to that question, I explained that there are many levels of risk that could be organized along standard company structure. My preference is to use three structure approach - - strategic, tactical and operational.
So, here’s the scenario: Your organization wants to purchase packaged software to support a key business function. Your team thoroughly evaluates several products and chooses the best fit. During discussions with the vendor, you discover they “use Agile.” This is great because your organization “is Agile” too! Awesome! Contracts get signed and we all get to work.
Then, things start to go awry as your assumptions jump out of the dark corners and startle your progress. Communication crumbles, messages are confused, processes and practices differ, team dynamics and what even is “a team” seems to be a huge struggle. You soon discover that the most basic agile terms being used do not mean the same thing! Your version of Agile does not align with your vendor’s version of Agile.
It’s easier to defend Business Analysts than it used to be. Part of the reason is because I am defending the role in general. My job isn’t on the line any more. For other people this is a much more immediate concern. Still, it brings back memories. I hear the question at a conference or networking event and my heart shrinks. “Why do we need business analysts?” No matter how the topic comes up, it always makes me sad*.
I used to think other folks didn’t get it. The significance provided by analysts was obvious and self-evident to me. How could managers, executives, teams, and developers not understand all the value BAs add? Can’t they see BAs are the glue that holds these projects together? What would a project be without the contribution of a good business analyst?
Part 1: What do Business Analysis and Entrepreneurship Have in Common?
Welcome to the first installment of the Entrepreneurial BA series. Given we are both entrepreneurs and BAs it seems logical for to write about this topic. But, why bother? What possibly could be relevant about entrepreneurialism for a business analyst? Well, for starters, it’s a great career option and more and more viable with each passing year. Even if you are not interested in forming a start-up, the principles of entrepreneurship are becoming increasingly important for organizations to innovate and stay competitive.
Many years ago few of my colleagues started working on a project, which was not so complex. It went well for the first few months. The problem started when the team travelled to client location to give a demo on a module to seek client’s feedback. The client suggested certain changes that were accepted by the team. The team built the module with new suggestions however, the client suggested few more changes. After a couple of similar back and forth interactions, this situation gradually led to passing the buck in the blame game between the client and the development team. The project was ultimately shelved by the company as it was no longer a delivering a good ROI since the client refused to increase the time and the budget any further.
Situations like above may not only lead to rework, wastage of time and effort, financial loss but may also result in huge customer dissatisfaction leading to loss of repute in extreme cases. Additionally resources working on such projects would be more than willing to exit such projects.
Each year we like to reflect on what’s happened in the business analysis, project management, and Agile professions and make our predictions for the upcoming year.
To summarize the trends we saw in 2014:
- Continued excitement about Agile projects with more informal communications and documentation and use of modeling tools to get from high-level user stories to detail needed to estimate and build them
- Focus on Design
- Cloud computing
- Greater interest in business analysis by project managers.
Below are the seven new trends we see in the Project Management and Business Analysis fields for 2015.
In 2009 I wrote the first edition of Scrum Product Ownership as a way of helping Product Owners understand their roles and responsibilities better. Before that, it was mostly an exercise in guessing and survival. In 2013, I updated the book in a second edition. In both books I took on the topic of Backlog refinement.
In part one of this post, I set the stage for what backlog refinement was by referencing the Scrum Guide. Then we explored 5 of 12 overall refinement tips. I’ll continue with the remaining seven tips here:
12 Tips for Effective Backlog Refinement
6. Talk Less, Spike More – I’ve noticed a very common anti-pattern in many refinement sessions that teams explore each story far too deeply. They wax into conjecture and guessing about design challenges. They debate implementation approaches. They argue estimates on stories that are still quite immature and ill defined. In a word, they talk too much about the stories.
What is co-design?
A number of terms have recently cropped up that reflect a new way of developing IT solutions – co-design, joint solutioning, as a service etc. Fundamentally they are all trying to fix a common problem and need to be properly managed to achieve the outcomes expected.
The premise behind the approach is that the traditional way that businesses have specified IT systems has been inefficient. It is quoted that 60% of code in IT applications is never exercised. The systems that have been built have high complexity, are difficult to upgrade and consequently provide a lower return on investment.
The new co-design process makes the reasonable assumption that the suppliers of these systems have valuable experience in implementing solutions and can use this experience to recommend “best practice”. Organisations procuring these solutions should merge the best practice recommendations with their own requirements in a collaborative supplier / buyer engagement.
“Certified Business Analysis Professional” (CBAP) always seemed a little awkward for a professional designation. Those of us who got it early actually worked directly with people to take the test (no on-line then). I had some low fun teasing the exam team (Cleve Pillifant and team, thank you again) about the acronym. It was low of me since the exam team was available and the decision makers were not (shout out to Kathleen Barrett, hope you are doing well). To those whose eyesight is fading, the “B” can even be mistaken for an “R”. This is no big deal and is common enough (case in point “PMP”).
Now things change, because it is increasingly obvious that ANALYSIS (breaking into parts) is only half the battle (the easy half). The harder “half” is business SYNTHESIS. * Synthesis means taking the parts stated by stakeholders (requirements [stated]) and organizing them into possibilities by reducing confusions and artificial constraints (“but we built what they told us to build…whimper, snivel”).
Modeling IS simplifying. Simplifying requires doing something MORE, NOT LESS. Some of you will understand the statement “If you want it shorter it will cost more.” We know this is true because stakeholders are very reluctant to “simplify” the information they can offer. We also see this is true because we must reconcile wants across silos – often very committed silos.