What do users want?
June 26, 2006 from ComputerWorld - "Want to complete a project successfully? Then you'd better have success at the start. That means getting requirements right, and there are as many ways to do that as there are business analysts charged with getting it done.
But impatience, miscommunication, misunderstandings and overlooked users can produce requirements that aren't clear or complete. "You want to have as little ambiguity as possible, because ambiguity creates defects," says Andrew Ari Clibanoff, a senior business analyst at GSI Commerce Inc., a King of Prussia, Pa.-based provider of e-commerce services.
Those defects can be costly. Ellen Gottesdiener, principal consultant at EBG Consulting in Carmel, Ind., and author of The Software Requirements Memory Jogger (Goal QPC Inc., 2005), says that roughly one-third of the budget for a typical project goes to fixing defects that originated in faulty requirements.
The following tips will help you avoid becoming part of that depressing statistic.
Understand the overall objective. "You need to have a point of reference: What is the strategy for the organization? What are they trying to accomplish in the medium and the long term?" says Josephine Day, director of customer care and technology at the Project Management Institute in Newtown Square, Pa.
When the objective is clearly defined, you can identify the right stakeholders and users, as well as which other programs could be affected by the proposed project -- all important steps toward success, says Day."
180 View - The article goes on to give some practical advice in collecting user requirements. However we think there are huge problems with the advice. Users often don't know what they want. They know the business process and the problems, and that's what a good analyst should document. Users may also not know what's possible. As well, some users may not be forthcoming because of job security concerns. Another problem with the approach in the article is that the level of detail in requirements will vary depending on the project. If you're documenting requirements for a system that will be purchased such as an ERP system, there is no need to document the basics. For example, if you're documenting Accounts Receivable, it's a waste of time to document the requirements related to an Aged Trial Balance. All the systems have it already. It would be better to focus on requirements that differ across systems. And lastly, all requirements don't have the same priority. You need to prioritize each requirement. Only those requirements that allow companies to achieve their CSF's (Critical Success Factors - defined as those things that must be done well in order to achieve success) can be classified as critical. But we do agree with the writer's view on being unambiguous.
June 26, 2006 from ComputerWorld - "Want to complete a project successfully? Then you'd better have success at the start. That means getting requirements right, and there are as many ways to do that as there are business analysts charged with getting it done.
But impatience, miscommunication, misunderstandings and overlooked users can produce requirements that aren't clear or complete. "You want to have as little ambiguity as possible, because ambiguity creates defects," says Andrew Ari Clibanoff, a senior business analyst at GSI Commerce Inc., a King of Prussia, Pa.-based provider of e-commerce services.
Those defects can be costly. Ellen Gottesdiener, principal consultant at EBG Consulting in Carmel, Ind., and author of The Software Requirements Memory Jogger (Goal QPC Inc., 2005), says that roughly one-third of the budget for a typical project goes to fixing defects that originated in faulty requirements.
The following tips will help you avoid becoming part of that depressing statistic.
Understand the overall objective. "You need to have a point of reference: What is the strategy for the organization? What are they trying to accomplish in the medium and the long term?" says Josephine Day, director of customer care and technology at the Project Management Institute in Newtown Square, Pa.
When the objective is clearly defined, you can identify the right stakeholders and users, as well as which other programs could be affected by the proposed project -- all important steps toward success, says Day."
180 View - The article goes on to give some practical advice in collecting user requirements. However we think there are huge problems with the advice. Users often don't know what they want. They know the business process and the problems, and that's what a good analyst should document. Users may also not know what's possible. As well, some users may not be forthcoming because of job security concerns. Another problem with the approach in the article is that the level of detail in requirements will vary depending on the project. If you're documenting requirements for a system that will be purchased such as an ERP system, there is no need to document the basics. For example, if you're documenting Accounts Receivable, it's a waste of time to document the requirements related to an Aged Trial Balance. All the systems have it already. It would be better to focus on requirements that differ across systems. And lastly, all requirements don't have the same priority. You need to prioritize each requirement. Only those requirements that allow companies to achieve their CSF's (Critical Success Factors - defined as those things that must be done well in order to achieve success) can be classified as critical. But we do agree with the writer's view on being unambiguous.
posted by 180 Systems at 9:27 PM 
0 Comments:
Post a Comment
<< Home