A Questionnaire for Identify Failures in Business Analysis Phase of ERP Projects

Business Analysis Process Failures
Page | 1
Group No - 06
13/05/2013
A Questionnaire for
Identify Failures in
Business Analysis Phase
of
ERP Projects

Page | 4
Table of Contents
1.0. Introduction ......................................................................................................................... 5
2.0. Questionnaire to Identify Business Analysis Process Failures ........................................... 6
3.0. Justification ....................................................................................................................... 19
3.1. Enterprise/ Company analysis........................................................................................... 19
3.2. Requirements planning and management ......................................................................... 24
3.3. Requirements elicitation ................................................................................................... 30
3.4. Requirement analysis and documentation ........................................................................ 38
2.5. Requirement communication ............................................................................................ 44
3.6. Solution assessment and validation .................................................................................. 49
4.0 Conclusion ........................................................................................................................ 53
5.0. References ......................................................................................................................... 54
6.0 Appendix ............................................................................................................................ 55

Page | 5
1.0. Introduction
Identifying business needs and designing solutions is done through the processes of
“Business Analysis”. Many solutions are developed to provide the needs of businesses which
include the implementation of ERP systems. ERP systems mostly cuts across many business
processes hence create many complexities while designing them. The probability rate for
these complexities to turn into failures is high. The Business analyst is mostly responsible in
handling these issues and reduces them as well. Business analysis includes many phases
which can be shown as follows;
 Enterprise/Company analysis
 Requirements planning and management
 Requirements elicitation
 Requirements analysis and documentation
 Requirements communication
 Solution assessment and validation
The above mentioned phases need to be executed in order to do a proper business analysis.
Many aspects need to be considered and standards need to be followed in doing this analysis,
so as mentioned earlier there is a high probability for these phases not to function in the
expected manner. So the identification of the potential process failures needs to be done.
This can be done by preparing a questionnaire which will monitor important elements of each
of the above mentioned phases of business analysis. These questions will be addressing many
aspects such as standards used, tools used, parties responsible, causes of actions, etc. In this
manner this questionnaire could simply identify the failures that could occur while carrying
out the Business analysis stage.
The questionnaire that we prepared will clearly indicate how effectively anyone could point
out potential failures of “Business analysis” stage.

Page | 6
2.0. Questionnaire to Identify Business Analysis Process Failures
1. Who are the key stakeholders of this system?
2. Have you identified all the stakeholders of the system at the beginning?
a. Yes
b. No
c. Not sure
3. Have you identified who the project is being done for (i.e. client)?
4. What level of understanding does the client have on what he needs?
a. Poor
b. Good
c. Moderate
d. Very good
5. Are you satisfied with stakeholders’ communication skills?
a. Yes
b. No
6. What is the domain of the project?
7. Have you experienced with same kind of projects?
a. Yes
b. No
If yes what are those projects?
8. Have you identified any difficulties when determining the domain?
a. Yes
b. No
If yes, what are those difficulties and how do you solve those difficulties? (Briefly
explain)

Page | 7
9. Did the clients have provided the complete requirements for the ERP system?
a. Yes
b. No
c. To a certain extent
10. How long you have worked in this domain?
a. Less than 1 year
b. 1-2 years
c. 2-4 years
d. Above 4 years
11. Have you used the domain experts for determination process of the scope?
a. Yes
b. No
If yes; what are the qualifications and experiences of used domain experts?
12. What are the goals and objectives you have established for the project?
13. Are you satisfied with those goals and objectives?
a. Yes
b. No
14. Are the goals and objectives within the project scope?
a. Yes
b. No
15. Do you think that clients clearly defined the business case?
a. Yes
b. No
16. Have you planned the initial cost, time and resource estimations?
a. Yes
b. No

Page | 8
17. What are the financial factors used to develop cost estimations?
a. Discounted cash flow
b. Net present value
c. Internal rate of return
d. Return on investment
e. Payback period
18. What are the business environment analysis methods have you used?
a. SWOT
b. PESTLE
c. Other
19. Have you used any standards during the business case preparation?
a. Yes
b. No
20. Do you satisfied with your knowledge about the current business environment?
a. Fully satisfied
b. Satisfied
c. Neutral
d. Dissatisfied
21. Who were the parties involved in identifying the requirements?
22. How did the identification of the sequence of the requirement development process
happened?
23. What are your initial activities and ending activities of the requirement development
process?

Page | 9
24. Will the output of a particular activity of the “requirement development process” surely
be the input of the next activity in line?
a. Yes
b. No
c. Yes in most situations
d. No in most situations
25. How long it took for the requirement analysis?
a. One month or less than one month
b. 1-3 Months
c. 3-6 Months
d. More than 6 months
e. More than a year
26. Have you finished the requirement analysis stage within the time period you expected?
a. Yes
b. No
27. How often you have review meetings with the stakeholders?
a. Daily
b. Weekly
c. Monthly
d. When it needed
28. Have you used traditional and modern requirement gathering techniques?
a. Yes
b. No
29. What are traditional requirement gathering techniques used to collect the requirements?
a. Interviews
b. Focus groups
c. Creating requirement lists
d. Other…………………

