"Keeping your head when ..." managing the TBT project
By Clive Shepherd
"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 Clive’s involvement over more than 15 years with literally hundreds of TBT projects, some extremely successful, some best forgotten.
Contents
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, 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:
| 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
logic estimating time allocating resources budgeting risk analysis approvals |
| Design | structuring content developing learning strategies media selection interface design, prototyping and test re-budgeting documenting the design approvals |
| Scripting | preparing the script approvals |
| Media creation | audio and video production photography, illustration, graphic design animation |
| Programming | developing software modules |
| Assembly | assembly of media elements and software modules using authoring tools |
| Testing | alpha testing beta testing approvals |
| Delivery | hand-over to the client |
| Review and evaluation | post-completion project review 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.
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 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 …
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:
List tasks
Some tasks, such as project review meetings might be recurring.
Establish dependencies
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.
A time for everything -
estimating time
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? -
allocating resources
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:
| 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.
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.’
Here’s 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 -
monitoring progress
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.
When trouble brews - problem
solving
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.
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, 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.
| © Fastrak Consulting Ltd, 1999 | All rights reserved |