Project Planning
The next stage will institute a project plan for the implementation, testing, deployment and maintenance portions of the software development life-cycle. So far, you’ve 1) Written a Capstone for your idea, 2) Taken your idea through an Opportunity Assessment to see if it’s worthwhile to further proceed with and 3) Worked on documenting as much of your idea as possible with both technical and non-technical specifications in your Software Specifications Document. This covers the documentation phase and some of the planning phase. Only 4 more phases to go, are you still with me? Good - Let’s do this.
One of the mishaps that I see in pretty much every request for staffing for a game design idea is the lack of a technical writer or project coordinator/manager. About 80% of everything that you do on a project should be in the Planning and Documentation stages of the product design. There have been a large number of studies done on cost effectiveness and project timelines, and all result in the realization that mistakes that could of been alleviated by proper documentation are the most cost intensive portions of product development. Not fully understanding the architecture that you’re developing on, or missing key, critical features during the deployment stages of your product can result in astronomical resource and financial costs. Knowing this, I doubt every person that starts looking for a game development team is an expert in technical writing and project management, which is why I find it so queer as to leaving out those positions when looking for a team. Perhaps the Lead Designer feels that he can manage these areas, though I highly doubt it.
Furthermore, and especially with indie development, keeping morale up (since most of your staff will probably be remote) and continuing to push ahead on your project is paramount. No other one thing in a project can provide as much detailed achievement as a project plan. Keeping this project plan transparent to the rest of your team will show team members that things are actively being completed by all areas of the team, and will give the team a much better focus on what they should be working on and when.
The Project Plan should be as detailed as possible without drifting into a documentation timesink. It should effectively detail each stage of the Implementation, Testing, Deployment and Maintenance phases of the software development lifecycle - breaking this down into identifiable and achievable tasks. You should work to identify milestones within your project plan that will reverberate back to your team - “Hey, we’ve finally gotten to THIS point and accomplished THIS! Awesome!”. Additionally, your Project Plan should detail out what positions should work on which tasks and estimate how much time the task should take(this is an art-form in and of itself) - what dependencies one task has to another task, and so on. I’m not going to go into detail on how to setup a project plan, there are hundreds of books out there that detail this process in length - and this portion of the product development is a particular, skilled expertise - meaning there’s no other way around it than just studying it out the ***.
Conclusion
If you finish with the above and still feel like creating a game, then hit me up and I’ll detail the rest of the stages. I feel this is a good primer to get you started. Additionally, I would recommend you study up on the following categories:
Project Management
People/Team Management
User Experience
Unit Testing
Software Design Patterns
Software Development Lifecycles
Process Improvement
Below, I have a list of books that I would like to recommend. The down-and-dirty is that reading is fundamental - you’ll be creating, essentially, a book in it’s own right just with the first few steps shown above. You’ll need to dive deep into certain topics, and there’s no alternative other than busting your ***:
The Mythical Man Month
The Power of Habit
UI is Communication
Programming Language Pragmatics
The Pragmatic Programmer
Design Patterns: Elements of Reusable Object-Oriented Programming
Good To Great
The Innovator’s Dilemma
Anyways, I hope you enjoyed this quick primer. I know I certainly did! Parting ways before I go, I would like to share some wisdom - Be wary of any type of educational or tutorial material that’s specific to Game Design and Development - stick with enterprise industry standards, and do not narrow your knowledge to just Game Design itself. Be aware that everything stated here is of my own opinion and experiences.