If you’ve ever doubted the need for requirements elicitation for an ERP project, you need to read this. Apparently a company is suing an ERP software vendor because the software it was expecting to work in a promised date did not work even more than one year late (shocking!). It’s a very interesting read. Among other things, the plaintiffs refer to prototypes or mock-ups as a form of deception by demonstrating “fake software.” In any case, the moral of the author’s story is that, “even when buying a COTS system (an ERP is a big COTS), you do need the expertise of requirements engineers.”

While on the legal theme, have you heard that the State of Indiana has made use of a waterfall methodology a criminal offense?

“Waterfall software development lifecycles have terrorized technology projects in this state for too long,” Governor Mitch Daniels said at a simple signing ceremony held at a meeting of the Central Indiana chapter of the Project Management Institute (PMI). “This bill will end the tyranny of big upfront planning, big upfront design, and litigation style change management.”

It’s a fun read. I actually did “LOL”. Before you go calling your whole team to your cube to tell them about it, please bear in mind that the article was, in fact, penned on April 1.

Here is an interesting take on what a “dev guy who has done app maintenance, DBA work, testing and performance analysis” wants to get from the business analyst. He is fairly detailed in describing his expectations of what delivery teams need from the BA in order for:

the developers to build the application

the DBA to understand the data model

the operations guy/gal [to understand] what kind of information they would get at run time

the testers to write their test scripts

the performance tester to determine what are their targets

the trainers to write a course on the application

the stakeholders to know what they are paying for

the BAs (both client side and your side) to understand what need[s] to be going on.

Lastly, many analysts are aware of the informative articles from IBM that describe software development and methodology, often in concert with their own software and service offerings. Here’s an informative article from IBM on creating a system specification from the user’s point of view by using UML to create a user model. The article includes lots of examples and diagrams as well as links to related information.

Copyright JonathanBabcock.com. View the original post or comment on

Weekly Digest - 8-17

I read a though-provoking article the other day by Tony Lock on why IT is still not communicating well with its business counterparts. Per Lock:

[F]ew organisations have formally established and monitored service levels reporting in terminology and language with which business users will be comfortable… But when it comes to measuring and reporting on IT’s contribution to either overall business goals or top line business value, the number of organisations with formal reporting processes in place drops to only one in five or even lower.

However, communication isn’t just about metrics and reports. He concludes,

The biggest benefits to the entire business and to IT departments themselves will come not directly from establishing and formally reporting on these matters in business terms but in establishing expressive two way communications between business and IT professionals.

Amen.

On the lighter side, here’s a fun graphic that compares the usability of an Apple product, a Google product, and “your company’s application.” Ouch!

I liked an analogy from Joe Shoemaker posted at Modern Analyst. In it, Joe compares the roles of customer, Business Analyst and Business Manager to a car buyer, salesperson and the buyer’s wife. It’s a quick, fun read and well-written. Do take a look. Also, parse through the comments. There’s some good dialog there as well.

I like to gather constructive quotes. Here’s a link to 21 Suggestions for Success. Some of them may seem a bit trite, I think at least a few are consistent with the subject matter of this blog. Here is a quick sample of my favorites:

“Work at something you enjoy and that’s worthy of your time and talent.”

“Be decisive even if it means you’ll sometimes be wrong.”

“Commit yourself to constant improvement.”

Requirements inflation? Nahh. Never heard of it. Thanks to Geek and Poke for the fun picture.

Copyright JonathanBabcock.com. View the original post or comment on

Weekly Digest - 08-16

Presentations

ONLINE PRESENTATIONS: 30+ Presentation & Slideshow Service - I was talking with one of my brothers the other day about the presentation application available through Google Docs. He was touting how easy it was to use, as well as the fact all you need to show the presentation is a Web browser. It seems that there are still a number of folks that don’t have PowerPoint, and even if you do, there is drama over e-mailing presentations, etc. etc. This post includes several other options - some with some pretty impressive features - for online presentations & slideshows.

Also on the topic of presentations, I found “Represent Your Company With Style - Presentation Tips for Executives” from Presentation Pointers to be a nice, quick reference as I was doing some research for recent presentations I’ve made. Below are some highlights.

• On being prepared:

Take the time to prepare an outline of your talk. If possible, write out your first and last sentences. These are the most important parts of your presentation, and you will deliver them best when you know them exactly.

