Lessons Learned: Closing up at TradeBank; a future state of practice I'd like to achieve

Whew, I can't believe it's been two months already.

If you are following my blog, I'm currently on my way towards the completion of my business analysis program at Mohawk College and finishing up my internship as a junior BA at Trade Bank.

I will be continuing my blog in the meantime, though I would like to dedicate some time for self-reflection and creating a lessons learned from my work here. Even with things going well, there are always areas of continuous improvement, and I do believe a lessons learned at the end of any project or deliverable is ideal business practice.

With that in mind, I have decided to compile some of my individual lessons learned into a list format that may help anyone else starting out in this exciting field. If you are facing anything similar in your workplace, it's always fun to find out you're not alone and we're all working towards continuous improvement.

With that in mind,

1) You may be efficient in writing your requirements, but are you effective?

While making use of your time and working in a productive manner is always the ideal, consider that you may be working "efficiently", but not necessarily effectively.

What this means is that, for all intents and purposes, we may meet the requirements of what we are told to do on a project, but still not generate optimum value for the project sponsor relative to the amount of time spent on a project. Sometimes, you can write a 20-page BRD (Big Requirements Document) that effectively covers all aspects of a project, but if it is not used or it is not required, while we may be efficient users of our time, the project we generate may not be effective relative to the use of that time. What you want to do is to spend the appropriate amount of effort and work on a project to communicate the business needs and requirements in a way that is understood, and refrain from going out of scope past that. If a project takes you a few weeks to complete, while we may want to add all the bells and whistles we can to that project, would adding cup holders to a bicycle necessarily be the most effective thing we could do?

The last thing you want to do is go out of scope or create unnecessary documentation which, while it may be appreciated, is indicative that your time could have been better spent elsewhere.

2) Have we generated shared understanding?

Building off of the last point, arguably, a business analysts prime role should be to provide structure for a business initiative and to help ensure that all stakeholders involved in a project have a shared understanding. This is easier said than done, as people have different lens they view information through and finding a common lens to highlight a process may take some creative brainstorming and insight into the nature of the people you are working with.

What we want to generate is shared understanding of the objectives and visions of a project and to bring all people involved in a project on board with how to best achieve the value originally envisioned for a project. Using visuals, use case development, casual conversations, or whatever method we can to generate shared understanding- this is the critical part of business analysis. If we can’t achieve shared understanding on what needs to be done within a project, the potential fallout from project confusion increases incrementally.

3) Beware of the feared “text blocks”

Often when I’m writing requirements documents or justifications for business cases, I have the tendency to write a wall of text. The reason I want to do so is to ensure that I have covered all aspects or possible misinterpretations of what I am attempting to communicate. Saying that, creating a wall of words or “word blobs” can be detrimental to communication. Sometimes, we may feel forced to (as in we don't want to write "bad requirements" or we may feel constrained by standardized requirements forms we are given), but even the forms you are given should be appraised to ensure that all sections are needed to highlight the business needs you wish to communicate.

Ask yourself, is what you are writing really required in communication? Does it have to do with the objective at hand? Am you rambling or writing redundant information? Nick, are you filling out too many boxes on this report when everything critical was stated in the first box?

The key here is, even with trying to follow a standard approach in documentation that you have developed or that has been given to you, you shouldn’t always feel the need to fill out every section of a report if it does not necessarily apply or create value. What fields need to be captured in my documentation is something every BA should ask themselves. You don’t want to necessarily overwhelm or disenfranchise your project sponsor with a wall of text and documentation that takes several hours to read, analyze, and understand.

4) Are you asking yourself why?

Bear with me here, and while this may not always be applicable (sometimes, you have to do certain things in protocol, even if the value generated isn’t necessarily optimum), this should always be the first thing you ask when starting a new project or being given new tasks. What business need does this serve? Why are we implementing this process? Why now? Why in this manner? Is there a problem we are addressing, or a potential future problem?

I was taught the 5 “whys” in school, and this does relate to this technique- but it’s something I think is something I need to consider embracing more, for any future projects. We really should pay attention to the “why’s” of what we are doing more often, at least before we start on projects, to ensure that we can all understand why and if there is a need to go through a project in the first place.

5) Do we have project metrics to follow?

Sometimes, you won’t have project metrics to follow. As a BA, you must make do with what you are given and more often than not, we will work in ambiguity. Saying that, something I believe is crucial to any successful project is generating the correct project metrics as soon as possible.

How will we measure the success of this project relative to its completion? Can it be completed or is it continuous? How do we quantitatively measure the work being done? Are there key deliverables we have to watch out for? What is the scope of what we are working on?

If you are unsure of any of these questions or anything similar, the best thing to do is to typically try and address these issues as early on as possible.

One should always attempt to address ambiguity head on, and if how we measure success becomes ambiguous, the potential for conflicting views on the quality of the work produced and appraisal of the final project increases exponentially.