Project Planning
From HowTo.Lifehack
Contents |
[edit] How to Plan a Project
So you've decided to start a big project. Maybe you want to write a book, start a blog, make a program or sell a product. Working on longer projects can be hard work, but there are few things more satisfying then looking at the end result of your efforts.
Since organizing and executing personal projects can often be difficult it also gives you a competitive advantage. Many people talk a tough game, planning out big ideas, but then fail to deliver. After doing several longer projects, I'd like to share some tips to help make your big idea a reality.
[edit] Step One: Know Your Outcome
Know exactly what you want to build and give yourself a deadline for when you want it to be completed. Software is often known for suffering from "feature creep." That is extra features continue to be packed on without realizing it, greatly expanding the size of the program and limiting its usefulness.
Projects can suffer from creep too. As you get more ideas, you may just continue to expand the project until it could take years to reasonably complete. There is merit in spending the extra time perfecting your creation, but unless you want it to be a lifelong pursuit you need a deadline.
Unless I already have a lot of experience in an area, I would never plan a project longer than six months without feedback. This means that if you want to write a piece of software, the first public version should take no more than six months. I might extend this if I had already created a several programs, but otherwise 18-24 month projects can be incredibly risky.
[edit] Step Two: Create a Simplified Idea
The next step is to know what the core of your idea is. Know what the absolute minimum that must be done in order for your project to remain a unique expression of your idea. If you are writing a book, know exactly what chapters must be covered and what ideas are merely ad-ons.
Often your minimal idea is all you have time to do before a release. Planning the best book or program in the history of mankind is a nice idea, but usually you only have time to simplify and release the essentials.
[edit] Step Three: Shift Risk in Early
Plans are overrated, the act of planning is invaluable. The most important element to remember when planning is to shift risk as early into the project as possible, where you still have flexibility and shift any dependent elements later into the project.
What does this mean? Well let's say you want to create a computer game. You have programming, interfaces, mechanisms, artwork and music. If you plan to sell the game then you also have website or publishing deals, order management, legal issues and more.
Shifting risk early means taking all the elements that could sabotage your process and testing them right at the start. Here are some examples of shifting risk we could use when developing a game:
- If you plan to do the programming, write a prototype to ensure that the basic concepts are within your skill level.
- If you want to contract out the artwork, find a suitable contractor before you've finished programming everything.
- Check all sales and legal issues before writing a line of code to ensure it will work.
- Run market tests to get an idea of how your game will be received before you start production.
Shifting dependent elements late here would mean shifting things like artwork and sound after producing all the code. Why invest time perfecting something that may later need to be removed from unanticipated programming problems or storyline changes?
This is just one example. The same applies to writing books, building a house or operating a blog. It's impossible to test everything, but it does remove a lot of the unknown.
[edit] Step Four: Finish
This may seem obvious, but in order to finish a project, you need to actually complete stages of development. But despite this, many people working on projects never get through any one stage to completely finished, always leaving gaps for refinement. I'm all for polish and perfection, but if you want to have a completed work afterwards you need to finish sections.
If you are writing a book that means you need to finish writing chapters, finish writing the content, finish the editing, finish the publisher deals. My rule is that whenever something is functional and reaches 95% polish it is considered finish. Spending extra months to move it to 99% polish can be done later.
[edit] Step Five: Know When to Quit
Projects have a high failure rate simply because dreams don't match up with reality. You may get halfway through a book and decide that you aren't really devoted to the concept. You can start a business and realize it wasn't the life you expected. This shouldn't discourage you from starting projects, but you need to be smart when deciding to give up.
It's hard to give specific rules for when to quit, but the general guideline I follow is this:
- If the project seems to be on an unending path either significantly eliminate sections or quit.
- If the project would require significant repairs to fit your original idea and currently can't compensate for the original investment, quit.
- If you no longer desire the end result of the project and completing it is not a financial or personal necessity, quit.
