Is your project a technical project or a change project?

Many projects fail to achieve the business results that were expected when the business started to plan for them. The basic reason is that the projects are seen as technical projects, that is, delivering a new piece of software that may be necessary to automate a business function.

While that software may be required to deliver the function, it is seldom sufficient. The software assumes that certain things are in place (I know that software can't assume, but the programmers do). In many cases, the software creates the opportunity to build a new business process. That business process would not be possible without the software, but it seldom addresses all of the problems. The changed business process may require changes in roles and responsibilities, new interfaces between people and departments, totally different activities. If those new functions are planned for, then the process falls down. In many cases, new approaches are developed after the implementation. Although this works, it is seldom efficient.

If the process is designed when the software is developed, all changes can be planned for. In many cases changes to the process can be completed before the software is implemented, thereby gaining some of the benefits early.

Don't assume that a technology project is a technology project, to be left to technicians. Make it a complete change project and paln for all of the activities that the technical people probably won't think of.