I came across a post by Meade Rubenstein this evening that I liked because it made me think a bit about methodology and how it evolves (or devolves) as it matures. We all want to get software out the door better, cheaper, and faster, right?

“Just because paperwork is a required deliverable does not mean that it adds value.”

“[T]he determination is made by evaluating project environments and organizational stakeholders.”

I’ve long been of the opinion that involving as many stakeholders in the project as early as possible is a key to successful business analysis, and, more importantly, to successful projects, and have said as much in a few of my posts on this site.

Jim Highsmith, in the book Agile project management : creating innovative products, thinks that the reason projects tend to have so much documentation and so few results is that:

The way I see it, offshore outsourcing of IT work - chiefly development and QA - is not going away. Those of us stateside will have to learn to adapt and thrive in this new type of environment in order to remain marketable. For many of us, retooling may be necessary.

One thing that I think we, as business analysts, occasionally forget is that the downstream delivery teams are our customers, too - and in a very real way. We need to make sure that they have an opportunity to develop a true sense of ownership for the project early on and that they understand what the requirements are all about.

Building rapport, requirement structure, use case disgruntlement, and RASCI.