Page | 10
30. What are modern requirement gathering techniques used to collect the requirements?
a. Prototyping
b. Use cases
c. Other
31. Who decided these requirement gathering techniques?
a. Domain experts
b. Business Analysts
c. Software Engineers
d. Other (Mention here)
32. Are the parties involved in all the processes apart from the client, have a good
understanding of the defined requirements?
a. Yes
b. No
33. Who are the resource personals or the supervisors facilitate each technique?
34. Why you selected these techniques and what is the criteria?
a. Knowledge
b. Cognitive skills
c. Experiences
d. Other
35. To which level of experience (in years) do the parties involved in planning and
management of requirements generally have?
a. Less than one year
b. 1 – 3 years
c. 3 – 5 years
d. More than 5 years
36. What are the methods of clarifying the requirements?

Page | 11
37. How often did business analysts and project manager meets to talk about the ERP
system?
a. Daily
b. Weekly
c. Monthly
d. Frequently
38. How do you choose the clients representatives for the requirements committee? (Multiple
Select)
a. By recommendations from client’s authorities
b. The individual's domain knowledge
c. The individual's computer knowledge
d. The individual's position or authority
39. Do all the functional requirements of the system gathered at the beginning?
a. Yes
b. No
c. Not sure
40. Are there any requirements you gathered in the design stage or after the design stage?
a. Yes
b. No
41. Have you identified all the non-functional requirements?
a. Yes
b. No
c. Not sure
42. What are the key non-functional areas you mostly focused on?
43. How the non-functional requirements affect the system?
44. Who are the people involved in the requirement analysis team?

Page | 12
a. Yes
b. No
46. What are the major barriers you have faced during requirement analysis? (multiple
choices)
a. Technological barriers
b. Volatile business environment
c. Stakeholders’ knowledge
d. Requirements verification errors
e. Other
47. Is there a proper documentation of the plan of requirement development process?
a. Yes
b. No
48. Is there a proper plan which will identify any change in requirements?
a. Yes
b. No
c. If yes, what is it?
49. How fast can the planned process be changed if the requirements change?
a. Very quickly
b. Takes a considerable amount of time
c. Very time consuming
50. Did you use any change management methods for requirement changes?
a. Yes
b. No
If yes, what are they?
51. What are the software tools used in planning and management of requirements?

Page | 13
52. What are the methods planned to be used to communicate about any change in the
requirements to others?
a. Written document
b. Emails and other internet based methods
c. Official meetings
d. Informal talk
53. What are the methods that will be followed to reduce the risk of failing the ERP system
due to change in requirements?
54. What are the methods that used for the organizing project information?
a. Technology architecture diagrams
b. Process flow diagrams
c. Domain modeling
d. Six Sigma techniques
e. Data flow diagrams
f. Organization charts
g. Other
55. What are the techniques that used to initiate risks?
a. Brainstorming Sessions
b. Interviewing subject matter experts
c. Identifying and analyzing root cause
d. Using prioritized requirements
e. Conducting a SWOT analysis
56. What are the areas of risk categories have you identified?
a. Project risks
b. Technological risks.
c. Quality and performance risks.
d. Security risks.
e. Generic risks.
f. Other risks.

Page | 14
57. What are the risk prioritization methodologies have you used?
a. Probability Impact matrix
b. Risk probability
c. Risk Impact
d. Risk exposure
e. Other
58. What are the validation methods have used to risk assessment?
a. Review meetings
b. Analogy
c. Matrices
d. Other
59. Have you decide any standard for risk assessment?
a. Yes
b. No
If yes, what are those standards?
60. Are all factors regarding “requirement development process” is considered when
identifying risks?
a. Yes
b. No
c. Most of them
61. Are there any standards used when prioritizing risks?
a. Yes
b. No
62. What are the difficulties and barriers you faced while communication with the
stakeholders?
a. Language barriers
b. Poor communication skills
c. Other

Page | 15
63. Have you used any review meeting during the business case preparation?
a. Yes
b. No
If yes, who are the participants?
64. What are the things you concerned about the quality of the system?
65. What are the time dependent assumptions you are making?
66. What are the difficulties and barriers you faced in requirement gathering stage?
67. If there are times dependent assumptions how you’re going to cope with volatile
environment?
68. What are the documentation forms have you used?
a. Textual
b. Matrix
c. Diagrams
d. Wireframes
e. Models
f. Other
69. Have you used any document standards?
a. Yes
b. No
If yes what are those standards?
70. Did you use formal specification documents to interpret and communicate the
requirements?
a. Yes
b. No
If yes what are those?
71. What are the informal specification documents you used?

Page | 16
72. What type of notations did you used in formal specification documents?
73. Could those notations easily understand by both technical and non-technical users?
a. Yes
b. No
74. What are the potential opportunities and risk factors did you identified in ERP project?
75. Did you conduct the natural language discussions with the clients to get the clear idea
about the business case?
a. Yes
b. No
76. What are the values delivered by the proposed solution?
77. If multiple options are available, what is the solution you selected and what is the reason?
78. If the solution does not deliver enough value, what are the reasons for the termination of
that initiative?
79. Is the solution meets the business needs?
a. Yes
b. No
d. Other
80. What is the most appropriate response to identified defects?
81. If a problem identified in the suggested solution what will you do and what type of
solution you will take to correct it?
82. Did you validate the verified and deployed solution?
a. Yes
b. No

