Segregate or not Analyst, Technical and Developer role

Hi all,

My previous scenario for a BI report project (BRD available) - met with business client to really understand the report needs, wrote the functional spec. which business client would review and sign off on, wrote the technical spec., developed the reports (2-8) and promoted the reports to production. If training is required, I would followup and there would be an official project closed-off. This assumed the backend (ETL/DB) folks took care of the model/data and made available for me.

There are now discussions to segregate the process; 'Analyst' role to meet clients/write the functional spec., 'Technical' role to write design technical spec. and a 'Developer' role to develop the reports. The roles could be filled by different people or the same person may take on some of the roles. Not exactly certain the main reason for segregation. On a large scale project (well, what is a 'large' scale ??), my guess is segregation is good as there may be subject matter experts who could fill specific role and there may be multiple 'Developer' people to develop so many reports. A 'normal' scale project, 2-6 reports for the case managers to view and analyse case loads/time/effort days/costs. Once again, assumption is ETL/DB folks took care of the model/data and made available.

I am hoping to receive suggestions and your experience the values in segregating the roles (different people) as opposed to the same person running the show using the 'normal' scale project as this is the most common bi requests. My choice is same person for 3 roles and if really want to segregate then 1 person for 'Analyst' and another person for the 'Technical' and 'Developer'.

Thx.

From my point of view, I would prefer that the Analyst also be the 'Technical' designer. Like you said, on large projects, they should be separate. But, a BI request is usually managable with a team of 2. One to gather requirements and design the reports, the other to actually take those designs and crank out the reports.

It's a lot easier to train newbies to develop a report using a tool when someone has set the technical design. Of course, why have 2 or 3 when the project size calls for 1.

It a matter of the size of the organization and scope of work. There are advantages of breaking things up. A really good analyst may be a lousy technician and visa-versa. There are diminishing returns... the more you break things down the greater the cost and time, due to increased meetings, oversight, etc...

Thank you for your sharings. I couldn't put my finger on it but I just knew not to segregate for the sake of segregation. You guys have shared me with some really good reasons I could use when I discuss segregation options. Thank you so much.

{{{{{{{{{{{{{{{{ THIS POST IS SO GREAT AND NICE }}}}}}}}}}}}}}

I would prefer that the Analyst also be the 'Technical' designer. Like you said, on large projects, they should be separate.}}}}}}}