1
Student name
Institution
Professor
Date
Assignment
IT Acquisition Requirements: Challenges and Solutions
1. Challenges in Identifying and Documenting IT Acquisition Requirements
One of the most challenging issues in identifying and documenting IT acquisition
requirements is balancing completeness with clarity. IT projects often involve complex
systems and needs that must be fully understood to create accurate requirements.
However, stakeholders may have difficulty expressing their needs clearly, which can
result in ambiguous or incomplete requirements (McGraw et al. 2020). This is
particularly challenging when multiple stakeholders with differing priorities are involved.
2
The requirements must be detailed enough to guide the acquisition process, but not so
complex that they become difficult to implement.
To address this, a structured requirements-gathering process should be employed, such as
interviews, surveys, and use case scenarios. Engaging all stakeholders early and continuously
revisiting the documented requirements can help clarify ambiguities. Another effective strategy
is to use modeling techniques like Unified Modeling Language (UML) to visually map out the
system requirements, making them easier to understand.
Another key challenge is managing changing technology landscapes. Given the rapid pace of
technological advancements, the needs identified at the start of an acquisition process may
become outdated by the time the project is executed. This can lead to misaligned requirements
and the need for frequent updates. To mitigate this, agile methodologies that emphasize iterative
cycles and flexibility can be adopted. Regularly reviewing and updating the requirements
throughout the project ensures they remain relevant.
2. Managing Changes to Requirements Post-Approval
Changes to requirements post-approval are a contentious issue. On the one hand,
flexibility is necessary to accommodate evolving needs and unforeseen issues. On the
other hand, frequent changes can lead to scope creep, increased costs, and delayed project
timelines. It is generally advisable to allow modifications up until a contract is signed
with a service provider. This ensures the most up-to-date needs are captured in the final
contract.
Once the contract is signed, changes should be limited and subject to strict change control
procedures. Any proposed changes during the project should undergo a cost-benefit analysis, and
their impact on the project’s timeline, budget, and scope should be carefully evaluated. Change
3
requests should be reviewed by a project steering committee, and only changes that are deemed
critical to the project’s success should be approved. This approach ensures that the project stays
aligned with its original goals while maintaining enough flexibility to adapt to changes.
3. Challenges in Developing a Work Breakdown Structure (WBS)
Developing a Work Breakdown Structure (WBS) can indeed be challenging, particularly
in understanding the full scope of the problem and the proposed solution. A WBS breaks
down a project into smaller, manageable components, but this requires a deep
understanding of both the project's deliverables and the work required to achieve them.
From my experience, one of the easier aspects of developing a WBS is identifying the major
project deliverables. These are often clear based on the project objectives. However, breaking
down these deliverables into finer, more specific tasks is where the complexity arises. For
example, in my individual project, it was difficult to accurately estimate the effort and resources
needed for each task, especially for tasks that were unfamiliar or involved emerging
technologies. I encountered problems in defining the boundaries of each task, ensuring there was
no overlap between different tasks or gaps in the WBS.
To solve these issues, I employed a bottom-up approach, starting with more general components
and refining them into smaller tasks through team discussions and expert consultations. I also
used project management software to visualize the WBS and ensure logical consistency. Regular
feedback from team members helped to validate the structure and adjust it as needed. This
collaborative approach ensured that the WBS was comprehensive, well-organized, and aligned
with the project goals.
4
References
McGraw, K. L., & Harbison, K. (2020). User-centered requirements: the scenario-based
engineering process. CRC Press.