Page | 17
83. Did you validate the allocation of resources?
a. Yes
b. No
84. If the allocated resources are limited or any problem with them, how you obtained the
excess resources?
85. Is this the right time for implementing the software?
a. Yes
b. No
86. Will the employees accept the change?
a. Yes
b. No
d. Other
87. If not; what type of motivation methods you are hoping to use?
88. Does the organization can spend sufficient time for user training?
a. Yes
b. No
89. Does the organization have necessary technology and equipment for maintenance of the
software?
a. Yes
b. No
If not; how will you provide them?
90. Does the organization willing to measure and assess progress and continuously improve
processes?
91. How do you identify defects/shortcomings?

Page | 18
92. How to analyze impact and define corrective action?
93. If the Performance Metrics of the Deployed Solution represent false details what sort of
actions you take to correct it?

Page | 19
3.0.Justification
3.1. Enterprise/ Company analysis
Failure 01:
Not having a proper understanding about the problem before expressing the
requirements by the client/customer
Business analyst should have a proper understanding about the problem to start the project.
Not having a proper understanding of the domain causes poor requirements gathering, poor
analysis etc. and it can be a reason for a failure of the whole process.
Questions
1. What is the domain of the project?
2. Have you identified any difficulties when analyzing the domain?
a. Yes
b. No
If yes, what are those difficulties and how do you solve those difficulties?
By these questions we can obtain information whether the team has understood the problem
clearly because if the team hasn’t a proper understanding about the domain they should get
difficulties when analyzing the problem. If they have succeeded finding solutions to those
then we can come to a conclusion that they have understood the domain. So from these
questions we can identify whether they have a proper understanding about the problem and if
not it will cause a failure of enterprise analysis.
Failure 02:
Poor risk prioritizing
When starting a new project, all the risks that can be happen should be identified. But only
identifying the risks doesn’t give a benefit if we don’t prioritize those risks. So risk

Page | 20
prioritization should be done properly for a successful project. So if the risk prioritization
fails it can fail the enterprise analysis phase.
Questions
1. What are the techniques that used to initiate risks?
a. Brainstorming Sessions
b. Interviewing subject matter experts
c. Identifying and analyzing root cause
d. Using prioritized requirements
e. Conducting a SWOT analysis
a. Project risks
b. Technological risks.
d. Security risks.
e. Generic risks.
f. Other risks.
b. Risk probability
c. Risk Impact
d. Risk exposure
e. Other
4. What are the validation methods have used to risk assessment?
a. Review meetings
b. Analogy
c. Matrices
d. Other

Page | 21
5. Have you decide any standard for risk assessment?
a. Yes
b. No
If yes, what are those standards?
Risk assessment is a main part of enterprise analysis phase. Also risk assessment should be
done properly. So if this step fails the whole phase may face a failure. In order to prevent that
we need to focus on which type of risks we have to face, prioritization of the risks and
validation of the risk assessment. So by using these questions we can identify what
techniques they have used to initiate risks, types of risks, risk prioritization methods and how
they have validate the risk assessment. From this information we can come to a conclusion
whether they have prioritized the risks properly.
Failure 03:
Over defined scope, Poor project prioritization
For a project the scope is very important as it decides what we have to do in the project. If we
over defined the scope all the estimations goes wrong and be a reason to fail the project.
Questions
1. What are the methods that used for the organizing project information?
a. Technology architecture diagrams
b. Process flow diagrams
c. Domain modeling
d. Six Sigma techniques
e. Data flow diagrams
f. Organization charts
g. Other
a. Yes
b. No

Page | 22
3. Have you completed the initial cost, time and resource estimations?
a. Yes
b. No
Scope is a main factor which can largely affect to the success of the project. So from these
questions we can identify the methods they have used organize the project information and
whether they have completed the initial cost, time and resource for the project. Although the
cost, time and resource estimations are done in preparing the business case, initial estimations
should be done properly to define the scope of the project. So from the answers to these
questions we came identify whether they have define the scope correctly and will there be
any failures due to over defined scope.
Failure 04:
Inadequate alignment of goals and objectives
Goals and objectives represent the direction of where the project is going. So these goals and
objectives should be aligned properly if we want to get succeed with the project.
Questions
2. Are you satisfied with those goals and objectives?
a. Yes
b. No
3. Are the goals and objectives within the project scope?
a. Yes
b. No
Goals and objective must be aligning properly for a successful project. So by these questions
we can identify what are the goals and objectives of the project and whether the goals and
objectives are compatible with the scope of the project. So from the answers for those
questions we can come to a conclusion whether they have aligned the goals and objectives

Page | 23
properly. Because unable to align goals and objectives properly can cause a failure of the
enterprise analysis phase.
Failure 05:
Not having Strong business case
A proper business case will serve as an essential tool for the team to make the best
investment decisions for the project. So strong business cases will helpful to success the
enterprise analysis where a poor business case can completely destroys the project.
Questions
1. What are the financial factors used to develop cost estimations?
a. Discounted cash flow
b. Net present value
c. Internal rate of return
d. Return on investment
e. Payback period
2. What are the business environment analysis methods have you used?
a. SWOT
b. PESTLE
c. Other
3. Have you used any standards during the business case preparation?
a. Yes
b. No
4. Have you used any review meeting during the business case preparation?
a. Yes
b. No
If yes, who are the participants?

