Project Management Foundations: Requirements

Managing requirements for successful projects

Basic requirements example about eating with friends

• Confirm everyone’s schedule
• What type of restaurant are we eating at
• What is the location
• Do we need to make reservations

How do we determine the projects needs to be successful.

Defining requirements: Key questions to consider

1. Who are the stakeholders?
2. What do our stakeholders need?
3. How important is each requirement?
4. How will we deal with issues?

Manage project requirements challenges

Requirements Management Questions

1. Who are the stakeholders?
2. What do they need?
   • These are the requirements
   • Document them clearly
3. How important is each requirement?
   • Determine the core requirements from the “nice to have”
4. How will new issues be dealt with?
   • Conflicts, changes, surprises, etc.

A ten-step project requirements checklist

• Identify standards
• Develop an elicitation plan
• Identify stakeholders
• Gather project requirements
• Analyze requirements
• Prioritize requirements
• Create use cases
• Document project requirements
• Approve project requirements
• Manage changes to requirements

Identify standards

• ISO 21500 – Guidance on Project Management

• ISO, IEC, and IEEE
• MIL-STD-961E – defense and program-unique specifications format and content

• Requirements Discovery and Analysis Workshops
  • JAD – Joint Application Design
  • JRP – Joint Requirements Planning
  • JAR – Joint Application Requirements
• Workshop/Brainstorming sessions

Applying a well-known standard or applying a well-known technique can reduce confusion and make it easier to collaborate.

Prepare the elicitation plan

Elicitation is a fancy way of saying, data gathering.

• conduct interviews with stakeholders.
• group sessions
• watching people work and documenting what is being observed
• studying process documentation and analyzing business data

Identifying the stakeholders

Stakeholder matrix can be created listing the different stakeholders, whether they are advocate/opponent of the project, Influence and impact.

Influence can be ranked from 1 to 10 – 10 being the most influential stakeholder and lower amounts means the project will move forward regardless of their support.

Rate each stakeholder based on the Impact they will have on the project. If the project will cause a major change to their work or their life, then they get a 10. If the stakeholder won’t really be affected by the project, then maybe they get a one.

The Stakeholder Analysis approach is helpful because:

1. Consider all your stakeholders.
2. Develop an elicitation plan.
3. Create a communication plan.

Gather project requirements

What will determine this project’s success?

1. Capture exact words – avoid biasing the report with your own perspective.
2. Ask follow-up questions – keep doing this until it’s clear.
3. Take and summarize notes
4. Be ready for changes – additional stakeholders or changing conditions

Analyze requirements

Attributes:

1. Absolute Reference – identification number for the requirement.
2. Complexity – how difficult will it be to address the requirement?
3. Risk – Level of uncertainty
4. Author – who elicted the requirement
5. Source – where the information orignated
6. Ownership – person responsible for addressing the requirement
7. Stability – status of requirement – is it well define or does it need to be modified or reviewed
8. Urgency – when does the requirement need to be addressed?
9. Priority – level of importance – needs to be met or nice-to-have
10. State – status of requirement approval

You may not need all of these attributes. Capturing attributes helps your organize requirements.

Prioritize project requirements

Look for potential conflicts. For example the project creates a product that one stakeholder requires it to be white while another stakeholder requires it to be black. You need to deconflict or negotiation into a shade of grey.

Ensure all requirements are unique. Review requirement complexity. Look to break requirements into two simpler ones.

Level of Importance – Ideal for smaller projects

• Necessary
• Optional

Rank Importance – for larger projects

• Scale of 1 to 10

Project sponsor makes the prioritization decisions. Document requirements priorities.

Create use cases

Use Case
How the solution should work once complete.

Actors
People and systems included in a use case.

Actions or Events
The steps in completing a use case.

• Customer
• Waiter
• Chef
• Computer

Customer -> Waiter (takes the order from the customer) -> Computer (enters the order) -> Chef (computer transmit the order) -> Pizza (chef makes the pizza) -> Waiter (collects the pizza) -> Customer (waiter provides food to customer).

Swimlane Diagram
Special kind of flow chart which shows which actors completes the steps.

Document project requirements

Scope Document or Requirements Document

• Executive Summary
• Background information
• Stakeholder list
• Project goals
• Scope
• Risks
• Interdependencies

Requirements

• Requirement 1
  • Solution
• Requirement 2
  • Solution

Are the Requirements:

1. Clear and specific?
2. Thorough detail?
3. Testable?

Approve project requirements

1. Stakeholder review
   • Give them a chance to review prior to management approval
2. Management approval
   • Lock down the requirements to move forward

Deliver final report.

Manage change requirements

Track projects with a versioning process. Also include a change log in each version to see exactly what changed and when. Always work from the most current version.

Develop process for submitting change requests.

Change Denied:

• Notify requestor

Change Approved:

• Incorporate into requirements report