• On being gracious:

Use the event as an opportunity to promote good will. Avoid complaints, criticism, or controversy. These will quickly alienate the audience and destroy your credibility. Instead, talk about what the audience wants to hear. Praise your host, honor the occasion, and compliment the audience. Radiate success and optimism.

• On using humor:

If you plan to use humor, be appropriate. Avoid making fun of anyone or anything that might offend people in your audience. Often, the only safe target of humor is yourself… The best types of humor are original stories that make a point. For example, you might tell about the time that you left your luggage in a hotel lobby, the struggles you encountered to retrieve it, and the outstanding service you received from the clerk who found it. Such a story also shows the value of great customer service.

Remaining on topic, you should also take a look at Executive Summary and Presentation Suggestions. Included there are some tips for the 10 minute presentation, tips for the executive summary, and a list of common mistakes relating to the two.

Humor

The Amazing Information Technology Title Generator! - Per the author: “Some time ago, I read an article about the ever-changing titles in IT and how they never seem to describe what any of us do. Well, after some thought, I decided that a random title generator was just what we needed to help us out.” Not happy with your current title? Go get yourself a new one. What does a “business analyst” do, anyway?

Short Cuts

• Over on the Seilevel blog, one submits that “[a] big challenge in requirements are today is that projects are often too big.”
• The IIBA has unveiled its draft definition of business analysis.

Business analysis is the set of tasks and techniques used to work as a liaison among stakeholders in order to understand the structure, policies, and operations of an organization, and recommend solutions that enable the organization to achieve its goals.

• Michael Flanagan shares “Ten ways to screw up your requirements.”
• Kupe over at B2TTraining argues that successful projects are all about teamwork;

When I look back at what made some projects challenged and others widely successful it came down to all team members doing what was needed to reach the goal regardless of their role.

• Craig Brown shares some ideas on how to speed up your meetings and keep them foused on the highest impact issues.

Copyright JonathanBabcock.com. View the original post or comment on

JB Weekly Digest (07-49)

Anyway, we’re back this week with some more links and commentary items I’ve found interesting or funny, and that I thought like-minded individuals might enjoy.

Language/Communication

Pain in the English - As business analysts know, it is challenging to communicate ideas with precision using natural language. It’s all the more difficult when we don’t use words correctly. Should I use “obliged” or “obligated”; “skilled” or “skillful”; “percent” or “percentage”? PITE is a “Forum for the Gray Areas of the English Language”. Per the site description,

PainInTheEnglish.com encourages discussions of such gray areas of the English language, for which you would not find answers easily in dictionaries and other reference books.

Users submit questions about word or phrases, and the responses are thoughtful and useful. It looks like a pretty good resource, and merits a look next time you are unsure of whether the word you’re using is appropriate or even a word at all.

Productivity

Chart Chooser - I found this the other day while looking for eye candy for a presentation. Chart Chooser from Juice Analytics provides a number of very practical (and attractively designed) chart templates that can be downloaded in used in Microsoft Excel or Power Point. They’ve categorized the available charts as follows: comparison, distribution, composition, trend, relationship and table.

A Little Levity…

> Here’s a tongue twister that probably only a techie can appreciate:

IF IF = THEN THEN THEN = ELSE ELSE ELSE = IF;

> “Goating” - Ever step away from your word area for a little while and either forget or just neglect to lock your computer? Bad idea. Never mind the security risks, Coding Horror warns of the possible pranks and embarrassments that befall those who take their chances. I’ve seen (and maybe even participated in) the one where you send a silly e-mail from a co-workers desk to one or more people. Or, I’ve seen people put up weird Google search results pages (i.e. hair regrowth formulas or, for that matter, hair removal solutions) on the individuals desktop. Per the article, other examples of “goating” include:

• Installing the bluescreen screensaver.
• Replacing the desktop with a screenshot of the desktop, and hiding all the visible items on it.
• Switching the mouse from right to left handed.
• Using the video driver settings to rotate the display left, right, or upside down.
• Switching the keyboard layout from QWERTY to Dvorak (or vice-versa).

There are lots of examples or “goating” and some funny pictures included in the original article. Take a look if you’re up for a chuckle, or up to no good..

Short Cuts