Page | 24
Preparing the business case is the main step of the enterprise analysis. Having a strong
business case builds the foundation to a successful project. So the answers to these questions
show us how they have done their preparation of the business case. If they have successfully
completed the estimations, environment analysis, used standards and review meetings, it
shows that they are successful in creating business case and if not it can cause a failure of the
enterprise analysis phase.
3.2 Requirements planning and management
Failure 01:
Poor prior experience of the planner in planning stage of the project
The experience of the planner is vital in planning the requirement development process. The
planner must be able to predict proper requirement eliciting techniques, proper documents
that needs to be prepared, proper tools to be used according to the ERP system that needs to
be developed. These can be a failure if the planner has poor experience in planning.
Questions
1. To which level of experience (in years) do the parties involved in planning and
management of requirements generally have?
a. Less than one year
b.1 – 3 years
c.3 – 5 years
d. More than 5 years
2. Who were the parties involved in identifying the requirements?
4. Is there a proper documentation of the plan of requirement development process?
a. Yes
b. No

Page | 25
a. Yes
b. No
If yes, what is it?
6. What are the software tools used in planning and management of requirements?
7. What are the methods that will be followed to reduce the risk of failing the ERP
system due to change in requirements?
These questions will identify how accurate the planning is done which directly reflects upon
the experience of the people who are responsible for planning. If the activities which are
being questioned above are not properly done, it will imply the fact that the planner does not
have a good experience in planning.
Failure 02:
Not properly planning the sequence of the “requirement development process”.
The sequence of the activities of requirement development process has to be in proper order
so that the activities happen smoothly. This has to be done according to appropriate standards
so that there might not be any deviations. If the initial activities and the latter activities are
not placed in order this failure might arise.
Questions
1. How did the identification of the sequence of the requirement development process
happen?
a. Very quickly
3. What are your initial activities and ending activities of the requirement
development process?

Page | 26
4. Will the output of a particular activity of the “requirement development process”
surely be the input of the next activity in line?
a. Yes
b. No
c. Yes in most situations
d. No in most situations
The questions that are mentioned above identifies whether the planning is done in a manner
where the identification and placement of initial activities and ending activities are properly
done, and whether the input and output connections are properly identified and planned. If
they are not done accurately it will directly imply that there is no proper sequence of the
activities of requirement development process.
Failure 03:
Lack of time consumed to plan the requirement development process.
Planning and deciding on the requirements can be shown as the foundation of the activities
that will be carried. So lack of time taken to decide what the important requirements will lead
to poor satisfaction of the customer. It is said that in any project, more time has to be given to
planning than the execution of any project. If there is a concrete plan, the implementation can
be executed easily.
Questions
1. Are the parties involved in all the processes apart from the client, have a good
understanding of the defined requirements?
a. Yes
b. No
a. Yes
b. No
If yes, what is it?

Page | 27
a. Very low
b. Good
c. Moderate
d. Very good
A question based on the level of knowledge the client or the planning team has on the product
that is planned to be built reflects on the time they took to plan. Then again questions such as
“Is there a proper plan which will identify any change in requirements?” would also identify
whether they took considerable amount of time to plan each activity. If the answers are
negative it implies “lack of time consumed to plan the requirement development process”
Failure 04:
Poor risk prioritizing.
At the initial stage of requirements planning process, there might be mistakes in risk
planning. In the risk planning activities of the requirements related activities, the risk
prioritization is very important and plays an important role. Poor risk prioritization leads to
fail the project at any time of the later stages of the ongoing project. Giving less consideration
on the most critical risk factors can put the entire system unstable.
Questions
a. Project risks
b.Technological risks.
d.Security risks.
e. Generic risks.
f. Other risks.
2. Are all factors regarding “requirement development process” is considered
when identifying risks?
a. Yes
b. No

Page | 28
c. Most of them
3. Are there any standards used when prioritizing risks?
a. Yes
b. No
b. Risk probability
c. Risk Impact
d. Risk exposure
e. Other
These questions will analyze whether the factors that are identified as risks are even worth
referring to them as risk factors. These questions will then again identify whether there are
any measures planned to be taken if they have an effect. Then again the identification of
whether any methods used to identify risks is questioned to see whether it is properly done.
Negative answers to these questions will reflect on poor risk prioritizing.
Failure 05:
Not having proper requirements management planning structure for the project.
In most cases, although the initial requirements are captured accurately there might be typical
issues like changing the requirements when the development process is going on. So if there
is no way to deal with this uncertainty of requirements and its dynamic behavior, ERP system
development process might be in danger.
If a requirements management plan is not implemented at the initial stage and practiced it
throughout the life cycle of ERP development, the ERP system might fail.

Page | 29
Questions
a. Yes
b. No
If yes, what is it?
a. Very quickly
a. Yes
b. No
4. What are the methods planned to be used to communicate about any change in the
requirements to others?
a. Written document
b. Emails and other internet based methods
c. Official meetings
d. Informal talk
The above questions will identify whether there will be a proper plan in managing the
changing requirements, how flexible the plan is for the changing requirements and so on.
This will clearly identify whether the process is designed according to a structure which can
survive in a “requirement changing environment”.

Page | 30
3.3. Requirements elicitation
Requirement Elicitation is the task of communicating with customers, users other
stakeholders of a system to determine what their requirements are. This is sometimes also
called requirements gathering. Before requirements can be analyzed, modeled, or specified
they must be gathered through the elicitation process.
Failure 01:
Incomplete stakeholder analysis
It cause to project requirement delays and customer dissatisfaction. If all of the relevant
stakeholders are not identified at the beginning, the success of the project/phase can be placed
in risk
Questions
1. Have you identified all the stakeholders of the system at the beginning?
a. Yes
b. No
c. Not sure
2. Who are the key stakeholders of the system?
3. Have you identified who the project is being done for (i.e. client)?
a. Yes
b. No
By 1st and 2nd questions we can identify who are the main stakeholders of the system and
whether they have identified the stakeholders at the beginning. I they didn’t identified the

