Define your business.

When developing business processes try to keep everything as simple as possible. Simple processes are likely to be followed: complex ones won’t. This is definitely true of written procedures, but human employees have the ability to sift through the junk and ignore it; you may not like that but it’s true.

Computers on the other hand don’t share this aptitude. Your software developers may try to ensure the software follows your monolithic procedures, but the conflicts ignored by human employees will have to be resolved; a long and expensive process.

A systematic approach to this analysis can help, especially with the inevitable documentation, take a look at business process modeling and the OMG notation.

Well implemented processes will be familiar to your staff and any software based on them equally so, saving a fortune on training.

What is success?

Now you’ve got a minimalist set of effective processes, you’re in a position to consider how the application of software and hardware systems might improve or expand your business, and bear in mind that it might not.

What will success would look like? It too needs to be defined as simply as possible if you’re going to recognise it. Frequently at the start of projects everyone is so excited that this step is lost. It is either overlooked or results in a requirements document so complex nobody can be bothered to read it.

Ask yourself how many other business purchases you would make without actually considering what you’re expecting to have delivered. Would you be happy if you were hoping for a photocopier and ended up with a filing cabinet?

Get involved.

Most organisations expect their involvement to end once they’ve specified their requirements. The developer will go away, build the software, and deliver it perfect and on schedule. OK, maybe that’s an exaggeration, but placing your staff in the development team is not an optional extra.

They’re likely to spend substantial time working closely with the developers, it’ll be worth it, you’re likely to get a better system. Most will be involved in user testing, but the customer representative is a key role representing the business interests within the team. Customers are not project managers, they are focused on the benefits to the business and its operational goals.

Primarily involve people that actually undertake the work this system is meant to enhance, and those that will continue to use it. There’s a huge temptation for senior management to attempt to fulfil this role, but they usually know next to nothing about the processes in question, so resist it. There is a vital role for senior sponsorship, but it’s not in the development team.

Resulting software will be intuitive, and the computer literate will be able to understand it based on their knowledge of their current job, and of course your procedures.

The pay back.

Get the basics right — develop good business processes, define success, and build an effective team — and your project has a much better chance of delivering satisfaction, on time, and to budget.