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 2

nd 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 5th

question 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, 2

nd 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].

http://en.wikipedia.org/wiki/Business_analysis

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

Technology

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