Welcome to week four and module five, and in this module, we're going to be covering how to scope of project.

And scoping. I can tell you this from experience and learning the hard way is extremely important. As a rule of thumb, you'll want to spend as much time on this phase of the project, as all other pre development phases combined. Really, this is critical this is a step that I would overlook and just honestly be lazy with, and it ended up biting me every single time cost me a ton of money and a ton of time. This might seem excessive, but it is what will avoid project nightmares scope creep miscommunication and just honestly avoiding major problems and costs down the line. This has happened where I didn't explain all the details properly developer built it in the way that I described, turned out I was incorrect I didn't spend enough time properly doing this and it ended up costing me a whole lot more. So, this is critical, and the consequences of course, you can lose time, you can lose money. At best it can lead to spending a little bit more money or taking a little bit longer to deliver the site. But really, it's usually worst case scenario with me, of this, it's resulted in receiving a product website that is quite a bit different from what I was hoping for and what the client needed. And at the end of the day it resulted in lost money, and really the hard part of it was last time when clients are judged for their new site. And when I've dropped the ball that is not a fun position to be in and really scoping out projects properly avoids so much of this.

So, when scoping out your project, you want to think about your audience, you want to think about your customer, your project might make sense in your head, since you have the experience and customer avatar and the details of what the client needs, but to your developers, this might be an entirely new business problem that they've never quite solved before. And the best way to optimize the money you spend on development is by first defining the project in a way that makes sense to the development team so really what it is is taking what you're trying to develop out especially with when it comes to like lead generation or anything unique with E commerce lead magnets anything that might be that's a little outside of the box of a traditional contact form or E commerce site you really want to spend the time to make it crystal clear that your developers understand exactly what they're getting into with as much details as possible so you know exactly how much it's going to cost you, you have a much better idea of how long it will take, and it just doing this work upfront really solves a lot of potential problems in the future.

So in this module, we're going to go over the key concepts into scoping, number one, describing your project this is obviously most important. This includes different modules features user stories how to kind of write out in plain language, what you want users to do, thinking about your customer Avatar the ideal client and their story of their experience on the website, deciding whether you viable product, and learning to scope one, and this is a lot for if you are bringing on like startup clients really getting something that's an MVP, so that you can, it's more cost efficient and time efficient, and really it's great for proof of concept. And then finalizing your scope which includes timeline considerations, defining milestones to wrap up your scope and choosing a technology technologies to build your product, your site.

So let's jump in and look at each one of these in a little more depth. So the first step, and the most important step is describing your project. So you want to outline modules features and user stories, it's kind of the most important part of scoping a project by describing your project in a clear way you can help your dev team understand exactly what you need to build for your client to define modules features and user stories.

We're going to use an example of a social media Wordpress site. So in this example, a module might be a particular page on the site, for example, a login page of my account page, and a news feed could be examples of different modules. And within each module there are different features, sometimes there's a lot sometimes there's not. So features are more digestible set of specific functionality that you want so for example on the login screen module, you'll probably want a login feature a register feature and a forgot password feature so what happens when you click Forgot Password does it send an email, how does that logic work right and you can see that this goes on and on. These are the details that are critical to your development team that you want to think through

for user stories, we define specific discrete tasks that end users should be able to do a good user story has three components the user, the task and the reason you should have a user story for every part of your site to outline the desired functionality in user flow. For example, let's use the template as a blank type of user I want to task so that reason, in the social media example, a good user story might be as a customer I want to post images so that others may view them. This template is powerful, not only because it defines the expected outcome of an action, and also gives a business or end user justification, which is great for the development team to kind of understand the ends to the mean.

Right and so why does all this matter. Well, the goal of defining your modules features and user stories is to provide your developers and quality assurance engineers with a full picture of what your site should accomplish if you only give vague descriptions of functionality. A lot of assumptions are going to be made, and you might end up with a site or product coming back to you that isn't what you wanted or what the client is expecting, which is a very dangerous position to be in. It's essential to be thorough, don't leave any room for interpretation in describing your project. In fact, over communicate, get as granular as possible, especially on bigger projects, some development teams might build the minimum solution that satisfies all the requirements that you gave them, but if the requirements aren't very well defined, it's pretty much guaranteed that the deliver product will not meet your needs, and we want to avoid that as much as possible.

