https://www.linkedin.

com/learning/project-management-foundations-requirements-2/identify-standards
Manage project requirements challenges
- Managing requirements can make or break a project. While the details and the terminology vary from one
industry to another, the high level challenges are always the same. The key to effective requirements
management is answering four questions. We need to ask them at the beginning of a project and we need
to continue asking them until the project is completely finished, just in case things change. First, who are
our stakeholders? If you're not sure whether someone is a stakeholder, then just ask yourself, will it matter if
this person isn't happy with the final result of the project? If the answer is yes, then they're a
stakeholder. Once we've identified our stakeholders, the next question is, what exactly do they want or
need? These are your requirements. We've got to get our stakeholders to explain their problems and
expectations as clearly as possible and we need to document them properly. The third question we need to
ask is how important is each requirement? We probably won't be able to do everything that all of our
stakeholders want so it can be a big help if they can tell us what's important to them and what things are
optional but nice to have. And the fourth question we need to ask is how will we deal with conflicts,
changes, surprises and miscommunications? Because as the project gets going, issues are going to come
up. In order to make sure that we're addressing all four of those challenges, I use a 10 step process for
requirements management and in this course, we'll walk through each of those steps. To get started, you
can download the workbook from the course files and look at the tab named Requirements
Checklist. Anytime we're working on a project, our team's job is to deliver something that works, something
that satisfies our customers and meets the needs of our business. And we need to have a process to do
that because our team success depends on how well we manage our project requirements.

Identify standards
- When we're working on complex projects, we need to collect a huge amount of information, and we need
to make sure that nothing slips through the cracks. So it helps a lot if everyone uses the same approach to
managing requirements. Some industries even have formal standards that provide a common
framework. So let me share three examples. The most general standard is the International Standards
Organization's ISO 21500, Guidance on Project Management. It describes how a project should be
managed, including how you deal with requirements. The ISO standard is built around the "Project
Management Body of Knowledge" from the Project Management Institute. You can buy a copy of the ISO
21500 standard from the ISO website and you can get the PMBOK from PMI. Next, more specifically for
software developers and for folks who work in the electronics industry, there's a shared standard from three
organizations, ISO, IEC and IEEE. It's a mouthful. The official name is the 29148-2018 International Standard
for Systems and software engineering Life cycle processes Requirements engineering, yeah. But if your
company or university has a subscription to the Standards library, you might be able to access it that
way. Otherwise, you can buy a copy online from the IEEE website. Third, companies that do work in the
defense industry should be familiar with the military specifications or MilSpecs. The U.S. military standard
for project management is MIL-STD-961E, Defense and Program-Unique Specifications Format and
Content. You can download a copy of that one for free from the Defense Logistics Agency website. In
addition to knowing about the formal industry standards, you should also be familiar with a commonly used
technique where you gather your stakeholders together in workshops to create project requirements. I call
these Requirements Discovery and Analysis Workshops, but you'll also hear them called Joint Application
Design or JAD, Joint Requirements Planning or JRP, and Joint Application Requirements or JAR. There are
other courses here in the Learning Library that explain this technique in more detail. And I've included a tab
called Standards in the course workbook where you can keep track of the standards that apply to your
project. Using a formal standard or applying a well-known technique can reduce confusion, and make it
easier for teams to collaborate. And sometimes it's actually required by your customers. So knowing which
standards are used in your company and in your industry is the first step in managing your project
requirements effectively.

Prepare the elicitation plan

- Michelangelo said, "Every block of stone has a statue inside it "and it's the task of the sculptor to discover
it." And that's very similar to what we're trying to do when we elicit project requirements because
stakeholders and businesses have requirements for our project hidden inside of them and it's our job to
find out what they are. We prepare for that by creating a requirements elicitation plan. Elicitation is just a
fancy way of saying data gathering. There are lots of ways to elicit requirements, so the elicitation plan
should describe what information you're trying to gather and how you're going to get it. For example, you
can conduct interviews with stakeholders. In that case, the elicitation plan should identify which
stakeholders you plan to talk with and what questions you'll ask them. You can also elicit tasks in group
sessions. Then, the plan should identity who you intend to include in the group and how you'll facilitate the
discussion. Another way to elicit requirements is by watching people work and documenting what you
observe. You might be able to see ways to make their jobs easier and that's often how we recognize the
challenges and constraints that people deal with in their daily work. Last, but not least, you can elicit
requirements by studying process documentation and analyzing business data. Documents like standard
operating procedures, flow charts, and reports can all provide information that you could use to generate
requirements. I've included an elicitation plan template for you in the course downloads. No matter which
techniques you use for eliciting requirements, you should include them in your elicitation plan and then
review the plan to make sure that you're asking the right questions and looking in the right places to
accurately define the requirements for your project.
resume auto scrolling

