a blog

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: , , ,

July 2, 2007 | Filed Under Software delivery 

comments

Comments are closed.

Additional comments powered by BackType

  • subscribe

  • One man's microISV

    Playground - an on-demand requirements management tool helping you get the right things done.

  • Lifestream

    • ... problem is they are already there about 23 days ago
    • So the Taliban stoned some adulterers recently. I wish US/NATO would bomb them back to the Stone Age but the problems about 23 days ago
    • Not sure that Wave is gone altogether. I can imagine it creeping into Gmail eventually. But why didn't they kill Buzz instead? about 33 days ago
    • Rooting for Uruguay. Still bad memories of CZ vs NL a couple years back. Plus I really like URU's game. #worldcup about 64 days ago
    • @ktorn what kind of app are you going to make for your Samsung? about 65 days ago
    • Firefox 4 nighly looks pretty good to me. But I still have to restart it after installing add-ons? Hope they'll fix that one day soon. about 69 days ago
    • I love that I can put MY photo on friggin Google HOMEPAGE! about 90 days ago
    • Or more precisely, it does seem a bit smarter AFTER you've visited a given URL that corresponds with the query about 92 days ago
    • Safari 5 doesn't seem to have a "smart" location bar. Enter "Google Reader" and it tries to navigate to http://google%20reader/. #fail about 92 days ago