A Senior Business Analyst Looks Back and Shares Lessons Learned

When we were young kids, there was I’m sure a time for each one of us in which we learned a lesson that we still haven’t forgotten. I can think of a few myself, such as don’t spit (mouth washed out with soap), don’t play with fire (lit forest fire with magnifying lens) and don’t play in construction sites (nail through hand). I’m just positive that you have a few of those to share from your childhood, too.

I find it strange then that we endure as adults the same consequences of our actions over and over, yet cannot seem in many instances to learn from those lessons. My personal belief is that it is rare that the light goes on long enough for us to recognize that we should not put our hand on the proverbial hot stove. In amassing the lessons learned information, I wondered what holds us as adults back from learning from those lessons many times. Think about it….if we fixed our issues in the workplace immediately, there would not be anything called a lessons learned exercise. There are tons of examples in industry writings about trends with defects, rework, project failures, etc. that keep an entire other industry (quality improvement and the like) afloat.

So, as I pondered this, another thought emerged. What lessons have I endured in the last 15 years or so, which represents most of my professional life, in which I learned my lesson so as to NEVER repeat the circumstances again? Surprisingly, I can think of a few, and thought I would share them below.

Lesson 1: When learning DOS (should you ever have the need), never, ever enter DELTREE at the root of a network tree and hit ENTER. Backups are good things. I think this particular lesson needs no explanation of what happened.

Lesson 2: Never take for granted that you are being told the full story, because there is always another side. Always question. A project that I was on became one molded by an aggressive business manager that, unbeknown to me, neglected to collaborate with her peers and senior management. My failure to assertively seek out other stakeholder opinions and delve into detail prompted portions of an application to be modified to suit this user’s unique view of what was necessary. The reality was different and the implementation, though accurate to her requirements, was never used due to the fact that it did not address actual usage. <<cha-ching>>

Lesson 3: Never assume that your way is the ONLY way. I can honestly state that even today it is hard for me break away from my views as to what is “right” in order to listen, not hear, but listen to what could be valuable points-of-view; I have to force myself. About two years ago I was on a project that I was convinced needed things done in a specific way, according to specific project constraints. Because of the constraints, the resources were just not understanding what we were going through. They weren’t “getting it” and the project was nose-diving right before my eyes. I pulled in a peer and had him assess what was happening and within 15 minutes he crafted a solution that immediately restructured our delivery and got the project on track. Better yet…the customers understood what I was attempting to do. My own stubbornness was derailing a project, because I was too enamored with my own skills to pay attention to reality.

Lesson 4: Always put the end customer first in your mind. At the end of the day, no matter who tells you as an analyst what to do, ensure that your solution will be well received and useful to the people that have to use it. On the same project that Lesson 2 spoke about, my process changes failed to take into account that though new user roles were being created, those roles would be filled be existing users who also had to perform their existing duties. It’s not always possible to have resources working in two departments at once. I failed to consider the end-users needs.

Here’s a few more that you will never regret….

Lesson 5: Never compromise your moral and ethical belief system for another

Lesson 6: Always address your stakeholders with an air of confident humility. You’re good, but not THAT good.

Lesson 7: Never represent yourself as something you are not…EVER!

Lesson 8: Never let someone else represent you as something you are not…EVER!

Lesson 9: Always tell the truth, even when you are wrong….which leads to….

Lesson 10: Always take responsibility for your errors.

The above lessons were painful and I have changed the names of those involved to protect their innocence, except for my own…who I’ve already proven guilty. Imagine how much more painful they would be if repeated and relived. It’s a shame that we many times forget to learn from our adult lessons and repeat mistakes. Though many of us have learned to resist it, change can be a good thing! I’ve learned over the years that if I stop putting my hand on the stove, my skin will grow back.

Have some stories of your own to share? I’d like to hear how you’ve learned from them.

Very Humbly Yours….Doug

Free Training - Quick Start to Success

(Stop the frustration and earn the respect
you deserve as a business analyst.)

Click here to learn more

