Justify Documentation

As Business Analysts we write a lot of documentation. Most of our documentation comes in the form of text, but many BAs have learned to augment their text documents with a variety of diagrams. The thing that bothers me though, is that too many BAs blindly follow prescribed templates for their requirements artifacts. Rarely do they ask how their requirements documents are being used by stakeholders, testers, and developers.

As a BA, you should always ask these questions of your audience in regards to your documentation:

  1. How do you use the documentation that I provide?
  2. What parts of the documentation do you read?
  3. Do you find the diagrams useful and understandable?
  4. What parts do you not look at? Why not?
  5. What can I add to the documentation to get you the information you need?
  6. Is printed documentation the most effective way to provide you with the information?
  7. How do you get the missing information? Do you talk directly with users and stakeholders?
  8. Could I help you do that?
  9. Are our templates organized in the best way?
  10. Does the same document work for different audiences (think business vs. development)?
  11. What’s the consequence if I don’t write some particular document?
  12. We need to justify why we write documentation, not simply follow some template because it’s always been done like that. Too many templates have a “one-size-fits-all” structure that won’t work for some projects. Question the documentation templates and find better ways of communicating your analysis insights.

    I believe that we need to look beyond documents as a way of managing and communicating requirements. Too many of my clients still use principally Microsoft Word to track, store, manage, and communicate their requirements. Why not publish the requirements as a Wiki? Why not track the requirements in an actual requirements management tool or at least a database? Why not use the power of the Web and HTML to provide live links and cross references?

    Tell us, how do you document your requirements? Do you produce different documents for different audiences? How do you manage these different versions? Do they find them useful? Do you ever ask your developers and vendors how they use your documentation and how you might improve them? Have you considered using Wikis as an alternative to sharing requirements?

Posted in Uncategorized, techniques | Leave a comment

Survey on Social Networking Tools

I’m conducting a survey on the adoption of social networking tools by professional business analysts. Help me by completing the survey! Here’s the URL for the survey. It’ll take no more than 5 minutes — there are only 9 questions. Plus, you might win a free copy of my new book on business process modeling — perhaps that’ll push you over the edge ;)

I’ll post the results once I have collected and analyzed the data — should be a couple of months.

How do you use social networking tools? Which ones have you found to be especially useful?

Posted in techniques | 1 Comment

Project Origination Sources

As BAs we need to know where projects originate so that we can pick the right techniques to apply to analysis and documentation. So, where do projects come from? Projects originate from many sources. They can come top-down, bottom-up, from the middle, or from the outside.

Senior management originates project needs based on their strategic goals and directions. This requires the development of business cases and using high-level requirements analysis strategies, such as business use cases, context analysis, and business benefit statements.

Click-level end-users are a frequent source of projects. They encounter problems with a system or a business process during their daily work and based on those complaints they force us to launch projects to repair those defects. Requirements catalogs, use cases, storyboarding, and prototyping work best for those situations.

Middle managers often need information to make decisions. They need reports and dashboards that consolidate data from different sources. For those types of projects use cases, context analysis, and prototyping work best as requirements analysis techniques.

Finally, many projects come from customer complaints, market changes, competitive landscape updates, and regulatory changes. Depending on what the changes are, different requirements analysis strategies will work. Commonly, SWOT analysis, Fishbone diagramming, brainstorming, and prototyping are well suited for these types of projects.

So, know where your project’s coming from — it’ll help you understand where it’s going, who you need to consult, and how to get there…

Posted in Uncategorized | Leave a comment

Are Too Many BAs Simply “Order-Takers”?

There is an issue that I’ve heard from my clients consistently over the past few years. It’s that too many Business Analysts (BAs) simply act as “order takers”. They go to the business to get requirements and simply write down what the business says. To them that’s the job of the BA and that’s what requirements elicitation is all about. I disagree! Elicitation is more than that and the BAs job goes beyond order taking. We must advise the business and we must analyze the requirements.

For example, too often we are given a fixed scope, fixed deadline, and fixed resources even before the requirements are even conceived. We then try to “get the requirements” and then struggle how to fit them into the project’s constraint. That’s not analysis. We need to advise the business when the goals are unrealistic — we need to manage expectations. If the project’s scope can’t be done in the timeframe we’ve been given, then tell the business why it can’t be done and tell what can be done.

As a former CEO, I always provided my projects teams with a vision, an overall scope, a deadline, a budget, and resources. Good leaders put stakes in the ground. If you don’t then the project teams work without goals and they won’t focus — deadline and resource constraints force prioritization and efficiency. But, if my constraints were unrealistic, I expected my project teams to tell me as soon as they know. I also want to know what they can do within the budget and timeframe. I want them to analyze the problem — not just go off, grumble and complain, and then tell me in the end that they can’t get it done. After all, I have set marketing, sales, and client expectations. So, if you can’t meet the objectives, let me know right away — I’ll understand if you give me reasons.

