Business Analysts and Grammar Police

I used to work with an experienced business analyst with a real talent for creating process flows and other useful diagrams. I enjoyed peer reviewing his work because it gave me ideas I could incorporate into my own. He was solid in most other aspects of the job as well, but his struggles with spelling, punctuation and grammar were a constant thorn in his side, eventually limiting his tenure with the company.

Our supervisor had little patience for poor writing, seeing it as a fundamental professional skill, especially for business analysts. Over time, and the course of many reviews resulting in red mark-up throughout his documents, management lost patience with his deficiency and lack of progress. Unable to see beyond the dread of his next document review, my colleague began to lose confidence in other aspects of his work, and his overall performance faltered. The eventual results were as expected; the team lost a skilled contributor, and the analyst lost a promising career with a great company.

I’ve often reflected on this, with empathy for both sides. A profession as highly dependent upon effective communication as business analysis must require good written language skills. However, written language is only one form of communication among many available to the analyst – and an inherently vague and ambiguous one, at that.

How would I handle a situation if I were the supervisor of a business analyst with similar struggles? To begin,  I would ask myself a few, basic questions to help me decide how to to manage the situation and the individual:

  • Is the analyst’s documentation otherwise correct and complete?
  • Is the documentation well-suited to its purpose and easy to understand and use?
  • Is the analyst making a sincere effort to improve?

Business analysts create requirements models in order to record and transfer important knowledge that business stakeholders depend on to validate the accuracy of the requirements, and  delivery team members depend on to design, develop, test and implement a solution based on those requirements. Documentation, at its core, is a communication tool. As such, ease of understanding and communicative value are paramount.

Poor grammar and spelling that cause a requirements model to be inaccurate, or difficult to understand and use, are serious because they negatively affect the documentation’s ability to serve its purpose. An otherwise solid, easy to understand document with some errors in grammar and spelling, is not as serious. In either case, poor grammar and spelling should be included in the offending analyst’s professional development plan, and improvement should be encouraged and expected.

Below are my words of  counsel to the analyst or the manager who finds him or herself in a similar situation.

If you’re a business analyst who struggles with spelling and grammar, here are a few recommendations that may provide short-term relief, while providing evidence of efforts toward long-term improvements.

  • Direct reviewers’ focus to the substance of the documentation and not the form. Grammar and spelling suggestions are valuable and welcome, but can be part of the finishing process. During the course of working sessions and early review meetings, ask participants to focus on correctness and completeness of content, and ensuring shared understanding.
  • Be intentional about showcasing the things you’re really good at, and partner with other analysts in “buddy” fashion to help them by applying your relative strengths to areas of team weakness. In my colleague’s case, he could have offered assistance and coaching on how to effectively model flows and diagrams in return for extra assistance with grammar and spelling.
  • Make improving grammar and spelling a pillar in your professional development planning, and communicate that desire and evidence of action to management. To my recollection, my colleague did ask for assistance in reviewing his documentation and making corrections before others saw the documents, but he did not demonstrate or provide evidence of a real intent to improve. Management is much more likely to extend grace in evidence of a plan to improve, and incremental improvement over time.

If you manage someone who struggles with spelling and grammar, here are a few recommendations that may enable you to avoid parting ways with an otherwise strong performer.

During my time managing business analysts, I adopted the following stance on grammatical errors, specifically: If meaning is not obscured by faulty grammar, punctuation & spelling, coach it up. Don’t let it hold up progress. Perfection comes at too high a price.

With that in mind,

  • Focus on the overall value of the documents as communication tools, grammar and spelling aside. Is the document correct and complete? Does it effectively fulfill its purpose? It it easy to understand and use? Focus on the effectiveness of the documentation in meeting its intended purpose instead of honing in the distraction of poor grammar.
  • Recognize and acknowledge (both privately and publicly) the analyst’s value to the team and the organization and  draw attention to his/her strengths.
  • Coach the analyst. Work with the analyst to set goals and hold him/her accountable for improvement efforts. Provide professional development opportunities to bridge the performance gap.

Developing people is every bit as important as managing the flow of work through the production pipeline, and every bit as satisfying, especially when you’re able to help someone who has struggled in some aspect of performance to make a break through.

That said, while I am sympathetic to those who are struggling in one area but who have offsetting strengths in others, and who show a willingness to improve, the manager, as steward over the quality of his or her team’s work, must be prepared to make difficult decisions if, after sustained efforts and patience, quality of output does not improve.

What is your stance on handling errors in writing, and how might you handle a similar situation?

Featured image credit Eli Reusch.

Post a Comment

Your email address will not be published. Required fields are marked *