• Michael Gladstone of the IIBA provides a glimpse at what’s in the works for the CBAP and what to expect in 2008.
• Scott Sehlhorst toasts the 2nd anniversary of his Tyner Blain blog. If you’re involved in business analysis or product management and don’t read Scott’s blog regularly, you need to.
• Craig Brown warns that “Agile projects threaten the role of business analysts on IT projects.“
• The NASA Software Assurance Quality Center provides a detailed dissertation on writing effective requirements specifications. Pretty standard stuff, but nicely organized and serves as a good reference resource.

Copyright JonathanBabcock.com. View the original post or comment on

JB Weekly Digest (07-47)

Building Relationships

I recently had an opportunity to spend some time working on a project with one of my company’s vice presidents. We talked a bit about systems, about processes, about solutions, but often about people. He emphasized that we do business with people. To be successful we have to have successful relationships. I agree with the importance of establishing relationships of trust. You may have heard the old cliché that people “don’t care how much you know, until they know how much you care.” I think there is wisdom there.

I get the impression that Jim from Project X Discussions feels the same way. In his article, Challenges of the Business Analyst, he states:

I have found that the first step in any meeting between people is the development of rapport. The people need to feel comfortable with each other as people. How many times have you been meeting with somebody and things go very poorly and you had the premonition in the first twenty seconds. Likely no rapport has been established between the people.

He then goes on to give some examples of how rapport may be built, and how to proceed once it has, or once it is lost. One of the points Jim makes that I’ve seen made elsewhere, but that I’d like to note is the danger of using IT jargon when dealing with non-technical stakeholders. If our goal is to establish a meaningful relationship based on the common ground we share, we can cause that ground to crumble quickly if we use terminology with which others are not familiar and uncomfortable. Per Jim:

Listen to the words the person uses to describe something and use the same words. If they have a name for a function, use that name. If they have a name for a process, use that name. Stay away from the technical jargon we all slip into in the IT world. “The ETL process of EDW is critical to Micro-strategy software. We need to understand how to normalize your data so we can drill down and across.” If you thought I was from the moon before, I just moved to Mars.

Writing Good Requirements

Structure in requirements writing, MJMurphy

I’ve come to the conclusion that the logical structure of the writing is as important as the content. Although it may seem that content is more important than structure, in fact it is the structure that makes a document readable and understandable. If your readers cannot easily comprehend your work the content really doesn’t matter.

Murphy then elaborates and provides a bit of useful advice on ordering grouping requirements. Go have a look at the rest.

I wanted to refer to this article in this week’s digest because I agree that the way a document is structured has a great effect on how readable and ultimately how effective the document is as a tool of knowledge transfer. This whole structure bit is actually one of the knocks on natural language requirements. As it is, natural language - even with the most clear and concise wording - can often have more than one interpretation. Couple that with an unclear or illogical arrangement of requirements, and you’ve got yourself a recipe for a disastrous document from the reader’s perspective.

I like to break requirements into subsections with nice, large headings and to to keep the progression of requirements as logical as possible, and seek early feedback on the document through informal reviews and one-on-one discussions with document consumers. Anyway, it’s a great topic and one that I may try to explore in more detail on this blog in the coming weeks.

Methodology

You Don’t Know What You Don’t Know Until You Take the Next Step, Bob Koss

Koss points out that one main reason for failure in a waterfall environment “or at least the problem with the way most companies implement it, is that there either isn’t a feedback mechanism or the feedback loop is way too long.”

I’d agree that a successful waterfall-type methodology is one that resembles agile if in no other way than that requirements gathering is a highly interactive and iterative process, and feedback begins early and happens often. Also, we have to understand that just because a document has been signed-off, we ought not to assume we’ve identified all the requirements. In Koss’s words:

Before there is UML specifying a design, there must have been requirements stating a problem that the design addresses. Have we captured all of the requirements? Are they complete? Are they accurate? Are they unambiguous? How do you know? I believe that you don’t know, and worse, you don’t even know what you don’t know. You don’t know until you take that next step and try to design a solution. It’s only during design that phrases like, “What’s supposed to happen here,” or, “That doesn’t seem to have been addressed in the spec,” are heard. You don’t know what you don’t know until you take that next step. It is very easy for everybody on a project to believe that they are doing good work and that the project is going according to plan. If we don’t know what we don’t know, it’s hard to know if we’re on the right track.

