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.


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?