It’s a well known fact that IT projects fail every so often. Standish Group has been researching the success and failure factors of IT projects for a decade and a half, and they publish their results in their CHAOS report every two years or so. According to their 2006 report, only about 35% of projects can be categorized as successful, while 65% are declared unsuccessful. In this report, word unsuccessful can mean anything from exceeding time and/or budget (46% of projects) or failing altogether (19% of them). With such a huge proportion of projects going astray, maybe there was something wrong with these projects from the very beginning. Were the time and budget unrealistic? Were the project requirements, or even objectives, unrealistic? Maybe. Or maybe not. How can you tell?
Last time, I gave you a recipe on how to do a bad thing. If you really need to do something bad, I figure it’s better to do it the way that would hurt the least, or the way that isn’t so bad after all. I wouldn’t have dreamt of a comment on that blog post, but Ian came, and gave the perfect example which really explains why things like that *ARE* bad. Funny thing is, how many customers really go for such a requirement, and even funnier, how many consultancies give in. I gave in once, most of you probably did. But, why are mandatory fields so bad after all?
Imagine that whenever you edit an object in C/SIDE Object Designer, and save it, the system automatically saves it in the version history. Imagine that it never simply overwrites your previous version, but keeps all of them there for you. Imagine that you can see all of the modified versions of any object, then make any version the current version by doing as much as a single mouse-click, no tedious imports and exports needed. Imagine that this is true for all of the developers on your team. Imagine that it is completely, fully automated.
Policies are sacrosanct. Every company has them, and when implementing ERP systems policies do come in the way. That’s the way we do it ’round here since forever, is heard rather frequently, but a simple question why can leave a big question mark hang unanswered.
There was an experiment…
Today, I got an e-mail from a reader of this blog, who asked me to help them with an actual problem on a project. Their customer is a small manufacturing customer in textile vertical. Whenever they calculate consumption, quantities for certain items get rounded to full numbers. Since the items are usually textile, measured in meters, a consumption of 1.27 meters can end up registered as 2 meters instead. Not that it’s something which can’t be overridden manually, but it is pain in the butt, and hey, why do we have computers in the first place if we have to do their job.