Back to the phased, waterfall type approach. If it’s hard to know if we’re on the right track, it’s hard to know that we can finish the requirements “phase”. When we’re unsure, we tend to prolong phases and begin to churn and overanalyze; we get stuck in analysis paralysis. For a waterfall-type methodology to work, I think it has to acknowledge - much as does the agile approach - that requirements gathering is iterative. Once we’ve gathered requirements sufficient to let us proceed with design with an acceptable level of risk, it’s time to dive in to design. As design moves forward, of course we’ll come across things that need to be included as requirements.

Use Case Disgruntlement

(Ab)using Use Cases from Stephan’s Process Blog explains that many companies try and then abandon use cases because they were too hard or complicated to use.

The usual cause I see is that organisations try to make [use cases] the vehicle for all requirements. This leads to long, hard to read, use cases causing disenchantment and ultimately abandonment of this technique. This is a pity because there are few approaches so powerful in eliciting and structuring requirements.

Stephan’s post provides 8 items that might be used to avoid discouragement with use cases and to help in using them effectively.

Short Cuts:

• BABOK 2.0: Kevin Brennan provides a sneak peak at the BABOK 2.0 framework.
• Roles & Responsibilities: Read up on the RASCI framework and even download a sample matrix from Kent Blumberg in his post, Clarifying Responsibilities.

Copyright JonathanBabcock.com. View the original post or comment on

JB Weekly Digest (07-45)

Humor

Developers are in tremendous pain. Have a look at their desperate call below.

Apparently, this is from a Devshop commercial. Hey, if there product is nearly as sharp as their commercial, it may be worth a look!

While we’re having a little fun with developers, why don’t you take a look at 10 types of programmers you’ll encounter in the field, by Jody Gilbert? I won’t go into detail about the various types, but I will give you some of their “names” to pique your curiosity; Gandalf, The Martyr, Fanboy, Vince Neil, The Ninja, The Theoretician, The Code Cowboy, The Paratrooper, Mediocre Man, and The Evangelist. Go have a look. This is good stuff. Even the most stoic software developer is going to have to admit to having met some of these guys..

If you can still handle another chuckle or two, have a look at a list of The Best Geek Quotes. Do check out the complete list, but here are a few of my favorites as a teaser:

“If at first you don’t succeed; call it version 1.0″

“Be nice to geeks, you’ll probably end up working for one.”

“It’s a little-known fact that the Y1K problem caused the Dark Ages.”

“Life would be so much easier if it were open-source.”

“Some things Man was never meant to know. That’s why we invented Google.”

“There are 10 types of people in the world: those who understand binary, and those who don’t.”

Relationships

I’ve read Dale Carnegie’s “How to Win Friends and Influence People” probably at least 3 times that I can recall. What a great resource to help you succeed with relationships - whether professional or personal! If you haven’t read it, I advise you to do so. Either way, I think you’ll find this very brief, quick-hit summary of use. It includes bulleted lists including Carnegie’s counsel on:

• Fundamental Techniques in Handling People
• Six Ways to Make People Like You
• How to Win People to Your Way of Thinking
• How to Change People Without Giving Offense or Arousing Resentment

Written Communication

List of Commonly Misused Words, NoSlang.com.

As authors of professional documentation, there is an expectation - and I think it’s a valid one - that business analysts use correct grammar and word usage in their deliverables. At its purest, natural language tends to lend itself to a certain level of vagueness. Misusing words certainly doesn’t help matters. While there are lots of good resources available on the web, I came across this site recently. I may share others if there is an interest. I just found this to be brief, and it covers several of the most common confused and misused words.

Usability

Into usability? 30 Usability Issues To Be Aware Of from Smashing Magazine includes information that may be especially useful to web developers or bloggers.

Ever heard of the 7±2 Principle? How about the 2-second rule? The 3-click rule? These and many other concepts are included in the article. I also appreciated the fact that they threw in a very helpful glossary of usability terms and concepts. Anyway, I included it here because I found it a nice primer on a topic that probably doesn’t always get the attention it deserves.

Staying with usability, Sim D’Hertefelt asks and then answers [w]hy user experience disasters happen at the start of web projects. Per D’Hertefelt:

