Soft Skills

Many BAs wait until their requirements specification is complete before they present it to some reviewers. Busy developers, testers, project managers, and users have difficulty finding the time to scrutinize a large document on short notice. It’s far more effective to review an evolving document incrementally. Give reviewers just a few pages at a time, preferably soon after an elicitation activity.

 It takes courage to scribe well. In many organizations we encounter pushback related to scribing. We hear lots of reasons why not to scribe. Remarks like those below can discourage us unless we have the courage to educate project and resource managers on why scribes are needed and influence them to assign this important role.

In my view, the most powerful quality practice available to the software industry today is inspection of requirements documentation. A peer review is an activity in which someone other than the author of a work product examines that product to find defects and improvement opportunities.

If I had to choose—not that I want to make such a choice—but if I had to choose, I’d take a scribe over a facilitator. I can almost hear a chorus of “You gotta be kidding!” No, I’m quite serious. How many meetings and workshops have we all attended where there was a weak facilitator or none at all?

If a business analyst is to step up to the task of becoming a credible project team leader, she must have an understanding of how teams work and the dynamics of team development. Team leaders cultivate specialized skills that are used to build and maintain high-performing teams and spur creativity and innovation. Traditional managers and technical leads cannot necessarily become effective team leaders without the appropriate mindset, training, and coaching.

The language of systems is no different; No, it is not C++, Java, COBOL, etc., but rather simple English (or whatever your native language happens to be). In the past I have gone into length about the differences between Systems and Software, the two are simply not synonymous. Whereas systems include business processes implemented by human beings, computers and other office equipment, software is simply instructions for the computer to follow. Systems are for people who must also take an active role in its execution. In fact, systems will fail more for the lack of people procedures than they will for well-written computer software.

As trusted advisors, business analysts must never forget the value of collaborating with stakeholders at all levels of an organization. The world of Agile has demonstrated this very point and is doing so with great positive impact and effect on the bottom line of many projects. When initiatives and projects are not collaborative, there is always a failing point within the stakeholder community.

Quite simply, root cause analysis is a technique designed to unearth the real, often unknown reason why a business problem is happening, and then to propose a viable solution to fix it. BABOK explains that root cause analysis “can help identify the underlying cause of failures or difficulties in accomplishing business analysis work”[1] [emphasis added] and further clarifies that it is “used to ensure that the underlying reason for a defect is identified, rather than simply correcting the output (which may be a symptom of a deeper underlying problem).”

One of the soft skills that BABOK [1] specifies is communication, and for good reason—understanding and being properly understood is key to any profession, but especially business analysis, where details are king and unearthing them is meticulous work. And an analyst has multiple avenues of communication that affect her work.

Of the four articles in the series, this particular article is the most sensitive. If not practiced with caution, trying to influence someone or a situation could have a devastating impact. Therefore, this article comes with a disclaimer: “Stupid is as stupid does.”
 

Teams that are geographically distributed and primarily work virtually face many challenges. One of them is sharing knowledge. I am part of an organization which has a team in Denmark responsible for development of the platform we support, while a team in India is responsible for the maintenance.

Now that you’re prepared to work with executives, I’m sorry to inform you that the tough stuff is about to begin. While preparation and understanding are crucial elements, and speaking executive language further deepens our conversations, the real meat on the dog bone is taking the next step and beginning to develop your relationship and establishing yourself as a trusted advisor.
 

In this four part series, I will give you the confidence and motivation you need to make a difference; a difference that will allow you to “Bark with the Big Dogs.” What I’m about to share is tried, tested and true. There are no gimmicks. Before you read on, ask yourself this: “Am I willing to try something different?”

I learned this in a virtual meeting where about 10 stakeholders were invited to give input to a mock-up created by our project. They were all subject matter experts within the area, and had earlier provided some input on an individual basis. I walked through the whole thing, and what happened? There were no comments or suggestions. I couldn't believe it. I know that subject matter experts always have an opinion.

There are three basic checkpoints the business analyst can facilitate to help ensure that he or she is on the right track. Two are informal, merely a get-together with other parties to review the situation and not fraught with the imprimatur of approval. The other is a more formal presentation. I’ll address each of the three checkpoints in this series.