Okay, so let's talk about requirements. Like we said earlier. One of the leading causes that projects fail is because of requirements, improperly collected requirements in accurate requirements, very frequently requirements from the wrong people, or
not evaluating all of our stakeholders, as
as they should be evaluated. So when it comes to requirements there a couple of big pieces here. First of all, it is stakeholder identification and evaluation that leads us to be able to collect requirements. Well, I have to identify all my stakeholders
negative. My stakeholder is not just the person that signs the check. And here's why. Many times we spend a lot of time meeting with our sponsor and senior management of the organization for whom were working. And maybe we don't properly, uh, interview the end users about what their expectations are.
So now we have a product that meets senior management's approval, but when it gets in the hands of the end users, they can't use it.
Therefore, we have delivered no value, so we have to start out by figuring out who the stakeholders are, what their degree of influence over the project with their level of authority is Are they legitimate stakeholders? Do they have a certain amount of power within the organization power over the project and it needs to be documented.
Based on that, we then need to develop a stakeholder strategy.
Not all stakeholders are created equally. Does my sponsor need to be contacted once a week? Once a month.
How did they want to be contacted via phone? Are there certain triggers that are gonna leave me to pick up the phone and call? How do I collect requirements from the customer service reps that are actually gonna be using the software that I'm producing? These air All things and decisions that need to be made and documented and approved of
approved by the customer
before we get started? Because when we look at poor requirements usually can come down to a couple of questions.
Uh, probably the big ones were the right groups involved in developing the requirements. Did I get the right stakeholders in the room at the right time
in order to move forward? Because if I don't, I'm not asking the right people. It doesn't matter what questions I ask, right? So start by making sure we've got the right people. Then let's find out. Are there unclear or conflicting requirements? If you have two people in that room, they're probably gonna be conflicting requirements.
We've got to find a way to prioritize those requirements
as we move forward. And again, not all stakeholders are created equally. So we want to make sure that we've evaluated our stakeholders properly. By the way, a document called a stakeholder register and I mentioned that if you don't have these documents already just as a place to start, go out on Google Project Management documents
stakeholder registers very important gives you
fields to document who your stakeholders are, their level of authority and influence and all those pieces of information. Okay, were there unclear or conflicting requirements? You wanna document both sets of requirements. But when push comes to shove, the person that signs the checks does win. So we have to have a way of evaluating resolving those conflicts.
How did we collect requirements? Did we just send out a survey and whoever returned the email? We took those requirements? Probably not very effective. So how did we collect the results? How did we document? And importantly, how did we verify the requirements
Because you'll tell me to do something. I will hear something totally different.
That's okay. Do I come back to you and say so? This is what I hear. Active listening documentation. You put your signature on what I've written here is what I've heard. Here is what we will be providing. You sign off here. Hey, historically,
has there been a problem with this particular customer of this particular state holder? This group
internal or external, to the organization? And where do you think I learned that I go back to my lessons learned Historical in front
Best practices. One of the best practices that your organization can implement is a project management office a p m. O. Now again, if you're a small company who only occasionally manages projects, that's one thing in that element, you still need a P m up.
But all the PMO has to really be is a central location for the betterment of project management. In fact, I know several different organizations that promote what they call P m o in a box. And what it is is a collection of templates. Ah, collection of processes
that could be distributed and then some tools and suggestions.
Larger organizations. They're gonna have an official, a legitimate PMO that actually it's staffed and contains, you know, ah, team that's there to support project managers, get more accurate and provide the resources they need. A P m o could be any size, though. What you need to start looking for.
standardization, well defined methodologies. Think repeatable. As a matter of fact, we talked about having a scope statement earlier and how it's really important that I agree on the scope of work and my customer agrees on that as well. That ties right into these requirements. Right Scope statement is built from the requirements.
If I don't have good requirements, my scope statement's gonna be lousy.
But the point that I was gonna make here waas
No matter how many project managers you have in your office, we should all be able to use the same scope statement template.
What we feel in is gonna be different. But the template ought to be the same. You should be defined. It should be repeatable.
All right, um, again, standardization. What are documents and where are they and who has access to him? Like I said. Not everybody in the company needs access to everything, but we do need to create a process that will support. Need to know.
Can I access it easily when I need it?
A defined methodology? Do you think there's a coincidence in the fact that we see standardization, defined methodology lessons learned,
uh, access easily for transparency? These things that we've talked about just keep coming up again and again. And it's a new mindset for many organizations because they're moving towards project management and haven't been doing this necessarily for years. I have to tell you, I've always loved Gilbert, and hopefully you can appreciate the beauty if this,
cartoon, when I also like
collecting requirements, is also known as nailing Jell O to a tree. And sometimes it feels like that. You know, sometimes it's really hard to pin customers down on what they need, but without a well defined scope statement in a sign off from my customer, it's very difficult to move forward because I can't
be assured that I'm providing the correct work and deliver Bols
unless we have a document in writing so very, very important. So uh, P M. Ise 2014
annual globe Global, uh, pulse of the professionals study. And they do this, of course, every year. And often they will update the PNP exam based on their findings. Ah, primary call calls of project failures and collect in correct requirements or
improper requirement. So it just goes back to everything that we're talking about.
What does it come down to? Lack of maturity in our process? We're not standardized. We're not formalized. We're not methodical. We don't audit
all of those elements.
failing to develop the skills in our staff and our team or other reasons that projects fail
we don't have the resource is to do things properly and again. This goes back to requirements. Let me tell you, it is a, uh, a very valuable skill to be able to collect requirements and document them well and again, it's not always what comes out of the customer's mouth. We need help in.
We need to help that customer and assist them in vocalizing their requirements
and make sure that the work we do provides value for the customer.
Some have senior management doesn't support us. Sometimes senior management does not support the project and That's just the way that it is. Sometimes we don't have. The resource is. Sometimes we don't have the funding. But again, this goes back to us needing to find a way to sell project management, to senior management into our customers.
And when we talk in terms of P. M. I and P and P search and ads on this and that,
often we get tuned out. What we need to do is talk in terms of cost benefit analysis, go back to how likely a project is to succeed or fail.
How much money is wasted on failed projects. Those were the things that speak to those that have the authority to sign the checks.
One of my favorite cartoons of project management and what it really shows is it shows how very difficult it is to produce a product that the customer wanted.
And that's just that. So you can see there couple ones that I really love. So the customer explained what they wanted. This way you can see that's probably not what the customer really wants, but that's how they explained it.
Project leader. Get something totally different.
I love that. This is how it's designed. Sometimes when you see this slide, this says this is how it was installed in the field, and it's somebody that came from working in the field. I can't tell you how many times we prop stuff up, use duct tape and chewing gum to make it work.
I like how it was documented. I think that's probably pretty accurate. They're just a bunch of shadows, Uh, how it was supported. And then ultimately, we come down to what the customer really needed was very basic. So, you know, this is in jest, but so many times, I mean, if you just think about it, how many times could this sum up
projects that you were involved in
And I think that sadly, that's the case. Sometimes when we get back to, um, you know, discussing project management as a whole, specifically in the area of requirements management, we go back to people, processes and the organization as a whole. So we've gotta have the people.
We've got a train, our people,
you know, you could do a five day class on proper requirements, and I think a lot of organizations would benefit that. How do we get the right requirements. How do we document? How do we come to an agreement? Because everything that we do is based on the requirements of the customer. If our starting point is off, we cannot be successful.
A and R processes in place. We have the documentation. We have the tools and the techniques in line to get those requirements documented and verified. And the company culture,
the company culture. It flows down from senior management.
senior managers need to show that they believe there's a value in project management. Senior managers need to understand. The value of the process is that we're gonna implement the importance of documentation. It all flows downward. Company culture is a direct
reflection of senior management of the organization. I believe.
All right, so poor requirements equal poor performance. And as a matter of fact, let me just define a term for you. I've used the term quality several times throughout quality has a little bit different of a definition than you might assume. A lot of times, when we think of high quality, we think very expensive material.
We think of something painstakingly put together,
but that's not the definition of quality
the definition of quality per p m. I Project Management Institute. And if you think about this, a very good definition.
Quality is the degree to which a product meets its requirements,
the degree to which a product meets its requirements. If a product meets its requirements and does what it's supposed to do, that is a quality product.
A lot of times when people are thinking about spending a lot of money and something painstakingly created, that's more the grade of something.
Okay, so great and quality or different.
You can have something that is low grade in high quality.
Have you ever had a customer say we're in a very tight budget? We got to do this as cheaply as possible.
Well, they may be choosing low grade, uh, materials,
but if you build a product that meets their needs, that's high quality.
I have a waiter that brings me a lobster for lunch that's high grade, but if I ordered a hot dog,
that lobster's low quality, and I know that's a little bit counterintuitive, but what we have, how can I provide quality if I don't have good requirements, right? I can't. So what? I'm trying to produce is driven by the requirements.
poor management of requirements.
10 cents for every dollar spent, 10% loss based on poor requirements. Rework going back and having changes when project do not projects don't meet their original goals
again. Inaccurate requirements Management is the primary calls again and again and again, 75%
in adequate or poor communication as a primary cause what it comes down to is the requirements were poorly communicated. Okay, so you know, the numbers are all fine and all very important. But the significance of this is if your starting point is wrong, you're not gonna get to your destination.
Every single thing that we do, you know honestly, when you look at starting a project,
they're a couple of things you do first.
As a general rule, you get a project charter.
That's a document that authorizes the project senior management or your sponsor signs they commit to the project they commit to funding. You have a high level evaluation of what the project's going to do
from there. You won't identify your stakeholders.
Who are the people that are impacted by the project? How important, what sort of influence and power. And what's my strategy dealing with him?
The third thing I do is get with those stakeholders and I get their requirements. It's that important, right? Because from those requirements, I'm gonna write my scope from my scope. I'll create a work breakdown structure that details the work of the project. I'll build my schedule for my schedule. I'll build my budget
from that point in time. You know, along with that, I'll be looking at quality. I'll be looking at risks and communications and all those things. But once I've produced my scope of work,
my schedule in my budget,
I go to my sponsor and I say, Here it is this what we're gonna do for you?
Hey, that's my baseline, right? That's my plan. And that's when I'm held accountable to so early on. We've got to get those requirements down
Important skills so many times. And I met project managers all across the spectrum, very small project to hundreds of millions of dollar projects, and so many of these folks focus on the numbers, focus on
the expertise of the work, and that's so important. Yes, yes, yes.
But you cannot underestimate the importance of soft skills in project management, communication skills. Delegation, um, conflict management, pulling out engagement of your stakeholders, right. Dealing with ambiguity. That's one of the biggest problems with collecting requirements.
I want to improve customer service.
What does that mean?
All right, how will you know if you get there
if we answer 500 phone calls on Monday in 501 on Tuesday Have I improved customer service?
I don't know. You may have heard with requirements the Acronym Smart. You need smart, objective, smart requirements and smart S m A r T stands for specific,
realistic and timely,
attainable and realistic and timely
meaning my requirements not to improve customer service. But my improvement is to enable our customer users service representatives to process 4% more calls by the date of July 15th as, uh, documented by,
you know, ah, review of call logs, something like that to improve customer satisfaction as shown by a 10% increase in customer survey scores by such and such date. And again, I'm just kind of pulling some things off the top of my head. But what I'm trying to stress is you don't want these sort of nebulous requirements.
make things better. Well, uh, too broad to big, big skills again. Whether or not you wanna argue the point, the customer's always right. The point I want to stress is the customer does not always communicate well, so I need to be able to help the customers articulate what their needs are.
And I have to understand the complexity
off what they want and how it's gonna fit into their environment and all the processes within my organization that might be impacted within my project. Okay, business strategies change. The world changed. This is a fluid and dynamic time that we're in,
especially for those of you that are in the I t field, the technology field
things changed. Technology changes, the market changes, drivers change. So, being able again, tohave that agility and react to change
when we come up with, um, changes when we provide solutions to our customers again, we gotta be able to sell it. I need that customer to understand the value that I deliver. Remember, chances are pretty good. I don't do anything unique. As in, I don't provide a unique service or product.
They can probably go somewhere else
and by the service or product that I make.
I need to show them how I do it better than others. How I deliver more value. So being able to sell that by really understanding how would I do is better
wrapping up the section on requirements. And again, I know we've talked about this a little bit, but requirements are so important. Make sure you have the staff. Make sure your staff is trained properly, that they have experience in requirements, documentation that they've done this in the past and they've done it well. And if they haven't given the skills,
put them through the training,
standardization, formalization, maturity of processes, templates, good, steady, repeatable practices. Why? Because once we do it well, I want to do it well again and again and again
and make sure that we have. And again, as a project manager, I may not be responsible for the company in which I work, so I may not be able to influence the company culture, but I can certainly influence the project culture. It comes down from the top, so even if I'm more know, laissez faire
sort of organization,
one that, you know, Maybe there isn't as much buying from senior management on the process. I do. I buy into the process, and if you work with me, that's gonna be very clear. I'm gonna bring you onboard and very quickly you're gonna understand the benefit of the process. So as project managers, one of the things that we have to be concerned with that
it's probably one of our primary
responsibilities. Get good requirements, start off on the right foot.