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).
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!
Not always, IT can drive business. No greater example of that than the PARC labs at Xerox where a group of IT developers came up with GUI but could not sell it to the business. Enter Steve Jobs for a tech presentation and was so overawed with the concept, he took (stole ?) it to Apple. Point and click, the way of the future where personal computing comes to the average individual rather than a big machine in the basement. Jobs clearly says that had Xerox business exploited what was within their fingertips, they would have magnified by the millions (billions) their revenue growth - everything that Apple became at the time would have belonged to Xerox. Considered by many to be the greatest lost opportunity in business.
Not saying this is the same, but new thinking demands new ways of doing things especially ideas and innovations
Cheers !
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.
Hi Jarett,
Semantics aside, the point I was making is that one has to challenge preconceived notions and open one's minds to new thinking and ideas. Nothing is cast in stone. Whether PARC was technically an IT shop or not is moot. They were technology centric. They also came up OOP. If a BA or one similar had looked at what they produced, would a light-bulb have gone off ? Or would they have said how does this support our business ? It took a technocrat in the form of Jobs to spot the opportunity. He was so blinded by the light, that he went back to Apple and cancelled all existing projects. Stop what your'e doing he exhorted his staff. The future is GUI. With one objecting, he literally went under his desk and pulled the plug.
Think different.
Bennett Mendes
brought to you by enabling practitioners & organizations to achieve their goals using: