Which of the following is the main reason for establishing a baseline in your project select the correct option s and click submit?

When to Perform a Baseline

Business analysts sometimes struggle with exactly when to define a requirements baseline. It’s an important decision because establishing the baseline has the following implications:

Formal change control begins. Change requests are made against an established baseline. The baseline. therefore, provides the point of reference for each proposed change. Make sure your change control process and players are in place before you define any project baselines.

Project managers determine the staffing levels and budgets needed. There are five dimensions to a software project that must be managed: features, quality, schedule, staff, and budget. Once the features and quality goals are defined in the baseline, the project manager adjusts the other three dimensions to accomplish the project’s objectives. It can work the other way, too. If staff, budget, and/or schedule are pre-established by external forces, the baseline composition is necessarily constrained to fit inside the project box bounded by those limits.

Project managers make schedule commitments. Prior to baselining, requirements are still volatile and uncertain, so estimates are similarly volatile and uncertain. Once a baseline is established, the contents of the release should be sufficiently well understood so that managers can make realistically achievable commitments. The managers still need to anticipate requirements’ growth (per their requirements management plan) by including sensible contingency buffers in their committed schedules.

Baselining requirements too early can push your change process into overdrive. In fact, receiving a storm of change requests after defining a baseline could be a clue that your requirements elicitation activities were incomplete and perhaps ineffective. On the other hand, waiting too long to establish a baseline could be a sign of analysis paralysis:  perhaps the BA is trying too hard to perfect the set of requirements before handing them to the development team.

Keep in mind that requirements elicitation attempts to define a set of requirements that is good enough to let the team proceed with construction at an acceptable level of risk. Use the checklist in Table 1 to judge when you’re ready to define a requirements baseline as a solid foundation for continuing the development effort.

Table 1. Factors to Consider Before Defining a Requirements Baseline

You’re never going to get perfect, complete requirements. The BA and project manager must judge whether the requirements are converging toward a product description that will satisfy some defined portion of customer needs and is achievable within the known project constraints.

Establishing a baseline at that point establishes a mutual agreement and expectation among the project stakeholders regarding the product they’re going to have when they’re done. Without such an agreed-upon baseline, there’s a good chance someone will be surprised by the outcome of the project.

And software surprises are rarely good news.

Which of the following is a main reason for establishing a baseline in your project?

What is the main reason for establishing a baseline in ITIL?

Which of the following baseline will be supported for project's work?

Which of the following is a good use of baseline?