Requirements Capturing

A major cause of project failure and source of frustration is not having captured the requirements correctly. Therefore, it is of utmost importance to use a variety of sources to outline the defined requirements before any research is done. This list is not limited, but these sources are where customer requirements are typically listed:

• Brainstorm sessions
• Questionnaires and data collection
• Analysis of pre-project documents
• Review relevant legislation
• Contract requirements
• Prototyping
• Written requirement specification
• Use Case
• User forums and focus groups

Requirements analysis

When tasked to analyse the requirements, the process weighs Value, Priority, Time, and Process together with the organisation’s strategic objectives as well as all the people and resources available.

• Value is what is the project worth, the ultimate benefit
• Priority puts the project in context with other projects or objectives in the organisation
• Time and process are the practical considerations

Justifying requirements: The MoSCoW prioritisation method

This is one of the easiest ways to label and categorise a long list of requirements by priority.

• Must-Have: These are the minimum requirements for your project; they are non-negotiable. So ' If the answer is 'cancel the project – there is no point in implementing a solution that does not meet this requirement, then it is a Must-Have requirement.
• Should Have: Our project’s should-haves are the features that are not essential but will add substantial value nonetheless, such as fulfilling customers' wishes and expectations
• Could Have: This is the catch-all category for features that are neat, interesting, or fun, but that don't necessarily serve any greater purpose
• Won’t Have: Finally, we have the won't-haves. This category is likely to fill up with ideas as you get further along in the project, such as features you would like to include in your product, but for some reason can't.

Documenting the Requirements Baseline

Once the requirements have been documented then the configuration management process applies (version control), as they are effectively part of the project’s baseline.

PBS, OBS and WBS

For you to create sprints or do any planning, there is a methodology where you create an overview of all the Major Tasks (PBS), then a breakdown of the work to be done for each of those tasks (WBS) and have an overview who in the organisation is that could perform the work or will be involved in the project (OBS). 

Product Breakdown Structure

A product breakdown is a breakdown of all the deliverables (products) that will need to be delivered.

Typically, those are split as major tasks that take a couple of days/weeks depending on the type of project.

See it as an overview of the major tasks in the hierarchy, with subtasks.

Work Breakdown Structure

The WBS is a breakdown of all the tasks that will need to be completed to deliver the products. These are easily recognised by using the of verbs to begin each item.

Organisation Breakdown Structure

The OBS is a breakdown of the people in the organisation (resources) that are involved with the project.

Outputs combined achieve an outcome

Take a look at the diagram below: you can see that project A, has output 1, yet combined with output 2 from project B, it achieves an outcome that can be observed. So, you could be working on a project that delivers a UX design for the company app, and that output is used in combination with the new website launch (project B), you could achieve an outcome of more sales.

Awareness of company programmes and linked projects, as discussed in the Project Context section, is always worthwhile.