Hey everyone. In this video, we're going to be discussing the guidelines for project planning. We're going to keep it at a very high level because there are a wide range of concepts. But I'm going to touch on a little bit in terms of software applications, hybrid models, physical projects, and how I've learned to adjust and calibrate for planning projects along the way. Again, from my perspective, I own companies, but I have brilliant people who do the work for me. My version of starting early may not be as compatible with other people's and might be like, "Why did you leave this last minute?" "Last minute, this was golden for me." I need to improve on that. Start the project early. This can be a little bit tricky when you're starting a company and you know which project as part of the overall program that you're developing needs to start early or how far you need to go with it. That's one of the reasons why when I work with a startup and we're launching a product or service and we're working on the initial prototyping phases, we look at what the initial parts and framework for the logistics, supply chain, operations, management, cash flow, all of that, how that ties in to the very beginning. That way we're ready to scale up and in an integrated way when we need to do it quickly with a quick turnaround. Because if you start the project too early, conditions change rapidly in this day and age, you never know what's going to happen and how user needs are going to change, where funding is going to come from, how new opportunities in the market may arise if your technology is going to obsolesce. Starting things too early can be a bit of a waste of time when you can be working on things that would be generating cash flow. Ultimately, as an entrepreneur, I don't like calling myself an entrepreneur, I like starting companies and doing stuff. That's what I find fun and it happens to pay well. But from an entrepreneurial perspective, if we put in way too much effort upfront into a product or service without establishing the potential customer base who's happy to pay for it, where and you build out all this stuff before getting that cash flow going. I'm like, why would I put that much effort in upfront if it's not a sure thing? Because I like to diversify my risk and work on several different projects and then say, ''this is where the money is going to be coming from." I've got my infrastructure, the groundwork already established wall. I've been working on the initial wireframes and low fidelity prototype of this particular concept. That way you're diversifying the risk. Start the project early and know what determines early in regards to what you're working on. Some people might say, "early means months." For me, early may mean a week. Because depending on the probability of something coming to fruition might be, well, a weekend ahead of time. It's not a sure thing, it's how much effort am I going to put in with a very high likelihood of it happening. Manage a project scope. Keeping brilliant people on track in project scope can be very difficult. That's why when we look at implementing Lean UX methodologies and we're breaking our project down into different modules and components to deliver in order to get our MVB out there. You need to keep people on track. Things need to be quantitative and measurable and really give you the opportunity to say, "has this being done?" Yes, no. Does the performance fall in this range? Yes, no. Things need to be quantified, and I definitely learned this the hard way when I first started hiring brilliant engineers with PhDs and worked on missile systems, and people who like literal rocket scientists, and that's not my forte, I just like starting companies. But trying to keep some of those folks on track when you give them autonomy to run certain aspects of the project, you're like, "I wasn't asking for a satellite, I really just wanted to have the comments box updated on this corporate blog, like what's going on man?" I'm just playing, but that's why it's important, was this done? Yes, no? Here is the matrix, was it done within the scope? How many hours were set on this? Really measure things in terms of "time" and "was it done?" That's where I've made a lot of mistakes with things; is that, when I'm dealing with really brilliant people, a lot of them lose concept of time, but when I'm paying by the hour and things aren't getting done, and I'm paying a brilliant person a brilliant salary, it can be a little painful. "Feature creep", "feature elegance", just stay on track with what the customer needs to get that MVP out there. Facilitate the exchange of essential information. The great thing again, about the day and age that we live in is that, collaboration has never been easier, especially with affordable tools like Google business, Drive, Sheets, Docs, I compiled, I pretty much to all of my planning and documentation in spreadsheets because I can then tie it to quantitative measures and metrics, and dates, and map everything out, but if I'm just creating a list in a Word doc or a Google doc, then I'm not as easily able to quantify or make it measurable, or actionable, so for me, everything goes in a spreadsheet, and we all share it, and we just keep collaborating, and that's how we get a quick turnaround and get things done with accountability. Completing individual tasks on critical path. Vital sequence of tasks, you can see how the different process is running in parallel, being able to map things out like this and see where dead ends are, see where you need a buffer, and where there may be redundancies in some operations, that gives you a good idea, because again, when you're just looking at a list of tasks versus mapping it out, you're not seeing where the integration points between the components are failing, and often, it's those integration points between the modules, where a lot of things go wrong, especially, when you're talking about integration of various facets of the human element; customer experience, sales, back-end, front-end integration, each component may stand alone and do a brilliant job by itself, but when you're trying to tie together this whole ecosystem to deliver and launch a company that people are going to pay millions of dollars for, you can't afford to let things fall through the cracks and just be completely disorganized., so I always like to get it started from the very beginning. If you're playing with some different ideas and working on initial wire-frames and sketches for developing a prototype, don't get all bashful by thinking that it could be something big, like some people, I found to have a lot of humility, and they're very humble about, and like, "Well, I don't know if it could be big," and then, they don't keep the right documentation, they don't go into it thinking, "This is going to be awesome." It's good to have a bit of an ego when it comes to starting a company, because then you're more shocked, and like, "Okay, well, this is going to be a problem for me." It may not be, i like to starting companies for fun, but risk mitigation and building out those capabilities from the get-go, it's a lot of fun and exciting for me because I'm always like, "This is going to be huge." It's like you made dog traits for us to sell on the neighborhood. Yeah, be an empire. If you rate, it's an empire. Aggregate safety times. Give yourself a buffer, under promise over deliver. Well, what a lot of people can't stand, nothing special or unique in this regard. I've got a development team or employees who need to deliver something and there are a lot more focused on, "Okay. Well, this is a deadline, this is the deadline" and then the deadline comes and they didn't get it done on time, and then I've spent lots and lots of money because it was a hard deadline and I don't get it done, or things weren't anticipated for going wrong. Now, I always add at least a 30-50 percent buffer time onto the end so that if things go wrong, I can correct it, make sure it's right and it's on-point, and meets the actual deadline. When am like "Okay. We need to have this feature or this piece of collateral done by this stage," people are like, "Oh, that's too quick." Well, that's what we're aiming for because we always need a buffer, hate being late for anything. More guidelines, eliminate some critical path tasks entirely. You may find that some things just aren't that important to a customer and make sure that you stay engaged with them. That's the great thing about implementing a Lean UX methodology and user centered design is that as the customer's needs change and evolve, you can be responsive to it. With how people's attention spends different technologies and needs adjust. You might say, "Hey, this was really important to you, " and they are like, "Yeah. Having a VHS player was super-important to me when I was nine, but now I'm 40, you don't want your product to obsolesce. Know when to outsource, and often that's going to be functions that aren't in your core lines of business. For me, I outsource my accounting and bookkeeping because I'm not a CPA. They know what they're doing. I outsource a lot of my legal because I don't want to keep an attorney on my books for several $100,000 a year. It's much better to just outsource it because legal and CPAs and finance, that's not my core line of business. Know what your core line of business is and stay true to it. Start early, but give yourself a good idea of what early is, and in terms of what the probability is of something painting at end of it coming to fruition. When I first started my company and I was working with companies getting started, I have much more detailed plans way ahead of time, way too much work done. It may not come to fruition, I'm like, "But I did all this work." By focusing on that, their opportunity costs involved, by not getting involved in other projects. But now what has worked for me is I'll be involved in several different things. Lay the foundation across the board and then say, "Okay, this one's got a higher probability." This can get me generating revenue now, while I sought to establish these capabilities and proof of concept and start to then manage your whole portfolio, bringing it up together versus just clunking along. Because private islands don't buy themselves. Well, maybe I wouldn't know, anyway. Working on that by the way. Thank you. Bye.
