![]() |
|
![]() |
|
|
![]() |
Home |
![]() |
Project Administrator Software |
![]() |
Method H
Software |
![]() |
White Papers, Links & Free Stuff |
![]() |
Consulting & Training |
![]() |
Project Management Blog |
![]() |
Contact us |
![]() |
Search |
![]() |
Contents |
![]() |
Tell your friends about this page |
![]() |
Join the White Paper mailing list |
Home | - | PA Home | - | PA Additional Information |
Whilst PA comes with the ability to manage almost every aspect of the project, you don't have to use everything. The project management software is flexible enough to just use what you want. You pick and choose which aspects you want to make use of.
The only thing you must do when using PA for managing projects, is provide a project name. The "Project Overview" screen allows you to enter all sorts of information, however if you only want to enter a name for the project, that is all you need. The rest is optional.
Having set up a project name, you might decide that you only want to use PA for managing Risks, or only managing Issues, or Scope variations. There are no interdependencies that need to be taken into account. As long as you have a project against which to log the issue, or risk, or variation, the program will allow you to record and report only this situation.
If your main requirement is to store generic project information, you don't even have to enter a project. You can create a corporate glossary, set up different types of reference documents and create project checklists without any other information being added.
Action Items. One of our clients had carried out a project review on a large project. They found they had almost 100 action items in a report and had a need to manage those items. They purchased a single copy of PA. By cutting and pasting from the report, they quickly set up the 100 action items in PA with due dates, and nominated people responsible. Over a period of some months, they were able to issue printouts to each person with their actions and due dates, report on those overdue, or completed, or due in a certain date range. This enabled them to spend half an hour a week to monitor and manage the work.
Glossary. The project review also suggested there be a common glossary for the organisation. Some contractors had struggled with the jargon and so it was decided to use PA as a corporate resource for jargon. It was a low key approach where a trainee was given the job of scouring previous project documentation for jargon and entering it in PA. In a short time, there were several hundred abbreviations, acronyms and technical terms defined.
Issues. Another project team had struggled with a well known web based problem management software product for managing issues. They gave up and decided to use PA. It was simple, quick and had the added benefit that many of the people involved in the project review were in this team. They received one consolidated list of action items each week. The actions covered the results of the review, and their current project.
Scope. Before long, they were using PA for producing scope variation request forms. They presented these to the steering committee for approval or rejection. They also found considerable benefit in being able to print out what was approved, rejected or pending. It also proved useful to know what the total impact of variations had been on the project.
Checklists. The Project Office had produced checklists for many tasks and transferred them into PA. In that way, teams could print out the lists, and quickly add their items as well for future use. Everyone contributed to the accumulation of knowledge.
Almost a year has passed and there are still many parts of PA that are not used. The organisation has however gradually made use of those parts that fit their requirements. This was always the intention of the software. It is not meant to be a "one size fits all". It is intended to be a toolbox that a project manager can use.
Use the best tool for each situation.