Page | 31
stakeholders at the first instance it will lead to a process failure of incomplete stakeholder
analysis.
By 3rd and 4th questions we can identify who the project is being done for, who will be
affected, what they want or expect and their actual needs to get rid from incomplete or missed
requirements.
By the 5thquestion we can identify whether they have used qualified and experienced domain
experts for this incomplete stakeholder analysis.
Failure 02:
Using poor requirement gathering techniques
Analyst should be wise enough to select the most appropriate technique or combination of
techniques by using his knowledge, cognitive skills and experiences. Otherwise it makes
difficult to users to recall all the relevant information they have available, get exact
requirements from stakeholders. It will lead to not captured requirements.
Questions
1. Have you used traditional and modern requirement gathering techniques?
a. Yes
b. No
2. What are traditional requirement gathering techniques used to collect the requirements?
a. Interviews
b. Focus groups
c. Creating requirement lists
d. Other…………………
3. What are modern requirement gathering techniques used to collect the requirements?
a. Prototyping
b. Use cases
c. Other…………………

Page | 32
4. Who decided these requirement gathering techniques?
a. Domain experts
b. Business Analysts
c. Software Engineers
d. Other (Mention here)…………………
6. Why you selected these techniques and what is the criteria?
a. Knowledge
b. Cognitive skills
c. Experiences
d. Other………………………
From the questions 1, 2 and 3 we can identify about their requirement gathering techniques.
We can recognize whether they have used traditional, modern or combination of both
techniques.
By 4th question we can identify who has planned and decided those techniques and from 5th
question we can identify who the people involved in these methods. From the 6th question we
can identify why they selected these techniques and what are the criteria of selecting that.
By the answers that we get to these questions we can identify any process failure caused by
using poor requirement gathering techniques
Failure 03:
Misunderstanding of client requirements
Incorrect information can be lead to unnecessary implementation of complex functionalities,
massive customizations of ERP components and user requirements keep changing even when
system or product development has been started. The ultimate result will be rework in the
later project stages, missed deadlines, budget overruns, decreased consistency and
completeness of the requirements and dissatisfied customers.

Page | 33
Questions
1. What are the methods of communication used for these techniques?
a. Poor
b. Good
c. Moderate
d. Very good
3. Are you satisfied with stakeholder’s communication skills?
a. Yes
b. No
a. Daily
b. Weekly
c. Monthly
d. When it needed
6. What are the major barriers you have faced during requirement analysis? (multiple
choices)
e. Other
By the 1st question we can recognize the methods of communication used and we can have an
idea about stakeholder’s knowledge and communication skills from the 2nd and 3rd questions.

Page | 34
From the 5th and 6th questions we can identify methods of clarifying those gathered
requirements and about their reviewing process. If they don’t have regular meetings and clear
methods of clarification it would lead to failures.
From the 7th question we can identify about difficulties and barriers when it comes to
communication. If they don’t have alternatives it would lead for a misunderstanding of client
requirements.
Failure 04:
Business requirements not captured
The requirements can be missed due to wrong requirement elicitation techniques, missed
stakeholders, difficulty in meeting with relevant stakeholders, clients’ unawareness of what
they need and poor communication. It caused to incomplete requirements and dissatisfied
customers.
Questions
1. Do all the functional requirements of the system gathered at the beginning?
a. Yes
b. No
c. Not sure
2. Are there any requirements you gathered in the design stage or after the design stage?
a. Yes
b. No
3. What are the difficulties and barriers you faced in requirement gathering stage?
5. Have finished the requirement analysis stage within the time period you expected?
a. Yes
b. No

Page | 35
From the 1st question we can recognize whether they have identified the all functional
requirements for the system. Without identifying functional requirements it would be a utter
mess.
From 2nd question we can identify whether they have identified all the requirement in the
requirement gathering stage and not in other stages.
From 3rd question we can identify the difficulties and barriers faced in this stage and proper
alternatives for them.
From 4th and 5th question expected time period and how long it took for the requirement
gathering stage can be identified.
If all the business requirements not captured correctly it would lead to a process failure in this
stage.
Failure 05:
Nonfunctional and quality requirements of the system are not properly captured
Usually the users of the system focus on its functional aspects. So when they are expressing
requirements they naturally give most of the functional requirements that they need but not
the quality aspects and non-functional requirements. But in the systems aspect those are
critical for a successful implementation of the system. If quality and non-functional
requirements are not captured properly it will directly give negative effects.
Questions
1. Have identified all the non-functional requirements?
a. Yes
b. No
c. Not sure
2. What are the key non-functional areas you mostly focused on?
3. How the nonfunctional requirements affect the system?
4. . What are the things you concerned about the quality of the system?

Page | 36
By first 3 questions we can identify whether they have identified all the nonfunctional areas,
nonfunctional requirements with the effect.
From 4th question we can have an idea about their concentration in the quality. If they ignore
or take them granted these nonfunctional requirements and quality aspect it would lead to a
process failure of this stage.
Failure 06:
Poor communication with the client
This is apparently the most significant failure that is happening commonly in the present.
There are numerous communication barriers existing between the analyst and client that
make eliciting requirements difficult. Analysts and clients often speak in different general
languages, with analysts often being more technical in nature, while clients will often speak
more from a business perspective. Due to this most of the time clients fail to convey his/her
requirement in the proper manner. Then the analyst misunderstands the client requirements
and entire development process is based on irrelevant requirements. It leads to a wrong end
product and dissatisfied customers.
Questions
1. What are the methods of communication used for these techniques?
a. Poor
b. Good
c. Moderate
d. Very good
3. Are you satisfied with stakeholder’s communication skills?
a. Yes
b. No