Identify the stakeholders

- Everyone who's affected by a project is a stakeholder. So in order to capture our project requirements, we
need to identify who they are and analyze what they need. A good place to start is to make a list of our
stakeholders. You can list them as individuals or you can list stakeholder roles or groups. For example, you
might put the name of your project sponsor on the list, but you might also add customers to the list instead
of listing every customer's name.  Creating the stakeholder list is a good way to make sure that you're
covering all of the people that need to be included in your requirements development. The next step is to
understand their relationship to the project. We can start by asking whether they're advocates or opponents
to the project. For example, the sponsor may support the project because it's going to increase
efficiency and reduce costs. But if those efficiencies come from eliminating jobs, then the people doing
those jobs today might be opposed to the project. Two other characteristics that you often want to look at
are influence and impact. For each stakeholder you can rate their level of influence on a scale of one to
10. If their support is critical to the success of a project, then they're a 10. If the project will move forward
regardless of whether they support it, then their influence is a one. Now, rate each stakeholder based on the
impact that the project will have on them. If the project will cause a major change in their work or their life,
then they get a 10. If they won't really be affected by the project, then maybe they get a one. Then you can
analyze your stakeholders using a matrix like this. If you download the exercise file, you'll find this template
on the stakeholders tab. Doing stakeholder analysis can help you in three ways. First, it can help to ensure
that you're considering all of your stakeholders and how the project will affect them. Second, it can help
you develop an effective plan for eliciting requirements from all of those stakeholders. And third, it can help
you develop a communications plan so that you can keep your stakeholders engaged and informed as your
project moves forward. Stakeholder analysis gives you an opportunity to understand who will be affected by
your project and how it will impact them. And doing that well can help to ensure that your projects are
more successful.

resume auto scrolling

Gather project requirements

- Gathering requirements reminds me of that old TV show about Detective Columbo. When everyone else
was satisfied with an answer, Columbo would always say, "Just one more thing." That's the mindset we need
to have in our projects. Our job is to find out where all of the requirements are hiding and to bring them
out into plain sight. An important part of this research involves matching our data gathering
techniques with our sources of information. When you need to get input from senior executives, you'll
probably need to schedule a one-on-one meeting. You can start the meeting with a quick explanation of
what you're doing and then ask an open-ended question like, "What are the things that you'd look for "to
determine whether this project was successful?" If you need to gather input from a large group of
customers, you can use an online survey. I generally use Qualtrics or Survey Monkey. They both offer free
versions and include templates that streamline the process. Now let me share four more tips that can help
you a lot. First, when we're getting input from stakeholders, I try to capture exactly what they
say because I want to avoid biasing the requirements with my own perspectives. You never want to be in a
position where you're saying this requirement came from Bob and Bob says, "That isn't what I
said." Second, if I'm not sure that I understand exactly what someone is telling me, I keep asking follow-
up questions until it's clear. It's not about looking smart. It's about understanding the issues. Third, as I
collect data about our requirements, I try to keep really good notes. Then I summarize those by listing
requirements in a matrix like the one on the requirements tab of the workbook. And finally, even though I
start off with an elicitation plan, I often need to adapt and be ready to change course. For example, during
an interview you sometimes find out about additional stakeholders that you hadn't even considered. You
start requirements gathering with a blank sheet of paper, but as you gather input from more and more
sources, you start to see a picture emerge of exactly what the project will need to do in order for you and
your team to be successful.

resume auto scrolling

Analyze requirements
- As project managers it helps a lot when we're organized. Like when we collect requirements, we also
need to capture some information about each one. In other words, we need to document their
attributes. That lets us build structure around the requirements that will form the basis for our project. I use
a spreadsheet to track attributes and I've included an example in the course downloads which captures the
attributes recommended in the business analysis body of knowledge. Here are the 10 attributes that they
focus on. Absolute reference. This is the identification number for your requirement. Assigning a number
makes it easier to track requirements over time even if the name or the description
changes. Complexity. How difficult will it be to address the requirement? You might want to rate this on a
scale like one to 10; or you can rate it easy, medium, or hard; or you might even put in an estimate for the
number of hours you think it will take to address the requirement. Risk. How much uncertainty is there
about the requirement? Do you feel like you really understand it? Author. Who documented or elicited the
requirement? Source. Where did the information about the requirement come from? Ownership. Who's
responsible for addressing the requirement? Stability. Is the requirement well-defined or does it seem like it
may need to be modified or reviewed? Urgency. Does the requirement need to be addressed right away or
is it something that can wait? Priority. How important is the requirement in relation to the entire project? Is
it one that needs to be met in order for the project to be successful or is it a nice-to-have feature that could
be left out if necessary? State. Is the requirement still being drafted or has it been fully documented and
approved? You might find that you don't need all of those attributes, or you might discover others that are
really important for your projects. That's fine. The key is that capturing attributes can help you organize and
manage your requirements and ensure that your project meets the needs and expectations of your
stakeholders.
resume auto scrolling

