The development of a technology-based
training (TBT) programme is, to all intents and purposes, a software project and, as such,
is a risky venture. In fact, between one third and two thirds of software projects exceed
their schedule and budget targets before they are delivered. So, if were responsible
for a TBT project, what do we do - resign ourselves to the inevitable or do our best to
break the trend? We have a choice.
"Keeping your head when ..." managing the TBT project
By Clive Shepherd
In this article, Clive Shepherd outlines a systematic approach to the management of TBT projects that could help you to break the trend. It draws upon Clives involvement over more than 15 years with literally hundreds of TBT projects, some extremely successful, some best forgotten.
A little planning goes a long, long way
Getting off to the right start - the project definition
Coming over all logical - establishing the project logic
A time for everything - estimating time
Who's coming to the party? - allocating resources
Hope for the best, expect the worst - risk analysis
Keeping a friendly eye - monitoring progress
When trouble brews - problem solving
The morning after the night before - the end of project review
A little planning goes a
long, long way
Good project management is a pain avoidance measure and, take my word for it, theres plenty of potential for pain in a TBT project. Ive been there when, at 2am on the night before final delivery, the bug reports so thick you cant get a staple through it; when the spouse of one of your key team members is on the phone in tears because the family is leaving on holiday in four hours time and hes still at work; when your only programmer has a crisis of confidence, turns to drink and refuses to get out of bed; and when at the eleventh hour the client decides, as only a client can, that the programme must also be able to run from floppy disk on a 386 PC because thats all theyve got in the office in Madagascar. Know what I mean?
Well, most of this pain is needless. We can learn from these mistakes and approach our projects in a more systematic way. In the end, a little planning goes a long, long way.
First, in case of doubt, lets just ensure that were talking the same language:
And before we get into the detail, lets refresh our memory about the stages in a TBT project:
|Definition||taking a brief
establishing project objectives, constraints, assumptions and deliverables
|Research and analysis||performance analysis, task
analysis, training needs analysis
setting learning objectives
selecting training methods
establishing the concept
|Project planning||determining tasks and project
developing learning strategies
interface design, prototyping and test
documenting the design
|Scripting||preparing the script
|Media creation||audio and video production
photography, illustration, graphic design
|Programming||developing software modules|
|Assembly||assembly of media elements and software modules using authoring tools|
|Delivery||hand-over to the client|
|Review and evaluation||post-completion project review
evaluation of success of learning materials
Well start at the very beginning, because, as the song
says, its a very good place to start.
Getting off to the right
start - the project definition
A high proportion of the problems experienced with TBT projects are caused by rushing, or avoiding altogether, the project definition stage. Without a clear understanding of exactly what the client wants and what youre prepared to deliver, theres far too much room for disagreement later. You know how clients always seem so nice at the start of a project? In the rosy glow of optimism, it hardly seems necessary to pin down the details, to dot the is and cross the ts - after all, theres plenty of time to work that out as you go along. For now, a statement of general intent will do. Oh no it wont.
The project definition makes it absolutely clear what the project is setting out to achieve. And as the saying goes, if you dont know where youre going youll end up somewhere else. Heres what you need to sort out at this stage:
Problem or need
A concise statement of why the project is required at the current time.
These describe what has to be achieved if the project is to satisfy the underlying need or solve the underlying problem. To be of use, objectives need to be specific, achievable and measurable.
Scope defines the magnitude of the project in terms of variables such as content, audiences, geographic regions and learning objectives.
Most projects operate under some constraints, which limit your flexibility to some extent. These might include budget limits, critical delivery dates, maximum training times, established style guides, delivery platforms, limitations on recruiting and so on.
Deliverables are the outputs of the project, not only in terms of the end product, but also what is to be delivered at each key milestone (prototypes, documents, etc.). Be careful to avoid subjective statements of quality for deliverables - quality guidelines need to be specific and measurable. And remember that quality does not necessarily mean high production values - what is important is that the end product is fit for purpose.
The project definition is the result of a negotiation between customer and supplier, one in which both sides win. It pays to remember that it is the client who is paying the bills and that, in return, they acquire a number of rights
|I have the right
From the Software Project Survival Guide by Steve McConnell 1
Coming over all logical -
establishing the project logic
Having agreed on what the project is setting out to achieve, your next task is to develop a logical plan for doing the work. This process can be carried out with pen and paper, but is made a whole lot easier if you use project management software. These are the steps:
Some tasks, such as project review meetings might be recurring.
Note that tasks do not have to lead directly from one to another. Sometimes an overlap will be required (lead time) or a gap (lag time).
Other forms of dependency are:
A good way to start off the process is to determine the task that must come first. Then ask what other tasks can commence given the output from the first.
Group tasks into phases
Long lists of tasks may be difficult to manage, in which case you can group tasks into phases. A phase is a logical grouping of tasks that represents a major step in the plan.
TBT projects are typically lengthy and complex, so it is helpful to establish interim goals or milestones to help you to track the progress. A milestone may indicate the end of a phase or a requirement for deliverables.
A time for everything -
Your project plan is a long way from complete. Before you can tell whether you have any chance of delivery within a sensible timetable, you need to apply time estimates to each task. You can obtain assistance in developing time estimates from the following:
The following rules will help you in developing estimates:
Who's coming to the party? -
Your project plan is still not complete - you still have to decide exactly who is going to carry out each of your tasks. In doing this, its important not to get confused between roles and people - they are not the same thing. Before we go further, heres a list of typical roles in a TBT project:
|Project manager||Responsible for co-ordinating the work of the other team members, setting budgets and schedules, monitoring performance and liaising with clients, funding bodies and other third parties.|
|Subject matter expert||Responsible for providing accurate and up-to-date content for the training materials.|
|Writer||Responsible for developing any text, narration or dialogue for inclusion in the script.|
|Instructional designer||Responsible for analysing the training need, setting learning objectives, designing instructional strategies and putting together the design document and script.|
|Graphic designer||Responsible for implementing the graphical design elements of the user interface and sourcing or preparing any required photographs, illustrations, diagrams and animations.|
|Author||Responsible for assembling the course materials (text, images, audio, video, program code) into their final form, typically using generic web development tools or CBT authoring systems.|
|Audio-visual specialists||Depending on the nature of the training design, other specialists may be required to source, produce or post-produce audio and video content.|
|Tester||Responsible for alpha and beta testing the course materials to identify any bugs or other technical irregularities and to ensure conformity with the interactive script.|
|Production assistant||Responsible for providing administrative and logistical support to the team.|
|Tutor||Responsible for providing human support to an online training course when in operation. The role could include reviewing student work, providing advice and counselling, initiating discussion topics, scheduling synchronous collaboration activities and pointing students to sources of additional content.|
The relationship between roles and people
A person can perform more than one role in a project, if they have the necessary skills. Multi-skilling provides you with greater flexibility in scheduling, although specialists may be more effective at some tasks than generalists. More than one person may be required to fulfil a single role.
Allocating people to tasks
Your human resources may be allocated from full-time or part-time permanent employees or contractors. The latter may be charged at a fixed or variable rate. Remember to factor in lead time if you choose to use contractors or recruit new permanent employees. And you may also incur recruitment fees.
It is not necessary to apply resources consistently throughout a project. A person may be applied to a role for a limited period. Alternatively, a person may devote only a part of their time to a role.
Resources other than labour
Sometimes other resources are in limited supply and need to be allocated with the same care as people. Possibilities include:
These may or may not be charged to a project directly,
depending on your organisations accounting policy.
Hope for the best, expect the
worst - risk analysis
By now you should have a pretty complete project plan and if you print it out, it will look highly impressive. But you know what they say - man plans and God laughs. To avoid the danger of future embarrassment, some serious consideration needs to be given to what could go wrong.
To quote Steve McConnell: Software development is a high risk activity. Many of the risks can be prevented or minimised by performing active risk management. Many of those same risks can cripple a project if they are not actively addressed. You might be an optimist, but with software projects, as the saying goes, you can hope for the best but you should prepare for the worst.
Heres a run through the steps in risk analysis:
Maintain your list of risks throughout the project, updating
it based on your experiences to date and new information coming available.
Keeping a friendly eye -
Were off and running and, as project manager, the fun bit is over. From now on your plan will be tested against reality. Your priority at this stage is to make sure that youve got enough information to steer the ship. The following will help:
Timesheets typically record the number of hours put into each project task by a team member over the course of a week. It is helpful if they also record work put in on other projects, plus non-project time such as administration, holidays, sickness and training.
You can use timesheet data to enter actual figures into your budgets and schedules and to monitor the amount of time being lost to the project.
Timesheets tell you how much work is being undertaken, but not how productive that work is. To monitor the project effectively, you need to know how far team members are progressing towards task completion and ultimately your project milestones.
If you break a task down into small modules, then you can create a task checklist. Every time a module is completed, it is ticked off. That way, you will have a good idea how far you have got and how far there is to go. If you are to get an accurate picture, it is important that modules are only checked off when the work is fully complete, checked and tested.
Project meetings are expensive, because they take up the time of every person that attends. However, if well managed, they provide an essential forum for communicating changes to the plan, recognising successes, problem solving and identifying new risks. On a smaller project, all team members will normally attend. With a larger project, you may only need the representatives of each major technical discipline.
To keep meeting times down, circulate the latest copies of the project plan and any reports in advance; create an agenda and stick to it; and dont get bogged down in topics that affect only a portion of the group.
It is important that each project team member maintains the primary responsibility for the quality of their work. That means that they do their own proofing and testing and only pass on the work when they are satisfied that it meets the specification. A right first time philosophy will help to minimise the tension between team members and will considerably reduce the amount of rework to be undertaken.
Even with a right first time approach, you will still need a system of checks and reviews. This is because it is often helpful to get a number of perspectives on a piece of work not least the clients and because some errors are always invisible to the person that made them.
The earlier in the project that reviews take place the better. If each piece of work is correct before it is passed on, then you will be building on sound foundations and end-of-project tests will become a formality.
It is important that your major planning documents (budgets, schedules, project plans, risk analyses, etc.) are maintained throughout the project. Your original plans become a baseline against which actual performance can be compared.
No plan is perfect and not all eventualities can be
predicted. Thats why project planning is an ongoing process, not a one-off.
When trouble brews - problem
However hard you try, youre going to end up with some problems on your project. One way of dealing with problems is to treat them as opportunities, but as one senior IT executive once told me, my life is full of insurmountable opportunities. Another way, is to follow a logical problem-solving process:
The major hazard in problem solving is jumping to cause assuming you know what has caused a problem without a thorough analysis. The correct first step in problem solving is defining the problem - being specific about what the problem is. What is happening? When is it happening? Where is it happening? With whom is it happening?
If the problem is particularly complicated, you might also ask: when, where, with what and with whom else might you expect the problem to be occurring, but it is not. When you know exactly what the problem is and what it is not, you can begin to narrow down the distinctive elements of the problem situation. You might also identify if something has changed that might have triggered the problem.
Identifying the cause
You may identify a number of possible causes of your problem. Test each one of these out against the facts. Does it explain why the problem is occurring with this but not that, at this time but not at other times, in these places but not other places, with these people but not others?
Performance problems are particularly danger-ridden. Its all too easy to jump to conclusions without assessing all the options. There are many possible causes for performance problems, many of which are nothing to do with the performers - the members of your project team. Depending on the cause, any of the following may be required to resolve a problem:
Research conducted on software projects provides some interesting findings:
The first priority in any corrective action is to tackle the cause the situation that created the problem in the first place. Without doing this, the problem will continue to occur and the effect on the project will get worse. If the problem has caused the project to get behind schedule, you will also need to take action to address this. Your options include:
Beware of over-optimism when you revise your estimates. A
1991 survey of over 300 projects, found that projects hardly ever make up lost time
they tend to get further behind.
The morning after the night
before - the end of project review
The closing phases of projects tend to be the most frantic and the most tiring. When the product has gone out to the client and all is quiet on the Western front, its nice to enjoy a period of relative calm, with no more problems to solve and no more adjustments to the project plan. There is, however, one more task to be completed before the project team disbands the end of project review.
Is this really necessary? After all, the project is all too fresh in your mind. You and everyone else on the team know all there is to know about the project. The answer is that the review is necessary, for these reasons:
Heres how to conduct the review:
And thats that. Youre happy because youve got a big rise. The clients happy and is going to give you more work. The trainees are happy because they got the training they needed when they needed it. All is happy in the garden.
Some chance - this is a software project after all. If you wanted a quiet life, you chose the wrong job. But you may start to have more successes than failures, and where you do have failures, at least youll be learning from them. At last, some feeling of control.
Clive Shepherd is running a series of two-day TBT project
Management workshops in 1999 for the Institute of IT Training. For further information,
contact the Institute on +44 (0)1203-418128 or by e-mail at firstname.lastname@example.org.
|© Fastrak Consulting Ltd, 1999||
All rights reserved