Requests for proposals for web projects describe the desired solution but often lack basic information about the problem that will be solved by the application. To design a usable user experience you have to understand the problem first: who are the future users, what are their current practices and what are their needs? The main barrier to this understanding is that some corporate cultures lack the courage to really listen to users… How do you understand users, their needs and their current practices? By really listening to users. Really listening does not mean asking multiple choice questions. It means that you listen to the story you didn’t ask for. It also means that you observe. Because what people say they do and what they actually do are sometimes very different things. And finally, it means leaving the safety of your office and going out to meet users in their context: their home, their office, the shop, etcetera. Because what people explain to you outside the context of their activities becomes distorted and rationalized.

I agree heartily on these points. In fact, I’ve been traveling a fair portion of this past week to meet with users of one of our systems to make sure that we understand how the process works and how users interact the system before we make some important decisions on how the work should be done in the future. You just can’t beat talking firsthand to the people who do the work. In my experience, users typically really appreciate the opportunity to share information - even if you’re just observing them. It helps the business analyst capture and document user need better, and gives the user a sense of involvement and ownership in the systems development process.

Well, that’s enough for this week. Please let me know if you are aware of other good resources on these topics, or if you have a particular comment on any of the articles I’ve referenced in this post.

Copyright JonathanBabcock.com. View the original post or comment on

JB Weekly Digest (07-44)

On UML Modeling:

How to draw UML activity diagrams, Scott Ambler. Scott provides a brief, introductory-level list of guidelines by Scott Ambler for drafting UML activity diagrams.

The use and misuse of includes and extends, MJMurphy. This article discusses the notion that includes and extends stereotypes or frequently misused in use case diagramming. In summary:

Adding lots of includes and extends to your use case diagram can make it difficult to read so use them only when they improve readability and maintainability, and use them correctly. If you are modeling behavior that is common across use cases, consider the includes relationship. If you have complex alternatives and exceptions, consider using the extends.

From use case diagrams to context diagrams, Kevlin Henney. Touts the merit of the good, old-fashioned context diagram, and does a basic compare/contrast with use case diagrams.

• Defining the context diagram:

Context diagrams are intentionally simple with a clear responsibility: They clarify where in the world a system fits, offering an opportunity to discuss the roles that use it and are used by it. It should be possible to fit a context diagram plus a brief description of each external role on a single page.

• Context diagram as compared to the use case:

It is tempting to consider use case diagrams as context diagrams because they do indeed show context. However, use case diagrams show more than just a system and its context; they also show the behaviors the system is to fulfill. By contrast, a context diagram has the single, simple responsibility of showing the system and its context.

On Outsourcing/Offshoring:

Two bloggers that I respect and enjoy reading, Scott Sehlhorst (Tyner Blain) and Bill Miller (You Want It When?), are debating the merits of outsourcing. In Scott’s words, “We looked at pro’s and con’s, and our discussion centered around the best outsourcing model, and what the ramifications of outsourcing really are.”

Scott takes the view that “[complete technical outsourcing] is a recipe for long-term failure,” while Bill argues that “outsourcing is an inevitable change that needs to be accepted.”

I’m not even going to begin to try to parse and pick favorite quotes from the exchange. I encourage you to read it for yourself. Nice work, gentlemen!

On Managing Requirements:

3 tips to improve requirements management, Craig Brown. Craig points out that an open line of communication with and among stakeholders, clients and subject matter experts throughout the project is required to avoid requirements failure (ergo project failure). He adds that BA’s need to be skilled at managing requirements, and not just gathering them.

Copyright JonathanBabcock.com. View the original post or comment on

JB Weekly Digest (07-43)

Here are some noteworthy quotes and concepts I’ve come across this week.

Nancy Knettell, Agile development: Don’t forget the documentation. Great article. I’d actually begun to outline a post on this recently, but see no need for it now. I like the idea of delivering functionality more quickly, but wouldn’t sacrifice quality documentation to get there. I’ve felt the pain of not having sufficient documentation often enough to know that if it doesn’t get you now, it’ll get you later. You simply have to have good specs and good design docs.

Often the goal of these agile methodologies is to have as little documentation as possible. I am all about timely communication and rapid time to market, but you need documentation. What concerns me is seeing everyone run away from the dumped “waterfall” bathtub without checking to see if the baby has to go, too…..Yes, the goal of all of these new approaches is to ensure that the software development process is more nimble to deftly handle changing customer needs. Rigid signoff software cycles have to make way for more agile forms of methodologies that allow for that feedback loop. But the question still remains: Why is everyone trying to kill the software functional specification?

