click here for the features menu
spacer
"Keeping your head when ..."
managing the TBT project
spacer
By Clive Shepherd

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 we’re 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.

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 Clive’s involvement over more than 15 years with literally hundreds of TBT projects, some extremely successful, some best forgotten.

Contents
pixel.gif (807 bytes)
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
pixel.gif (807 bytes)
Good project management is a pain avoidance measure and, take my word for it, there’s plenty of potential for pain in a TBT project. I’ve been there when, at 2am on the night before final delivery, the bug report’s so thick you can’t 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 he’s 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 that’s all they’ve 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, let’s just ensure that we’re talking the same language:

And before we get into the detail, let’s refresh our memory about the stages in a TBT project:

Stages in a TBT project
Definition taking a brief
pixel.gif (807 bytes)
establishing project objectives, constraints, assumptions and deliverables
Research and analysis performance analysis, task analysis, training needs analysis
pixel.gif (807 bytes)
setting learning objectives
pixel.gif (807 bytes)
selecting training methods
pixel.gif (807 bytes)
establishing the concept
Project planning determining tasks and project logic
pixel.gif (807 bytes)
estimating time
pixel.gif (807 bytes)
allocating resources
pixel.gif (807 bytes)
budgeting
pixel.gif (807 bytes)
risk analysis
pixel.gif (807 bytes)
approvals
Design structuring content
pixel.gif (807 bytes)
developing learning strategies
pixel.gif (807 bytes)
media selection
pixel.gif (807 bytes)
interface design, prototyping and test
pixel.gif (807 bytes)
re-budgeting
pixel.gif (807 bytes)
documenting the design
pixel.gif (807 bytes)
approvals
Scripting preparing the script
pixel.gif (807 bytes)
approvals
Media creation audio and video production
pixel.gif (807 bytes)
photography, illustration, graphic design
pixel.gif (807 bytes)
animation
Programming developing software modules
Assembly assembly of media elements and software modules using authoring tools
Testing alpha testing
pixel.gif (807 bytes)
beta testing
pixel.gif (807 bytes)
approvals
Delivery hand-over to the client
Review and evaluation post-completion project review
pixel.gif (807 bytes)
evaluation of success of learning materials

We’ll start at the very beginning, because, as the song says, it’s a very good place to start.
pixel.gif (807 bytes)
Contents

Getting off to the right start - the project definition
pixel.gif (807 bytes)
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 you’re prepared to deliver, there’s 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 i’s and cross the t’s - after all, there’s plenty of time to work that out as you go along. For now, a statement of general intent will do. Oh no it won’t.

The project definition makes it absolutely clear what the project is setting out to achieve. And as the saying goes, if you don’t know where you’re going … you’ll end up somewhere else. Here’s 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.

Objectives
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
Scope defines the magnitude of the project in terms of variables such as content, audiences, geographic regions and learning objectives.

Constraints
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
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 …

Customer’s bill of rights
I have the right
  • to set objectives for the project and have them followed
  • to know how long the project will take and how much it will cost
  • to decide which features are in and which features are out
  • to make reasonable changes to the requirements throughout the course of the project and to know the cost of making those changes
  • to know the project’s status clearly and confidently
  • to be appraised regularly of risks that could affect cost, schedule or quality and to be provided with options for addressing potential problems
  • to have ready access to project deliverables throughout the project

From the Software Project Survival Guide by Steve McConnell 1

Contents

Coming over all logical - establishing the project logic
pixel.gif (807 bytes)
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:

List tasks
The first step in establishing the logical flow of your project is to list all the tasks. Tasks are concrete steps required to meet project objectives. If your tasks are too large, they might mask smaller tasks that actually need to be completed and tracked separately. If your tasks are too small, they might be trivial and clutter your project plan.

Some tasks, such as project review meetings might be recurring.

Establish dependencies
A dependency is a logical relationship between tasks in a project plan. The most common form of dependency is where one task must be completed before another task can commence.

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.

Establish milestones
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.

pixel.gif (807 bytes)
Contents

A time for everything - estimating time
pixel.gif (807 bytes)
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:

Contents

Who's coming to the party? - allocating resources
pixel.gif (807 bytes)
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, it’s important not to get confused between roles and people - they are not the same thing. Before we go further, here’s a list of typical roles in a TBT project:

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.
Programmer Responsible for preparing any custom code required, using languages such as JavaScript, Java, Perl and C++.
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 organisation’s accounting policy.
pixel.gif (807 bytes)
Contents

Hope for the best, expect the worst - risk analysis
pixel.gif (807 bytes)
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.’

Here’s a run through the steps in risk analysis:

  1. Conduct a brainstorming session including as many members of the team as possible. Ask yourself the question: ‘What could go wrong to jeopardise us meeting our project objectives?’
  2. Using a high / medium / low scale, rate each item on your list for probability and seriousness. Select those risks with the highest probability and seriousness for further analysis.
  3. For each risk on your priority list, ask yourself what the possible causes could be of this happening.
  4. For the most likely causes, decide on actions that will prevent this occurring. Build these into your project plan.
  5. Where you feel you will not be able to completely eradicate the causes of a high priority risk, develop contingent actions that will reduce the effect of the risk if it does occur.

Maintain your list of risks throughout the project, updating it based on your experiences to date and new information coming available.
pixel.gif (807 bytes)
Contents

Keeping a friendly eye - monitoring progress
pixel.gif (807 bytes)
We’re 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 you’ve got enough information to steer the ship. The following will help:

Timesheets
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.

Task checklists
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
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 don’t get bogged down in topics that affect only a portion of the group.

Quality checks
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 client’s – 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.

Reports
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. That’s why project planning is an ongoing process, not a one-off.
pixel.gif (807 bytes)
Contents

When trouble brews - problem solving
pixel.gif (807 bytes)
However hard you try, you’re 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:

Problem definition
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 analysis
Performance problems are particularly danger-ridden. It’s 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:

Corrective action
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.
pixel.gif (807 bytes)
Contents

The morning after the night before - the end of project review
pixel.gif (807 bytes)
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, it’s 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:

Here’s how to conduct the review:

And that’s that. You’re happy because you’ve got a big rise. The client’s 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 you’ll 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 info@iitt.org.uk.
pixel.gif (807 bytes)
Contents

click here for the features menu

Fastrak Consulting Ltd, 1999

All rights reserved