Here are some links to worthwhile content that will fill your brain with business analysis.
- How Now Brown Cow (registration required) – James and Suzanne Robertson describe a handy method for arranging the various points of view from which business problems are typically approached into a usable context.
In other words people (all of us) see the world in terms of their own experience and importance, and their own levels of abstraction. The requirements analyst needs to be able to unscramble these disparate viewpoints and decide what to focus on to further the goals of the project. The Brown Cow model is a tool for helping to understand a number of different viewpoints in parallel.
- Art and IT: Two Solitudes? – Howard Podeswa, author of the book UML for the IT Business Analyst, provides an interesting comparison between art and the work we do as professionals in the IT space. It is really an interesting read. My favorite excerpt:
Whereas science and technology are largely about following disciplined, repeatable processes to arrive at a result, art encourages the mind to wander between ideas and see unexpected relationships. It’s a skill the Business Analyst needs to develop when looking, for example, for a common thread behind a slew of customer complaints or when coming up with a novel approach to solve a problem.
There’s a bleed, in other words, between the ways of thinking promoted by art and those promoted by science. Which is why I think it’s a good idea to explore both, as opposed to staying within one silo … not that there’s anything wrong with that.
- Requirements are the Lifeblood of the Project – Brad Egeland at PM Tips shares some examples of the benefits that good requirements bring to a project. Loved the title, too!
- A Serious Question – Kevin Brennan compares Gartner’s definition of enterprise architecture to IIBA’s definition of business analysis, then poses the questions, “Are business analysis and enterprise architecture fundamentally the same discipline? Or is there a real distinction between the two?” I’ve always considered the enterprise architect to be more of an extension of technical architecture than business analysis, but the definitions do bear a striking resemblance. There are some interesting comments worth a look while you’re there, too.
- Why Group Dynamics and Interpersonal Skills Matter – Esther Derby explains that , “It takes more than smart people to succeed. It takes smart people who have the interpersonal skills for creative collaboration.”
- DOD aims to beef up in-house engineering expertise – Anybody interested in a gig with the U.S. Department of Defense? Seems as though they’re looking!
[A]DOD engineer doesn’t need to be the person who actually writes software code, but the engineer needs to grasp what the contractor is writing to manage the contractor appropriately. The engineers need to understand what’s going on with the IT systems and software that is constantly being updated as the technology evolves. …
While seeking their own experts, defense officials don’t want to alienate industry and what it brings. The private sector is a key component for DOD to create IT systems …. DOD can run into problems if there’s too much software development from inside the department. Working with industry can help prevent the syndrome that he called NIH, or “not invented here.” … A strong relationship between DOD and industry keeps both open to new ideas.
To keep up with the latest on Practical Analyst, you can subscribe to the RSS feed, follow Jonathan on Twitter, or view his profile on Linked In.
Latest posts by JB (see all)
- Jim Rohn – February 20, 2014
- Elicitation Tip: When the Stakeholder Asks for a Specific Implementation – February 19, 2014
- Paul Oldfield – February 11, 2014