Don't forget the process

By mOrPhie on Friday 11 September 2009 00:29 - Comments (4)
Categories: business, software engineering, Views: 2.656

A lot of line-of-business software automates a previously physical process. For example: project planning used to be a process on the white board and paper schedules, but nowadays this is done with software. Planning a project can therefor be done faster, cheaper and better.

An anti-pattern of line-of-business software development is developing unneeded software. It seems like a great idea and software is used to spawn the new business opportunity. The process and business case are forgotten. The risk here is that the software won't match your expectations because there is no cohesion between the software and the underlying process.

So, if you want to be safe: set up a business case, define the goals, define the process and be sure it works. Use software to support the process instead of being the process and dodge a lot of frustrations.

Volgende: Quality vs. Functionality 09-'09 Quality vs. Functionality
Volgende: Problems migrating a VM from Virtual Server to Hyper-V 02-'09 Problems migrating a VM from Virtual Server to Hyper-V

Comments



By Tweakers user FatalZero, Friday 11 September 2009 09:09

A very compact but solid blogpost! The before mentioned is exactly the reason why business analysts are so important to a project.

By Tweakers user MrX, Saturday 12 September 2009 17:59

So, if you want to be safe have a decent chance of preventing failure: set up a business case, define the goals, define the process and be sure it works. Use software to support the process instead of being the process and dodge a lot of frustrations sure road to failure.
Fixed ;) Also underlined the important parts. Quality is all about process: both the process by which you build software and the process that your software is supposed to support.

The first one refers to the "heroic programming is not a sustainable business practice" principle. The biggest problem with the second is that people forget how flexible people are: they are and will always be much better at dealing with deviations from a process. When a piece of software is not able to accommodate that, it only hinders. This is why software in 99 out of a 100 cases should only support people and not attempt to replace them.

As a side note: It would be interesting to create a list of criteria of business processes where software could replace people instead of just support them. I think that when this list were to at some point to be complete, people would be shocked by how long and strict it would be.

[Comment edited on Saturday 12 September 2009 18:05]



Comments are closed