Below is a short list of free desktop/productivity tools that I use regularly. I thought some of you might benefit from knowing about them as well. Please feel free to comment or contact me with other nifty free tools you use to help you (or your computer) work more efficiently. I’ll continue to add to this list as I discover new ones as well.

Evernote

Evernote is my “external brain”. I use Evernote for my personal notes, work notes, and to brainstorm blog posts. It has handy web-clipping capabilities that make it easy to capture screenshots or text and save them for future use. Evernote allows you to arrange information into separate notebooks on different topics and supports tagging. I’ve been really pleased with it so far. Evernote also stores all your notes online so they are accessible from anywhere you can get a connection – even on your mobile phone. It also enables you to share notebooks if you want to collaborate on a small scale.

Freemind

Freemind is a free mind-mapping tool that I regularly use to help sort out my thoughts. It is great for use in decomposition exercises and for arranging ideas hierarchically.

Pencil

According to the web site, “The Pencil Project’s unique mission is to build a free and opensource tool for making diagrams and GUI prototyping that everyone can use.”  I don’t use it everyday on the job, but I have begun investigating Pencil as a GUI/Prototyping tool. It comes as a Firefox add-on, or stand-alone application. Obviously, it isn’t as robust or sophisticated as some other wireframing/prototyping products, but it provides all the basic functions one would expect in a quality tool, and you can’t argue with the price!

Fences

Fences is a tool for helping clean up messy desktops. It’s sort of like being able to throw all your clothes and junk under the bed and in the closet with a mouseclick. Basically, fences lets you sort your desktop icons by logical groups and temporarily hide information you don’t want to see. As a practical application, I often have to present documents or presentations via projector. Instead of the world seeing my cluttered Windows desktop, with a double-click I can hide all but those icons I want to remain displayed.

CCleaner

CCleaner helps clean up all the junk files and registry issues that can bog a computer down and cause it not to perform well. CCleaner takes care of the junk and is useful for uninstalling programs and cutting out some of the unnecessary programs from your startup menu that cause your computer start-up time to be slower than you’d like. An alternative with a few more features, but that I’ve not used for as long is Glary Utilities.

Icon Restore

As I mentioned, I have to do presentations via projector quite often, and one of the most annoying things about doing that is that your desktop icons end up getting moved all over the place. Icon Restore lets you save your desktop icons so when your desktop gets messed up by changing display types, you can quickly set it back to normal.

View the original post or comment on Free Desktop Tools a Business Analyst Should Know About

Related posts:

1. The Business Analysis “Artist” and the Requirement Tools of the Trade
2. Requirement Visualization: Mock-up & Wireframe Goodies
3. Free Scrum & XP Project Tracking Tool

Here are a few of the articles I found “bookmark-worthy” over the past week.

• Improv Comedian Turns Business Analyst by Jonathan Kupersmith – Kupe draws out some of the parallels between comedy improv and the soft skills – or characteristics – that can really help an analyst “perform”.

• Bridging Documents by Karl Wiegers – “It’s not unusual for a well-meaning requirements analyst to carefully prepare a software requirements specification and deliver it to the development team and testers, only to have the recipients gripe about it.”

• Creating wireframes and mockups – Includes some wireframing fundamentals, and then reviews of some of the more common wireframing tools.

• Using User Stories by George Dinwiddie – List a few advantages of user stories, and includes a link to a helpful handout on “writing and splitting” user stories.

• Where’s the juice in  your requirements? from Hobbs on Tech

Requirements are difficult. I should say good requirements are hard to put together. One thing to look for in requirements, instead of a shopping list, is the juice in requirements. Sure you may need a bag of oranges, but what you’re really after is orange juice. Of course, you also need a knife, juicer, pitcher, glasses, and to know how to make orange juice. But really, orange juice on it’s own really isn’t that interesting a requirement since pretty much anyone can make orange juice. So ideally you want to dig deeper and define more clearly what kind of juice you are attempting (perhaps mint orange juice made at your table?).

