Episode 392: Face it. Your Project Requirements are Poorly Written! (Free)

Written by Cornelius Fichtner.

For your Project Management Professional (PMP)® exam use PMP exam prep on your phone with The PM PrepCast:

Jordan Kyriakidis, CEO of QRA Corp

My goal of having these show notes on the website is to give a quick and concise introduction of the podcast topic and to tell you what you can expect to learn from it. Sometimes I am right on point and sometimes I’m a little more vague.

And tomorrow, when you are back at the office working on your project requirements your goal will be to correctly and succinctly describe the requirements for that project your company is going to launch. The big difference here is that your descriptions have to be 100% on point. You cannot afford to be vague, because requirements that can be misinterpreted is a sure-fire way to doom your project. So what can you do to improve your requirements?

The problem of poorly written, ambiguous, and inconsistent requirements is something that Jordan Kyriakidis (https://www.linkedin.com/in/jordankyriakidis/) has thought about a lot. And his answer to this problem is not only a list of “21 Top Tips for Writing an Exceptionally Clear Requirements Document” (https://qracorp.com/write-clear-requirements-document/) but also to use computing power. Yes, there is actually a software that will scan your requirements document and tell you what's wrong with it.

But we’re not going to talk about the software much, because that would be pretty boring here on an audio podcast. Instead, Jordan and I look at the root causes of poorly written requirements and then we introduce you to the most important 6 out his 21 tips. In that way you can start using your brain power to write better requirements.

Episode Transcript

Podcast Introduction

Cornelius Fichtner: Hello and welcome to Episode #392. This is the Project Management Podcast™ at www.pm-podcast.com and I’m Cornelius Fichtner. My goal here during the first ninety seconds of every podcast episode is to give you a quick and concise introduction of the podcast topic and to tell you what you can expect to learn from it. Sometimes I am right on point and sometimes I’m a little bit more vague. And tomorrow when you are back at the office working on your project requirements, your goal will be to correctly and succinctly describe the requirements for that project your company is going to launch. The big difference here is that your descriptions have to be 100% on point. You cannot afford to be vague because requirements that can be misinterpreted, well they are a sure fire way to doom your project. So what can you do to improve your project requirements? Are you PMP certified and want to earn 37 PDUs quickly and for less than $6 per hour? That’s no problem with the Agile PrepCast. It not only prepares you for your PMI-ACP Exam but also qualifies for a ton of PMP PDUs. Log on at www.AgilePrepCast.com/pdu for the details.

The problem of poorly written, ambiguous and inconsistent requirements is something that Jordan Kyriakidis has thought about a lot and his answer to this problem is not only a list of the 21 top tips for writing an exceptionally clear requirements document but also to use computing power. Yes there is actually a software that would scan your requirements document and tell you what’s wrong with it but we’re not going to talk about the software all that much because that would be pretty boring here on an audio-only podcast. Instead, Jordan and I looked at the root causes of poorly written requirements and then we introduced you to the most important six out of his 21 tips. That way, you can then start using your brain power to write better requirements. And now, following this very badly written introduction, please enjoy the interview.

Female Voice: Project Management Podcast Feature Interview. Today with Jordan Kyriakidis, CEO and co-founder of QRA Corporation.

Cornelius: Hello, Jordan and welcome to the Project Management Podcast™

Jordan: Hello, Cornelius. It’s a pleasure to be here. Thank you.

Cornelius: So we want to talk about natural language processing today but before we get into this, what is it? What is natural language processing—NLP?

Jordan: Well, it’s a very good description. You can take a very literal description. It’s any kind of processing you do with natural language and processing is the same—maybe we can work by analogy and look at financial processing. You go to a bank machine, you type in some information, you give us some data and you give us some instructions and that data is processed whether you’re paying a bill or taking money out or buying stocks. There’s lots of financial processing and of course there’s many different kinds of processing as well. Natural Language Processing is doing the thing with natural language. So is having a machine, a computer, usually but a machine in general that is fed natural language and to some extent, understands what the language is and it processes it according to instructions, either innate instructions, like what the computer is programmed to do or instructions that you also give it yourself. That would be the 10,000^th foot level we can go as deep as you want.

Cornelius: [laughs] Let me just first ask one follow-up question here.

Jordan: Sure.

Cornelius: There are thousands of listeners listening to this interview right now. Is the fact that they are listening to us talking Natural Language Processing?

Jordan: Sure, in a sense your brain is listening to natural language and it is processing it, right? Now they’re saying that “Boy, that Jordan really does know what he’s talking about” or “He’s a really sharp fellow”, right?

Cornelius: OK. OK. Let’s stick with our listeners here because it sounds like an off-topic for the Project Management Podcast™. What can they expect to learn from our conversation about NLP that is going to be valuable and important for the projects that they manage?

Jordan: Well, for one thing that I am sure your listeners already realize is that many projects are described by natural language. We have all these processes and data and algorithms but really a lot is done just by the written word. As projects start becoming more complex, it’s important to realize as early as possible when your projects have some ambiguities or you start inserting the seeds of future problems and you ought to deal with it as quickly as possible and as early in the development cycle as possible. That usually means that you do it with natural text—that’s usually one of the early stages of a project and so it’s important to really understand any risks associated with the written documentation you have for the project.

Cornelius: One area that you have specifically identified as being able to benefit from Natural Language Processing is the requirements analysis and the requirements documentation. Why specifically this area?

Jordan: We chose this area because we started looking at big complicated projects and we started asking the question of why are these projects always so out of budget and so past their schedule of completion dates. It’s very common for that to happen. And we guess some kind of general statements of all complex projects in general that people have looked at it and it turns out that about 80%--slightly over this study by Carnegie Mellon University that over 80% of all areas in a project come in the early phases and that’s either the requirements phase or the design phase. If you look at the requirements, it’s about 60-70% come actually in the requirements phase. And so if that’s where you inject the errors into the system, it seemed reasonable for us to look at the tool that can actually uncover these at the point of introduction into your system—and that is the requirements phase.

Cornelius: You have written an article, it’s titled “Twenty One Top Tips for Writing an Exceptionally Clear Requirements Document” and we now want to go through some of these—not all 21—we’d be here tomorrow still and learn how a Natural Language Process thing works here and we’re starting out with No. 6 in your article. Making sure that each requirement is testable. How do we approach this from Natural Language Processing perspectives?

Jordan: So, typically, if you’re going to write a requirement, first let me back up a little bit and talk a bit about why each requirement should be testable. It should be fairly self-evident if you’re building a –it would have to be building a machine or building a system, whatever projects you’re doing, you have to know if you are done and so the requirement has to be testable because if it’s not testable, how will successful implementation of the requirement be verified? How can you say that, “Yes, we’ve tested this requirement, or we verified that it actually works”. In Natural Language Processing, the way we look at that would be to look at how specific the requirement is and there are typically a set of words that when they’re present in the requirement, is a signal that someone has taken the easy way out and has not really thought of what they mean.

Cornelius: Example of such a word?

Jordan: Sure. A typical word is “efficiently”. This thing should happen efficiently. So what does that actually mean, efficiently? Usually you want to be able to quantify it whenever possible because after all, something could be efficient to one person but horribly inefficient to another person. That’s an example of the kinds of Natural Language requirements can catch.

Cornelius: OK. Tip #7 that you have, Writing functional requirements to be implementation-neutral. How do you approach this one?

Jordan: It’s important for a requirement in particular, a functional requirement to be implementation-neutral because a requirements document is not a design document. A requirements document should be outcome-specific so what I mean by implementation-neutral, what I mean is that, a functional requirement, it really should not restrict the design engineer to any particular implementation. It should be free of the design details. You want this system to work—not work in a particular way—but it should accomplish a particular task. In other words, you should state what the system must do and not how it must do it.

Cornelius: And so from a Natural Language Processing perspective, we would look at this and make sure that we’re only talking about the what and not the how then. Is that correct?