Information technology acquisition plan is deemed simple, rapid and the most essential

technique through which a firm can reach its objectives. The acquisition procedure can be

beneficial and can boost a firm’s significant benefit. However, it can also backfire. Among the

most significant difficulties in information technology procurement include the heterogeneity of

users and non-functional needs.

What are the most complex challenges in establishing and recording IT acquisition needs?

Reasons and how the issue may be solved appropriately.

Heterogeneity of users

There are different approaches that stake holders use to identify the needs of an

organization to acquire a new system application.  Conflicting, inadequate and complex data may

result as the stakeholders try to define the requirements of an organization. Stakeholders may

conclude on decisions that are badly designed and inconsistent which causes loopholes that

exposes the organization to vulnerabilities or problems.  When stakeholders misinterpret the

requirements of an organization, this leads to arise of challenges. In order to solve this challenges

that may arise, the organizational goals, mission and vision should be well understood by the

stakeholders. To successfully make an IT acquisition requirement decision, the firm stakeholders

should be in constant consultation with the software engineers  

Non-functional needs

Technology procurement often emphasizes on functionality instead of quality criteria. IT

acquisition complexity may emerge due to ambiguous details about policies, procedures and

nonfunctional needs for example security and performance. One of the biggest problems that

software developers experience is finding details in the procedure of IT acquisition. This

challenge can be handled by establishing a defined policy framework and regulations.

 Should that be permissible to change, delete, and amend criteria once they have been

accepted up until the moment an agreement has been executed with a provider? Would it even

be feasible to add, remove, and alter requirements throughout the future project?

A contract describes the obligations and accountability of every participant. One of the

primary reasons why a party may change the contract is to extend the time restriction. The

opposite party may change the contractual terms in order to improve or diminish the quality a

product or service. Parties may elect to adjust the need of the contract in order to affect the

delivery method or payment mode. A contract that has been approved and signed by a service

provider should not be permitted for any modifications of the contractual terms either by

adding, deleting or changing the requirements. This will be violation of the contract as; the

service provider might have started implement the tasks assigned to him. It may also incur delays

in supplying the product because the participating parties have to negotiate over the

requirements. However, modification of the requirements may result in an increase or reduction

in price and standard of the product. It should not be able to allow modification of

demands during a subsequent project because finances, personnel, and other aspects have already

been agreed on. When a prerequisite is added, removed or altered it signifies that the budget of

the project will either grow or decrease. The parts and personnel needed to accomplish the future

project will also change. It is vital to carefully check the contract before signing so as to avoid

adding, removing or modifying the requirements of the contract

The establishment of a job breakdown system might be challenging. It demands a firm grasp

of the issue and a good comprehension of the suggested solution. The recommended solution

should be subdivided  into its primary pieces, which could be progressively broken down.
Experience in designing a job breakdown structure for your unique project. What was easy?

What was difficult? What challenges did you experience, and also how did you handle them?

Work breakdown structure is generally used to map out the project from start to

conclusion. In addition, the work breakdown structure essentially comprises disintegrating

deliverables and tasks. As I was designing the work breakdown structure, I faced some issues

identifying activities needed for each key activity. Although it was straightforward breaking out

all the resources and expense needed for each operation. One of the primary issues that I found

when building the work breakdown structure was predicting the amount of time that each activity

will require. To tackle this problem, I took the average salary of the area where I was carrying

out the project and assessed the personnel cost. In addition, I contracted an IT supplier to enquire

more about the projected time for a task.