Rob Appman, What requirements gathering technique should you use? We’ve begun to place more emphasis on visual methods in my shop recently. Although I’m not quite as comfortable with modelling as I am with traditional, natural language specs yet, I can appreciate Rob’s point below.

Methods that involve visualization of the requirements, such as prototypes, storyboards, scenarios, and to a certain extent use cases are beneficial when you have a business user who may not be concerned with the ins and outs of the technical solution or have a very long attention span for validating the requirements in a long-winded document. Using visual methods to gather and eventually validate the requirements with the user allows the analyst to drive the discovery more effectively than simply reading through a document with a prospective user.

Scott Barber, Smoke and sanity testing. Per Scott, Smoke and Sanity testing are terms that are used interchangeably. In my experience, the smoke test was the last kick of the tires prior to implementation, and the sanity test was the small, targeted test conducted in production immediately after code is deployed to make sure the new functionality works, and that selected key functionality hasn’t been broken. I didn’t know the origin of the term “smoke test,” though. Thanks Scott!

If you’re interested, the term “smoke test” comes from plugging in an electronic device after it has been shipped to a distribution point but before delivery to the final customer. If the device smoked when it was plugged in, the distribution point would send that device back to the shipper and request a replacement instead of sending it on to the final customer.

Mike Schaffner, Gimme the Names. Mike’s article here is on using metrics to give a true measure of whether or not a project has met it’s objective(s).

A way to truly judge the effectiveness of a project is through the use of adequate metrics… Developing a specific metric related directly to what the project is about can show a true before and after picture… The difficulty is that these specific metrics probably are not generally collected and there will be some hesitancy to go to the effort to collect the necessary data. However, if you make it part of the project and it is seen as a way to help get the project approved you’ll get more acceptance. You might also consider making the data collection temporary to be used to establish a “before” scenario and then drop it after you are sure the “after” scenario has reached a steady state.

Bill Miller, Part 1: How To Manage An Unrealistic Schedule. Sometimes making the date requires “all hands on deck” in a true team effort. This article made me think about the importance of cross-training and understanding all the roles in your company’s systems development process. You never know when your ability to “switch hats” might make the difference.

Nobody has only one job responsibility on this team; any task required to deliver the project can be performed by anyone on the team. If you need developers to test, then they put their QA hats on to test. If you need them to write documents, then they write documents. This is a team effort, and there is no room for prima donnas on a team - especially one that is delivering on a tight schedule.

Conceptual Thinking from Trials and Tribulations of a Business Systems Analyst. I’ve begun to outline a post of my own on a similar topic. Mine will be on the the importance of the analyst’s ability to draw concepts to their logical conclusions, whether that be decomposing high-level concepts, or rolling up details into higher-level bullet points.

Conceptual thinking is very important to an analyst. Not only the conceptual thinking itself but the ability to apply concepts to real world problems…. We can have all of the most advanced technological knowledge available but if we can’t apply the technology to the problem in an efficient manner it is meaningless…. The ability that you want to develop is the ability to see a problem from different angles. You want to envision it and turn it over and over in your mind looking at each moving part. You need to envision more than one solution and then you need to choose the solution most appropriate to the problem.

What are your thoughts on these quotes and articles? What articles have you come across this week that you thought worth noting? Do share!

Copyright JonathanBabcock.com. View the original post or comment on

JB Weekly Digest (07-42)

• The Practice of Leadership - Blog Archive - Resolving stuck conversations.. -

Conversation creates involvement, which generates the commitment. It’s commitment that ensures aligned action and an effective end result. Therefore, getting the conversations right is of critical importance.

Copyright JonathanBabcock.com. View the original post or comment on

Recommended Link for July 1st

• David’s Software Development Survival Guide: Undreamt Requirements

  Interesting insight into 3 distinct types of requirements: Conscious Requirements - Problems that the new system must solve; Unconscious Requirements - Already solved by the current system; Undreamed of Requirements - Would be a requirement if we knew it

  (tags: requirements requirements-gathering management analysis)

• Better communication through better listening

  Nearly every aspect of human life could be improved by better listening.This article lists eight common barriers to good listening, with suggestions for overcoming each.

  (tags: communication management relationships)

Copyright JonathanBabcock.com. View the original post or comment on

Links for 2007-06-22