The week before last, I was asked to provide some sample documents from past projects to a gentleman that is transitioning to a business analyst role in from a different position in another area of the company.
As I scanned through some of my old documents for some good examples, I was a bit surprised to find that I wasn’t all that happy with a lot of my older work. It’s not that the documents were that bad. They weren’t. I just kept finding things that I wish I had done differently; that I certainly would have done differently had I known then what I know now – both from a business perspective, and from a principles of business analysis perspective.
So, what’s my point in calling myself out like this on my own blog?
Over the next few days I’ll be wrapping up a use case document that I think is quite possibly the best one I’ve done so far. I think the design team is going to be able to put it to good use and deliver a good software solution.
That said, in another couple years, I suspect I’ll be just as critical of that document as I am now of the ones from a couple years back. I’m working on a longer post to explain why I think this way, but in the interim I’d be interested in hearing whether others among you have had similar reactions while looking through some of your past work? If so, why do you think that is?
I look forward to your thoughts on the matter.
I often experience the same thing. For the most part I think this is because my business analysis skills are constantly evolving, whether through background reading or direct experience. Also reactions from customers or colleagues can make me sit back and think about how I can improve on what I've done. I look back on earlier work with mixed feelings – I wish I'd known then what I know now, but I'm glad I know now what I didn't know then! This is one of the great appeals of the profession.
I went through that window a while ago. My next step was to move away from complete and accurate to sufficient.
Now my documents look less impressive, but also take less time.
I am with you on the notion of evolving or "maturing" as I'm referring to it in my follow-on. Experience is indeed a good teacher.
I think that's part of it, too, Craig. The goal is to write a document that is "good enough" to serve as a basis for good design and good software, not to win an award for documentation. I hear you there.
Yes absolutely I've gone through that….sometimes as soon as the end of the project while doing a review. To compliment the others' comments, I guess I'd just add that none of us are experts out the starting gate. It takes time to craft anything good, and that only comes via experience and practice. Whether "good" describes simpler, more concise, more detailed or the like is irrelevant. It's just that one must start off somewhere, screw it up a few times and learn from those mistakes.____The one thing I've noticed with myself, is that I really need to force myself to look to the rear in order to teach myself how to better my capabilities. This is an active exercise, not a happenstance encounter with my previous work. As such, I find the rewards are greater.____Best Regards__
Thanks for the comment, Doug. "Live and Learn" definitely factors in. To paraphrase another common maxim, "those who don't learn from history are destined to repeat it."
I look forward to following your comments on Twitter, too.
I agree completely. I've had similar experiences have been on discovering techniques and communication skills that help identify and solve problems more efficiently or with less overall stress on the team…"If I'd only thought do to that then!"
I think this happens because we are all on roads of continuous self-improvement. In a few years we become better people, we learn new things, we have experiences that change us. Just the fact that you are a blogger means that you are self-reflective: writing about what you've done helps you learn about it. Also different teams challenge us in different ways and it's quite possible that the people you work with or work for have helped you become a better business analyst and create better documents. I sure know that's happened to me too.
As I've been hearing a lot lately "it's a process". 🙂
Cheers,
Laura
http://www.bridging-the-gap.com
So many times JB, Everytime I am asked to share some documents which I have created in Past…I get depressed- How could I miss that? Why din't I review it again?
I think thats how it is- Professionals evolves in their respective fields. Thats not only true with BAs but with other too.. for example a very popular actor/director in Bollywood once said that he gets embarrassed watching his own movies …and believe me he is one the finest we have in India.
I have been following your blog since 2.5 years ..since I started my career as Business Analyst…and I must say ..YOU ROCK!!
Ranjan
http://beingbusinessanalyst.blogspot.com/
Thanks for chiming in, Laura. And yes, it's definitely "a process." Speaking of process, as I've been thinking on this topic over the past week, it's struck me that at least a few of the things I think I'd do better now than then were things that I would have liked to have done differently then, too.
Sometimes we're constrained to do things a certain way to fit the process framework under which we operate. But in any case – and to your point – that's part of the "living and learning" experience. We improve as individuals, and ideally, we also improve as organizations.
Good to hear from you Ranjan, and thanks for the compliment! Glad you find some of my stuff useful. If I recall correctly, you've been blogging about that long, too, haven't you? I know I've had you in my reader for a while.
Anyway, I guess it is a good trait to not become complacent and to strive to improve continuously. And you're right, this is true regardless of your field of work.
As far as looking back at past documentation, even as I wince I try to cut myself some slack and remember (to Craig's point above) that the goal is to get the documentation "good enough" to enable design and development folks to produce a solid solution in a timely manner.