PMP Primer Masterclass Online Training
Shares
Shares

Project Requirements Excellence – Part 1

Project Requirements Excellence – Part 1

A great project manager will have studied business analysis aspects such as how to write and communicate excellent requirements.  Your project will rise or fall on your ability to take what the user and customer really wants and to articulate it clearly.

The first topic that project managers talk of is defining the scope of the project – that is, identifying exactly what the project includes and most importantly what it does not.  There are two aspects to scope, project scope and product scope.

I’m sure you can see the importance of getting the requirements right and reflecting the true needs, since getting this wrong from the start will mean your project is doomed to failure at one level or another.

Put simply, the job of capturing requirements is vital since your project specialist team will depend on the requirements to effectively design and construct solution components.

Excellence in requirements leave no room for interpretation, must create no cause for confusion, and omit no critical detail. They ensure that any customer or user of the requirements can understand what has been requested.

Such customers and consumers will only be delighted with the end product of the project if the above criteria have been followed.

Requirements that generate more questions than they provide a answers are not excellent requirements because they lack in clarity, and the team may find delivering the appropriate solution much more difficult and frustrating.

Excellence in project requirements need to capture seven different characteristics which I will lay out in detail for you in this series of articles.

The seven characteristics of project requirements excellence

Project Requirements

Complete requirements

A complete requirement for only describes the use a task and all the information required to support that task. To create complete requirements, you will want to push stakeholders to focus on describing the goal to be accomplished and the requirements for achieving that goal.

This is opposed to talking about the system functionality. Focusing on system requirements often creates gaps because stakeholders frequently think of only the specific tasks that are relevant to themselves.

The stakeholders miss critical interactions With or dependences on others around the gold or outcome, and those elements are typically important for the overall solution.

Here are two contrast in examples of completeness:

Poor. “accounting needs to be able to process employee expense accounts”

Excellent. “accounting supervisors needs to be able to approve expense accounts submitted from employees”

Correct requirements

A correct requirement appropriately meets the goals of the project and accurately describes the users expectations Of the functionality being specified.

You must challenge and eliminate assumptions that occur when stakeholders who are very familiar with their business areas, internalize different business roles or scenarios and then omit those critical details from their requirements.

Here are two examples of varying correctness:

Poor. “An employee may change their last name off for a change in marital status “

Excellent. “An employee may change their last name off to submit an appropriate legal proof of name change”

Unambiguous requirements

An unambiguous requirement is crystal clear. Based on the requirement, all readers should arrive at a single and consistent interpretation.

Misinterpreted ambiguous requirements can result in the wrong system being developed, a situation that may not be found during testing if the test that is working under an incorrect interpretation of the requirements.

Here are two examples of clear/Unclear requirements:

Poor. “Overtime is not permitted”

Excellent. “any consultants time sheet that is submitted with an excess of 40 HRS work will be designed for payment and returned to the consultant for revision”

Verifiable requirements

Excellent requirements need to be testable to verify that what you get when the solution is completed is what you wanted in the first place.

Requirements that are not verifiable may be descriptive enough to be subjectively assessed, but they are not provable, which can complicate ensuring someone really got what was needed.

Here are two contrast in examples of verifiability:

Poor. “order fulfillment should be able to pack most orders within 5 minutes”

Excellent.  “or the fulfillment must be able to pack 90% of orders within 5 minutes after receipt of the packing slip”

Necessary requirements

Requirements need to clearly support a project goal or objective. They should not be on someone’s personal wish list, and they should not be requirements that anyone would review and declare to be scope creep.

Every project operates under time and budget constraints, so if a requirement is not necessary, it can be deprioritized.

Here are two examples of levels of necessity:

Poor. “Accounting systems must have current, up to the minute exchange rates available”

Excellent. “Accounting Systems must have their exchange rates updated once daily”

Go To Project Requirements Part 2 HERE!