In our project we have a very passionate BA/dev team. They believe they know better than the business itself in terms of specifying what the system should do. They are creating many requirements that are not actually being asked for (or understood) by a business stakeholder. Partially this is because of a lack of experience in the business. It does concern me though that if there is nobody in the business who is asking for feature x, how will it be understood, accepted, used. How do we verify that it is useful or the right feature? Will we be creating a system that is over engineered and over specified? My preference is to deliver a basic system that can be understood and discussed with the business and then deliver incremental improvements based on priorities? I wonder if anyone has any experience with a similar situation?
Hi John,
First, of all, welcome. I have been in this situation often, usually in organizations where the IT department is a relative monolith that creates 'IT projects' with insufficient business input.
What is the project sponsor's role? Is the project coming directly out of their budget, or is this being done using 'IT funds'? How are the business SMEs currently engaged? Are they involved at all? When do they usually get to see what's being worked on - during planning, development or only at UAT?
In general, whenever I've had concerns about IT doing 'black hole' work I start with raising the issue to the Project Manager. It's their job to report to the sponsor and any Steering Committee that exists about issues that can impact quality, timelines, or cost; creating needless features can impact all three. I would have some suggestions ready about how to address the issue proactively so that the development team members can still feel involved in the decision-making process for feature development and have their input taken into consideration, while at the same time making sure that clearly defined business needs are addressed first and foremost. For instance, Joint Application Development sessions can be a good way to get innovative ideas from the development team on the table and allow the business users a chance to provide insight on how the business works. An experienced facilitator should be involved in such sessions and the BA(s) should meticulously document all possible features discussed so that the business can decide which ones to proceed with.
If the PM does not see the status quo as an issue or is part of the problem and you feel strongly that the current way features are being developed is not right, I would inform the PM that you will be taking up the issue with the Steering Committee and/or sponsor after raising your concerns with the PM. At the end of the day the sponsor needs to be aware of the issue and make the decision if s/he wants to do something about it.
Hey John! There are usually such conflicts between the BAs and shareholders/management. This especialy happens when either the business analyst is not in touch with your business environment or if the management is reluctant to appreciate progress and trendsetting. If i were in your position, i would remove all prior 'mind-blocks' and study the Business analysts' proposals and make a decision as to whether the ideas presented to you as the shareholder are in fact beneficial or whether the ideas are coming from an analyst who doesn't want to do his job. If the idea is not being practiced in your industry but yet your business could benefit from it then don't be afraid to implement. You will be suprised to find your competition following suit. All the best in your business and may 2012 bring much success. Regards Felix
John,
Welcome to the BA world. Always remember one thing - business drives IT;not the other way around. So the better you understand and create healthy relationships with the business, the better off the BA will be in the long run.
Coming back to your issue. When the dev team leads, I look at this as an ego/power trip issue. What should be done in your case is document true business requirements and it must come from the business. Do not worry about the feasibility/doability of the requirements - simply document "what" they want.
The next step is to get priority of the requirements from the business. Start with this but remember that the business must lead and the BA is the ky link between the business and IT.
Cheers!
brought to you by enabling practitioners & organizations to achieve their goals using: