Here are just a few impressions I’ve jotted down over the past few weeks that may never evolve into full blog posts, but that I wanted to share just the same. Please feel free to chime in with your feedback, or with your own thoughts.
- In my observance, the primary difference between the expert analyst and the novice lies in the ability to recognize the recurring business (industry and company specific), technical and even political patterns in the problems we’re asked to help solve, and the knowledge of how to apply the right mix of principle, practice and personal touch to solve them. Talent, or a knack for picking up on patterns helps, but there is no substitute for time and experience.
- As a business analyst, it’s beneficial to have expert knowledge of the systems and technology in use, but it can also make it that much more difficult to fight the urge to originate requirements instead of eliciting them.
- That a deliverable has been approved doesn’t necessarily mean it was read or understood. If you want to be sure you’re being read and understood, seek out feedback early and often. What measures are you taking to make sure your deliverable is read and understood?
- It’s a simple fact of life that the longer a document gets, the less likely it is that it is going to be read. That’s why you bought the Cliff’s Notes in high school.
- A picture is worth several – if not quite a thousand – “system shalls.”
- One man’s “what” is another man’s “how.”
- Of course we all want to be more agile, but wholesale conversion to an “Agile” methodology isn’t the only, or even necessarily the best way to do it. Salesmanship (read: evangelism) of these single, fit-all and fix-all methodologies brings to mind the maxim, “if all you have is a hammer, everything looks like a nail.”
- Be wary of the pedaler of “best practices.” That’s not to say that there aren’t best practices, only that what’s best is relative. What’s best in one or even many situations doesn’t mean it’s best for most, let alone all. The trick – and this gets back to my comment above on recognizing patterns – is to understand a variety of “good practices” well enough to determine what is “best” in a given situation.
- Processes and templates are great to the extent that they serve as a reminder to do things that might be important, but they are a drag on productivity when they require work that isn’t critical to delivering quality product for the sake of satisfying a process or template.
[download id=”2″]
Agree with Todd. Some nice gems here.
Todd, as to what to do with your 200 page documents, what value or utility are they providing you and your organization now? Is there a better way to provide that utility?
Laura
http://www.bridging-the-gap.com
My these ARE some juicy tidbits. Think I like the last one. We’ve been grinding heavy CMMi where I’m slaving away for about three years. While I’m a big believer in process for an immature organization, as it matures less rigor is needed to control it. After a year’s worth of screaming from the bowels of the org, the staff is finally getting relief with a scale back to documentation that provides….wait for it…VALUE! Things had gotten so bad in filling out docs, the resources were blind as to what to do with the content once it was written. I actually had to create an engagement process for the process. I’d like to learn how other orgs avoid falling into these traps.
Thanks for another good post JB
DougGtheBA