By signing up, you agree to our Privacy Policy.


  1. Doug goldberg says

    Painful lesson but a great learning oppty for us all. Glad to see you are employing your lesson positively. Thanks so much for sharing!

  2. Hi Doug,

    I was just snooping around and found your lessons learned. I particularly like the one about don’t represent yourself as someone that you are not. In my case it was representing myself as knowing something that I didn’t really know much about but in essence it’s the same thing. Here’s the story and the painful lesson learned.

    A while ago I was working as an Independent and found a potential client who had a number of projects that were just right for me. But first they needed help with their monthly close process – they had configured something wrong and needed help to fix it. I had a little bit of experience with the financial software they used so I thought – hey I know about system x! I can fix this little issue and then they’ll be so pleased they’ll give me follow-on work. Great!

    In the interview I told them I could help them because I knew all about the financials of system x. I could fix the GL close because I’ve fixed a couple of other AR close problems. Yes, I am sure I can get this done by the next close!!

    Of course, it turned out to be more complicated than just a simple configuration problem that you could read up on in the manual or search on the internet for help with. The client had customized the GL to handle some unique project accounting situation and simultaneously made some other changes to their chart of account setups. In the process something had gone majorly wrong and transactions weren’t booking correctly. So I didn’t know how the GL software was supposed to work and had no idea of where to look to diagnose the problem. It took about a week of floundering around in a panic before it became very apparent to the client that a) I didn’t know the GL system and b) I couldn’t solve the problem. Worse, the client had 1 week less to find a solution and they were back to square one. To say that things didn’t end well is a complete understatement.

    I’m not sure what was worse – being thrown out of the office, or the 1 week of absolute panic and late night cramming on the GL System Manual that I went through but it was definitely a painful experience. I now know to be very up-front about what I do and don’t know and what I can and can’t do. If I don’t know something or haven’t had direct experience with a system, I will say so.

  3. Well, Doug, you can’t make all the mistakes! 🙂 I’ve made the “not asking a question” mistake a few times myself. Here’s a post from deep in the archive about the topic.


  4. DougGtheBA says

    Excellent advice Kriti. I should have included that one when I wrote this originally. Thanks for reading and contributing!

  5. Kriti Gupta says

    Hi Doug,

    I just read the posting, it was truly insightful and gave me so many “aha!!! this happened to me” moments. I agree with Laura about learning things and making mistakes.
    I think one of the lessons I’d like to add to the collection would be ” Do not be afraid and/or embarrassed of asking questions even when you think it makes you look like the least knowledgeable person in the room.” The regret and the work involved when it later comes to light that it was in fact a valid question and a critical one at that, is overwhelming at times.

    Thanks again for the list. It helped me remember the humbling lessons again.


  6. Hi Doug,

    I’ve re-read this post again after a long time and it still speaks true! It’s great to hear your story about learning from our mistakes. All too often we get bogged down in our mistakes and don’t have the humility to learn from them (myself included). What a great reminder that there is something to be learned from every experience!

    And those who don’t make mistakes aren’t taking risks and growing. If you are constantly learning and trying new things, you are going to make a few mistakes along the way.


  7. Alan Maxwell says

    Watch your Assumptions

    I have always remembered a situation that occured more than 20 years ago.
    For many years a retail industry client with 100’s of employees and sophisticated custom developed computerised systems was in the situation where the total of their debtor’s ledger (containing the amounts owed by each of their individual credit customers), couldn’t be completely reconciled to the Debtor’s total in their General Ledger/Financial Accounts. In the big picture, the problem was very small but the unexplained difference increased each month by about $2,000. It was always reported as an issue in our firm’s Audit Management Letter, and eventually the client asked for assistance to resolve it once and for all.
    The cost of me researching and reconciling the full accumulated error would have been be too expensive, but I could and did successfully reconcile the most recent month. That highlighted the kinds of errors that caused their problem, and the process that could be used to identify others in earlier months.

    There were several causes of the unexplained differences, but the most memorable were:
    1. The total of the individual invoice line items was not the same as the invoice total. The GL postings were based on line item amounts to get a product based revenue analysis into the GL, while the Debtors Ledger was updated by invoice total.
    2. Debits didn’t always equal credits. If an error occured, the offending transaction would be immediately reversed out of the complaining customer’s Debtor’s Ledger account, but it wasn’t always transferred to another account until much later (days or weeks) when the error was followed up and resolved. So processing of the Debtor’s Ledger amounts were incomplete, and no record of this activity appeared in the GL at all.

    These are two very basic assumptions, and here was a situation where both had failed.

    There were other important lessons I learned from this assignment but the biggest one was definitely to be careful of assumptions.

Before you go, would you like to receive our absolutely FREE workshop?

(No formal experience required.)


Quick Start to Success
as a Business Analyst

By signing up, you agree to our Privacy Policy.