Page | 37
a. Daily
b. Weekly
c. Monthly
d. When it needed
2. Are you satisfied with stakeholder’s knowledge?
a. Yes
b. No
6. What are the difficulties and barriers you faced while communication with the
stakeholders?
a. Language barriers
b. Poor communication skills
c. Other
These are the same questions we asked for the process failure misunderstanding of client
requirements. Parallel to that we can identify process failures of poor communication with
the client also.
If the answers are negative for above questions it emphasizes that there is a poor
communication among them. It would be a process failure for this stage.
Failure 07:
Requirement elicitation carried out by technical people
Sometimes the elicitation process is carried out by technical people like engineers or
programmers instead for personnel with the people skills and the domain knowledge to
understand a client's needs properly.Technical personnel and end users may have different
vocabularies. Consequently, they may wrongly believe they are in perfect agreement until the
finished product is supplied.

Page | 38
Questions
a. Yes
b. No
These questions were raised before also. By using these questions we can identify who were
the people that carried out the elicitation phase.
If non-qualified and inexperienced people did this it would not give the expected quality and
the final outcome.
If the technical people involved in the requirement elicitation phase there is a high probability
of this process failure.
3.4. Requirement analysis and documentation
Failure 01:
Analyst lacks the domain knowledge:
In this requirement analysis and documentation process analyst must have good knowledge
and experience about the working domain otherwise without lack of knowledge they will
work with fallacy requirements.
Questions
1. Who are the people involvedin the requirement analysis team?
a. less than 1 year
b. 1-2 years
c. 2-4 years
d. above 4 years

Page | 39
3. Have you experienced with same kind of projects?if yes what are the projects?
4. Haveyou agreed with yourknowledgeabout the currentbusiness environment?
a. Totally agree
b. Agree
c. Neutral
d. Disagree
e. Totally disagree
Using the 1st questionnaire we can identify that they have used any domain experts or
consultant for this process. According to 2nd and 3rd we can get the idea about analysis team
work experience. Not only that within 4th questionnaire we can get aware about the business
knowledge of the current environment. Within these questions we can identify whether they
have good or lack of knowledge about the domain.
Failure 02:
Unrealistic assumptions:
By using unrealistic assumptions analysis process will delivered the unrealistic outputs.
Therefore it may be a huge trouble for the future processes.
Questions
1. Haveyou agreed with yourknowledgeabout the currentbusiness environment?
b. Totally agree
c. Agree
d. Neutral
e. Disagree
f. Totallydisagree
2. What are the time dependent assumptions you are making? If there
aretimesdependent assumptions how you’re going to cope with
volatileenvironment?

Page | 40
According to the 1st questionnaire checks the analysts have better understand about the
current business environment.
Therefore with their knowledge, we can have a rough idea whether realistic or not about the
assumptions that they made. 2nd questionnaire facilitates to reveal are they considered about
the time depend/ volatile environment.
Failure 03:
Lack of experience:
Without proper experience analysts get more difficulties when they analysis the requirements.
Therefore it may cause to unexpected failures in the process.
Questions
a. less than 1 year
b. 1-2 years
c. 2-4 years
d. above 4 years
2. Have you experienced with same kind of projects?If yes what are the projects?
By asking the work experience and the projects experience we can have better understand
about the analysis team.
Therefore if there’s any less experienced person in a team, we can make changes for the team
to avoid the chances of make failures.
Failure 04:
Volatile business environment:
With volatile environment business requirements are change very quickly. Therefore we need
to identify the business environment properly before analysis.

Page | 41
Questions
1. Have you agreed with yourknowledgeabout the currentbusiness environment?
a. Totally agree
b. Agree
c. Neutral
d. Disagree
e. Totally disagree
2. What are the major barriers you have facedduring requirement analysis? (multiple
choices)
e. other
a. One month or less than one month
b. 1-3 Months
c. 3-6 Months
d. More than 6 months
e. More than a year
The 1st question identifies the knowledge of the analysts about the working environment. It is
really useful to identify whether analysis team has identified the environment or not. With 2nd
and 3rd questionnaires reveal what are the difficulties raised in the environment and is it
enough time you have to get understand the environment.

Page | 42
Failure 05:
Improper use of requirement analysis approaches:
If the analysts don’t use proper analysis approaches, then the business requirements can’t be
aligned with the design. Therefore we have to use proper methodology during the analysis
process.
Questions
1. What are the requirement analysis methods have you used?
a. OOA
b. GOA
c. BPA
d. Structured Analysis
e. Other
2. Why you selected those analysis methods?
By asking what requirement analysis methodologies that they use, we can aware that the
analysis team has a good knowledge about analysis methodologies and why they moved to
select those approaches in this process.
Therefore if they cannot specify what they use, we can aware that they don’t consider about
good methods and it may cause to future process failures.
Failure 06:
Improper documentation:
Analysis documents are passed to the design phase. If it may not be understood by the
designer, Designer may end up with design faults and ultimately results in a failed project.
Therefore we have to use standard way for documentation.

