When planning out a project, I generally start by
determining and documenting a list of specific goals, tasks, costs and
deadlines. I believe having all this information early in development
guarantees for successful completion. This is why I prefer to set limits to the
scope early as opposed to the later route.
The bigger the
project the bigger the scope:
The Scrum process seems to suit big projects that have
rapidly changing and highly emergent requirements quite well. How this works is
via a series of iterations called sprints, which generally last from one to
four weeks. This model suggests that each sprint begins with a planning meeting
and concludes with a debriefing. These planned meetings ensure communication
throughout various disciplines, which then spark further knowledge and
creativity for that project. I believe this model fits perfectly with an early
approach because it ensures that the teams understand the project vision.
Implement, document
then test:
When working on big projects, it’s almost natural for parts
to change. Ensuring that the project has been “scoped” early in development
results in the team being able to adapt faster and more efficiently. Also,
making sure that all team members are fully aware of the projects scope,
guarantees undivided concentration, which then translates to zero ambiguity.
Naturally one might say that taking this early approach
leaves room for contingency. My way around this problem is to leave room in the
scope for any unforeseen issues or events. Having this clear path means that a
team can devote their time to quality. This absolute devotion to quality is
what makes for great games in my eyes.
