I’m not sure I agree. I think it’s much easier to train staff to enter accurate information about their outgoing calls than it is to try to figure out why 30% of callers hang up before getting through the automated answering system and what their reason for calling was in the first place.

Regarding Twitter, when I first got harassed about it, I thought the same thing – why would anyone care that I’m making a cup of coffee? What can I possibly say of value in 140 characters other than “w8ing 4 metro 4ever. will be l8. sry”

However, there is potential there. First, do you have a favourite author? Did you know they are book signing in your neighbourhood next week? You would if you followed them on Twitter. Twitter can be extremely useful for following personal or business related interests. I follow a couple of companies and people who work in my area of interest, and now know where they’re holding their next seminars, the books they are reading or recommending or not recommending etc. I also know how my Calgary Flames are doing even though their games are rarely televised here (they are doing poorly unfortunately)

The second thing I would mention is that there is a lot of valuable information in addition to that 140 characters. How many people retweeted it? Who responded with answers? How often does that person tweet questions related to your software? Do they follow a competitor’s twitter account?

The problem with the information on Twitter is not the lack of it, it’s the lack of organization of it. You’re basically mining text. Twitter has potential. It’s not there yet, but it will be soon I’m sure.

What I was trying to say was that I agree that the term ‘baseline’ should be clearly defined in a process or system that spans different traditional areas of project work. Conflicting terminology is a common problem when trying to move from a development process and systems that are developed for groups in silos, like RM, SCM, Test Management, Project management, to an ALM approach. If you pitch an ALM process or system that uses baseline as defined in your post, without first clearly defining to RM practitioners and Project Managers what baseline means in this context, you will at the least get a lot of confused looks, at worst get a lot of resistance.

The “baseline” in requirements management, according to the likes of the Booch/Jacobson/Rumbaugh trio and others, is taken when the initial elicitation and analysis has been completed and the initial requirements have been approved. The requirements are ‘frozen,’ which is also not a very clear term, because they can still be changed after the baseline. Really, what taking a baseline means in most schools of requirements management is starting to apply some form of change control process on the requirements. From a Project Management perspective, especially in more traditional waterfall development shops, when the baseline has been taken, it’s relatively safe for development staff to start working with confidence that the requirements are unlikely to suddenly change drastically.

So, if you are working on a project and you start talking about taking multiple baselines some people, particularly business analysts and some project managers, get quite agitated. As you said, it’s important to be clear to the participants what the definition of a baseline is in the context of the project.