Prioritize project requirements

- I love the Rolling Stones' song, You Can't Always Get What You Want, and it gets stuck in my head every
time I have to prioritize the requirements for a project because as you go through the elicitation
process, you can end up with a ton of requirements, but your project can't do everything. So, you need to
prioritize and sometimes that leads to tough choices. This is where the work that we've done to survey
requirement attributes and analyze our stakeholders becomes really helpful. First, we take a look at all of
our requirements and look for potential conflicts. If one stakeholder needs our project to be black and
another one needs it to be white, then we need to find a way to deconflict. We might need to choose either
black or white or we may be able to compromise on a shade of gray. Next, we make sure that all of our
requirements are truly unique. Are there duplicates or requirements that could be easily combined? Then,
we check to make sure that our requirements aren't too complex. Sometimes it's better to break a single
requirement into two or more simpler ones. Now, we can evaluate the importance of each requirement. For
smaller projects, it might help to make this a simple binary choice. Each requirement is either necessary or
optional, but for bigger projects with lots of requirements, we can rank their importance on a scale of one
to 10. So, how do we determine the priority for our requirements? Well, that depends on the
project. Sometimes prioritization is a team effort. It requires a vote or a consensus from several
stakeholders. Other times, the project sponsor or the product manager gets to make the prioritization
decisions. Last, but not least, of course we need to document our requirement priorities and we need to
keep records of any changes. In most projects we can't do everything that everybody wants, so prioritizing
your requirements helps you prepare for conversations about which items need to be in scope for a
project and what resources will be required to achieve your project's goals successfully.

Create use cases

- Project requirements describe what our stakeholders want a solution to do, but they generally don't
provide the context that we need to develop good solutions. We can solve this problem by using our
requirements to create use cases. A use case tells the story of how the solutions should work once it's
complete. It provides a step by step explanation of a process and what everyone involved needs to do
along the way. A single use case could provide the context to support many different requirements. There
are a couple of key terms that you need to know. The people and systems that are including in a use
case are called the actors, and the steps are called actions or events. Now let's walk through an
example and create the use case for ordering pizza at a restaurant. This use case has several actors like the
customer, the waiter, and the chef. And since the order needs to be entered into a computer, well the
computer's an actor too. Now, what are the steps that occur in the process? The waiter takes the order from
the customer, and enters it into the computer. Each of those steps is an event. Then the computer transmits
the order to the chef. The chef makes the pizza and the waiter brings the pizza to the customer. There,
you've got a simple use case. Sometimes the easiest way to communicate a use case is to write it out, but
you can also document them by using diagrams. For example, a swimlane diagram is a special kind of flow
chart that shows which actors need to complete each step. Or for more complex use cases, you can use a
technique like unified modeling language, or UML to diagram the process. UML is especially helpful if
you're writing software and need to understand how the people and the computers are going to
interact. You can learn more about UML from several of the courses here in the library. Use cases enhance
requirements by providing the context to help everyone understand a process. Using them properly makes
it easier for everyone to work together to build better solutions.

Document project requirements

- How do we take all of the information we've gathered from our stakeholders and use it to frame up a
project? Well, we do that by documenting them in a requirements report, or what some people call the
scope document. I think of the requirements report like a story that explains what our project is going to
do and why it's important. It starts with an executive summary, then there should be some background
information to explain why the project is important for the business and who the stakeholders are. Next, we
can have sections to discuss the goals for the project and the description of the things that are in scope and
out of scope. We can also describe the risks that we anticipate and any interdependencies with other
projects in the organization. For technical projects, I like to include a glossary with definitions for key
terms. Next, the report should lay out the requirements with enough detail but not too much detail. The key
to documenting project requirements is to describe what you want a solution to do without explaining how
to do it. That requires some judgment. So here are the three things that I look for in each requirement. First,
is it clear and specific? Can someone on my team read that requirement and understand what it means
without getting confused or without needing additional explanation? Second, is it thorough? Can we tell
where the requirement came from, who documented it, and why it's important? And third, is it
testable? Will we be able to know for sure whether the requirement has been met once we complete the
project? If all three of those criteria are met, then it's probably a pretty well-written requirement. One other
thing to keep in mind about requirements reports. They get revised and evolve over time, so make sure that
you have a version control process for managing changes and for ensuring that everyone is working from
the most current version. The requirements report is the foundation on which our whole project will be
built, so doing a good job in documenting our requirements is key to preparing our whole team for success.

