New Lesson

Now I regret the way I handled the "out-of-scope" issue. I shouldn't have gone to my project manager directly without negotiating with the client first. Instead of communicating with the client, my project manager escalated it to the executive level, and the client looked bad in front of their superiors, and of course the client got pissed off at me. The lesson learned here is: notifying the project manager may not be the best solution all the time even when the client is obviously wrong. There are things I could have done myself, such as let the client know I am not qualified to do the work that I was asked to do; the implications of documention something I am not familiar with could be fatal. I could have simply done the work and then let things slide instead of escalating before my work is complete. The relationship is broken now despite my previous effort to earn trust and building rapport. Well, as I have been told, there is never failure only lessons learned!

Comments

Post a Comment

Popular posts from this blog

Benefits of exposing UI mockups early in requirement cycle

During a recent use case walk through session, I presented the UI mockup before we finished going through the whole use case. We ended up spending the whole session discussing the UI because people were so adamant on what they want on the UI they lost the big picture of what the use case is trying to accomplish. That said, my lesson learned is to walk through an entire use case first before showing any UI. This doesn't mean the approach of exposing UI early in requirement cycle is inappropriate, in fact, I preach religiously the benefit of having UI as supporting document to the use case. 1. UIs are so easy and quick to understand, they accelerate the requirement cycle. They help you to expose missing requirements or reach agreement with stakeholders early, thus save time and money on having to rework the requirements later. Personally, I'd rather find out any conflicts, issues early so I can form a plan to address them. 2. Stakeholders are involved early in design and help to ...
Read more

Best Screte to Being a Successful BA

Excerpt from Seven Steps to Mastering Business Analysis: Your biggest challenge is to convince these (business) people that they should spend time with you and tell you everything that you want to know about their business. Successfully convincing them that you are on their side and working to help them is the best secret to being a successful BA. This is probably the most important thing that one should remember as a BA. Some people are natual "people" person, some are more introverted like me and need to work on "people" skills. I find that if you take a genuine interests in everyone you meet, pay attention to what they say, observe how they interact, you can become better at networking with efforts. In fact, in my opinion, introverts tend to be better at observing details and they listen more than they talk. This is actually a good people person skill, which is to focus/prob more about others and less on themselves.
Read more

The Day Has Arrived

Three years ago, I set a goal to become a business analyst specializing in the health IT industry. I wasn't a BA back then and I wasn't working in the health IT industry. I anticipated I can probably become a BA in three years, and maybe another 5 years or more to get into the health IT industry. I became a BA 9 months later, and got a job as senior technical business analyst in health IT two years after that. Now that I look back on the journey, I realize how incredible it has been: of all the hardwork I have put in, all the amazing people that helped me to get to where I want to be, and all the mentoring and support from friends and family. I have to say I am very fortunate to have all this. I hope I never take things for granted and never forget how I felt, for I am living my dream.
Read more