Coaching or Mentoring Business Analysts

Suppose your boss, the business analyst manager, project manager, PMO director, or whoever, asks you to coach a group of business analysts, or to mentor an individual business analyst. What would you focus on? What would you consider to be the most important aspect to improve the business analysts you are culturing or mentoring?

Of course; a lot would depend on the experience level of the people your coaching or mentoring. One might assume that you might be mentoring a less experienced business analyst, perhaps a person who is new to the profession, and providing coaching services to business analysts who are somewhat experienced. After all, even the most experienced of us can benefit by coaching, even if the coach is less experienced. But that would be a topic for another blog later

The question here is what areas of the entire business analysis spectrum would you choose to begin your coaching with?

Obviously; most of us would start a coaching or mentoring initiative, as I have in the past, by asking the coach cheese or protégés where they would like help, or where they feel they are the weakest in their skills. Clearly focusing on what they need first and foremost would likely get the best bang for the buck, the most improvement for the leased time invested. But then there is the issue that the area that they request help in is also an area that you need help in. For example, if they are running into issues with basic data modeling since they are getting into some data analysis projects, and you don't know how to spell ERM, entity relationship modeling much less have ever done it, your coaching would not be exceptionally effective. But a request for something specifically technical like data modeling, probably is best handled with a formal training session by an expert in the field, or one of those online on-demand training sessions.

If the business analysts requiring coaching need the coaching in elicitation techniques and how to ask the right questions, and you break out in hives whenever you are forced into a situation where you must ask questions and get answers, your coaching might not be effective.

But it certainly is good to know that up front. So you don't waste your time coaching them on writing user stories when they don't know how to gather the information to write these stories the first place.

Bring us back to the original question if you were to be given this assignment, along with a general instruction to coach them on "everything business analysis". What would be the first area of business analysis that you would provide coaching in?

Think about it it's a good thought exercise to put the tasks and activities of a business analyst into perspective.

Digital Transformation and the business analyst

When you look at it, the concept of “Digital Transformation” is not about technology; it’s about business.  You might call it “business transformation” but that just does not have the zing and marketing pizzazz that “Digital Transformation” has.  One of the earmarks that make a successful “Digital Transformation” successful is that it focuses on the business and not technology and that business focus is squarely on the customer. Since the “movement” is driven by a focus on the customer and the business needs, then the role in the forefront of any “Digital Transformation” is the business analyst.  To ensure that you are in that forefront of your organization or any organization, make sure you are knowledgeable about the technologies of “Digital Transformation”: omni-channel approaches, artificial intelligence, machine learning, neural networks, blockchain, data and business analytics, predictive analytics, and so forth. You don’t have to be an expert, just knowledgeable enough to recommend which technology to use in which circumstance and be able to justify the recommendation.

Views of Risk

Risk is uncertainty. To reduce risk must remove uncertainty. To remove risk faster you must attack uncertainty earlier, quicker, and with continuing consistency. In linear approaches the uncertainty is attacked on a slow but steady basis. During requirements we confirm as many as we can along with as much confirmation of the problem domain as we can which of course removes uncertainty. We do the same thing during design and coding. Where most of the risk of failure of the application occurs is in the testing which in the linear approach is typically at the end. The uncertainty in terms of whether the final product can be successful, that is generate the business anticipated, reduce cost as projected, be easy enough for those who need the solution to actually use it to solve the problem, generally does not come until after the delivery. Thus we have a continuing level of uncertainty and risk which must be dealt with through artificial means such as risk registers and contingency plans.

In an agile we attack the uncertainty immediately. We get parts of the complete solution done, tested, and demonstrated in a short timeframe. As both the developers and the business see what is being developed, and how it will work, the uncertainty of application failure is removed through the continuous testing, and the uncertainty of appropriate business use and achievement of business objectives is removed by the business inspecting and verifying little pieces as it goes so that at any time the product can be modified, adjusted, changed, or even discarded if it does not seem to be in alignment with meeting the business objectives. As long as it is, uncertainty has been diminished, and thereby so has the risk of product failure or implementation failure.