notes and views on crm, social media, and the human side of information technology

Bratislava: Lessons Learned

I’VE COME HOME from a six-months long assignment in Bratislava, Slovakia, and while I am not at liberty to discuss project details, I’d like to share a few bits that I’ve learned there. It might be relevant to you out there who are also engaging in requirements engineering and/or software delivery in general.

And no, I haven’t accidentally re-discovered America: it’s been yet another experience in a series of many, and this just happens to be the first time I talk about it.

I’ll try to put out a short series on the software delivery process as I see it from the Business Analyst perspective; this installment will target some process-related issues and likely be updated as I think stuff through.

PART ONE: Process

A well-defined development process that doesn’t stand in the way of innovation and at the same time puts clearly defined limits on it is … a Holy Grail, and as such rarely achieved in a production environment. Nor is it often attempted.

In my capacity as BA, I mostly work in a documentation-heavy, top-down process context, and that’s when I am lucky: it’s not uncommon to work in a completely ad-hoc environment.

Worst of all, many clients will have rigid rules as to how they want things done without thinking through what they should want in the first place. The developer is then put in a position of very limited power without having been given clear clues as to what he’s supposed to accomplish.

As a result, the business analyst has no choice but to define the process himself and fight for its implementation with both the suits who are used to being able to push requirements into development at any stage, and the IT that is either defiant and unwilling to lift a finger or lethargic after losing way too many battles.

You could object and say it’s the PM’s role to worry about the process, to which I say: it can be, but look at the big picture: PM isn’t as concerned with requirements as he (usually) is with putting checkmarks next to tasks and walking importantly through the hallways. (some offense intended).

It’s my prelimiary conclusion, then, that the BA is most competent to define the process (from requirements to implementation) where there is none, since he has intimate understanding of what the suits want and what the developers are capable of delivering. Unlike the PM, he is also concerned with the value being created and delivered as he is personally invested in seeing it materialized.

Next: requirements versus design (tomorrow).

Technorati Tags: , , ,

Additional reading

July 2, 2007 | Filed Under Software delivery 

comments

Leave a Reply