Projects are approved and vendors are identified. You think you covered all the basis, but there is something still nagging at you. What did you forget?
Here are a few things to consider:
2. Policy changes
3. New Procedures impacted by the project
Each of the above issues are internal that must be addressed by the organization and your software vendor cannot help you.
Budget issues are often the result of thinking that the costs of a project is reflected in the vendor supplied contract. Software installations often only include the price of the actual application which often includes just 20% of your cost! When you add all the other factors such as Interfaces, Maintenance, Hosting/Hardware and Internal Resources then you realize that you will be going back to the proverbial finance well.
Policies are not static. They need to be reviewed with every new project to ensure that it is not impacting current policies, and maybe review if the policy needs to be changed to reflect new processes or initiatives.
Procedures execute the policies. It details how you are carrying out the organizational Policy (married to the Mission/Vision) and how employees can accomplish consistent quality standards to meet organizational goals.
Training is never a vendor responsibility. It sometimes is included in your software contract but should never be “outsourced.” Training is ALWAYS under-valued by organizations. The software training needs to be tailored and customized by the organization and tightly weaved into Policy-Procedures. You end up with your own Organization’s Training curriculum. This is the glue for your project that fits all the pieces together. Outsource it to the software vendor and you get a vanilla training focused on technology and not operations. This results in a missed opportunity.
Accountability is the uncomfortable conversation that people don’t like to have. It is the expectation of how your employee’s certify proficiency in not only using the software, but carrying out your policies and procedures. But most importantly, what are the steps taken when they fail to meet those expectations. You end up having to involve Human Resources to make sure that this is fully thought out.
Project success is quantified by pre-defined metrics. They may be tied to an ROI or revenue target. Ironically your software vendor will be in “software maintenance mode” while your still trying to figure out what went wrong. One of the projects I was involved with was so focused on the software that they totally missed all the internal impacts. We ended up holding the project for an additional two months to address the above 5 items and leverage the software to impact organizational change.
There is no such thing as a Software Project. Each project impacts your operations and it cannot be outsourced out to your technology team or the software vendor. Success only comes with the “Constancy of Purpose” tied to the organizational Mission. If it doesn’t help the Mission, then why are you doing it?