• Thoughts on Lean Thinking by Dean Leffingwell

• An entire ERP system in a single diagram from Kishore Kumar – It’s just as it says. An image of a UML package view of an entire ERP package. I’m just sharing it because I liked it and thought it could be useful. There’s something to be said for having that high-level, overall view of “what this thing does.”

View the original post or comment on Bookmarks & New Favorites (09-38)

Related posts:

1. Favorites for 2007-03-31
2. Use Cases or User Stories? Read Up!
3. Requirement Visualization: Mock-up & Wireframe Goodies

Here are a few of the articles I found “bookmark-worthy” over the past week.

• Improv Comedian Turns Business Analyst by Jonathan Kupersmith – Kupe draws out some of the parallels between comedy improv and the soft skills – or characteristics – that can really help an analyst “perform”.

• Bridging Documents by Karl Wiegers – “It’s not unusual for a well-meaning requirements analyst to carefully prepare a software requirements specification and deliver it to the development team and testers, only to have the recipients gripe about it.”

• Creating wireframes and mockups – Includes some wireframing fundamentals, and then reviews of some of the more common wireframing tools.

• Using User Stories by George Dinwiddie – List a few advantages of user stories, and includes a link to a helpful handout on “writing and splitting” user stories.

• Where’s the juice in  your requirements? from Hobbs on Tech

Requirements are difficult. I should say good requirements are hard to put together. One thing to look for in requirements, instead of a shopping list, is the juice in requirements. Sure you may need a bag of oranges, but what you’re really after is orange juice. Of course, you also need a knife, juicer, pitcher, glasses, and to know how to make orange juice. But really, orange juice on it’s own really isn’t that interesting a requirement since pretty much anyone can make orange juice. So ideally you want to dig deeper and define more clearly what kind of juice you are attempting (perhaps mint orange juice made at your table?).

• Thoughts on Lean Thinking by Dean Leffingwell

• An entire ERP system in a single diagram from Kishore Kumar – It’s just as it says. An image of a UML package view of an entire ERP package. I’m just sharing it because I liked it and thought it could be useful. There’s something to be said for having that high-level, overall view of “what this thing does.”

View the original post or comment on Bookmarks & New Favorites (09-38)

Related posts:

1. Favorites for 2007-03-31
2. Use Cases or User Stories? Read Up!
3. Requirement Visualization: Mock-up & Wireframe Goodies

I was sorting through some of my bookmarks and articles I’ve accumulated over time via the Web, and found that there are a few articles that I  seem to refer back to time and again. I’ve provided links below to several articles/presentations I consider to be “classics” in the field of business analysis and requirements engineering that I think any analyst would benefit from reading.

Some are relatively new, and some have been around for quite a while but are still every bit as valid as the day they were published.

I hope you’ll get as much use and enjoyment from these articles as I have.

Analysis/Requirements

• Building a Requirements Foundation through Customer Interviews – Esther Derby
• Use Cases: Best Practices – Ellen Gottesdiener
• Why I still use Use Cases – Alistair Cockburn
• The Fuzzy Line Between Requirements and Design – Karl Wiegers
• Structured Analysis Wiki – Ed Yourdon

Architecture

• Straight from the Shoulder – John Zachman

Communication/Collaboration

• Customer Rights and Responsibilities – Karl Wiegers

Methodology

• No Silver Bullet – Fred Brooks
• Lean Primer – Craig Larman and Bas Vodde
• Software Development as a Cooperative Game – Alistair Cockburn
• Agile Analysis – Scott Ambler
• The Agile Manifesto and the Twelve Principles of Agile Software

If you have any “classics” that you’d like to share, please comment so I can add to my collection and readers can add to theirs, too.

Keep an eye on this post – I’ll add more “classics” as I come across them.

View the original post or comment on Classic Business Analysis Articles

Related posts:

1. On Business Analysis in an Agile Setting
2. The Business Analysis “Artist” and the Requirement Tools of the Trade
3. Quoteworthy: Alistair Cockburn