So now let's talk about if you are going to work with startup, someone that has an idea and they want to use you to bring it to life. We're going to talk about the minimum viable product MVP. And so you want to consider with these clients or prospects, whether they should build an MVP out or really go full bore with it. And so if they're an early stage startup that they're trying to take their idea from concept to real world, you might want to consider scoping out what's called a minimal viable product right MVP instead of everything, obviously building out a full website and fully functioning and everything is better for your bottom line, but it might not be better in terms of the client's needs. So, obviously a full website has all the features and integrations that the client wants all the designs have details, and this is really a big finished version of the idea, one that you and the client can be proud of. And obviously this takes a lot more time and money. If you build this out and it might be exactly what your client wants or needs, but it's really up to you. But if you first build a lighter, less expensive MVP, the client can quickly validate their idea and see if they've achieved it product market fit for a fraction of the cost of a full product. And if that goes well. Obviously they know who they're going to be using to build up a full project. So this is great for prospects clients that may think that they want to go all in on a project. And sometimes that I come in and say hey let's let's prove this out first, and then we can make the full investment into the full project so the basic scope content for an MVP includes a short project summary for a project tech stack. In this case WordPress PHP kind of really whatever you need for the functionality to find user roles and modules features and user stories for the core features right and so you really want to focus on a hypothesis, and the main intent of your MVP is to prove a concept or a hypothesis for the client, don't want to worry about scalability and growing pains. You really want to get something out there to see if this is a good fit for the market. The primary focus of the MVP should be to build a product that is as simple and cost efficient as possible in order to really prove it out in the target market, I've had clients that I had a client specifically an E commerce client that I pushed for an MVP, over and over and over. I knew I would make a lot more money building the full thing out. I just, it didn't seem like the right thing to do and so I gave the client my opinion based on my experience. I wanted to break it down into it let's prove this out concept by concept. He didn't want to do that he thought he had a homerun idea you'll find this a lot, email will get in the way. So we ended up building a full thing we spent four to six months out I built it out and it was a dud it flopped. They were out of business with, in wanna say, six months, so don't be afraid of giving your opinion, and doing the right thing or what you think is the best thing for your client. And especially with an MVP, this will come up, if you work with startups, they think that a lot of times they think that they have a great idea, and it's the best ever. And then when you bring it out to the real world. In the case. So really, you just want to build something that's simple and cost efficient. In order to prove the concept, so that you is happy. They have exactly what they need in order to keep investing in their idea. So when it comes to MVP you really want to be brutal when it comes to prioritizing features. What's must have. What's nice to have, what can we. And so that's really the MVP portion of it. We won't deal with this too much, but it's great to have in your back pocket, if it does come up.

And so last but not least, is finalizing your scope. So the final step for scoping your project is really defining your timeline milestones and technology stack that's more so if you're doing custom projects. For us, it's really the theme that we want to go at and how I want the admin editor to be structured because it needs to be easily editable by the client and the majority of my clients are not necessarily tech savvy, and, again, when all comes back to trust when they log in for the first time, they can kind of start to figure out a way around it, they'll be much happier. So, these are the last few remaining variables that you want to nail down before you're ready to start your project.

After scoping your dev team should sit back proposal, and in this proposal, want to make sure that there's a proper timeline for delivering the project, you need to find the right balance associate delivering the project quickly and having enough time to address any unforeseen issues, which basically happens every single one of my website, just the nature of it happens so you want to be very vigilant. If there's any discrepancies in your timeline, or you're not technical and just not sure about the justification behind the timeline that the development team gives you simply just ask the reasoning get more details on it so that you have a way to communicate clearly, right, it's extremely important to make sure that you're not pushing for unreasonable.
Or you might shoot yourself in the foot by putting too much pressure on your development team to deliver a short timeline, which meant for everyone cut ends up just hurting you in the long run. In the world of software development, there's a thing called the 9090 rule that states that the first 90% of your code will take 90% of development time in the last 10% of your code will take an additional 90% development. So it's a little tongue in cheek, but the gist is that getting a project from almost onto done can take as much time as it took from not started to almost done, because the complexity of the code has increased over time.
A lot of us will find it too often but it can, it just depends on the complexity of what you're building out and it's pretty straightforward. You won't run into some of these issues, but things change. There's a lot of moving parts and especially the scope. If people aren't on the same page, you can run into these challenges

And this is really why you always want to break down your scope into several different milestones and different items that are grouped into milestones by functionality and position over time. This allows you, the client to sign civically approved or rejected, individual milestones as complete were included. Now when I say you as a client, your development team that you're outsourcing to you are there. Right and so multiple roles so you are kind of what I talked about before. Quality control that making sure whatever leads, he forgets the table that you're signing off.
If you define that milestone sequentially, you can get a ground rule with your development team to break down your costs and project structure by miles. If they haven't done so already, so if you're following a milestone structure. This helps to protect you from having to pay for unfinished or incorrect, and to help plan your budget, you should always ask, estimated delivery date for each milestone in software development, unexpected delays can always arise they usually do, but at least you have a baseline budget. I've definitely been caught not defining myself clear enough. And then at the end day, it's coming out of my pocket and because that, ultimately, the more time you spend with this, the better off you're going to be. It just makes the project that much smoother.

So, final step of scope is choosing your technology stack so this really depends on if you're doing custom work or custom stuff, don't really want to say get into that, but when it comes to WordPress, really you want to choose your theme, and how you want your admin editor to be controlled. So, for me specifically in my agency, I always choose a theme that is literally just bare bones that doesn't need updating and gets WordPress, out of the way as much as possible. I don't like to use page builders I don't like to use pre built themes and the reason why is there's so much bloat you have page load speed issues. You've got editor issues. And you've also got security issues and stuff you've got to always be updating. Like to drip all of that away. Turn my design into front end code front end code into WordPress using this stripped down theme, and we use underscores.me for these barebone themes. And this helps everything load faster, ie CF Pro. This is worth its weight in gold. It is basically a templating plugin that allows you to make the WordPress editor super easy to use and will be gone I'll be showing you this with the website training coming up in future modules but that's fun for me is pretty much those same two things in terms of the theme we're going to use, I always say underscores and then how we want that admin structured and I'll be showing you this in future modules

but that's really how you scope out a project so after you've decided on the scope of your project, you're pretty much ready to get started with development before you jump right into it. There's a few final steps of planning, you're going to want to perform so. So at the end of the day you want to make sure that you and your development team agree upon the scope and also your client and just making sure that both sides of the project, agree to the scope that is detailed out and that's going to save you a lot of pain down the road so at the end of the day spend as much time as possible, doing the prep work for this before you start writing any code before you start designing anything. This will help you out in the long run.

I'll see you in that next module.