Re: Standard systems...
Yes. But our system is more of a programming framework with a workflow to our needs that we initially bought off the shelf and then customised so we could do the job more efficiently. They have a system that is hard coded for their job in C# by external providers.
As a result, in our enviroment when changes come in we sketch a new process out on the existing documentation workflow, everybody agrees that it's correct, a test branch goes in and people use it once to ensure that it does what they thought they were asking for, and when they agree then we put it live. This typically takes us a couple of hours, because that's how long it needs to take.
In government IT going by the Price2 method they worship they'd be first having a change management meeting to
- Agree whether or not there is sufficient justification to proceed with the project
- Establish a stable management basis on which to proceed
- Document and confirm that an acceptable Business Case exists for the project
- Ensure a firm and accepted Foundation to the project prior to commencement of the work
- Agree to the commitment of resources for the first stage of the project
- Enable and encourage the Project Board to take ownership of the project
- Provide the baseline for the decision-making processes required during the project's life
- Ensure that the investment of time and effort required by the project is made wisely, taking account of the risks to the project.
After this then the project board needs need to appoint a project manager with correct terms of reference, who needs to appoint change managers in each of the affected areas to explore the impact on affected individuals etc. When they get to the next program phase and have everything firmly specced then they can consider putting the programming work out to tender.
To put this into perspective, before they have had their first meeting to decide if they have justification to have a change management project, we've scribbled on our existing workflow documentation with the changes that are required by the new legislation, other managers have added a few new scribbles and crossed out others where they figure "if you do this here then you can save a step later here" and finally we draw it out again minus all of the crossed out bits, most people agree that's the way to go (except the guy that gets the acidic comments from legal about "yes, doing it that way would be easier, but it's also breaking the law"...!) and have programmed the changes up in test.
This then gets "tested" by overly harried staff who don't really care and just sign it off regardless, and then gets put into production and tweaked slightly a few months down the line when somebody realises that you could trim a step off by ammending an earlier form. Afterwards we sort out the pretty flow diagrams for the documentation for doing it again next time.
I suppose you could call this agile development if you squint at how we go about ignoring most project management essentials. We just call it quick and effective, because it wastes less of everybodies time.