Respected sir,
at which site i can know about
" TODAY'S INFORMATION TECHNOLOGY " and
" INFORMATON TECHNOLOGY IN BUSSINESS ". KINDLY GET THIS INFORMATION SIR,I AM REQUESTING THIS TO YOU BECAUSE I HAD A SEMINAR ABOUT THESE TWO SO KINDLY SEND ME THE INFOR.
WITH REGARDS,
PAVAN
Discussion on:
View:
Show:
There have been times where the need (and payback) was clear to managers and to myself, but the users didn't "grok" it.
The role of the analyst also included a bit of salesman.
This has happened to me several times and I'm proud to report success in all cases.
Your mileage may vary.
The role of the analyst also included a bit of salesman.
This has happened to me several times and I'm proud to report success in all cases.
Your mileage may vary.
You can't argue with, and there are some good tips here for:
- using an organized, structured approach to gathering requirements
- doing requirements before designing
- and using proven questioning techniques.
I particularly like the ideas of dealing with user's fears. Many analysts/consultants overlook the opportunity and risks of the requirements meeting in the overall change management process -- and fail to see the need, as mentioned, to sell the benefits of the project and the changes to the stakeholders.
I know the article focused on one-on-one interviews (often the best lesser alternatives) but if you're able, try holding facilitated meetings or 'Discovery Sessions' with multiple stakeholders. This has the added advantages of enabling you to get consensus & agreement and more complete needs defined more quickly and accurately (without having to revisit, clarify, resolve discrepancies, etc.)
But certainly, one-on-one's done by skilled requirements analysts using these techniques and following a defined process will be a whole lot better than ridiculous survey's, checklists or consultant/IT-originated requirement specs. For that is certainly the recipe for disaster.
- using an organized, structured approach to gathering requirements
- doing requirements before designing
- and using proven questioning techniques.
I particularly like the ideas of dealing with user's fears. Many analysts/consultants overlook the opportunity and risks of the requirements meeting in the overall change management process -- and fail to see the need, as mentioned, to sell the benefits of the project and the changes to the stakeholders.
I know the article focused on one-on-one interviews (often the best lesser alternatives) but if you're able, try holding facilitated meetings or 'Discovery Sessions' with multiple stakeholders. This has the added advantages of enabling you to get consensus & agreement and more complete needs defined more quickly and accurately (without having to revisit, clarify, resolve discrepancies, etc.)
But certainly, one-on-one's done by skilled requirements analysts using these techniques and following a defined process will be a whole lot better than ridiculous survey's, checklists or consultant/IT-originated requirement specs. For that is certainly the recipe for disaster.
Definitely agree with Arlittle's text - In my experience,i found that getting stakeholders together for a "discovery & elicitation" excercise turned out much more fruitful than doing one-on-one interviews. Giving the stakeholders a free hand and making them think 'out-of-the-box' leads to a lot of valuable inputs.
Great article. It validates procedures I have been using for years. But, don't make the mistake of abandoning the users input after the interview process. If at all possible, when you complete the preliminary analysis/design efforts, put togethera semi-functional prototype and meet with these same people to demonstrate what their input has engendered. Following the addage, "users never know what they want until you give them what they asked for", I find this 2nd step of user input invaluable in the requirements/design process.
Selecting Interviewees is vital. Every computerisation project generally involves varying amount of business process re-engineering. Therefore, at the requirements stage, it is vital to identify the employee performing each componant of a BP and decide whether or not to interview them.
The actual users or "doers" of a particular step can throw some vital light on finer points, particularly infrequent variations that can throw your new designs out of gear if not identified in advance. Be prepared if this means more time and effort up front as it will save troubles later.
Technique / ways of eliciting these odd variations should be included in the interview. The analyst's past experience of simillar BPs definitely helps here.
Also try to build into a project the vital step of prototyping and prototype approval.
The actual users or "doers" of a particular step can throw some vital light on finer points, particularly infrequent variations that can throw your new designs out of gear if not identified in advance. Be prepared if this means more time and effort up front as it will save troubles later.
Technique / ways of eliciting these odd variations should be included in the interview. The analyst's past experience of simillar BPs definitely helps here.
Also try to build into a project the vital step of prototyping and prototype approval.
What if you can't take notes as fast as people can talk? Also, I've found that when people are talking and I'm writing they stop talking until eye contact is restored. Consequently I prefer group sessions where I can have a scribe present, less obtrusive than in a one-on-one session. Opions about tape recorders is mixed.
@
@
Let me just say what a nightmare it can be for IT when you try to force a new system on users without thier input and without any solid training. How can/do you modify this process if you will be implementing an off-the-shelf packaged product like PeopleSoft or SAP?? Unfortunately, where I work the users don't want to be bothered by IT and requirements. But were that not the case I think interviewee selection can make or break the end result. I know when we migrated off our legacy system to peoplesoft, the turnover rate was so high I know of only 1 or 2 users left that actually worked on the legacy system. There is potential to develop a system based on user input only to find at installation time that none of those users who providedinput are there to use the system and perhaps the new group of users has a totally different outlook of how the system should look/feel. Unfortunately - of course turnover is an inevitable result when users are not trained prior to go live - so that is another key factor for post-prototype phase. Train those users that provided input in a class with a mix of new users or users who did not provide input. This way, should any questions arise as to why things are they way they are, (provided you developed what the users asked for), then you don't have to field the reasoning by yourself - you have valuable user backup to validate and explain the whys and why nots...
Just curious, are many companies really still building custom applications from the ground up today? It seems rather costly, and today unless you can do it quickly - your technology will be old by the time the system is completed. Is there a trend that shows this is increased, decreased or unchanged... just curious ifanybody knows any statistics or trends on building systems from the ground up vs. purchasing packaged complete products?
Just curious, are many companies really still building custom applications from the ground up today? It seems rather costly, and today unless you can do it quickly - your technology will be old by the time the system is completed. Is there a trend that shows this is increased, decreased or unchanged... just curious ifanybody knows any statistics or trends on building systems from the ground up vs. purchasing packaged complete products?
There is a massive amount of custom software development underway across the world.
While the number of "Dot Bombs" has fallen off, they are on the rebound, all looking to be the next Ebay, Amazon, or Google. Those are BUILD examples.
My mainclient is in a line of business that is mature, but hasn't been effective. So they build custom applications to replace Gov't paper processes when they take over a Gov't operation. That is a BUILD example too.
An example of major programming isBEND, that is the integration of systems large and small. Look at all of those $2k/day SAP consultants.... The rise of .NET and Sun One and SOAP are all aimed at letting coders integrate systems.
Finally let's talk about BUILD. My main client has purchased their POS and back office Accounting and HR, but that IT crew (3 coders) have a say in what they buy so it can be BENT. Further, the CEO has made it clear that these solutions make sense now, but if the firm reaches a certain size, theBUILD option will be looked at again.
It depends if your business activity is new and small, thus needing the benefits of an industry standard application (BUYING basically adopting the best practices) or if it is large enough and old enough to set the standards (BUILD).
My $0.02 worth,
Don Gilman
While the number of "Dot Bombs" has fallen off, they are on the rebound, all looking to be the next Ebay, Amazon, or Google. Those are BUILD examples.
My mainclient is in a line of business that is mature, but hasn't been effective. So they build custom applications to replace Gov't paper processes when they take over a Gov't operation. That is a BUILD example too.
An example of major programming isBEND, that is the integration of systems large and small. Look at all of those $2k/day SAP consultants.... The rise of .NET and Sun One and SOAP are all aimed at letting coders integrate systems.
Finally let's talk about BUILD. My main client has purchased their POS and back office Accounting and HR, but that IT crew (3 coders) have a say in what they buy so it can be BENT. Further, the CEO has made it clear that these solutions make sense now, but if the firm reaches a certain size, theBUILD option will be looked at again.
It depends if your business activity is new and small, thus needing the benefits of an industry standard application (BUYING basically adopting the best practices) or if it is large enough and old enough to set the standards (BUILD).
My $0.02 worth,
Don Gilman
- Keyboard Shortcuts:
- Prev
- Next
- Toggle
