Okay, let's take a look at what we mean by smart requirements. So what we want to avoid is a situation in which we use project managers feel like we've met the requirements as the customer has communicated them. And yet the customer still not satisfied with the software, the program that we've developed for them.
So the way that we do that
as we make sure that with our requirements, we get rid of any sort of wiggle room, so to speak. So we want requirements that are specific, measurable, achievable, realistic, in timely
and what we mean by each of those when we talk about specific goals, we want them is not to be generic, sort of thes, nebulous, very they goals that would fit in any environment. We want to make sure that we've nailed them down, and we don't have any possibility for misinterpretation. So what I have here is a week requirement.
All sales data, all important sales status should be included on the monthly report.
Well, the problem with that is when we use words like all always never, you know, sort of those all inclusive sort of adjectives. The problem with that is Well, what happens if
what's important today isn't the same is what's important tomorrow. And, um, I could include all sales information. That would be way too much to include,
you know, when we use words like important that air really subjective again, what if what's important to the customers different than what's important to me?
So what a strong requirement would be is actually listing out the specific fields that are gonna be included on the monthly report.
There won't be, you know, 50 specific fields, but they need to be named out. We need this to be specific as possible, and we want to make sure that the customer and I are on the same page when it comes to what's gonna be included on the reports.
What we need is we need requirements that I know have been met. I need a way to test and say, Am I on track? I need a way to monitor and make sure that we're gonna provide exactly what the customer wants. So when we talk about the idea of critical success factors, what must be achieved,
any sort of requirement that's not measurable, be very very wary of. So, for example, a week requirement. The application will improve customer service.
What does that mean? How do we know if we've gotten? How do I know if I'm on track? How does the customers say? Yep, You've improved customer service enough or not enough. So much better requirement. The application will improve customer satisfaction as measured by a 2% decrease in hold times
and an improvement. Customer service feedback scores no less than 5%.
So I can know that I've achieved those goals or that I haven't. And there shouldn't be any room for misunderstanding
attainable. You may also hear these refer to his achievable, actionable or appropriate in any of those air Fine, but the idea is that we have to physically be able to meet this requirement.
So, for instance, what might be now this the first sounds like a fine requirements. The completion of printing and the shipping of books will take place on the first day of each month.
In and of itself. That doesn't necessarily sound like a bad requirement, However, there may be additional information that says after books were printed, there's a two day verification process before the books are shipped, you know where we proof read and make sure the printing process worked well. For instance, so what we would do to make that a
The completion of printing will be completed on the first of the month.
The shipping must be completed no later than the fifth day of the month. So I make that achievable by allowing for that time between the two and notice how I've also split out the requirements. One requirement for printing a separate requirement for shipping. We want to be careful and lumping too many requirements together
because a lot of times those dependencies there may be problems with the dependencies.
All right, the next one realistic. Can I accomplish this win? Considering the other constraints off the project.
Ah, week requirement customer may request that all work be completed by April 15.
Now that in and of itself is not a week requirement.
However, when I look at the constraints and the risks associated with the project, I may realize that there's no way we can complete this. This just isn't realistic.
So what I want to do is maybe I can negotiate the in date with the customer.
Maybe I can ask the customer for more. Resource is. Or maybe I can document some assumptions that are made in order or some requirements so that we can make that April 15th deadline. So, for instance, the strong requirement work will be completed by April 15th. Assuming that
our budget is approved has submitted,
resource is will be available that we've documented. Project team members will not be getting pulled off the project to complete other work. So I'm going through and I'm specifying, Yes, I can meet your of April 15th deadline, but the's elements must be in place,
all right, And then the last of the smart requirements. Time bound, timely.
So avoid phrases like as soon as we can soon as possible. Ah, and try to work with completion dates. Even if the dates are more vague, you know, more vague than first. Maybe by the end of the third quarter, something like that. But try to stay away from things as soon as possible.
My expectation for what, as soon as possible
versus your expectation again, can be different. So let's bind those requirements to time. So once again, you're smart requirements specific, measurable, attainable, realistic and timely thes make for the foundation for good requirements