Too Many Business Requirements from End Users
An ambitious project using MSFA failed due to demand-overload
My company started an ambitious project to run our entire ERP (Enterprise Resource Planning) system as a web application, and they were prepared to throw a lot of time and resources at the project to make it work.
We hired a consultant who had experience managing large scale projects and also had an extensive background with writing web applications. We even hired additional staff solely for this project. Despite all of our efforts, the project still ended up as a costly failure.
Now, there were a number of reasons why the project failed, but I would like to focus on what I believe to be the most significant problem: “too much, too fast.”
First, let me provide a little background on the software that we are currently using for our ERP. It is approximately 10 years old, and extremely limited in what it can do. Although it supports some standards such as SQL (a given for any database application) it has a number of bugs that prevent these features from being usable, meaning complex workarounds are necessary for almost every facet of our business.
There are upgrades for the software that fix these bugs and expand functionality, but since it is an “off the shelf” retail application upgrading all of our existing systems is prohibitively expensive. Especially considering that the most recent version would not satisfy all of our business needs and would only be viable as a temporary solution anyway.
We have done pretty well with what we have available, but it is just not enough. Admittedly, many of the problems we have are not with the software itself but with how we use it (and abuse it).
This project, which we started in november of 2007, was not the first attempt to migrate from our disfunctional ERP system, however it was the first attempt we had made using a proven methodology instead of just “winging it”.
You may have heard of Microsoft Foundations for Agile Software Development (MSFA) before, which is the methodology recommended to us by our consultant.
Part of this process involved defining Business Rules (what the current software does now), Business Requirements (what the new software would be required to do), and Use Cases (examples of how the current software is used).
All of this is intended to give a very clear definition of what functionality in the old system needs to be preserved in the new system, and what it will be expected to do better.
So if we allocated plenty of resources for the project, followed a proven methodology, and had experience from failed projects in the past, then why did this project fail? I believe the reason that had the largest impact was the fact that the end users both defined the business requirements and approved them.
Needless to say, this is a recipe for disaster since end users are focused on entirely different problems than developers are. I’d hate to use a car analogy, but if we were building a car, the end users would be more worried about leather seats and air conditioning, while we the developers are just trying to get the engine and transmission to work together so that we can move forward.
Now don’t get me wrong here, nobody knows more about what a system should do than the end users, since they are the ones who have to put up with it.
Ideally, they could provide a wish list of things they want the system to do and the developers could prioritize them based on how feasible they are. Unfortunately, there were several people at each development team meeting that probably should not have been, prioritizing power windows as more important than having a windshield.
Although this project left a bitter taste in my mouth, I learned a lot from it.
As of today I have been told that the project “isn’t dead, it’s just sleeping”, suggesting that we will pick it up again sometime when there is less going on.
Fortunately, I’m not that naive and I can see that the project as we envisioned it this time around is not only no longer reasonable, but should not even be considered desirable.
What we need is to get back to the source of the problems we are having now, and carefully work out as much of the details as we can before we start hiring additional resources to help.
Comments
Leave a Reply
-
Buy a Review!
-
Sponsored Links
