The ‘secrets’ of successful projects
August 18, 2010 Leave a comment
OK so I’ll admit it upfront, these aren’t really secrets but sometimes you would be forgiven for thinking they are! This is by no means an exhaustive list of project tips but a collection of a few things that really have stood out to us over the past few years. These tips may sound simple and common sense but so often are forgotten or not given the attention and due diligence they deserve!
1) The Great Unknown: Serious Games sound cool – but do we know what we are getting ourselves into?
Many organisations hear about the great work going on the serious games industry and understandably want to explore the space within their own learning and development. However serious games development differs just a little from traditional e-learning development and therefore it is always a good idea to set expectations on how the project will flow.
- The project output needs to be clearly defined. What are we making and how is it going to be used.
- What does the client involvement look like, where will their input be required. Not only in the sense of the project time line but also in the sense of the design input, and evaluation.
- Finally it is always worthwhile ensuring clients understand the general process required to create the game. Understanding the priorities and order of development helps the client to understand that they may not see a whole lot up front, that there may not be realistic voices, or final animations in the product at Alpha stage – this is crucial to setting expectations and ensuring the project runs smoothly both from a development point of view but also for internal communications within the client organisation.
At PIXELearning we always try to have a face-to-face kick off meeting where we spend time creating a Project Inception Framework, which captures all of the information noted above and more! The framework then becomes a charter for the key project goals, requirements, inputs, outputs and time scales. Both the project manager and client sign off this document ensuring both parties are happy with what has been agreed and of course it always helps to have key decisions documented early on just in case anyone needs a refresher!
2) This is our most exciting project but…I’m 100% maxed out on other projects…
Far too often clients don’t consider the internal cost to serious games development. In the main serious games developers (and PXL is no different) are not subject matter experts in the clients industry. What we are subject matter experts in is taking that content and merging it with games design principles and technologies. Therefore if you are not careful in stating key client inputs as noted in point 1, you will be left with a client who has no or very little time to dedicate to the project in helping you, the developer, to understand the content so that you can do your job. This often results in projects running behind schedule and content that is a little less robust than desired.
3) Start with the learning outcomes!
This may seem obvious, but many clients want to start with the story, who the learner will be playing, where the game will be set, a space station, a desert Island, or another dimension. However that is the wrong place to start if you want a great learning product! Yes it’s cool to brainstorm what might appeal to the learners, but don’t get sidetracked – make a note of these ideas and keep them somewhere safe and then get on with that is really important: understanding what we are trying to communicate with this serious game.
What are the raw learning outcomes you want people to understand? What do you want people to come away from the course thinking? These should be quantifiable and measurable: how else will you measure the success of the course!
After you have the key learning outcomes defined and an idea of the activities you need to build the design around often a scenario will naturally present itself. Matching the game genre to the learning outcomes is the only way to go about the initial design stages, trying to shoe horn learning outcomes into a specific game genre will only result in an un-enjoyable and poor learning experience for end users.
4) Build in contingency and time for review into the project plan.
Again this is pretty obvious, but it hardly ever gets done. Often we receive RFP’s which have start to finish time scales of 2/3 months: totally do-able from a development point of view, but, a key piece of information developers need when planning a project is to understand how long it will take a clients to review, feedback and make final decisions on the designs. If like PIXELearning you include a concept design, a high level design and a detailed functional specification and the client needs for example a week to review each document, this will then clearly add 3 weeks to your project schedule. Then take into account reviews of prototypes, narrative, Alpha, Beta, and Final and Gold you could be adding a good two months to your project schedule if you are not careful.
Delays caused by insufficient allocation to review and sign off in the project plan will only reflect badly on the schedule – however if you allocate more time than is required, you have more contingency and perhaps will move ahead of schedule!
5) Do not design by committee!
I cannot stress this enough! Too many serious games designs are watered down to a point of being irrelevant due to too many cooks. You know what they say about opinions…everyone has one, and they are bound to be different, contradictory, and very personalised. It is always 1000% necessary to appoint a lead designer in the development organisation and give responsibility to someone in the client organisation as well. A lead client SME should be established who will be a single point of contact for content. These individuals will make up the core project team and have the responsibility for the software’s core functions.
A couple of issues with this step is finding someone who will do it! And also it may go against the corporate culture, so often through committee. However a word of warning, design by committee runs the risk of ending up with a watered down version of the original vision. There needs to be one person in the organisation who has the passion, and the drive to make their vision a reality. A designer needs this person to stand head and shoulders above everyone else so they can work together and create a solid design.
6) Get sign off!
And get it at every stage of the project. Make the consequences of delays and changes clear up front. Get the design team (development and client side) to commit to what you are producing and if it changes ensure everyone understands that there will be time and budget impacts to the project.
So that’s a first run of our top tips! Do you have your own tips on running a successful project – are there any lessons you would like to share?