Tuesday, January 06, 2009

The way we screw requirements up.

My previous job was at a small software firm. They had no software development process at all. There was couple of people who mainly interacted with the customer to get the requirements. They spend few days with the customer discussing; and then sit with the developer for half an hour and ask him to write it! No documentation; no diagrams; no nothing. Write this. Once in a while they’d check what’s going on; show the customer what’s going on and change few things here and there and that’s it!...

Needless to say; we never made correct estimates; we never delivered what we initially thought the system was and very little number of customers came back. The applications were not designed at all. They were ad-hoc code with only the blessings of the skills of the developer.

That sucked… So I joined this company which has a pretty matured software development process. It defines how to capture requirements in different scenarios and conducts periodic audits to make sure that everyone is on track. Pretty neat eh? This all works well when everyone involved in it is committed and competent (almost all committed people are competent and almost all un-committed people are incompetent. Once in a while there’s a committed but incompetent person and a competent but un-committed one.)

But requirement capturing was a nightmare in the last two projects I worked in. Why? Some smart-ass thought anyone with CIMA or a MBA, who’s fluent in English, could be a BA. They simply didn’t know reasoning or probability. They just wrote what they heard. (I’m pretty sure they didn’t understand a thing what the customer wanted. But they didn’t know how to ask a question so that there won’t be ambiguity)

So what’s the end product? A big pile of documents that has no value at all and several wasted months (this is no small deal; one project had two BAs who wasted three months and the other had 5(!) BAs who wasted 10 months!!).

So; to think of it; the first company did less damage to the customer and the developers than the second.

So what really works?
A requirement capturing process practiced by professional BAs or Software Architects. That works really well - I’ve seen that. So; if you have any stake in a software project, make sure that you are talking with someone who’s capable of translating your requirements in to something that developers understand. Otherwise you’d just be wasting time and money - a lot of it (those 5 BAs wasted at least about US$1 million).

5 comments:

  1. Welcome to the world of BAs :D have been working as one for the past 2 years (First job; yeah i know bad choice).

    By the way, I thnk sometime back, one of the bloggers (probably Yasas, http://yasasva.blogspot.com/) used to write about the whole analysis thing and I think somewhere I read that there was going to be a forum for BAs to share ideas. Any idea where this is?

    ReplyDelete
  2. It's not a bad career if you enjoy it and know your role.
    I don't recall Yasas starting it. I should ask him when I see him online again.
    BTW Yasas is one of the best BAs I've known. Kind of proof that it could be done right. Two of us started our careers from the same project.

    ReplyDelete
  3. Dont you think itd be worthwhile to have such a forum? But ofcourse we'll have all the problems in the world as each company (at least in LK) tends to define Business Analysts in its own terms and confidentiality matters would also cause some concerns

    ReplyDelete
  4. I agree.

    The BA practice is relatively young; especially in Sri Lanka. And it's at a stage where it could benefit a lot from a professional body or at least an informal standardization.

    Software Development and QA practice went through an informal standardization over the last 5 years in Sri Lanka. Many companies adopted the standard designations like Software Engineer / QA Enginee, Technical Lead / QA Lead and Architect with an informal and rough agreement in their roles and responsibilities. The bigger companies played a great role in that. Now the BA practice and PM practice is in need of that.

    Unfortunately; the whole software industry as a whole in Sri Lanka is going through a rough period now in terms of maintaining standards. The bigger companies which played a leading role in standardizing software engineering practice in Sri Lanka are themselves having difficulties in maintaining that rigor.

    I think now it's up to the community to gather and take on that responsibility. But of cause, there should be a reasonable number of professionals who feel the need of such a process and are keen in improving themselves.

    ReplyDelete
  5. Hey,

    Yet again another interesting topic.
    Thanks Mahasen for starting up this again.

    You are true in one thing and the overall message is true.

    CIMA and MBA won't save your ass and the same time Architect won't save the ass as well.

    Let me brief my reasons.

    Guy with a MBA or CIMA does know little bit about computing and he will put everything coming from the customer as it is.

    Finally you will get hundreds of pages long BRD, which won't read by anyone else other than the BA.

    Hmmm... thats weired...

    Similarly, Architect will look at the technical side of the requirements and will put several blocks and it will lead to unnecessary arguments between the client and the development firm.

    Ideally get a good techie, a BA (ideally programmer or a QAE turned in to BA practice) and a project manager combined.

    Better if they having good communication skills as well. Cos there is an ART behind developing the requirements and prioritizing them.

    Techie and the BA will discuss the requirements with the customer and PM will monitor the whole event.

    Techie will look at the technical side of it and will discuss the limitations of the implementation side of the requirements.

    Simple example will be a delivering a bus to the customer. Anyone can identify that customer need a bus but a real techie with solid understanding about the domain plus the market changes would deliver something which tally's with the customer's expectation. He/she should be able to look in to what sort of a bus will it be, whether the customer could afford it, are their any impediments for the delivery. You can design the best frame and the body but if you have to wait for three to four years to obtain the suitable engine, that message has to go to the customer.

    Thats what these BAs not doing at the moment. These BAs can talk good English. Agreed. People see that as a positive or a plus sign to hire them as BA. But poor fellows with lack of domain competency and consultancy background (i'd say they do not have common sense at all) will spoil the whole thing.

    Just a quick thought... will add a detail opinion later tomorrow....

    ReplyDelete