Episode transcript The transcript is generated automatically by Podscribe, Sonix, Otter and other electronic transcription services.
Ricardo (4s): Hello, everyone. Welcome to the five minutes. Yes. Today. I'd like to go back to It topic that I recorded several podcasts in the past, but recently I was challenging a lot, the concept of memorizing names and memorizing what is a document for. So I decided to record this podcast because I received this request and a request saying, look, people are confused about what a Scope statement is, what a statement of works, and what is a requirement document. So first, even before I explain the three of them is that don't be overly concerned about naming and what is the name?
Ricardo (44s): Should we be we called Scope Statement, Work Statement look, this is less relevant, unless if you're preparing for a certification and something like that. But let me tell you what is the meaning of each of them. And let me tell you, these Understanding are extremely valuable. Also, if you were working in, in agile, using an agile methodology. So let me explain a little bit more about what a Scope Statement is. A Scope Statement is basically a description of what do you plan to do with your project. So it's a basic description of the journey and maybe some of you will tell me Ricardo in agile we don't go into this detail.
Ricardo (1m 28s): And then my answer is that you don't need to, you don't need to. Who sat that this scope statement should mention every single step of every single moment of your product development, for example, no, it's not in the case and whatever you call this is that at some point you need to explain what is your basic assumption on your journey from point A to point B in an agile environment, this journey could be a little bit more open, but look, you cannot just change completely your project because otherwise, you will lose. It's like, for example, I want to go to Mars and at the end, you end up going to the moon.
Ricardo (2m 9s): So it's a very different approach. So I'm talking that the basic concepts for you to drive your project should be on this Scope Statement and this does not need to be policed, does not need to be a formal document written in Microsoft word. No, you can do this using mural. You can do this using post-it notes, whatever drawing, but it's a basic explanation of the journey you're taking from A to B and you can do it in a more detailed way, for example, if you are working in waterfall in a very capital intensive project, sometimes you need to have a very strong, detailed information to move on.
Ricardo (2m 50s): So this is you produce in this case, more robust and more detailed scope statement. but sometimes you're just planning a new software or a new release. So you have a more, not generic, but a more open Scope Statement. The second document is the statement of work. Okay. It looks similar, but it's not Statement of Work is usually a procurement document. It's a document that you use in a tender. For example, I want to hire someone to do some work for me. Then I put these in a Statement of work or in the terms of reference because with that, it's clear for this supplier, what is expected from her or from him on that specific job, for example, if you are a government, this is a very relevant part of any public beat.
Ricardo (3m 42s): Again, these will be related to the type of procurement you are planning to do on the type of contract. For example, most of the time when you are in an agile environment, it's very hard for you to use a fixed firm price with your supplier because you know, how are you can and fixed the price for a Scope that is not fixed so most of the time, what do you, do you create a more generic statement of work that is shown expectations of skills, of knowledge of products. And then you work in a time material, for example. So yeah, if you pay by the hour or you pay by product, so it's a more open kind of agreement that will allow in combined with fluctuations.
Ricardo (4m 26s): of your Scope. However, if you have a fixed firm price and you need to have a sharp price, you need to detail the Work or otherwise, you will open very relevant risks of having a claim in your project. And this may be, if you work in a small project, this is nothing, but if you work in a very large project, this can be a real nightmare. There is an industry of claims in large scale projects, and they are due to the lack of clarity in the statement of work. And the third is the requirement document. So every time you go on the Scope do you need to put in the requirement is a combination between the scope and quality Requirements tells you the limits of what you expect from that work.
Ricardo (5m 18s): For example, Requirements is the software must be moved to a platform or not. And you create a requirement that this software should allow access on this time for up to 3 million people at the same time, for example. So it must have this performance. So you are creating a requirement and these requirements, they can be more functional and they can be more technical. I recorded podcasts about that in the past, but you need to understand some of the requirements are related to the customer that you were expecting So you can say, Oh, my car should have electrical windows. Okay? And then you need to create a technical specification for that because someone needs to put a motor there that is able to move the window up or down.
Ricardo (6m 8s): So this is more technical. So this is exactly what we are calling the requirement document. So the requirements document, it's something that gives some boundaries to the scope of your project and they will become if needed part of a statement of work. If you want to procure something or part of your own scope, or for example, Part of your next scrum or part of your next, MBP. So it's exactly, and the why I'm telling a lot on agile here is that people should not be so strict saying, Oh, these terms were created in a waterfall environment. So it does only Work in that environment.
Ricardo (6m 49s): No. Or if you go back to the concept is the reason why they exist. then, you can open your mind and understand that to solve a problem. It's not only one competence. You need, you need a set of competencies and understanding how to navigate. What you need to do is a key success for a factor of your project. Remember, you can do this in a spreadsheet, in a PowerPoint slide, or you can do it in the wall, like in agile you can do and draw that most of the use stories and these are requirement documents are things that you are creating. To understand what are the requirements. So don't be trapped by just understanding that names contain all the explanation.
Ricardo (7m 33s): So behind the name, there is a lot of concepts that you need to understand that could be applied in absolutely any kind of approach to deliver your product. Okay. I hope you'll find this useful and see you next week with another five minutes. Podcast.