I recently mentioned Laura Brandau’s new book on becoming a business analyst, and wanted to highlight another resource that was recently made available by Alex Papworth. If you are active in the online BA community, you may recognize Alex from his Business Analyst Mentor website, his articles on Computer World UK or from Twitter (@alexpapworth).

Alex’s likes to emphasize the value of mentoring and training in BA development, so it’s no surprise that his free e-book, Blueprint for Success as a New Business Analyst, follows the same pattern:

[The] advice in this guide is the result of combining my knowledge and experience of the business analyst role with the knowledge acquired from helping a number of individuals who want to become business analysts. … [It] is deliberately brief so that it can be read quickly and easily.

“Blueprint” provides some information on the why, who, what and how of becoming and developing as a business analyst, and includes some practical tips and links to helpful external resources (thanks for mentioning Practical Analyst, Alex!).

One of the things I like in particular is the new/collaborative media tack Alex seems to be taking which distinguishes “Blueprint” from many of the traditional, more static publications in the niche. Clearly, he intends for the work to evolve from “1.0″ in an iterative and collaborative way:

This is the first version of this guide and I intend to continually improve it and release new versions as I help individuals who wish to become successful new business analysts. Your help is key in achieving this. Please contact me with stories, recommendations and advice on training, gaining experience and presenting yourself as a credible business analyst.

Go have a look at Blueprint for Success as a New Business Analyst and give Alex some good, constructive feedback and a “thank-you” for the work that went into providing this free resource to the community.

View the original post or comment on Business Analyst “Blueprint for Success”

Related posts:

1. Free Desktop Tools a Business Analyst Should Know About
2. Corporate Strategy and the Business Analyst
3. It’s Good to be a Business Analyst

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.

View the original post or comment on More Business Analyst Link Love (09-28)

Related posts:

1. Requirements Management Link Love (09-13)
2. Business Analysis Link Share (09-24)
3. Sharing the Love – 2007-04-01

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.

View the original post or comment on More Business Analyst Link Love (09-28)

Related posts:

1. Requirements Management Link Love (09-13)
2. Business Analysis Link Share (09-24)
3. Sharing the Love – 2007-04-01

Here’s some “light reading” on some interesting analysis topics to kick off your weekend. Wait, you don’t really read business analysis articles during the weekend… do you?

• Business Analysis and SCRUM Development is a really interesting and well-conceived article. As is the case with many such articles, the comments are great, too. This quote gives the gist:

Over the past few years, the rise in popularity of SCRUM has raised many questions as to how agile works in practice.  One of the recurring questions has been: is there a place for the business analyst within the ADM environment?

In my view, the answer is unreservedly and unquestionably ‘yes’.

• In Need of a Theory for Software Engineering is an article by Ivar Jacobson that I found out about via Craig Brown. I had never actively looked, but I didn’t even know Jacobson blogged! And get this -  I just found out he tweets, too. In this article, he addresses methodologies and shares some methods for “finding the ‘truth’ of software engineering.” My favorite quote is the following:

There are many ways for people to learn software engineering but the only way to get good at it is through practice and experience.

• Check out Angie’s thoughts on COTS (commercial off-the-shelf) implementations and enhancements at The Business Analyst Blog. She is also looking for some feedback on others’ experiences with COTS  implementations and enhancements.

Organizations often prefer COTS applications because of a belief that these applications can be implemented faster out of the box than homegrown systems with very little custom development or ongoing IT maintenance. One mistake companies make is choosing a vendor or package before thoroughly analyzing their business requirements. Just like any other project the business drivers, the core business processes, the data, business rules, the users and external interface requirements need to be defined and understood before a solution is selected. Once the requirements are defined, performing a gap analysis with each of the COTS applications under consideration is recommended.

• Management methods, tools and theories – This is a very thorough, content rich page full of links to, well, management methods tools and theories. I think I picked this link up from Kevin (@bainsight).