Page | 43
Questions
1. What are the documentation forms have youused?
a. Textual
b. Matrix
c. Diagrams
d. Wireframes
e. Models
f. Other
2. Have you used any review methods forrequirement analysis and documentation?
a. Yes
b. No
Ifyes what are thereview methods you selected?
3. Have you used any document standards?
a. Yes
b. No
If yes what are the standards?
Using 1st, 2nd questions can have better understand about the document types and validation
methods what they used in the documentation process.
Not only that by asking about the standards that they use, can easy to identify whether they
documented according to standardized way or not. So without proper standards and methods
there should be vulnerability to occur failures.

Page | 44
2.5. Requirement communication
Failure 01:
Not having a good communication constantly with the project manager
Business analyst should have a proper communication constantly with the project manager.
This will help to monitor project status, risks and costs, and to manage stakeholders and the
business case accordingly.
Questions
1. How often did business analysts and project manager meets to talk about the ERP
system?
a. Daily
b. Weekly
c. Monthly
d. Frequently
This kind of failures happens because lack of meetings between project managers and
analysts. We can get clear idea about this situation by this question. This is a close ended
question and user must choose a one answer.
Failure 02:
Poor communication with the solution team about changes in business requirements.
There should be proper change management plan to appropriate adjustment to scope,
schedule and budget and communication with stakeholders about changes.
Questions
e. Yes
f. No

Page | 45
This failure is about poor change management. Therefore by this question we can identify
that did they follow a proper change management method and their idea about it. This is an
open ended question and we can analyze the answer.
Failure 03:
Poor communication with the business stakeholders of deviations from the project
charter, reflected in a revised business case
This failure is also a result of poor change management practices. It can lead to performance
degradation.
Questions
1. What are the methods did you used to exchange information with clients?
a. Face to face discussions
b. Using documents
c. Telephone conversations
d. Formal meetings
e. Email & Online chat
f. Videoconferencing
g. Other
These kind of failures happens because lack of change management and unclear idea about
the business case. We took idea about change management from previous question and this
question will help us to identify what kind of communication happened among clients and the
project team.
Failure 04:
Poor communication with the Service Level Manager of changes in business
requirement

Page | 46
Failure 05:
Poor communication to stakeholders of present or expected conditions under which the
service is preventing realization of the intended business benefit
Questions
1. How do you choose the clients representatives for the requirements committee?
(Multiple Select)
a. By recommendations from client’s authorities
b. The individual's domain knowledge
c. The individual's computer knowledge
d. The individual's position or authority
These two kinds of failures happen because of the misunderstandings and not clearly
expressing their needs by the clients. So this question will help us to identify what kind of
people and their knowledge level about the project analysts dealt with. User can select more
than one answer for this question.
Failure 06:
Not looking to the future
The business analyst should look into the future and ask the every kind of questions rather
than listening to their requirements. This will helpful to success the ERP project. If not this
will be cause to a lot of problems and losses in a log run.
Questions
1. What are the potential opportunities and risk factors did you identified in ERP
project?
Typically this kind of failure happens because analysts do not think about future aspects of
the ERP project.
By this question we can identify that if they concerned about future aspects such as
opportunities and risks of this project. This is an open ended question.

Page | 47
Failure 07:
Incomplete requirements as a source of aggravation
This failure is happens due to lack of complete understandable explanation of requirement by
stakeholders.
Questions
a. Yes
b. No
When clients did not successfully explained their requirements to the ERP project team this
kind of failures will happens. By this question we can measure the idea of analysts about
client’s requirement explanations.
Failure 08:
People give short shrift to the process of soliciting and documenting requirements
When gathering requirements from clients those should be documented, actionable,
measurable, testable, traceable, related to identified business needs or opportunities, and
defined to a level of detail sufficient for system design. Business Analysts should get right
and complete requirements.
Questions
1. Did you use formal specification documents to interpret and communicate the
requirements? If yes what are those?
2. What are the informal specification documents you used?
3. What type of notations did you used in formal specification documents?

Page | 48
4. Could those notations easily understand by both technical and non-technical users?
a. Yes
b. No
Documentation plays a huge role in business analysis process. If they are incomplete and
misleading it will cause this failure. By these questions we can identify if the Business
Analysts used formal and information specification documents and what are those. Notations
will help users to easily understand the specifications. 4th question will measure the view of
analysts that these notations can be identified by both technical and non-technical users. This
will ensure that correct communication of design to the developers of the ERP project and
requirement gathered from clients have documented in a proper way.
Failure 09:
Not defining the business processes
Clients should clearly define the requirements to the business analysts. It will lead to a ERP
project successful.
1. Do you think that clients clearly defined the business case?
a. Yes
b. No
2. Did you conduct the natural language discussions with the clients to get the clear idea
about the business case?
a. Yes
b. No
This failure is also based on the client’s explanations about the business processes. Natural
language discussions will help business analysts to get the exact idea from those stakeholders.
This question will confirm that. This is a close ended question.

Page | 49
3.6 Solution assessment and validation
Failure 01:
Solution design assessment failures
In this stage BA determine how well possible options for solution designs will meet the
requirements. If this fails it affect the whole project, so by the following questions we can
avoid it.
Questions
1. What are the values delivered by the proposed solution?
2. If multiple options are available, what is the solution you selected and what is the
reason?
3. If the solution does not deliver enough value, what are the reasons for the termination
of that initiative?
4. Whether the solution meets the business needs?
a. Yes
b. No
d. Other
5. What is the most appropriate response to identified defects?
By these questions we can identify whether they have clearly identified the available
solutions and they have selected the most suitable solution. Whether the identified solution
meets the business needs, and what are the responses to the identified defects of the solution.

