Hi John,

Ah, the beloved enterprise project.  Finding the right champion who will keep all parties on the right track and ensure that groups are involved has been the biggest predictor of success for such projects in my experience. Otherwise IT takes ownership, or the needs of some groups are neglected while others are overemphasized, etc.

As a BA on such a project I think your responsibility is to identify the issues you are encountering and demonstrate what the root cause of those issues are. As Tony mentioned such projects are usually complex with many inter-related requirements; when looking at a set of requirements in isolation things may appear reasonable but when combined with others may not make much sense or be inapprorpriate for other stakeholders. If you can show how some of the requirements being defined aren't appropriate for various groups or conflict with other requirements, you can build a case for more business involvement.

Another option would be for you to get approval to do a 'show and tell' of the requirements identified to date (this can be done at a high level but still highlight any potential issues you see coming). You can make it a traveling road show through the various departments to get their feedback. Document the responses you get and if there is disagreement over any of the existing requirements then you have reason to get business staff together to resolve the issues. I worked on 2 intra-organization projects with 60-120+ organizations involved and did similar road shows to communicate what was going on/decisions being made while getting feedback and also buy-in for the project (which subsequently caused them to invest more time in the projects).

 Hi Engle,

You bring up a good point but I would not characterize PARC as an IT shop within Xerox (using the definitions for such a unit that you would find in ITIL or ITSM), but rather an R&D arm who pushed out a lot of interesting possible products, many of which happened to be information technology related. The purpose of PARC was to come up with innovative ideas, while the purpose of an internal IT department in most organizations is to support the business in achieving its strategic and operational goals (i.e. business tells IT what to do via what they need). I believe that's what mbrault's comment was based on.

That said, I see BAs playing a critical role in helping businesses identify solutions to meet their goals, regardless of where they come from. So if someone in a plain-vanilla IT shop comes up with a great idea that could open new markets for the company, it is the BA's job to help communicate this opportunity to relevant stakeholders in the organization. Great organizations have developed an invent-from-within culture that nutures the inherent creativity in all of us, and look to capitalize on the ideas of their employees. In some cases they have incubator and venture arms to help spin off great opportunities that aren't in the scope of the core mission of the company, but that present something that could help out the world.