Over my professional years, I have learned one really important life lesson: Every time I make a mistake, I learn a lot. So I was thinking about that in the context of being a business analysts. I believe that making mistakes is not such a bad thing and instead should be seen as a wonderful opportunity to learn more about how to be a better business analysts. These are some of the mistakes I encourage you make….or if not to outright make, at least be ok when they happen and recognize the lessons learned.
- Miss a requirement: As Business Analysts, we know we must do everything we can to not miss requirements. But here’s the deal, we are going to miss requirements, I guarantee it. There is no such thing as a perfect requirements document. So the sooner you can miss one, have it later be realized, and see that you can survive it, the sooner you realize that it’s ok to not be perfect and there are processes to recover.
- Hire someone who actually doesn’t want to be a Business Analyst: Working with a business analyst who doesn’t love the job as much as you will help you recognize even more so why you do love it. These people will likely not work as hard as you at the job, so you will be frustrated. And with this you will learn how absolutely important it is to hire the right people. I do believe hiring the wrong folks will ultimately help you hire more of the right ones over time by helping you hone the set of skills and personality traits you need.
- Ignore the details: Go on, get lazy about the details and see what happens! As an example, you really have to follow the template formatting exactly and worry about your style headings? Well, I’m super detail-oriented, but sometimes I wonder rather I really have to be as careful as I am about those pesky details because they can be so time consuming, especially if we are working long hours. Well, once you make the mistake of not being detail oriented, and someone complains or you figure out you really needed to be more detailed and have a harder job to recover after the fact – then you will gain the appropriate level of respect for the details that do matter.
- Manage your requirements in Word: I’m willing to bet, you’ve already done this one! Haven’t we all? But having a project right now where they refuse to use a tool and we have instead got 100 different documents of information to manage and not trip over each other with is reminding me once again that you must use one at all costs! With brand new business analysts who don’t really know the value of using a tool over something like Word, I actually like to let them feel the pain of this fully before I force them into using a requirements tool – otherwise they won’t really adopt the tool and will be frustrated by it being forced on them.
- Write 1000 shall statements, call it done, dump the 500 page doc on your developer’s desk and walk away: Check back in a few weeks later and see if the developer has used it. Or don’t, because we know they haven’t. One of the most important lessons I learned was from someone else’s mistake, though I had also been guilty. I had to come into a project and read 2000 shall statements to get up to speed on it. Needless to say, there was no way I had a clue about what the system really needed to from that document, and neither would a developer. If anything I just had great reading material to put me to sleep at night! Anyway, in going through this, I realized I had done this very thing myself. I had written the long documents of requirements and was so proud because I was sure it was all there, written down in plain English. But up until that point, I hadn’t considered whether the stuff I’d written down was actually consumable. And with that, I learned the awesome lesson that you really do need models (like RML®!) – to add visual context and better explain the requirements.
- Have a full on failure project: I really don’t want to promote purposefully failing your projects, but if you are in one that is failing, take it as a valuable opportunity to learn that you alone cannot save the world. Here’s the deal, most of us aren’t performing brain surgery (though if your project IS related to brain surgery, that’s a great example of a project NOT to make this mistake on!!). But rather, most of us are working on corporate IT software, so if you screw up, no one is going to die. Also, many of us have the type of personality that really does want to please our end users and help build the right software. So when things aren’t going well, it’s extremely frustrating for us – making this lesson so hard to learn. Once in a failing project, I found myself pouring more and more of myself into it, only to continuously be disappointed…and tired. But I learned so much by stepping back and looking at why the project was failing – recognizing all the things I did right and learning from all the mistakes that myself or others made. But the big takeaway on this one for me was that you don’t have to save the world on every project. And if a project fails, it’s likely not your fault and not your responsibility to fix it. Just show up and do your best business analyst work and learn what you can do better next time!