Anyway, we need to act more as analysts and not simply take orders and then go off without helping the business understand what can and can’t be done. Keep in mind that business does not know how IT works; educate them, help them understand why some requirements might not be doable.

Posted in Uncategorized | Leave a comment

Using Tools During Elicitation

When I teach my courses on requirements elicitation, I’m always asked what tools business analysts should use. My answer surprises many people (after all, I’m a trained Computer Scientist and Software Engineer): don’t use computer-based tools during elicitation sessions. Why not, you may ask?

Well, for one, the tools inevitably crash, have quirks, and kind of get in the way. Plus, the resolution of most projectors is way too low for any kind of large diagram.

Whiteboards are much better — lots of space, great resolution, never runs out of battery, projector bulb doesn’t break, etc. When you are done, take a picture (even a cell phone camera is more than enough these days to get a good image), and then transcribe (and analyze) into a more permanent format using a modeling or requirements tool.

The real reason why I like whiteboarding is this one: it engages your audience. Give them markers, have them go to the whiteboard, have them make their own corrections. Suddenly it’s their model, their problem, their requirements. If you drive a tool, then you own the model/artifact.

In summary, use whiteboards to think, use tools to record.

Posted in Uncategorized | Leave a comment

Got my book on BPM done

Over the past few years, I’ve been doing a lot of business process modeling and found that I spent just as much time modeling processes as I did defining the general business architecture. So, I codified my approach and wrote it up in a book: “The Art of Business Process Modeling: The Business Analyst’s Guide to Process Modeling with UML & BPMN” (ISBN 1450541666); available at Amazon and other retailers.

The book covers my process-centric approach to defining the business architecture. I call the methodology PROMAP (PROcess Modeling APproach) for short. PROMAP uses a collection of integrated models to define a business process within the context of the business architecture. It’s an easy to follow BPM framework for the practicing BA.

As far as visual modeling notations goes, the book explains UML and BPMN. Coverage focuses on the core notational elements that are useful in practice yet are advanced and complete enough to model complex processes.

Check out the book, order a copy, and give me your feedback. It’s available through Amazon.

Posted in Uncategorized | Tagged , , | Leave a comment

More on Tools

To get back to the use of tools: I’ve been using a number of business analysis tools and I want to give you my impressions:

1. Enterprise Architect: that’s the tool I use most frequently. Low cost (sub $200); mostly based on UML, but supports also BPMN. Add-ons for enterprise modeling including TOGAF and Zachman. Does not require the use of any particular methodology.

2. Visual Paradigm: been using the community edition (free) for teaching IS Analysis at Northeastern University; pretty good tool; nice use case modeler; supports UML well.

3. StarUML: open source and free, but you get what you pay for; does not support UML well enough for business process modeling; would not recommend

4. ProVision: really nice tool for BPM and BPA; strong support for hierarchical enterprise modeling; very expensive, though. The big thin is that it has monte carlo and discrete event simulation capability for business process engineering

That’s it for now…

Posted in Uncategorized | Tagged , , , , , | Leave a comment

the business analysts open source toolbox

I’m always asked about tools for modeling, requirements tracking etc.; invariably, the discussion turns to price and that’s when it gets interesting; now, some companies are spending the money to get commercial enterprise-class tools into their IT organizations, but many are not; partly, because they can’t afford it, but also because the analysts and developers can’t agree on the tools to use. In the meantime, Word, Excel, Paint (yep, you read right), and perhaps Visio are the tools of default. Good tools are important: they reduce labor and increase productivity, making analysis faster and less expensive.

So, how about some “open source” and “free” tools:

StarUML: a simple but effective UML modeling tool that supports most of the UML that analysts need; the only thing I don’t like is that the activity diagramming module is missing expansion regions (so now easy way to show repeated actions)

OpenProj: a good replacement for Microsoft Project; its files are compatible with Project and it has very similar features; not as good as Project, but you can’t beat the price

I’m still looking for a good requirements management tool, testing tool, and document generator. In the meantime, I’m continuing to use Sparx’ excellent Enterprise Architect: low-cost and full-featured for small to medium size projects that is being used in our development projects and in my consulting work; I’ve also been adding it to my seminars wherever appropriate. Perhaps more about that in a later blog entry.

Posted in tools | Tagged , , , | 1 Comment

hello, everyone

welcome to my blog! my goal is to share with you some of the insights I gather while teaching seminars on business analysis, software architecture, and IT design. there’s so much to talk about now that business analysis is becoming established. I often hear clients and workshop participants complain about very similar issues, so whenever there’s an issue worthwhile to talk about, I’ll do it here. Of course, I won’t reveal anything proprietary or confidential — that would not be right.

I welcome your comments and I always love to hear how different analysts approach problems. On occasion, I may also interject insights from my academic work: my lectures at Northeastern and UMass-Lowell, conference talks, and workshop presentations…

And yes, I will continue to write in lower case; it’s faster and more informal and allows me to quickly blog when I encounter interesting issues.

Posted in Uncategorized | Leave a comment