Home  |  Services  |  Downloads  |  Why Us  |  Resource Links  |  PM Techniques  |  Contact Us

 
 
  Project Management Techniques

Here are just some of the Project Management techniques we use in assisting our clients in their software implementations.

1. Listening: It is common once having purchased commercial software to have doubts about the investment made. The salesman has now
left and you may be under pressure to deliver on their sales pitch. We Listen to your concerns and will endeavour to deliver on those issues that affect you.

2. Reporting: A system is only as good as the reports you get out of it. To do this the system will need to be user friendly for the data in-putters and the system configured correctly to avail of the reports supplied.

3. Auditing: There are two basic rules in most audits.

  • "You must do what you say you are going to do: Your Standard Operating Procedures (SOP's) must be realistic (but not Idealistic as you will probably not have the resources to do them) as you will be judged by them.

  • Continuous Improvement: Clear concise reports will show where the issues for concern are. These should be addressed to stop reoccurrence. If the reports do not highlight issues then it is probable that not all the data is being recorded. Try either configuring the system to prompt for issues or design input formulae for the system users.

4. Purchasing Software: It is common for Software Houses to make little if any profit on the packages they sell. It is the ancillary services that will pay the dividends for them. Watch out for:

  • Training: This is usually charged Per Person Per Day outside of the initial project sale. So make sure you have plenty of training built-in upfront.
  • Reports: When purchasing the system you will need to make sure that the report templates you need are available at no additional cost as this is one of the main reasons you are buying the product.
  • Maintenance Fees: These charges can vary, but is usually based on a percentage of the initial sale per year, the number of licences purchased or the amount of known users. Either way you should make sure that the first year is free of this charge as you will need to contact Support regularly during the start-up phase.
  • Licences: Industrial software (i.e. not 'Off the Shelf') is mostly based on Licences purchased at the point of the initial sale. A Four user licence will mean that up to Four people can logon to the system at the same time regardless of how many Workstations it is installed on. Check there is a Time-out option that will close down a user (therefore freeing up a licence) after a set period of time. Check the cost of additional licences.
  • Customisation: If possible try to avoid this as this will not only increase the costs considerably but will probably cause issues when Upgrades come out.
  • Data Conversions: You will never get a perfect 100% correct data conversion from your old system (or Excel sheet) over to your new system. It can be a messy job but can save a serious amount of time when trying to get your new system started. Your Project Manager (from the Software House) should discuss this with you.

5. Training: Knowing a package and being able to train it are two different things. You will need to be able to field questions from all sections of the company up to director level with confidence, demonstrating that you know the answers or can provide a work-around. On top of this you will need to keep control of the training course, show that you can listen and evaluate the trainees concerns. Never try to hide or side step issues as they will get bigger.

6. Ownership: In order for the system to work you will need the cooperation of everybody who will use it. Full disclosure in advance while involving the resources in the implementation process will help later when you expect them to start using it.

7. Data Capture: Once your system has been Installed \ Configured the next step is to input data. At this point it is vital that you follow set Goals and Targets that are realistic in the systems roll-out. Take a set area, product etc. and try getting this working before diving full in. If this works fine then move on to the next. If not then you will only need to tweak the small amount of problem data before trying again.

8. Software Tests and Validation: There is no such thing as bug free software though you may find simple applications come close. Ask for the last Software Test Results and notes on system Patches, plus a list of Known Bugs. If you are required to Validate your system (typically this will be in an FDA Pharmaceutical environment) then you should ask the software house to provide the Protocols. They will charge for these but this will be preferable to creating the extensive documentation yourself especially when they know the systems inside and out when you do not. If possible investigate to see if they can provide a resource or advice on who to contact that can provide the service. This is a very time consuming process which will involve full time resources.

9. Hats: You will only understand how to implement the system if you can wear the hats of the different users. They all have needs and concerns which are important to them so you will have to see them from their point of view.

10. Project Plan: A Project Plan is not just a Gantt Chart showing events, but a combination of documents that let you control a project with all its Deliverables, Responsibilities and Risks. Constantly review the plan with the resources involved.


 
 

    Copyright © Fenetra 2008