Guilty of Over-Customising
-
Comments posted to this topic are about the item Guilty of Over-Customising
-
There's what users want and there's what users need. If you are lucky there is a lot of overlap between the two.
I find that over customisation has many causes- Users dictating solutions rather than discussing problems
- Poorly defined or understood business strategy so solutions not aligned to the coporate need
- Failure to understand the commercial aspects, TCO, ROI
- People too far down in the detail and not seeing the bigger picture.
- Someone's bonus depends on a quick win
-
One of the greatest challenges of managing projects is stakeholder buy-in. Stakeholders must agree and sometimes compromise on what project success looks like. It is tempting during a project to downplay or ignore the long term consequences of project decisions in favor of the short term squeaky wheels. The project manager should consider and communicate the long-term analysis of costs for significant project decisions and let the stakeholders work it out. It does not make you loved by anyone but you at least have a chance of being considered a success. I am guessing that in your scenario the decision would have been the same but at least they would have owned the decision.
- Keith Dunn - Monday, June 12, 2017 6:24 AM
You guessed it right Keith. The Stakeholders at that time did own their decisions and considered this as a success. But they have now been replaced with new members, who seem to have a difference in opinions.
-
I'm replying based on my assumption that this was developed in-house rather than customizing a third-party commercial package. If that assumption is wrong, please ignore this post.
The needs of a wholesale and retail business are *different*. So different in fact a huge chunk of functionality needed for retail is plain missing.
Given that, and given that IT ultimately works for the users who will be using the software, you have to satisfy the users. There's no such thing as over customization, just poor initial architecture. If a change introduces "overhead" (whatever that means in each individual context) then either the original architecture wasn't flexible enough, or the original architects disdain the new requirements and are just dragging their feet.
Either way, that's a high level problem.
Now, if the customization is poorly done (bad implementation, overuse of IT resources, etc.) that's not over customization, that's just a bad add-on, kind of like adding a truck trailer to a 747... 😛
Either way, the bottom line is the application had missing functionality that made it unfit for purpose. I'm unsure from the article what politics were involved (and there are *always* politics at scale, sigh) but anyone worried about "the big picture" darn well needs to finish coloring the book, not whine when somebody else adds a page because the original authors wouldn't!
PowerBuilder had an interesting solution to the inevitable update problem involved in updating versions. They built an empty customizable layer between each layer of their framework. That made it *possible* (not easy, but possible) to keep in-house customizations to the framework when they updated it.
I'm familiar with building flexible architecture, since our company's salespeople have the unfortunate habit of adding weird new lines of business without warning. 🙂 As a result I can offer readers some advice:
1) There are no rules set in stone.
2) Anything they assure you will never change will last exactly as long as it takes you to deliver the software.
3) As a result, constants aren't and variables don't. 🙂
4) Therefore, code by data and make EVERYTHING a property.Call it the Shape Shifter programming model...
-
You didn't necessarily do anything wrong. There was hopefully a steering committee adjudicating these changes and deciding what was worth it and what wasn't. I've never worked at a one-size-fits-all. There is some variation for whatever reason, but usually because it's what the subordinate offices needed to keep their clients happy. There have been some good points made on the previous posts. I especially like the one that said users discuss solutions rather than problems. I've gotten better about asking users what they hope to accomplish, or how do they view the end state. But these don't seem to provide the need for some level of customization. In the end, someone higher than both the IT department and the department wanting the changes should be making the call.
- nitinbhojwani - Monday, June 12, 2017 6:44 AM
Very good point! I forgot to say to get the decision in writing, LOL! The important thing is that you can demonstrate to the current administration that the previous administration made that decision and it was not imposed on them by someone who did not have a stake in the short or long term costs. If the current administration wants to change that now, I am sure you would manage this new project just as well as you did the first one. Cheers!
-
Making the customers happy is one thing, but when the customer keeps requesting changes and adding features, well, that project will never get finished.
I worked for one company where management would not say "Sure, we can make this change or add this feature, but it will cost extra and delay delivery of the project." There were signed contracts that specified the features of the program that would be delivered. Instead it seemed that management suggested "Sure, do you want to supersize your meal and get a biggie drink also?"
The company lost the bank clients because the product was never delivered. But how can one deliver a product when the specifications are a moving target? - roger.plowman - Monday, June 12, 2017 6:49 AM
I'd say the speed of change was inversely proportional to the adamancy of the statement that it won't
- David.Poole - Monday, June 12, 2017 7:25 AM
Poole's Law Of Software Stability: The speed of change of a business rule is inversely proportional to the adamancy of the guarantee it never will.
I LIKE it. 🙂
- I've found there is often a discrepancy between what the business asks for today versus what they really want and need long term. The decision to customize a software package and database to support both wholesale and retail lines of business perhaps was the best decision that could have been made based on the information you were provided at the time. Perhaps the misalignment between the feature set of the application versus the organization's current lines of business was not the result of poor planning on the part of IT in the past but rather a failure on the part of the business today to live up their original stated goal of expanding operations into retail five years ago.
You are in IT, not C-level executive management; so it's really not your job to predict what the organization will be doing (in terms of lines of business). IT depends on the business to give us useful and dependable strategic information on which to build solutions.
Here is what happens when leaders blame IT for what is essentially bad strategic decisions on the part of the business:
Oct 8, 2015 - Volkswagen America's CEO blames software engineers for emissions cheating scandal
https://www.theverge.com/2015/10/8/9481651/volkswagen-congressional-hearing-diesel-scandal-faultMar 9, 2016 - Volkswagen's top U.S. executive steps down amid ongoing probe
http://www.reuters.com/article/us-volkswagen-emissions-executive-idUSKCN0WB2RJ"Do not seek to follow in the footsteps of the wise. Instead, seek what they sought." - Matsuo Basho
- My career has been involved in writing and supporting LOB apps. So yeah, just about everything is highly customizable to the particular situation. Normally that's made the users happy, but I can see how it might not make an IT DevOps group happy. Once I took one of our products and removed the customization so we could open source it. It took me about 2 months to get rid of all of the things specific to us in pages and reports, then documenting all of that so others using it would know where to put in their own organization's banners, etc. It wasn't fun, so yeah I can definitely see how IT groups wouldn't be happy with what I've worked on most of the time.
Challenging article, Nitin. Makes me wonder how I can make it more generic.
Kindest Regards, Rod Connect with me on LinkedIn.
-
I have always said that the barometer for my success in the work place is the smiles on the users' faces whenever I passed them in the corridor. Now, I also have to say be careful of users. One day they are happy and the next they blame you for their failures.
Another thing, a friend who, after 12 years, see you for the first time reminds you of something you thought was a success and they thought differently is not a friend.:ermm::ermm::ermm::ermm::ermm::ermm:Manie Verster
Developer
Johannesburg
South AfricaI am happy because I choose to be happy.
I just love my job!!! - manie - Monday, June 12, 2017 11:43 PM
Yes, it easy for users to love the "helpful" DBA who is willing to bend over backward and cater to their every whim, but when things don't turn out as expected, or when that DBA decides to move on to other things, it's also convenient for those same users to blame him or her for everything that goes wrong going forward. It's best for the DBA to maintain boundaries, stick to best practices, and not allow that type of unhealthy codependent relationship to cultivate in the first place. If that means the DBA is perceived as being "grumpy", then so be it. DBAs don't lose their job because they're grumpy, they lose their job because data is lost or deliverable deadlines slip. At the end of the day, we're more like the pilot of an airplane or a chef in the kitchen, we have a specific job to do. We shouldn't flatter ourselves into thinking we're politicians running for office or rock stars seeking fame and praise from the crowd.
“Public opinion is a weak tyrant compared with our own private opinion. What a man thinks of himself, that it is which determines, or rather indicates, his fate.â€
- Henry David Thoreau"Do not seek to follow in the footsteps of the wise. Instead, seek what they sought." - Matsuo Basho
-
manie - Monday, June 12, 2017 11:43 PM
I have always said that the barometer for my success in the work place is the smiles on the users' faces whenever I passed them in the corridor. Now, I also have to say be careful of users. One day they are happy and the next they blame you for their failures.
Another thing, a friend who, after 12 years, see you for the first time reminds you of something you thought was a success and they thought differently is not a friend.
Yes, it easy for users to love the "helpful" DBA who is willing to bend over backward and cater to their every whim, but when things don't turn out as expected, or when that DBA decides to move on to other things, it's also convenient for those same users to blame him or her for everything that goes wrong going forward. It's best for the DBA to maintain boundaries, stick to best practices, and not allow that type of unhealthy codependent relationship to cultivate in the first place. If that means the DBA is perceived as being "grumpy", then so be it. DBAs don't lose their job because they're grumpy, they lose their job because data is lost or deliverable deadlines slip. At the end of the day, we're more like the pilot of an airplane or a chef in the kitchen, we have a specific job to do. We shouldn't flatter ourselves into thinking we're politicians running for office or rock stars seeking fame and praise from the crowd.
For those who are primarily development DBAs, our job is to help our customers, both internal and external, solve their business challenges. It is not simply being helpful or "seeking fame and praise" to do that job. The users have a role in this as well, and sometimes they don't do as well as they should. I have had the experience of "just one more thing" and eventually I have to pull the plug. But most users know basically what they want. There may be some adjustments once they see the first products. In this case I'll let them know if the changes will affect the deadline or conflict with other priorities. Sometimes the first manager over different affected organizations has to make a decision. But that decision is not ours to make.
Viewing 15 posts - 1 through 15 (of 16 total)
You must be logged in to reply to this topic. Login to reply