When I started in the IT arena, the first George Bush was taking office, Paula Abdul was straight up, and the mainframe ruled supreme. (COBOL, DB2, and CICS ruled the day). There was no formal Business Analyst title. We did, however, create documentation to capture the “business ask” that enabled the delivery of IT solutions to capitalize on an opportunity or solve a business problem. For close to 30 years, I have written requirements documentation in one form or another and have a strong record of success. There is little that surprises me. I am now in a position where people are entering the Business Analysis profession now look to me for guidance and direction. (Perhaps they mistake the gray hair, the salt, and pepper look, as proof of wisdom).
When asked what my secret for Business Analysis success is, I indicate fundamentals first. You can acquire skills related to Agile, the latest modeling language, and software development tools but you will fail if you have not mastered fundamentals.
The following fundamentals are crucial to success:
The ability to communicate is non-negotiable. You cannot succeed in our profession if you fail to have strong verbal and written communication skills. In the written arena, mastering spelling and grammar is the start. This should not surprise anyone, but I can tell you that in my experience errors in grammar and spelling continue to plague a significant number of Business Analysis professionals. I am frankly astounded about how many people fail to hit the F7 key. A second chronic problem that I continue to witness is the failure to recognize and eliminate ambiguous language. Vocabulary and syntax matters. Here is a strong hint. If you need to explain the wording of a requirements statement in multiple review sessions, you may want to consider rewriting it. I recall once receiving a compliment that the requirements I produce "sparkle". I was pleasantly surprised and questioned the person further. It turned out that they viewed the deliverable as a pleasure to read. It was not about brilliant requirements with deep insight; the praise was generated from simply well-written communication.
Self-discipline is crucial. The timeframe to write requirements is continually under siege, so we need to work both smarter and harder. This means eliminating distractions and focusing on activities that directly relate to the requirements product. Analysis paralysis is a pattern that I continue to see in 2017. An example is the obsession of some Business Analysts to focus on understanding and documenting current state processing. Self-discipline also means having an internal schedule and resisting the temptation to inflate self-ability and underestimate effort. Experience helps in this regard, but humility can also assist.
Taking ownership is about taking initiative. Taking ownership involves self-discipline as noted above. Taking ownership is also about accountability. In Business Analysis, this is about accountability for the acceptance and usage of the requirements deliverable. This seems simple enough, but in reality, I have witnessed Business Analysts repeatedly characterize their business and delivery partners as difficult because they fail to embrace words as written. In their view, if a delivery partner repeatedly asks for clarification, then there is evidently something wrong with that person. Ownership means taking the viewpoint that any failures in understanding start with the communicator, not the communication recipient.
These are just three quick hits to point out that fundamentals matter. Are there other key fundamentals? Yes, the items that I share are based on the patterns that I have observed. I encourage you as a reader to respond and express your viewpoint.
Author: Michael Roy, Business Analysis Professional / Requirements Leader
Michael is a solutions-focused Business Analysis professional with extensive experience leading change initiatives at a tactical and strategic level.