A glossary of project management phrases and stages
roughly in the order you should do them

Analysis phase:
What are you being asked to do? Defining the goal(s) - what are you being
asked to make or do? This is often called a brief, it
is often time critical. If you don't know what you are doing don't start,
you are wasting your time.

Setting objectives - how will you
know when you have done it right? Pretty easy if you are making something,
much harder if you are training people or changing a system. Objectives
are often the same as deliverables what will you make
or do. They are often broken down into specification points.

problem analysis - break down the job
or brief or sepcification into smaller manageable pieces (tasks).
Start to think about who will do what and how long these tasks will take
. Think about what resources you have available these can be people or
computers or factories. This is a good time to make an implementation
plan and carry out a swot analysis.

investigation of current system - If
you are improving or replacing something look at what they have at the
moment. Why is the current solution not working? This may help you do
a better job. Remeber also "if it 'aint broke don't fix it" sometimes
the best advice is to leave it alone. Not easy advice to give if you
are getting paid.

feasibility study - will it work? Is
it even possible? This is a good time to check what you are setting out
to do is possible. If you can't do it for the money or you can't do it
on time or you just can't do it. You could go back to your client and
ask for more money or more time or just admit its impossible, better
to do this early than fail to deliver on your project.

preparing a project proposal - What
are you going to do? How will you solve the problem? This is usually
a document where you say what you are going to do, how long it wil take
how much it will cost and what the client will get for their money. Sometimes
called a tender or a bid.

Design phase:

Most of the design work will be
done after you win a job or contract some will be done before you get the
order. People often talk about initial design and detail design. The first
one is a bit rough the second one has to be very accurate.

Make a time plan

Work out who and what you have available and work back
from the day you must deiver allow some contingency (time for things to
go wrong). Some tasks can't be done until others have finished these are
called dependencies all the dependancies together make up
the critical path.

producing possible solutions- You may
have said what you are going to do, it is now time to say in more detail
exactly what you are going to do. If you are designing a car you would
say whether it is going to be front or rear wheel drive, diesel powered
or petrol or even electric. If you are making software how will people
log in? will it be web based or stand alone?

designing aspects of the system- Do some
designs, these could be layouts for pages in a web site or a style statement
for an in house magazine. You need to think about and write down as many
details of your solution as possible.

the use of prototyping- If you are making
a magazine do a proof or an early version. If you are making a sports staduim
build a 3d model in computer aided design software. If you are building
a spreadsheet model to control costs get a simple version working with
some dummy data. These models or demos or walk
throughs or maquettes often
help you check things work and help the client know how things are going.

Implementation phase:

creation of a system (hardware and software)- Make
it. What ever you said you were going to do, do it. Make sure
everyone know when they have to do things and
what they have to do. keep your project plan up to date with progress and
make sure you regularly update your swot analysis.

creation of user documentation- Make user manuals or videos so
everyone who will have to use your solutions knows how to.

testing all parts of the system Now
you have finished it test it. Firstly funtional testing - does it work?
if it doesn't fix it

user acceptance testing- Secondly user
testing, can the people you want to use it, use it. Ask them to feedback
to you. then make any changes they ask for until they are happy.

user training- Now you have got a product
or solution that works train the people who are going to use to use it.
Let them become familiar with the user manual or user aids you have made
and answer any questions they have.
methods used for launching a system- Do you have have a big opening
ceremony? Do you email the users to tell them the system is "live"?
Do you launch the system at the training event?

maintenance does it needs its batteries
changing regularly? Do you need to provide updates and support only a monthly
yearly or daily basis? If you do do it and make sure you are getting paid.

Evaluation:

analysis of feedback from users did they
like it? did they use it? was it better than what they had before?

review of project process Why did it go
so well or so badly? Should you have shouted at that supplier? Should you
have asked the client more questions? Shouldn't you have known they were
all vegans before you served them veal at their wedding breakfast?