Soft Skills

Driving Lessons. We all did it. We all know how that very first one went. It was described to us that the clutch should be engaged, place the car in first gear, release the handbrake, release the clutch and press down on the accelerator… Only for the car lurch forward then stutter and lurch forward again. This process continues several times before the car stalls and comes to a stop.

What does innovation mean to the Business Analyst?  This article is my practical way of handling innovation and understanding the role that the Business Analyst plays in innovative projects.  Giving five tips for success the article explains how innovative projects can be approached and how the unique skill set of the Business Analyst can add measurable business value. 

Business analysts are jacks-of-all-trades -- and masters of some... unfortunately, many BAs fall short. They often spread themselves too thin, lack the requisite confidence to speak with authority, or don’t understand fully the important role they play.

It’s pretty rare to be a business analyst and not facilitate meetings...  In this article, we’ll look at 3 possible roles new BAs fill in meetings, how to expand your meeting facilitation experience, and review 5 critical meeting facilitation techniques that will help you run working, productive meetings.
 

Interaction skills are a soft skill set that includes tactful communication, mediation, and diplomacy. BABOK divides interaction skills into three broad areas: facilitation and negotiation, leadership and influencing, and teamwork. All of these skills encompass the ability to navigate politics, even in tricky territory, in order to bring people together in consensus on a project, to mitigate conflicts, and to help people feel heard.

In an ideal world, a single, full-time, expert user would indeed be sitting within view—“on sight”—of developers, ready at a moment’s notice to speak definitively for the entire user community. In reality, this is unlikely in most situations.

This article describes an integrated system of actions, tasks, and methods for managing project stakeholders. It highlights the strategic business actions, the tactical project tasks, and operational methods conducted by project sponsors, project managers and business analysts respectively.

Business analysts need to understand their role on a project. Please note I use the word 'role' and not 'job' or 'the work we do'. As business analysts, our role is to deliver business value. If you do not have a clear definition of what that business value is, how can you expect to deliver it? “Improve the customer experience.” Where is the business value in that? And how do you measure it? When faced with objectives that are poorly defined, the business analyst is allowed to become like that irritating toddler, constantly asking “why? why? why? why? why?”.

Recently I saw the movie “42,” based on the true story of Jackie Robinson,who in 1947 bravely fought custom, bigotry, and violent hostility to become the first African American to play major league baseball. His courage came from his inner strength which allowed him to withstand with dignity the cruel behavior from fans, other team managers and players, and at first some of his own teammates.

Multiple stages of a project can benefit from brainstorming, from identifying your stakeholders, to eliciting requirements, to enterprise analysis. In UML for the IT Business Analyst, Howard Podeswa describes brainstorming as useful “during the Initiation phase and whenever the project is ‘stuck’”.

The purpose of this article is to assist business analysts in writing business requirements. This article provides six guidelines on technical writing. The six I cite here are the major ones I consider when writing a business requirements document (BRD).There are, of course,other technical writing guidelines; for comprehensive texts, see Further Reading (1). 

This article reviews the complexity of the role of the business analyst (BA) facilitator in obtaining a stakeholder agreement (i.e., a consensus or a compromise) on solution features and/or user requirements. The BA facilitator achieves this agreement by maintaining a neutral posture in guiding the stakeholders though a dialogue in a series of meetings.

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.