A FEW THOUGHTS

Going through some of the “lessons learned reports” from previous projects I’ve come up with a list of my 11 main lessons from running IT implementation projects. There will certainly be more along the way but these are very important I think;

1. Get involved from the Start
   To take over a project from someone else, or to get involved as PM when the project is already on it’s way is something you need to be aware of. When your company or customer alreay have signed agreements with third parties that will affect your project deliverables you need to go through it and as soon as possible raise a warning if needed. To have the IT department or provider with its PM involved at the earliest stage is important. Maybe just as a consultant just to oversee contracts, but nevertheless important. Both, if the project is run as a delivery within the organisation or as a delivery to an external customer someone from the IT-management or Project Management should before project initiation do an initial validation of the project scope together with a risk assessment and analysis. If possible the customer should be a part of this even if they have done their own assessment.

 

2. Make sure the customer can ask the right questions
   Either if you are confronting a customer in the project, a part of the organisation internally or a partner of some sort it is important that the stakeholders have the right competence to ask the right questions for your type of project. If they don’t it is your job as project manager to alert them or bring it up as an issue for the steering committee.

 

3. Make sure you have your backoffice support available
   If you are doing implementations that are scheduled for a certain period of time to avoid downtime for the users etc, make sure that you have the necessary support teams available during that time – and within the same time zone. It is nothing worse than being stuck with a problem somewhere in “NeverNeverLand” on a Saturday evening during migration-weekend with nobody to ask. So get support-teams, backoffice-teams and make sure you have ways of escalating if necessary.

 

4. Do not assume everything is as usual
   This part has sub-paragraphs actually:
   1. After, for example, a migration-weekend – do not go into the trap of thinking everything will work. It will not! Something has not been tested thoroughly enough and somebody will complain! It’s just the name of the game. Most of it will hopefully work if you and everyone else has done your job right, but there is always something.
   2. For an organisation going through change or a massive project changing routines etc, it is directly ignorant to assume a “business as usual” attitude through the project. Instead steps should be taken making sure you have a chain of command through the project phases and that resources are kept available. In project oriented organisations one should be aware that a change of organisation affects responsibilities and people taking responsibility.

 

5. Do not underestimate the benefits of a steering committee!
   Large projects should automatically have a steering committee. Smaller projects is often left out in the cold.
   Do not underestimate the benefit of a good steering committee where you have representatives from the different stakeholders, customer and project management. If you run into problems, the right committee can move mountains.

 

6. Theory and practice are two very different things!
   Having a good design is not enough. You have to make it work. That is also affected by lesson no 9, having the right people, but first of all you need quality assurance. Before starting anything – go over the design with as many as possible. Not every Tom, Dick, and Harry – but people that know this area. Get the providers to look at the design and make comments too. Better to find flaws before starting than after.

 

7. Every design has an expiration date
   Do not think something that was designed a year ago will work today without going over it for quality inspection again.

 

8. Every OSI layer counts
   Make sure you do not forget any of the OSI layers when designing,  implementing or troubleshooting. It is all connected, no matter what the tech-guys tell you!

 

9. Make sure you have people who know what they are doing
   You need to both make sure you have people onboard the project that know what they are doing, and that the organisation have employees that can operate this in an operation phase. Hired consultants do not count in this matter. The organisation need to have its competence inhouse if they are to operate it themselves.

 

10. Trust yourself, your instincts and be fair.

 

11.  Take learning from this: