We fit the process to the project.

Part of doing a job well is using the right tools for the job. When it comes to digital media and information technologies, one of the first tools we use is our process. This process is the foundation for how we think, how we communicate, and what we deliver. Every project demands appropriate methodologies that are suited to the work being completed. It would be silly to try to apply a script-writing process to a dynamic weather database project. Or an Object Oriented Analysis and Design process on a linear video animation project. Processes and methodologies are not "one size fits all" and our team understands the needs for a flexible approach early in the project life-cycle.

Our Process has 4 common key phases.

Our process, at a high-level, is simple. We follow the same key phases no matter what part of the project life-cycle we are involved in. What changes is how these phases are completed. Often, we find that a project will require multiple approaches to the phase in order to ensure the most holistic solution is found. The following examines these phases in greater detail. Books have been written about the tasks involved in these phases and while GystWorks has chosen its own set of terms that make sense to the team, at the core, the phases are based on proven methodologies.

Phase 1 - Project Inception

Project inception is the phase that includes two general groups of activities. First is the collection of any and all ideas, research, and visions that are related to the project. This collection is an important part of capturing as much of the team's dream of what the end product will be as possible. Every project is a compromise of this collection. In fact, there may be conflicting expectations that are collected.

With the collection of ideas, we can proceed with the next part of this phase. This is a high-level visualization that captures the essential requirements of the project. During the next phase, Elaboration, every feature is related back to this high-level visualization while maintaining the balance of the scope elements. In general, GystWorks and the client project team should always understand the following when the project inception is complete:

  1. Who are we building this product for and who else stands to gain by your organization investing in it?
  2. What are the primary goals of all individuals involved and what are their outcomes?
  3. What is the best approach, technology or not, to reach these outcomes?

It is vital that the three scope elements of time, budget and features harmonize in order to ensure project success. When any one of these elements is altered once the scope is defined, a review of this alteration must be performed to bring all the elements back into balance. This is referred to as Change Management. We discuss GystWorks’ Change Management in another section.

Phase 2 - Project Elaboration

Elaboration is the phase that works through all the collection of project ideas (typically all project ideas can be related to features), prioritizes them according to the defined outcomes of Phase 1, and matches them up with an appropriate allocation of time and budget. By working through each of the ideas in order according to priority it becomes fairly clear what features will fall "in scope" and what features will be labeled as "out of scope." Output from elaboration, the requirements document, forms the basis of the Construction plans that is implemented in Phase 3 - Construction. The requirements document also serves as a basis for future releases, as all features that are deemed out of scope, are cataloged for future reference. It is also here where strategies for measuring the outcomes, defined in Phase 1, are created. These are sometimes referred to as success criteria and involve meeting the defined expectations of time, budget and features. With the acceptance of the requirements document the style of the project shifts slightly. The end of the elaboration phase represents a major milestone and the beginning of the Change Management strategy. Once the project team has signed off the requirements document, any new ideas, requirements, time lines or budgets are considered changes to the scope. Change management is an important part of limiting scope creep.

Phase 3 - Project Construction

Construction is the actual building of the features defined in the Elaboration Phase. Most software projects, including interactive and multimedia projects, follow an iterative method of build, test and review. This allows the construction team to focus on a single slice of functionality, test it and allow you to view and comment on the feature early and often. GystWorks uses this method of construction as it has proven consistently to be the most successful. The Construction phase is considered completed when all the features are built, and presented as a "beta." The beta release is an untested version of the final product. With the completion of the Construction Phase, all effort now shifts to testing and debugging. The Change Management Strategy is closed and no new features will be allowed for this version of the product. All new ideas, features, and changes will be added to the next version's feature list.

Phase 4 – Project Transition

Transition includes all testing & bug-fixing or final edits and continuity checks (colour correction, shot consistency, etc.) that are required to meet all the outcomes or success criteria defined in the Scope Definition Phase. It also includes any installations to host servers, publications, printing and any other product launch preparations still remaining. During the project transition, the project team will invite various closed test groups to use the product and provide feedback about any problems (bugs). The project team will compare the product to the success criteria to determine how well the product matches the expectations set out. Transition also includes all the publication/distribution activities as well as the post-completion reviews. The reviews then serve to facilitate the "next version" discussions as well as a project team post-mortem. This is a formal review that encourages the entire team to share their experiences of the project with an eye for continuous improvement. This also helps the team bring closure to the project.