Page | 50
Failure 02:
Failures in allocated requirements
In this stage BA determine allocation of requirements among releases and/or solutions
components. By the following questions we can identify the progress of it.
Questions
1. Did you validate the allocation of resources?
a. Yes
b. No
2. If the allocated resources are limited or any problem with them, how to obtain
excess resources?
There can be failures due to the incorrect allocation of resources; by above questions we can
avoid them, because these questions help to validate the allocated resources.
Failure 03:
Organizational readiness assessment failures
If the organizational Readiness Assessment fails or they are not ready for change possible
system failures will occur, by the following questions we can avoid the failures.
Questions
1. Is this the right time for implementing software?
a. Yes
b. No
2. Will the employees accept the change?
a. Yes
b. No
d. Other
3. If not; what type of motivation methods you are hoping to use?

Page | 51
4. Does the organization can spend sufficient time for user training?
a. Yes
b. No
5. Does the organization have necessary technology and equipment for maintenance
of the software?
a. Yes
b. No
If not; how will you provide them?
6. Does the organization willing to measure and assess progress and continuously
improve processes?
Above questions help to measure the readiness of the organization for the deployment of the
software. To consider whether the organization has necessary technology, resources, people
and other requirements to deal with the system.
Failure 04:
Verified or Deployed Solution failures
When a problem is identified with the deployed solution we should determine what the most
appropriate response is. To do this appropriately, we can use following questions.
Questions
1. If a problem identified in the suggested solution what will you do?
2. What type of solution you will take to correct it?
By these questions we can identify solutions for the problems to the deployed solution.

Page | 52
Failure 05:
Validated Requirements failures
Validate the verified and deployed solution meets the business need. Define acceptance
criteria. If those validated requirements are wrong or false it will create false Business
Analysis, So it will create failures on BA. So by the following question we can identify it.
Question
1. Did you validate the verified and deployed solution?
a. Yes
b. No
By this question we can identify the availability of the required resources.
Failure 06:
Defect impact analysis failures
Identify defects/shortcomings and analyze impact and define corrective actions will be
needed. So this Defect Impact Analysis fails to identify those defects and their impact it will
eventually create failures in BA. So by the following question we can identify it.
Questions
1. How do you identify defects/shortcomings?
2. How to analyze impact and define corrective action?
By these types of questions we can identify defects of the solution and analyze impact and
define corrective action.
Failure 07:
Deployed Solution Performance Metrics failures
If the Performance Metrics of the Deployed Solution represent false details it will create BA
failures in that project. So by the following question we can identify it.

Page | 53
Question
1. If the Performance Metrics of the Deployed Solution represent false details what
sort of actions you take to correct it?
This question helps to get details about the Performance Metrics of the Deployed Solution,
and to deal with appropriate solutions.
4.0 Conclusion
Business analysis plays a major role when implementing ERP systems and it is the
foundation of the whole process. This business analysis phase consists with six phases as
Enterprise /Company analysis, Requirements planning and management, Requirements
elicitation, Requirements analysis and documentation, Requirements communication,
Solution assessment and validation.
Completing these six phases successfully, supports a better business analysis. But in practical
scenario there can be so many errors and confusions due to various reasons. And it causes
result process failure at the end. So identifying potential process failures is very essential to
conduct a good business analysis. Questionnaires can be very helpful in such occasions.
In this report we have prepared a series of questionnaires which can be helpful in evaluating
those process failures, which will be helpful for the success of the whole project.

Page | 54
5.0. References
1. Business analysis - Wikipedia, the free encyclopedia. 2013. Business analysis -
Wikipedia, the free encyclopedia. [ONLINE] Available at:
http://en.wikipedia.org/wiki/Business_analysis. [Accessed 10 May 2013].
2. ICIQ. 2013. ICIQ. [ONLINE] Available at:
http://www.iciq.net/validationprotocol.htm. [Accessed 11 May 2013].
3. Questionnaire designing and validation. 2013. Questionnaire designing and
validation. [ONLINE] Available at:
http://www.jpma.org.pk/full_article_text.php?article_id=3414. [Accessed 12 May
2013].
4. Failure analysis - Wikipedia, the free encyclopedia. 2013. Failure analysis -
Wikipedia, the free encyclopedia. [ONLINE] Available at:
http://en.wikipedia.org/wiki/Failure_analysis. [Accessed 10 May 2013].
5. Advanced Strategies - Business Analysis Methods and Techniques for Everyday
Projects Course Description. 2013. Advanced Strategies - Business Analysis Methods
and Techniques for Everyday Projects Course Description. [ONLINE] Available at:
http://www.advstr.com/web/training/description.cfm?CID=66. [Accessed 11 May
2013].

A Questionnaire for Identify Failures in Business Analysis Phase of ERP Projects

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Viewers also liked

Viewers also liked (20)

Similar to A Questionnaire for Identify Failures in Business Analysis Phase of ERP Projects

Similar to A Questionnaire for Identify Failures in Business Analysis Phase of ERP Projects (20)

More from Varuna Harshana

More from Varuna Harshana (11)

Recently uploaded

Recently uploaded (20)

A Questionnaire for Identify Failures in Business Analysis Phase of ERP Projects