Prince2 is a project management methodology which has also been described as "a language of change". It applies a product based approach to planning, and has a strong emphasis on Organisational Structure. It is widely regarded as being the best practise approach to Project Management.
Criticisms of Prince2 accuse it of being over bureaucratic, too paper based and point to public sector IT projects as examples of where it fails. However, Prince2 is not prescriptive. Each project should be assessed on its own merits to determine to what extent or not the Prince2 methodology is applied.
If a project appears to not be working this is usually a Project Management issue, not Prince2. It doesn't manage the Project.
You don't have to go for a "big bang" approach and switch on every feature for day one. Get the basics right first. If there's a problem with the frills it can cloud over everything else and have an adverse impact on user confidence.
Keep your eye on your internal control environment. People, not computers, are responsible for these. Remind them lest they abdicate this responsibility.
Poor scope management is oft cited as one of the key reasons for project failure. If it's not in scope do you really want to be doing it? There will be an impact on the rest of the project. Change management is the process that should handle changes in scope.
User expectations should be managed, kept in perspective and restrained. Don't promise them all the features. They need to focus on getting the basics right and not on some magical future where the system solves all ills. You can run your business with the basics. The "nice to have" can follow later.
Ownership of controls rests with people, not with programs. This is worth repeating. Ownership of controls rests with people, not with programs.
No matter what the system is there will always be a need for it to combine a series of manual controls. It's an important point to appreciate. The computer isn't responsible for the internal control environment and you shouldn't shift that responsibility away from staff and onto the software.
Allow for flexibility in your timetable. You need key milestones but don't get too bogged down in the minutiae of the timetable at the expense of quality. Step back. What's important?
That's the result you're looking for.
Always keep in mind the outcome you want, the integrity of the basics, clean data, user buy in, and a successful conclusion to the implementation.
Inspired Notes
Resources