Good project requirements are like GPS for project success: They show a clear path to done, with each critical step laid out. In this class, you’ll learn how to gather and document project requirements, align your team and stakeholders, track and manage change, and confirm project requirements have all been met.
Brett Harned: Hi, and welcome back to the Art and Science of Leading Projects. Today I'm going to talk to you about project requirements. It's a term that hunts me still because of a bad experience I had with really poorly written and poorly tracked requirements. They're a part of a project I inherited very early in my career. Spearing the details, but basically they were half written, the project was about 90% complete, and the stakeholders started asking where some things were and why what was there was not working as they had expected. I had to jump in and figure it out.
So I resurrected the requirements document, discussed them with the stakeholders and recorded a whole new set of priorities. We use that to discuss an increase in scope and timing. But just taking that step back saved me a lot of stress and confusion. My situation isn't uncommon. Very often projects fail due to poorly managed requirements or even a lack of requirements. I'm not sure if that's because people are scared to ask questions of one another on projects or if they just don't think to do it. I do know that if your project is complex, or if it changes often, or even if your team and stakeholders are not great communicators, working without requirements will definitely be painful.
Okay, if you're new to this, you might be wondering what requirements actually are. So thanks for hanging on and let me explain. A requirement is a document or a statement that defines what must be achieved or created on a project. They're often also referred to as use cases, features or even functional requirements. It essentially defines an overall goal of what a product must do. What it should look like. And how it should function. I've mostly seen requirements defined as detailed text in a spreadsheet, or as annotations on a design or schematic.
But you might decide to look at them in a different way. Essentially, the goal is to make sure you're able to communicate the information a team needs to design, build and test a product or even just a piece of it. Requirements are also great for setting expectations with clients or stakeholders to make sure they're clear on what they're going to get. In that respect, it makes it easy to decide if something is complete or not. Plus, if a stakeholder decided to add a feature or request and change the project, you can refer to your scope and requirements to make a decision about priority, or if scope increases are needed.
Requirements in whatever form they take are really essential to building a product or service. Because they help set expectations and align teams and stakeholders. Without them, there's a strong chance that you could produce an incomplete or a defective product, or worse, one that your stakeholders won't accept at all. So while they take some time to produce, it'll be well worth your time spent gathering and managing them.
That said, not all teams document and manage requirements, and that's okay. As long as you're comfortable with managing the details on your project without having them documented. After all, not all projects are complex, and not all project leaders feel the need to document and manage requirements. If your team is agile, and your projects are fairly loose, you'll be fine without documented requirements. Chances are you're using stories or epics, and those are pretty much the same thing as requirements. But if you're dealing with complex projects with large scopes and budgets along with tight deadlines, you might want to think about how requirements can help you.
All right, are you sold on the need for requirements yet? Let's talk about how you can document and manage requirements in four steps. Gathering and documenting. Alignment. Tracking and managing change. And confirming. Let's dig in. The first step is gathering and documenting requirements. That's a fancy way of saying how the heck are we going to figure out exactly what we're supposed to be doing here? But before I get into the process of gathering and documenting, I think it's important to talk about what a good requirement looks like.
First and foremost, a good requirement should be valuable and actionable. That means that while it should define the goal or need, it should also detail how you'll meet that goal. Also, it should be written in plain language so everyone involved can actually understand what it means. Like I said earlier, formatting language may vary by team. They can be sketches of what's intended, they can be structured in statements that say what it should do, they can also be high level requirements that state an overall goal and have sub-requirements with hyper specific detail that rolls up to them.
You'll probably start high level then dig deeper as you get into the work. That's a good way of approaching requirements, because what you know about the project will evolve over time as the team works through each goal. You'll get to a level of detail that will help your team to execute on each requirement accurately. At a high level, it's important to remember that good requirements need to be concise, and specific, and simply explain what's needed.
Okay, now let's talk about how to figure out what those requirements actually are. Well, it's got to start with a statement about the project goals and what exactly the business and the stakeholders expect the final product to do. So you have to get some pretty high level info first and start digging. Sounds easy, but it can be a little bit like pulling teeth. It's important to remember that not all stakeholders think like you do in terms of features, functionality and time to build. In fact, it could be a big black box for them. So this is your chance to connect their business goals and requirements to your project.
The best way to understand what your stakeholders actually want is to ask questions. If you watched class three on estimating, you know that I'm not afraid of asking a bunch of questions to make sure I can be as accurate as possible. You shouldn't be afraid of asking questions either, especially if it'll help you to gain clarity with your requirements. Here's the thing, you can't necessarily take a cookie-cutter approach to every project. Sure, you may have some core questions to use, but before you dump a set of questions on your stakeholders, be sure you understand what you're asking and why.
It may be helpful to ask yourself some questions about what exists already in terms of supporting documentation and your stakeholders. If you're not sure you're thinking about this in the right way, check out the pre-requirements question download as well as the sample requirements checklist, which is a real template I've used on web design projects in the past. My hope is that those documents will give you an example of how you might start to organize your thoughts and draw out the needs of any project. It's really about being thorough. The answers to your questions will eventually turn into expected interactions, features or functionalities that will help you to begin your requirements documentation. So set yourself up for future iterations of your document by formatting these responses in a readable, sharable format.
This will set the expectation of what goals the project will meet, and how what you will deliver will map back to those goals. The best way to document these requirements is in a spreadsheet, or a list that works for your team. Essentially, what you must document are the requirement name and number, which is a unique name that describes what is being discussed and can be easily referred to. You'll want to number these in case you have a lot of them, so you can easily find them in your document. Second is a requirement description, which is a simple statement that defines the business need the requirement fulfills. Then there's the category, which is a group identifier for similar requirements that all project resources will understand.
This could be the section in your site map, a part of your product, a technology, or whatever other category that makes sense to you and your team. Last is notes, which the place to capture questions, yours or your stakeholders', that will surface as a requirement evolves. As soon as you've documented the high level business requirements, you're ready to compile the questions you need to ask to get into the true details. Start broad with a top level question about functionality, and use the response to dig deeper.
Here's an example with follow-up questions that could arise. Will your site require users to log in? Does registration require payment? Will the site display a logged-in user's name? First and last name, or just the username? Where is login information stored currently? Will it stay there? Do logged-in users have access to information or functionality that non-logged-in users have? What happens if someone forgets a password? Do you have error states currently designed into the system?
As you can see, there are several questions that could come out of one single response. And each response could add requirements to your work, that means that one simple yes or no answer could have scope or budget implications attached to it. Therefore, the exercise is really important in understanding what your team can do within your scope. That's why a requirements checklist, similar to the example download, can be really helpful. As soon as you've determined all answers related to a piece of functionality, add it to your requirements doc. Arguably, this step in the process will take a lot of time, but again it can be worth that time spent if it helps you to avoid issues with scope creep and even communications.
All right, let's move on to step two, alignment. This is the step that feels like it could take an hour, but can last weeks if you don't handle it well. There's no playbook for how to gain alignment on requirements, because it really depends on the size and intensity of your project, and how you engage with your stakeholders. My suggestion is to gain consensus on high level goals and requirements, and leave the detail to the team. But that requires a level of trust between the stakeholder team and the project team. If your stakeholders want to be in the weeds, plan for some additional time to discuss, document and revise your requirements.
But mostly, what you want here is buy-in on approach, your overall approach in what's included. This is going to help you to better plan your project, control your scope, and say, "Sorry, we can't add that new request without looking at the requirements and scope to see where it fits." That sounds pretty powerful to me.
So let's move on to step three, which is tracking and managing. Okay. This isn't really a step as much as a reminder to stay updated. Projects get busy, and we forget about this kind of stuff. But if you're not keeping all of your documentation up to date, there's really a good chance that you'll forget a detail, and it'll come back to get you. We all know that projects change, that doesn't always mean it changed your requirements, but keep it in mind when new requests pop up. So make the time to get all of your administrative work in while you're doing everything else on projects. When you think about it, the really cool part about requirements is that when you manage them through a project, you get to see something that started as an idea, a discussion about goals, and then that being formalized into writing and taking it to something that's designed, built, tested, and functioning in the world just the way it was intended to be.
If you truly want to do a good job with that, you'll take copious notes and update them in your requirements documentation. That brings me back to format. There are a lot of great ticketing systems out there that can help you to manage your requirements. You can also use TeamGantt to help communicate requirements and even record changes over time. So you have to know that things are going to change with projects. And you have to expect it and adapt to it. One more time, you have to document those changes.
All right, the last step is confirming. If you nailed your requirements and kept them updated, chances are you'll nail QA and then release. That's because when you take ideas and get specific about them, you leave less room for error or even misinterpretation. That makes the quality assurance process easy too. So there are a few different ways you can close or complete requirements. The process for it will depend on how you like to work. First, like I mentioned earlier, you can use TeamGantt to document and track requirements. In fact, our development team at TeamGantt uses notes and discussions to track requirements through their sprint process. I recruited one of TeamGantt's founders, John Corelli, to walk through how it's done. Check it out.
John Corelli: How you handle technical requirements is crucial to how efficient your team performs. Too little information and they'll spend their time trying to gather the missing requirements. Too verbose, and your team will have to sort through the details to pull out the information that's important to them. Each team is different, and it's up to you to find the sweet spot for you and your team. Today, I'll show you two examples of how we're managing requirements within the dev team here at TeamGantt. The first will cover new features, and the second will be for a bug fix. However, before we jump into these specific tasks, I'd like to say we have a pretty simple and straightforward approach. Requirements go in the notes section on a task, and any additional discussion revolving around the task goes into the discussion area below.
We're also leveraging Markdown anywhere we can to increase the readability. We'll use our Slack integration for this first example. In this task, we're adding the ability to list your active projects regardless of where you are in Slack. When it comes to requirements, I like to cover what is happening, then drill into how. As you can see here, we want to allow the user to type in a command, and list their projects. We also want them to be able to add a search term and narrow the project list. Once we've established what is going to happen, we'll talk about how to get there.
In this case, we want the user to enter the command /tg projects with an optional search term. We want this response to be private so that only the user making the request sees the response. We want to make sure only active projects are returned. If a project is starred, we want to make sure it's indicated. Finally, we cover how to make the request. As for bugs, we handle them a little bit differently. Here's an issue Aaron reported from a while back.
Within our bugs' project, he created a task called plus sign not working when project is open. With the notes field the steps to reproduce the issue were added along with the expected and actual results. Aaron also provided a screenshot with additional information. It's always helpful when you can get a screenshot or screen capture with your bug tickets. In this specific case, our steps to reproduce are very simple. Open any project, ensure the sidebar is expanded, and click the plus button next to the active projects heading. We're expected to be taken to the create project screen. However, as you can see, nothing actually happened.
We were quick to jump on this, and had it fixed out a few hours later. Once it was live, we used the discussion area and let Aaron know. That's pretty much it. Managing your technical requirements doesn't have to be hard. Like most people, we found it best to break things down into small chunks, but without overdoing it. I hope this helps you as you take your projects from an idea to a success.
Brett Harned: So, while using TeamGantt is a great solution, as with anything else, there are many ways to track requirements. I tend to like to use ticketing systems during the QA process so I can track those requirements in work being done against through an acceptance and an eventually launch. The process around that would generally be that I would initiate a ticket, that would get passed down the line during the project process, and it would end with QA to test. If QA finds an issue, they record it, and assign the ticket back to me. If they don't, they mark it as complete, and assign it back to me. As the lead, I close the tickets to ensure completeness.
I've also used spreadsheets to track the completion, and essentially would move a row to another tab, or just color code requirements when they're complete. You can handle this anyway you like, really. The point is just that you have to track what is complete before you release your product. In fact, there are plenty ways of handling requirements. We asked our PM experts for some tips on documenting requirements. Let's hear what they had to say.
Aaron Irizarry: Documentation is crazy important. We live by the rule in my teams, that if we haven't documented it, it doesn't exist. I think documentation is very crucial for teams. I don't think we have to document every single little thing we do, but I think meeting notes are key, open questions to the group are always key to document. Then obviously some of the larger things like timelines, artifacts, things that we're doing. I'm not necessarily set on any one tool, but as long as there is one that everyone uses, and understands, so there's a shared place, a common place for everyone to go to to be able to see and dig, and find any bit of information they may be missing as they go through the projects, I think that helps a project just run so much smoother as opposed to having to send out another email, Slack another person to try to figure out where that one document is or that one screen is, or that one meeting summary is.
If we have it in that one kind of shared common place, then I find it makes the process so much easier. And our teams feel more well-equipped. They can go into their meetings feeling confident [inaudible 00:17:26] they have all the information that they need.
Carson Pierce: I think the first thing we think about when it comes to gathering requirements is like the tools or the techniques we use, I really don't think that matters at all, what those are. I think the most important thing is that you're doing it in a sort of open environment, you're doing it in conjunction with the client, or your stakeholders, and that's a collaborative thing, you're doing it together. Then, it's not just something that happens at the beginning of a project, but rather something that lives throughout the course of the project. If it has to change, you change it openly with your client and you make those as needed as you go through the project.
Meghan McInerny: Again, I think thinking about the audience that you're communicating those requirements to, so the way that a developer needs to internalize and understand requirements may be different than the way your client needs to internalize and understand those requirements. So really thinking about what are the ways in which you are creating a shared understanding of something, but also being aware of the different needs of the audiences that you're trying to serve with those requirements. I think often we write requirements in a way that makes sense to us, and our clients don't clearly understand them. Then that means they don't really understand what it is that they're buying.
So really making sure that you're tailoring what you're communicating so that everybody agrees. "Yep, this is what we're building. This is how we know we're successful."
Rachel Gertz: I think it's really helpful to actually [inaudible 00:18:52] workshop it, so don't just talk about what you have to do, and then write it down, but work through it together. Use that time to visualize what you're trying to make, try to use that to maybe develop early flows or ideas. You can start tracking again the pieces that you might miss, sometimes you can do that by working backwards from a launch idea. So if you're going to launch a version or an iteration of the product, think about what needs to happen in reverse and you can actually come up with some interesting new ways of solving it. I also would recommend that teams use [inaudible 00:19:26] confidence when they are setting up their requirements.
So what that means is that we would sit down and try to find out what the minimums to the maximums in terms of complexity and effort would be, and that'll help us actually frame the project in a way where we're really comfortable with what we're creating in terms of outputs.
Shahina Patel: I'm a real fan of writing down direct quotes, because sometimes they're able to capture what somebody means without trying to wrap it up in some kind of technical jargon. Another tip I have is to document everything and take care of future you, that's something I learned from a friend of mine, Katie, back in the UK. Taking care of future you means writing things down and not relying on, "Oh yeah, we'll remember what we meant by that. That's fine." You probably won't. Just write it down, and that's my tips for documenting requirements.
Tera Simon: When documenting project requirements, make sure you're constantly asking the question why? How? Where? When? Asking those questions will ensure that you know exactly what needs to go into the requirements. When you're also putting together requirements, make sure that you're covering all different avenues that are important. It's not just understanding the technical side of how things need to go. But it's also understanding the business rules and requirements around that, and understanding how it's going to impact the end user. Also, getting in feedback from your QA team, and making sure that they've validated how you can through and do acceptance criteria and tracking all that information is extremely important. We use different tools in order to make sure everything is documented, so that you have clear access for everyone that's a part of your team. Whether you're all working in the same office, or you're working remotely.
Making your documentation easy access for everyone where they also have the ability to continue to edit as requirements change, make sure that you're not missing anything.
Brett Harned: That brings us to the end of the class. I hope it inspires you to take a look at the downloads and think about your own requirements practice and process. There's more than one way of doing this, and it's up to you to find the right way. So come back for class five, which will be all about project planning.