How a project is conducted is probably the most important aspect of the quality you get in your training module.  Like most professional developers, we follow a quality assurance software development life cycle which ensures a lot of things happen at the right time – quality assurance, design signoffs, reducing confusion over specifications, and so on. 

Our software development life cycle is built around two important premises:

1. Your team learns what it wants as it goes, so change control is built into the cycle. 
   
   We decided long ago that this is real life in software development, so change is part of what we need to be good at; and
   
   
2. That your team needs to constantly see what it is getting, so multiple reviews are built into the life cycle. 
   
   Why is this good for you?  You and your team learn a whole lot about the development process, and get better at it, which makes the cost of future modules lower!

To make it simple, we have the following project phases:

1. a Project Start / Requirementsphase, where we have a series of meetings in which we set project resources, detailed project requirements, schedules, plans, and extensively interview your team about learning outcomes, instructional choices – you can imagine there’s a lot to talk about here. 
   
   In this phase, we also perform a test installation of the technologies we have agreed to use – IT people don’t like surprises, so we try not to give them any…
   
   
2. a Design / Prototype phase, where we do 3 important things: 1) we create a general design to solve the requirements of the project; 2) we create lots of choices for you in an interface design and fine tune this until it looks (and more importantly, works) right; 3) we determine parts of the training to be incorporated into a prototype module, and build a prototype for your team’s review, which you get to take away, change a bit, and sign off on.
   
   A prototype is a fully designed, working model of one part of your module, and it should be complete enough for you to “test” all of the design assumptions which you and the developer have made thus far: navigation, look and feel, writing tone, interactivity, tracking – everything!
   
   No matter what developer you use, always demand to review a working prototype of the module!  It’s the only way for your team to be sure about what they’re getting!
   
   After the prototype is reviewed, adjusted and improved, we finish writing the design of the remainder of the module – based upon what we’ve learned from your earlier reviews.
   
   
3. a Build phase, where we put the entire design through full production, perform unit testing on all parts of the development, and integration testing when we put the pieces together.
   
   
4. a Delivery phase, where we perform a full system test on all units of development, package, document and deliver the full product for your Acceptance test; and
   
   
5. a Project Rollout phase, where we assist you with the rollout and implementation of the module in your learning audience.  There is a lot of preparatory work that goes into this, of course, and it starts as early as the Project Start / Requirements phase.

Return to Top