Approve project requirements

- How do we make the transition from gathering information to actually working on a project? By getting
our requirements approved. Then we can create a plan and start allocating resources. There are really two
steps in the approval process. First we should give our stakeholders a chance to review our
documentation to ensure that their requirements were captured accurately. And then we should get
management approval to lock down the requirements and move forward. Asking stakeholders to review
your requirements sounds simple, but it can actually be really hard. Our stakeholders are busy, so they
might think I already invested the time to explain the requirements to you. Why do I need to look at them
again? But we know that requirements go through a whole process of refinement and prioritization. This
review is our stakeholders' last best chance to understand the full requirements for the project and to
provide any last input before it goes to management for approval. Once the stakeholder reviews are
complete, it's time to deliver the finished requirements report. In some organizations, the approval is a
stage gate. We need to submit our requirements for review, then get formal approval from management in
order to pass through that gate and move on to the next stage of the project. Other organizations are more
informal and our approval might be done via email or in a meeting with the project's sponsor. If you
followed my process for developing your requirements, then the approval should be pretty simple. But
sometimes the approvers can raise questions or concerns that we'll need to address. In that case, we just
need to go back and repeat the steps in the requirements process until all of our approvers are in
agreement. Getting your requirements approved is an important milestone for every project. It's a good
opportunity to recognize our stakeholders and team members for their help, and it provides everyone with
confidence that we're working towards the same set of goals.
Manage change requirements
- If there's one thing we can always count on from projects it's that things are going to change. In order to
define our scope we need to start off with a good set of requirements, but even after they've been
approved those requirements can change. So we need to be ready for it. It could be that we miss some
requirements during the elicitation process. We could have learned something once we started working on
the project, or something about our business, or our business environment might have changed. The
easiest way to track all of this is with a versioning process. First we need to have a process for submitting
change requests, and for having them reviewed and approved. It's sometimes handy to have a change
request template to make sure that we're getting the necessary information about what the change is,
who's requesting it, and why they think it's important. If a change isn't approved, then the person who
submitted it needs to be notified. If the change is approved then it needs to be incorporated into the
requirements report and everyone needs to be notified. Now the requirements report is a formal
document that's been reviewed and approved. So, every time we make a change to the report, we're
actually making a new version. In order to keep track of the versions it helps to include a revision number. I
also like to add a change log to the requirements report so there's a short summary of the changes in each
revision and the data on which they were approved. That makes it easy to see exactly what's changed and
when it happened. I've included a template under the change log tab in the course workbook. Last, we need
to make sure that everyone who uses the requirements report is working from the most current version of
the document. That's pretty easy with electronic documents, because you can just email the most current
version out, or store it on a shared drive. But people do need to know about it when requirements change,
so it's a good idea to address this scenario in your communications plan. Think about who needs to be
notified and how you're going to let them know. Requirements need to be flexible enough for us to keep
our projects aligned with the needs of the business. Being prepared for changes and having a process in
place to manage them helps to ensure that we can be agile and adaptable in every aspect of our projects.
Manage the project requirements process
- Project requirements are really the foundation that every project is built on. They link the needs of your
business and your customers with the work that your project team needs to do. So Project Managers and
Business Analysts play a really important role by making sure that the requirements are defined well and
managed properly. In this course we've walked through a 10 step process for managing project
requirements. You may not be able to go straight through all 10 steps in every project. For example, as
you're collecting requirements you may identify some additional stakeholders and that'll force you to step
back and update your stakeholder analysis. That's fine. As long as you're prepared to complete all 10
steps then you've got a pretty thorough requirements management process in place. I hope you found this
course useful and that it helps to make you more productive. If you want to dig deeper into requirements
management, there are other courses here on the Learning Library and there're lots of great articles on the
Project Management Institute website. I'd love to hear about your experience, too. And to learn from your
journey. And I share a lot of insights form the work that I'm doing. So please follow me on LinkedIn and
Twitter where we can all continue to learn from one another. Until then, keep up the great work that you're
doing and keep investing in developing your professional skills.