How to Succeed in Information Systems
A step-by-step guide ...
Tie your project to some burning platform (old software going out of support, new regulatory requirement, security vulnerability, or similar) in order to generate sufficient anxiety to secure approval, incidentally determining a hard, and ideally pressing, deadline for delivery.
In order to secure broad support for funding, stoke unrealistic management expectations about what is additionally going to be achieved. In particular, commit to seamless integration with all existing organisational systems and processes.
Determine the budget for the project, prior to understanding the requirements, by what money is likely to be available not by what is needed to do the work envisaged.
Select a project management methodology, but no software development process.
Organise the project so that the technical architect reports to the project manager.
Hire a business analyst who knows nothing about the business, tell them to speak to anybody who might possibly have a distant interest in the system. Assemble a very large business requirements document, distribute it to everybody in the organisation so that they can be deemed to have sanctioned it.
Reassure all subsequent enquirers that, whatever their requirements, they will be met.
In order to meet the unrealistic budget, decide to buy packages rather than build anything. Convert the enormous requirements document into an even more enormous Invitation to Tender (ITT).
Accept the bid from the (lowest cost) supplier that has demonstrated the organisational capability to respond to the ITT by dutifully ticking off items (but not necessarily the capability to develop the software).
Accelerate the project to meet the unrealistic deadline by hiring short-term contractors of unknown capability (probably from the selected supplier who must now make up for their under-bid on the original project).
Cut the training and helpline budget to pay for the expensive contractors.
Further accelerate the project by shortening the testing phase, leaving no time to fix any faults found. Start an acrimonious dispute with the supplier about the residual bugs.
Remember that you will need a deployment environment and kick off a further major project. In the interim decide to run the production service from the development environment.
Deploy across the organisation in a single phase. Distract attention by changes to another business process.
This is not really -your- project, so don't worry, nothing can go wrong.