• Simulating Success is a Forbes article on “how high-fidelity user-interface simulations reduce risk and improve the quality of software development.”

View the original post or comment on Business Analysis Link Share (09-24)

Related posts:

1. Requirements Management Link Love (09-13)
2. More Business Analyst Link Love (09-28)
3. The Business Analysis “Artist” and the Requirement Tools of the Trade

Adam Feldman, blogging from Bright Green Projects’ “Bright Ideas” blog poses a fun and interesting question. Twitter limits entries to 140 characters. Should we do the same for requirements? Per Feldman,

One of the things that first annoyed me about twitter was that the messages are restricted to 140 characters.  It is hard at the start, as you don’t want to lose the point of your message, but after a while it becomes much easier, you stop using flowery words, are careful not to repeat yourself and make sure you get to the point quickly.

I know that I and many other BA’s are guilty from time to time of writing requirements that are longer than they need to be. Good requirements are concise.  I’m reminded of one of my favorite quotes (of debatable origin), “I’m sorry this letter is so long, I didn’t have time to make it shorter.” It seems to take some real mental conditioning to drop extraneous words and phrases. It’s definitely something I’ve struggled to get better at.

So, about the 140 character limit. I’m going to have to say I’d be against programatically enforcing an artificial limit. There may very well be good reasons for exceeding that limit on occasion.  To quote Einstein, “Everything should be made as simple as possible, but not simpler.”  I like the incentive to be as simple and concise as possible, but I’m not overly keen on having an analyst have to oversimplify to fit a requirement into a character limit.

So, Adam, what would I do if I had a nifty new web-based requirements management tool (which he does, by the way)? I think I’d let the analyst type away, but much like Tweetdeck and probably other Twitter applications, I’d give the user a visual indication (change text color, or something not overly intrusive) that they’d exceeded 140 characters, only I wouldn’t truncate the requirement if they decided to keep it a little longer.

Just right!

Too long…

This way, you’ve got the analyst thinking about keeping it short to make the “suggested” character length, but not forcing split or incomplete requirements with a hard and fast rule.

Anyway, there is some good discussion in the comments section for the original post. Go check it out and chime in, I know Adam will appreciate the feedback.

Oh – One last thing – if you do go with the limit, please, please don’t call them “tweequirements”!

View the original post or comment on Bright Idea on Requirement Character Limits?

Related posts:

1. Precision Tools: Requirement Structure
2. Looking for Sample Requirement Specifications and Templates?
3. Requirement Visualization: Mock-up & Wireframe Goodies

There are tons of great articles on business analysis and other topics of interest for project professionals that come out each week. It’s impossible to keep up with all of them, but I like to occasionally point out a few I’ve come across that I think align fairly well with what you folks (PA readers) like. Enjoy!

• Dean Leffingwell walks us through the stages of disillusionment with waterfall development.

• Thanks to Martin for pointing out this nifty web application for creating and publishing basic UML diagrams.

• Friend of Practical Analyst, Doug Goldberg (@DougGtheBA) makes his blogging debut at Bridging the Gap discussing ways to smooth the waters between business and IT. While you’re there, check out Laura’s post on creating a user interface spec.

• Have a look at an interesting explanation of  virtualization and cloud computing using Legos.

• Page through Alistair Cockburn’s slides on software engineering in the 21st century .

• How can you pass up reading an article titled, “Chuck Norris Syndrome and IT Project Failure.”

• Docstoc is an interesting resource for finding documents on almost any topic. I’ve started posting nice, printable PDF versions of some of my blog posts there.

Lastly, on an administrative note, please check the URL of the feed you’re using to get updates from my site. For those of you subscribing to my feed via http://feeds.feedburner.com/jonathanbabcock, please either resubscribe to my new feed via the front page on my website, or by clicking here. The old feed is about to be turned off any day now, and I’d hate to lose any of you.

View the original post or comment on Best of the Web this Week (09-21)

Related posts:

1. Bookmarks & New Favorites (09-38)