Closed. This question is off-topic. It is not currently accepting answers.
Want to improve this question? Update the question so it's on-topic for Stack Overflow.
Closed 13 years ago.
Improve this question
In our main product, we've got a feature request that's been around for a couple of years now that's been requested quite a few times. It's technically easy to implement, the problem is that it will fundamentally change the concept of what the tool does, and will likely cause more bug reports as people mis-use the new feature to match the new concept (which we won't be able to work around). We've got a separate feature that works around the issue quite well, but we still get requests to implement the new one.
Should we
listen to our users, and implement the new feature, even though it changes the concept of what the product does and what we want it to do, and will increase support costs
add some more support articles explaining how to use the workaround
make the workaround more obvious in the UI so the users find it more often
something else
Implement it as a plug-in.
It will be available for users who really want it, but won't fundamentally change your product.
Most users won't end up installing it, so your support base will be smaller.
It won't get in the way of users who don't use it.
If this feature runs counter to the philosophy of your product, it indicates that the product does not conform to the mental model of your users. The consequences of that are much larger than just a single missing feature. You need to get inside your users heads, and figure out how to adjust your model to their expectations, or guide their expectations towards your model.
Put enough thought into this and it could become a great opportunity for you.
In 'The Mythical Man Month' (which you have read, haven't you?), Brooks says words to the effect that 'conceptual integrity of the architecture is the most important thing'. That means that if the requested feature breaks the conceptual integrity of the overall design of your product, you probably should continue to avoid implementing it, regardless of how much it is requested. Or, you need to reshape the architecture so that the requested feature fits into the revised architecture.
One of the products I work on has a 'much requested feature' that was added. It behaves unlike any other feature in the product. It is a horrid wart. But since the competition does it, we had to do it. But instead of remaining true our architecture (which happens to differ fundamentally from the competition's in this area), we aped the competition's feature, down to silly details.
I still bitterly resent the fact that the feature was botched into the system with broken semantics w.r.t the rest of the product. To rub salt into the wound, I had to present the new feature as the 'greatest thing since sliced bread' to our customer base -- that really hurt.
Having said that, no-one has complained (as I think they should) about the feature. It probably gets used sometimes. It is one less difference that the competition can use against us.
(And note: I was not against the feature being implemented in a style consistent with our product's normal way of working; I was only against it being implemented in the style that our competition uses - because the other related features work analogously to the broken implementation in their system, whereas our system is more sane and friendly.)
It's tough. Sometimes the market wins out.
It's almost impossible to answer this, as we don't know exactly what you're talking about.
Having said that some points:
The number of users who actually want the feature, probably are far higher then you think, as most users will never log feedback.
You describe a 'workaround', this implies your product either has a problem, or it's UI needs to change.
I'd be inclined to implement it, as this will make your customers happy.
An option would be to give them a menu option, which directs them to both methods.
Possibly a wizard of some sort, which helps them decide which workaround to use.
I would try to re-design the UI for your work around to make it easier and more obvious for your users. At the end of the day, the customer pays the bills so we have and obligation to meet their needs. When what they ask for will cause more problems, it comes back to us to offer a different solution such that we don't create more future bugs, and we still keep the customers happy.
While not a programming question, I've seen quite a few people over the years struggle with this type of issue.
You need to ask yourself a few questions
1) Have you, or management, done a cost-benefit analysis?
Ask yourself "How will the feature.."
increase sales? i.e. will more people
buy it
decrease sales? i.e. loosing customers that are put off
impact customer service?
2) If the product will change radically - would it make sense to spin it off to an entire new SKU?
3) Management will get what they want in the end. Do you want to work with them to provide your customers the best experience possible & be the hero, or against them and look for other opportunities.
Define "our users". Is it 5% of your user base, 80%, 95%? Have you surveyed enough of them to find out if this is something that the vast majority of the users want, or is it just a rogue group of users (they can be the most difficult and hard to please).
I think that needs to be established first. If it's the majority of your user base and it adds value in their eyes, then I would try to reach a compromise where you meet in the middle, not compromising the integrity of your product, but still offering the customer an alternative solution that would still meet their needs.
Announce the workaround as the solution to the request to those who have requested it. Make the workaround more prominent in the UI / easier to use.
I would go with whatever has more potential ROI. Will you increase profits by implementing this feature? If so, does that exceed the cost of supporting the new feature? If potential profits are greater than your support cost, I'd suggest going with the feature.
If there is no gain to be made either finacially or by lowering costs for support, then it makes no sense to do it.
I'd go with a simple guess at the cost (in terms of usability) versus the benefit, at least as a major factor to weigh. For example, if the feature will likely help 45% of users but make the program harder to use for the other 55%, don't do it.
Related
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 3 years ago.
Improve this question
... and how to prove to management that use-cases can be informal and still useful?
Hi folks,
I came in the middle of a project and found out that there are no use-cases, user-stories, requirements, neither anything similar to a specification. Since the deadlines are short, the current dev team don't want to spend time on such things. I wanted to join that project, but by digging more I found out that the current development adds features just by considering their "wow-effect" and chooses what to add just by using the easiness that the underlying technology provides. I was surprised how they have managed to go so far (more than 4 months) without requirements, but this is what we have now. I believe that the way they have chosen is the most sure one to kill the product which has a good marketing value.
Am I right, and what would you do in a similar circumstances to prove the dev team/management to make use-cases/requirements before moving forward? Thanks in advance, kh.
P.S. Two copies of Cockburn's book are on the bookshelf...
You should give your colleagues the use-case spiel :D Tell them that use-cases are useful as they're:
A way of capturing business processes in a manner which is reasonably comprehensible by all stakeholders. This helps to bridge the gap between programmers, clients and users.
Traceable units of functionality. Use-cases are formed (ideally) in the analysis phase, referenced in the design phase, and can be used as sources for test cases later on.
Quick and easy to write up and useful, even if informal.
If you need more ammunition, you might want to read Use cases - Yesterday, today and tomorrow by none other than Ivar Jacobson.
If your colleagues still can't see the potential usefulness of use cases as a business analysis tool, then they're probably beyond help :P You should remind them that they're developing software to meet other people's needs and solve their problems in the long term, not to ostentatiously impress them in the short term with petty gimmicks. And so a little bit of direction and specification helps. Even if the use-cases themselves don't prove to be that useful, the simple act of coming up with them will force your colleagues to consider the actual underlying purpose of the software.
Ask questions, of both sides. Of development, ask them if they are certain that all of the ways in which they have considered using the application are all of the ways in which the end-users will want to use it; if they say they have, ask for proof. Of management, ask if they've ever used software that does everything they want, but still ends up being hard to use (they will have). These questions will seed the concept that what will be delivered might not be what is desired, on both sides; use that seed of an idea, then, to open up discussions (not documents, not at the start) on how the software will be used, and in what way any differences can be resolved. They'll get around to use-case documents eventually.
I am a product manager by profession, and my first reaction to your post is that ideas can come from anywhere, and if the dev team has decent ideas they should be incorporated into the product.
Having said that, a product can not develop a soul (a simple message) through a string of disconnected ideas that do not serve the ultimate purpose: solving the needs of a target user. And, ultimately it boils down to making the case that time is better spent on requirements/use cases that make sense for the product, while the opportunity cost of not having a clear strategy/end goal will lead to too many chefs and a jaded product message.
The ultimate way to make this message hit home is to involve other stake holders and have development demonstrate their work. Eventually, there will be disagreement and a more formalized (less cowboy) approach will lead to a more refined and simple product.
One of the problems you mention is tight schedule and scope creep induced by the devs themselves. Explain them, that by using use cases you can earn time by dropping features, which will potentially end up on the "never used" pile. With use cases you can find out what are the features customers need and will pay for and by removing unimportant features out of the scope you would have time to implement. Use cases apart from defining the scope also help to identify all the stakeholders, which might help you to focus even better while defining the scope and prevent forgetting about trivial things, which are not so apparent, but are a must if the product should be usable. The third most important thing about use cases is that they allow you to start thinking about corner cases which might be important for the customer before development and therefore you can find out with the customer what would be the ideal solution instead of letting the coder decide on his/her own under pressure of deadline.
Just show them.
Example is not the best way of educating people, it is the only one.
Lead by example focusing on extensions and exceptions. In other words emphasize the failure scenarios because everyone knows how the system should work. The real value of written Use Cases is identifying what should happen when something goes wrong.
That noted, consider you may have to live without written use cases. And, for the environment you describe, a major win is any sort of requirements documentation. Screen comps and/or prototyping are often easier to introduce.
Closed. This question is off-topic. It is not currently accepting answers.
Want to improve this question? Update the question so it's on-topic for Stack Overflow.
Closed 10 years ago.
Improve this question
I am a first time intern at a large corporation and I created a GUI tool that lets my coworkers visualize the log file that their product produces. The tool, known as MRI, is nearing completion and I face a conflict.
One party, (Two ambitious Indian guys that live in California) want me to adapt MRI to a new format and to display much more detailed information. The current version of MRI is built around the idiosyncrasies of the 20 year old log file format. In my opinion it is a bad idea to attempt to grow a more powerful, more universal tool out of a less powerful and idiosyncratic one (Better to start from scratch; something I probably don't have time to do).
The other party is composed of several marketing types and my father. They are drooling over the shiny new GUI that I slapped on top of their crazy old log file, and every one of them wants some feature that would help them with their day to day work.
Whom should I please? I just want to code. Which path will lead to less dumb conflicts like this?
Sounds like you are getting your first taste of the world of a manager! I'm doing exactly the same thing 10 years later, with a much bigger budget and head count. So it never really ends.
I love the answer about doing some time estimates for each requested addition, and then sitting down all parties and working on a negotiation that gets the greatest degree of satisfication. I'm betting that since you are an intern, and many of the people you mention have seniority, that they will be able sort out amongst themselves who has the biggest stake and most power in the situation. But if not, don't hesitate to act as moderator -- after all, this is your project.
Other things to think about:
Types of stake holders:
Customers - the person who controls the budget is often the most powerful of stakeholders, after all, they control your ability to do the work by controlling your funding. For an internal tool, this is probably an internal stakeholder, but it may be someone from a non-engineering group, if this tool is for a non-engineering purpose.
Users - in the long run, users often make or break a tool. They definitely determine the tool's longetivity. It's not unusual, though, for users to lack advocates. And in a big internal project, it's entirely possible that users are not the customers.
Technical Management - particularly when you are an intern and when you are working on an internal project, technical management is the group that's most important for you (as an individual) to please. They may have their own stake in the feature set, as they may be looking for a certain feature path for the product that fits a long term technological end game. Ideally, they should be on your side, and helping to figure out the best feature set.
In a big company, hopefully these roles are really well defined. Probably with an org chart. But not necessarily. And in a group that's used to working together, they may not make it really clear to a new comer exactly what the official roles are. As the guy doing the work, you're job should be to accurately and honestly tell them your best guess on what effort it will take to get the feature done. And to be open to ideas for making it cheaper/easier.
Negotiation:
The best negotiation advice I've ever gotten was "A good negotiation is one where everyone thinks they won". Sadly, the frequent outcome is that everyone feels equally screwed. The trick between every stakeholder leaving happy and every stakeholder feeling beaten down is to see the big picture and be innovative about getting everyone's needs met. In the end, no one really cares how you do it, if you can make their jobs easier, they will be happy. So finding features that serves everyone well can be the key to resolving the conflict.
Being able to do this well will really make a positive impact on your bosses. This is an extremely rare skill, and this type of finesse does get noticed.
Not having it does not mark you as a pariah, however, not many engineers enjoy negotiation. And it's never worth making every engineer be good at it. It's far better to find an engineering manager who is good at negotiating and to let them be the "speaker for the geeks", so the rest of the engineers can do their work in peace. :)
Sit the two parties down in the same room. Show them a list of the features each has asked for and how long you think each will take. Then explain that all of it is possible but all of it takes time, and ask them to come to agreement on what they would like when. Note down what is agreed and mail it to everyone afterwards so there is a record. Don't forget to pad your estimates to allow for testing and debugging time.
Alternatively, work out who the person directly responsible for managing you is, implement what they tell you (feeding back estimates of how long each thing will take) and tell anyone else who asks you to implement anything to go talk to that person to get it on your schedule; then doing the above management work becomes their problem.
Explain, if doing one of the above does not cause the matter does not resolve itself, that the Californians' features would require a refactor, and if you are going to do that you would rather hold off implementing any features for the other party until that is complete since doing the same work twice is wasteful.
Closed. This question is off-topic. It is not currently accepting answers.
Want to improve this question? Update the question so it's on-topic for Stack Overflow.
Closed 9 years ago.
Improve this question
How do you cope with that?
Is it normal to allow the costumer to change the software as often as he wants? I´m working in a environment where there are no specs and constant requests for changes.
For every new costumer we have to create a new branch and makes so many changes that by the time I finish I have a complete different product. I´m pretty much losing my interest in programing because of that.
So, am I wrong to say that the costumer should not be allowed to change the software at his will?
English is my second language, so please excuse any mistake.
Related:
How to deal with poorly informed customer choices
EDIT: I originally missed the part that you have many customers and are customizing a single piece of software for each. I'll leave my original answer for reference, but it's not really applicable to this particular situation.
In your case, I would suggest that you need a different tack to addressing customer concerns. One technique I have seen used is that any changes need to be consistent with making the product more useful for all customers. This would mean that you can say yes to many changes. For example, making the UI customizable via templates. That would benefit all customers, but may be driven by a particular customer's desire to fit the look-and-feel into their standard. But it would also mean that you need to say no to some requests, or modify them in a way that they are generalized to be useful to all.
You may also want to have your customers use something like UserVoice to make feature (and bug) requests and vote on them. This allows your customers to have some direct input into the direction of the product, but forces the requests to be filtered through all of them. Again, you need not always accept the highest rated requests and you can accept some lower rated requests. The guiding principle ought to be making your product useful to the widest range of customers.
I don't think that it's practical to have a separate, custom branch for each customer unless you plan to have only a limited number of very high-paying customers. Eventually, your version control system will become your bottleneck and not allow your company to grow or even serve your current customers well.
Once you get into a more sustainable feature selection mode, my original answer may still apply. Hope this helps.
Original
I'll say up front that some customers are just not worth having. Only you can tell when this is the case.
Typically, though, it's our job to discover what the customer actually needs and deliver that. I'd recommend following an agile development methodology to do this. Rarely does a customer actually know up front exactly what he needs. Even more rarely does a developer understand what a customer needs before they start writing code. Agile methods embrace this reality and follow practices that make change less damaging to the process.
First, agile methods employ lightweight processes and delays making decisions until the latest possible moment. There is "just enough" up front planning to lay out a basic architectural framework, but for the most part it is design-as-you-go. This is not as freewheeling as it sounds as the techniques used in agile methods, such as TDD, pair programming, refactoring, etc. are sound techniques that encourage good design and design improvement.
Second, agile methods are light on documentation. While not documentation-free, these methods keep document maintenance to a minimum. One of the worst aspects of change is that documentation becomes dated and must be constantly updated to be correct. Agile methods identifies those documents that are truly useful and maintains those, but other documents that become out of date can be discarded. They are used in the moment as needed, but you are not tied to them. Agile methods put a premium on the code, and tests, being self-documenting.
Third, agile methods encourage a cooperative form of development based on mutual trust. This goes both ways. The customer must trust that you have their best interests in mind, while you must trust that the customer knows or, at least, can recognize what he needs when he sees it.
Lastly, the hallmark of agility is release early, release often. Getting the product in the customer's hands early is the best way to get feedback (again, early) on what he really needs. Once you have a concrete product you'll start getting information on the changes that really matter. By planning to release early and often, and coupling it with other agile practices, you'll also build a framework into which change can fit more easily.
Even when following these methods, though, as I said earlier: some customers are not worth having. If your customer doesn't trust you enough to follow your advice when a change is bad or if the customer doesn't know and can't recognize what he truly wants, then there may come a time to sever your ties with them. I'd suggest that talking with them and letting them know that you want to get them what they need, but they need to know what that is. Spend some time talking about it so that you both have a better understanding of the goal and put into place agile methods to deal with the reality of change. If they are still unreasonable, then perhaps it's not going to be a good fit for you.
am I wrong to say that the costumer
should not be allowed to change the
software at his will?
Who owns the software? You or them?
If I own a house, I can hire someone to paint it in a different color every week if I want to. If the painter complains, I can get a new painter. If I run out of money, maybe it is because I am an idiot. But the painter did nothing wrong in painting my house, getting my money and using it to feed his family.
If I own a certain software, I am allowed to do whatever I want with it. And if you don't do it, then I'll ask someone else.
specing out the app is as important (more even) then implementation. Giving the customer at least a base line document, UI mock up or something like that i think is critical.
you have to accept change requests as the system evolves and matures, otherwise the system will suffer from entropy and any hard work you have put in will be lost forever. if it is a more commercial product try and restrict to changes that all your customers want. then everyone is getting added value.
If you have baseline documentation you can then charge for customization. the less you want to do the customization the more you charge :P make sure you document and estimate all the change requests. (i use fogbugz for this but there are many other tools out there) If the customer is paying for the changes then at tleat you will be getting renumerated for the pain of changing the system.
Your company is running itself hopelessly into the ground.
You should go job-hunting immediately.
before i put forward my suggestion, i should say i personally believe that a business is there to make money. so if a client is willing to pay for something they want, figure out how to accommodate them (rather then turn them away).
now, a solution:
i was at a company where they had a software package which they sold to many government organisations - each with their own particular tweaks and features.
i asked the managing director how they avoid version hell - considering they have to maintain a specific version for each client. he said "we dont, everyone gets the same version". they simply maintain one version for all clients, but switch off features which arent specific to a client.
LM
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 3 years ago.
Improve this question
I read
what-payment-structure-do-you-use-for-small-projects
and I wonder how you guys are dealing with bug vs. feature. I once had a situation where a client wanted static reports. Then near the end of the project after most of the work on reports had been done he said he had always wanted dynamic reports. That change was not easy, because framework we choose did not support dynamic reports. It was a weird situation, because client had a programming team, so they should have known. Maybe it was just a lack of communication skills.
How do you guys deal with clients trying to make you add features, because they forgot, change their mind, or were misunderstood?
I mean big features, not small ones.
EDIT:
He stated that the budget is fixed and can't be changed and that this feature (like every) is critical and without it they wont accept the system. (just worst case scenario)
In my experience, having been on both sides of this issue, this is usually more about economics than it is about programming, process, or project management.
We, the client, often say "it may be a feature, but if we call it a bug, maybe we can get them to do it for free."
In the end we, the programmer, charge or don't charge based more on whether it will help or hurt our chances for future work. We, the client, dangle the carrot of future work as the incentive to get the programmers to do the extra work for free.
I don't believe any of that will change just because we have a better process for saying "this is a bug" or "this is a new feature."
It is important that both sides understand what they're getting for their money very early on in the process of software development. The Agile methodology is an excellent tool for managing this process. If you have your team's velocity, you can fairly accurately determine how many features it will be possible to add during each iteration. Estimate the tasks, and keep the customer involved in prioritizing what features are to be added and what things are less important. Be sure to have a customer demo after each iteration to show the working functionality you both agreed would be working at the end of the current iteration. Should the customer want another feature or significantly change one that you have already agreed upon, estimate the number of story points necessary (units of work used in Agile) to make this new change or rework a current piece of functionality. This will help them remove another feature that they consider less important than the current one they have just suggested. This keeps everyone happy and there are no surprises when the product "ships"
There is no point in trying to argue them out of the feature. After all, communication issues or not, the mission is to deliver what the customer needs in the software.
I'd go with an Iron triangle argument as follows:
1) Obviously we want to deliver the product you need, so lets work together.
2) We all understand that regardless of how we got to the current point, we can only go forward from where we are today.
3) We also understand that implementing changes will take time and money which has to come from somewhere.
4) At this point your options are these (pick one)
* Replace the work that was planned for some other functionality with the work required for this change to stay on budget and schedule (sacrifice other features)
* Extend the deadline (increase cost/shift deadline)
* Add resources (increase cost)
Warning: Although C makes logical sense if you are doing manufacturing type work (build another 1000 pencils), in R&D work like software engineering it usually is just another flavor of B where you the cost and deadline shift is magnified.
If it isn't in the project plan / written agreement it's out of scope.
We have the spec in writing and have the client sign off on it, agreeing to pay for the features described in that document. If they change their minds later on something simple, we will usually work in the changes for no extra charge, but anything like what you described would require a new purchase order.
Well, simplest answer is that the budget or contract stipulates the requirements. Changes to those requirements have to be submitted as an extra and then go through the same process as the original project. They have to be budgeted for and estimated.
Once all that is done, if the client wants it close to the original launch date (and that's feasible), add extra for overtime hours.
At least, that's what I've done.
I charge them.
I would recommend making sure that the requirements are ironed out as much as possible, and that both sides understand exactly what is being promised. It keeps the client happy because there's fewer situations like you describe, and it keeps you happy because you don't keep getting yanked around.
The question is about two topics: negotiation and project management.
As far as project management concerned you need to manage the risk of customer changing their mind or misunderstanding an agreement in advance. Here is a list of preventitive measures one would normally take in a software development project, it can be used as a checklist when planning or revisiting a project:
Avoid most of the risks by having a written spec aproved before you start. In case you do smaller iterations have a spec for iteration approved. It doesn't need to be overly detailed but should set customer expectations and serve as a reference point. Detail things you're not certain about in the spec.
You might have an opportunity some other ogranisation that reports directly to the customer to do certain risky bits.
Put some contigency time and budget into the plan, exlpain to the customer that any contigency is going to be used only by agreement with them.
Explicitly offer alternative solutions to customer on the planning stage, discuss pros and cons and document the decision.
Even if you do waterfall build in several milestones into the project where you will make a litte demo to the customer or clarify requirements. Take that opportunity that customer is still ok with the proposed solution.
As pointed out by Webdtc always confirm outcome of phone and face-to-face discussions by sending a short summary e-mail.
Keep deliverables, their acceptance and payments spread out for projects longer than a month. Even if customer pays at the end of the project make sure you get evidence of their approval of interim deliverables.
Hopefully, following these tips won't ever put you into a tough situation when you need to negotiate deliverables with customer post-factum threatened by a non-payment. But if nonetheless you found yourself having to stand up to unreasonable demands the info you would have accumulated by then would have given you very strong leverage. Tips for negotiation:
Start with understanding the exact reasoning behind customer demand. And exactly what their position is. Confirm with the customer you understand them correctly.
At this point it can be either your fault (unlikely if you managed the project correctly), customer's fault (sometimes they do change mind their mind) or a cock up on both sides (most likely).
When it's all your fault most likely you'd need to swallow the pill and learn your lesson. However you'd need to negotiate with customer new deadlines to prevent the problem costing you even more. Always consider suggesting an alernative solution to the problem built on top of the software you've got now.
When it's customer's or mutual fault start with "no". Push back to let them understand you not absorbing the cost, not fully at least. Don't let them convience you that they can easilly walk away, this is never true. By this point even if they haven't paid you a penny their investment into the project will be sizeable: time spent evaluating bids, taking part in meetings, the effort they made communicating requirements, their and their customer's dependency on the project being completed mostly on time and within budget etc. You still might have to split the costs between the two organisations, but start with "no" to make it clear that they are as responsible for making an effort to timely clarify requirements as you are for discovering what is needed.
It sounds to me like the client may be looking for an excuse to get out of the agreement without paying anything. If he can arbitrarily add features and insist on them for final acceptance, without additional cost, he's got a way to make you break the contract.
There's two obvious ways to avoid this.
One is payments throughout development, so that the client can't wiggle out of much of the payment, and you're more or less compensated from what you've done at any point.
Another is a good contract. For any reasonable software project, a few hours of lawyer's fees is cheap insurance against something like this. If you are confident that you can sue the client for agreed-on fees and win, the client is less likely to make trouble, and if all else fails you can sue.
I don't know what the contractual arrangements are that you're working under (and I'm not a lawyer anyway), but in a situation like that I'd get a lawyer and see what sort of situation I was in. Even if you're in a dubious legal position, it's possible that a letter from your lawyer could help resolve things.
And don't get into that position again.
Well, if it's the truth, just go by it. What's to explain if you agreed to one thing and now he wants to do extra? Are you receiving push back?
I would make it clear that we originally designed a static report and that was what was signed off on. It can be extended to dynamic reports and that you can provide a quote if he would like to know the specifics.
I often use the analogy of building a house. Either the client is changing the blueprint, or the finishing materials that are requiring more time, materials to get done from what was originally agreed to.
Hope that helps!
What I do in this case is look at prior documentation and communications.
For example, if documentation/communication says "Create reports". If there is no specific mention of dynamic reports I would not give in to the client.
If there is any documentation saying "dynamic reports" then the client would be right and I would have to develop the reports at no cost.
If there is communication about "dynamic reports" I would have to look at what the final outcome is. This is where it might get harder because a lot of times a client might as "Is it possible to create dynamic reports?" and a developer might say "Yes, that is possible." (meaning it's possible, but does not mean we will do it). This is where I would have to explain that although discussed it is not in the scope of work. There has to be concrete agreement that a feature will be developed.
If you do not keep documentation and prior communications then I would say you are at a loss and would need to decide if you are going to give the client what they want or risk losing the client.
One of the worse things to me is a client who insists on telephone communications. These clients are the ones who usually play it fast and easy with their requests. What I usually do here is to always do a written follow up with the client on everything that is discussed during a face to face meeting or phone call and require the client to respond to make sure we are on the same page on what will and won't be done.
There's no right answer - just a few wrong ones. Specs and requirements have more white space than information - there's always room for interpretation and misunderstanding...what it really comes down to is:
future work - is there future work with this client or potential reference for future work? if so, you give in a bit, try to un-grey other areas of the deliverables that, based on this instance, could turn in the right direction.
payment - are they holding payment based on this? and is the work still within your buffered budget (you did add a buffer for this type of work - right? well, next time you will - future clients pay for past client mistakes)
deliver quickly and often - IKIWISI -I Know It When I See It - if it's in front of the client sooner then later, then the 'interpretation'/grey-areas get reduced...iterative deliveries (even incomplete ones) work wonders
After the fact you can't do much, if it comes down to legal action, you lost this client and a good reputation (potential) - be careful in how hard you push it
I'm in a situation where this happens on a regular basis. We write web applications that do complex tasks, then after we've completed it according to specification the user will then turn around and say "We want not just X & Y, but we want Z too". Z wasn't in the project scope and thus isn't achievable in the current system, therefore it must be rewritten to acommodate for the newly introduced "features".
The way we work around this is simply as follows. Treat the user like they're an idiot, and understand the system better than they do. I know this sounds really mean, and at first when my boss introduced me to this I told him straight that I would never treat a user as such - unfortunately I learnt the hard way and now have to know more than the user to complete my tasks. Mitigation is of the utmost importance, and foreseeing major changes which could be introduced is a skill learnt over time.
I now mitigate for these unplanned, but probable changes.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 3 years ago.
Improve this question
Does anyone have any practical suggestions about how to manage feature creep in GUIs?
I'm getting strong pressure from both internal and external sources to add, modify, tweak, etc. I always cringe when someone approaches me with the words "wouldn't it be nice if...?". I can't just turn around and yell "NO" at them, because often they are my superiors or customers.
Instead, I'm looking for suggestions to help explain why it's a bad idea to be constantly adding new features, and in doing so, manage their expectations of the final product.
Have feature requests handled in a formal process, normally through the project manager and whoever analyzed the requirements originally. Its always better to palm those sorts of decisions off to someone that isn't the developer, assuming that whoever is going to do that job is actually capable of it.
If you're freelance then obviously charge for changes to the requirements, and if you're an internal development team, then you could consider inter-department billing to make sure people think about what they want to spend money on.
Finally, expect requirements to change and feature creep to happen. If you code without considering what changes might be requested, or your process and/or deadlines are so inflexible that you can't adjust to this, then you'll find that the project will become a nightmare.
What I do is keep feature ideas on index cards and post the cards somewhere visible. When someone asks, "Could it also do XXX?" I write a new card. This is a better relationship building move than screaming "NO!" :-) It also has the advantage of not losing potentially good ideas. OTOH, I'm under no compulsion to implement it right then. The suggester knows they've been listened to, I know I won't forget, I can get back to work, and we can all get together to make priority decisions at a better time than when my brain is in CodeLand.
All right then, I'll be the voice of agile here. The problem can't be solved at the end of that process, it has to be avoided by managing the project differently.
Aside from a specific methodology, the trick is to put those decisions into the hands of the customers. You have a list of things to be done. When they want to change that list, you ask them which item from the list won't be getting done to accommodate the new item. Or, how much more money they will be giving you to handle it.
Also, you have to do the work in small iterations (a week to a month) so they have chances to readjust in between.
We use SCRUM and its been great. After a couple of iterations all the business-level and process-level items get worked out and you're delivering exactly what they want by the end.
Ideally requests like this should be handled by the person in charge of the Functional Design. Wether you like it or not, changes will happen (from the first letter in the functional design to the last byte of code and beyond) and there will always be requests for extra features. So make sure your design is up for such a dynamic process.
This will probably sound like a very lame solution (and I doubt it's good practice), but I have been struggling with the same issues in the past. The fact that it happened in a very small company (lack of 'layers' in management) made it worse, since I was in charge of development, functional design, technical design and managing my own projects.
What worked for me is to deflect the problem back to the person asking (wether it was a superior or the customer). Hand over the functional design, a prototype printout or whatever describes the current situation and ask them to figure out 'how' and 'where' this mighty new feature should be implemented.
Both the superiors and the customers were then 'forced' to take it back to their own people, discuss it in meetings and whatnot. Usually this means that you don't hear from it a second time. In the cases where it did come around, it was actually a concept that worked.
Your company appears not to be defining requirements clearly before starting a project, and this will only end in tears.
My policy is to get a clear breakdown of all requirements in advance and have all parties know the implications of intruding these requirements.
Progressively Delayed Release times
Increased Bugs
Incomplete features
Staff stress
Staff resignations.
Extra charges for expecting more out of the final product than was agreed upon at the declaration of a price ( and this is REALLY BAD )
If they don't want to adhere to a system that is sustainable and productive, one might want to opt for #5, or threaten with #5.
For managers:
the sooner the product is released to the market (assuming it's shrink-wrap), the sooner the company can make money and the better the cashflow.
don't rule out the new feature outright, but balance it against the value you can derive from doing alternative work; explain the opportunity cost.
For everyone:
if the new features are in-your-face in the UI, start talking about the effect of visual complexity on the usability - and from that, attractiveness - of the product as whole. But I'm sure you're already doing that. I'll try digging out some references...
The best way IMHO is to clearly outline exactly what the cost of implementing the new features will be. "It would be nice if" really starts to dwindle when the user starts to see the cost of such additions.
Disagreeing with the customer about a feature usually gets you nowhere. If you blatently say NO to them they will feel alienated and out of touch with you and your team. The feature probably is a good idea overall, granted you have all the time and money in the world and no technical limitations. In their world being able to see a fiz next to a bar after they click on a snip is a good idea. Of course in our world it means a full table scan, potential security vulnerability, and an all nighter to make sure it's in by the next point release.
If you lay it out for them and explain why it is not a really good idea overall they will usually understand. Don't forget all of the different factors (time/money/cost of adding complexity to the project/risk of slipping deadlines). A reasonable person will understand if you paint the picture clear enough, and you can at least say "I told you so" to an unreasonable person.
You cannot handle just feature creep - you need to organise your whole development process in an proper way.
However from your description it seems that you just code what other people ask for and could not re-organise the process. In this scenario your best way to manage the requests effectively by havign a tracking/ticketing system which would allow you to receive requests from other people, prioritise them, estimate them, agree the implementation schedule and track the time you actually spend working on them.
When you will be able to prove with the real-world figures that 'this small button' would take 2-3 days instead of 5 seconds the customer probably believe it should be you will be in much better position to negotiate.
If you will be able to clearly show that the project go-live date will be delayed by two weeks because of the new features you might see those requests simply vanishing.
You have to remember however that 'feature creep' is not always a negative thing. As application matures and grows your customers priorities are changing as well. Failing to acknowledge that could mean that your finished product will not be what they want.
Try checking if they would accept trading a new feature for an old one from original specification which is not yet implemeted.
I keep a prioritized list of work tasks and my estimates on what will be in build X and how long (roughly speaking) I expect it to take to write tests, implement code and do whatever else is related. I always take their inputs, discuss what they really want/need and insist that we determine where it fits in the grand scheme of things. We talk about the impact to schedule and other tasks.
It keeps the communication line open and clear - there aren't any surprises and the expectations are managed. In the end, it isn't my program - it is the customer's (whoever the customer is) and I want to build them what they want (and need) built.
The key seems to be in the question.
'Managing feature creep'... you do this by implementing a management process that needs to be followed. You can't avoid it (after all, it's frequently the customers requesting it and shouting no at them all the time tends to drive the poor creatures away)... but that doesn't mean it has to be undisciplined. With a procedure in place that entails the person placing the request to give simple things like justification and a preliminary investigation/use-case for the change you start to reduce the number of 'wouldnt it be nice to'. Once you have this in place, your feature creep is managed and you can start prioritising and providing more consistent feedback.
Your users have lots of needs that aren't taken care of. They are suffering. They need attention, and they need you. I think feature creep is something that happens when you don't implement the right features already.
Cultivate a close relationship with your users. Let them know you are always interested in their input. Periodically give them a call and ask how your software is treating them.
Get to know their work habits, standard practices, how they use your software, and how they use their other software. As that information comes in, collect it.
When feature requests come in, your users won't really know what they want. You know what they want, though, because you have expertise and you've been listening. So, work with them to clarify the problem they're having, then use your collected knowledge to generalize the problem as best you can. Write a solution that solves that problem.
On the other hand, "feature creep" is often the response of a software product to an evolving business. If your customer's business is growing, you're fortunate, because they will spend more money on your work. So relax, they'll pay you! They just need to understand that, the bigger a system gets, the harder it is to change, and sometimes a new small feature necessitates a big rewrite, or a whole new user interface, in order to keep everything working smoothly.
You have to be careful to balance a reluctance to avoid feature creep with a tendency to ignore feature requests and feedback.
Every time a user comes to you with feedback, that's an opportunity to improve your product and what you're working on. It may end up that you're adding something interesting to both the user, and your developers; it might actually be fun to work on. And yes, it may be a stupid idea, as posed to you. But it's your job to accept the feedback, extract anything positive from it, and shape it into something valuable to your users, the product, your company, and your development team.
That being said, feature creep is a very difficult thing to manage. And how well you manage it depends on your position and who the "creep" is. If you're a mid-to-junior level developer, and the CEO is demanding a feature; well, you're going to be adding that feature. You can try to convince the CEO that it's not a valuable feature, or it won't work, or there are more important things to be working on, or it will negatively impact the schedule. But never do any of that at the time the feature is being requested. All you'll end up with is two people defending their position instead of working together towards a common goal.
Instead, accept the feedback and feature request (or feature demand) at face value immediately. Walk away, think about it openly for a while by yourself. "Could this be valuable?" "Am I missing something in the way the CEO asked for this?" "Is it as hard as I'm making it out to be?" Ask yourself these kinds of questions, and come up with some concrete answers. Then always go back to the CEO with follow-up questions. Demonstrate that you've thought about the feature requested, and have actually come up with some ideas, tweaks, enhancements, or objections, etc. This will create an open discussion. One that the CEO hadn't anticipated, but that he most likely would not object to since it was not outright resistance to his idea initially.
One of our financial backers requests features all the time. Sometimes he says can we get the software to do 'x'. If it is possible we tell him yes, and then ask him what timescales he had in mind. If he comes back with ASAP - then we tell him that some other feature will have to give, or extend our deadlines. Thankfully he then normally changes his opinion to sometime in the future.
I think the most important thing is to actually record the idea or request, even if the feature doesnt get implemented straight away.
We use Bugzilla to keep a track of bugs - but also Feature Requests. We have a 'features' worklist (or target version)... that way everyone can see what features we would like to develop in the future and as people have more ideas on a feature they can simple add more to the item in bugzilla.
Every release when we sit down and work out the worklist's for a version we dip our toes into the features list to see if there is anything we can pull in. We do try to pull in a feature when we can and give feedback to people - this shows that features and ideas are not falling on deaf ears.
This feedback in helps people know that we are acknowleding their features requests and we DO get round to implementing them, rather than them just sitting on a list which gets bigger and bigger.
1)Increased time before release.
2)Increased cost.
3)Exponential maintenance cost
4)Increased potential for bugs
In order to manage a feature request, ask them to submit a change order. Periodically, review the change orders and send back a statement about each request, "This will take X long to do, implying this Y additional cost. Is this acceptable?" Once the requester has accepted the additional cost, then that's a-ok. Your hands are washed. :)
You explain "sure, it's doable, would you like to have an estimate of how much it will push out the project completion date? Also, giving you that estimate will add about a day to the project end, as well."
There's nothing wrong with adding features, so long as the stakeholders understand that there is a cost associated with doing so.
Suppose you build a product that has exactly one feature and all 100 of your customers love your product and find it easy to use. Now suppose that you add ten more features to your product that only 10 of your customers will use. Now you will find that 90% of your customers have much more trouble using your product because there are ten times more choices to make, and ten times as many things you could do that won't help you. The good stuff has been lost in the noise.
This is of course a simplification but the reality is that most of your users will only use a small portion of the features of your product.
Read some good books on software design and UI design, and get your manager to read them too. Joel Spolsky's books are a good place to start - www.joelonsoftware.com
If there's a lesson we can learn from the Internet and Web 2.0 kinds of things, it's that people love customization. That's what iGoogle and hundreds of other sites are all about. If you can build customization in to your GUI, chances are your customers will love you for it.
Also, take a look at how other projects successfully manage feature creep. For example, Google lets users submit feature requests, but also shows a list of features already requested. Users can then vote to request that feature as well. Not that I'm a suck up, but take a look at stackoverflow.uservoice.com. They have a similar policy.
It's critical to listen to your users and get their feedback. Expect them to come up with new ideas that are better than yours. Expect them to come up with ideas that you think are dumb. If enough people want it, and it seems reasonable, give them what they want.
Create work mandates that define the problem that needs solving. Your work is constrained by only needing to implement that which is necessary to solve the problem.
Any further refinement of the problem then becomes change control.
We follow wireframes in my office. Any change after signoff has to go through a Change Control procedure.
Lock-in feature set for a short time frame (Scrum/iteration/agile). As the user starts seeing things working, the necessity or lack thereof of features will become more apparent.
Also, it is helpful to have a person through which all changes come (in Scrum, a really good Product Owner).
Show them how simple GUIs can be effective. Examples: Google Chrome, Apple's software. You may also want to show examples of bloated software, like Eclipse, Netbeans, Visual Studio... ok, these are actually all software IDEs, but they all have cluttered interface.
The trick is to define the project as a sequence of versions. Your initial design is for version 2.0, but, the intended first release is version 1.0. All new ideas (features) are welcomed but since, due to scheduling, version 1.0 is frozen, the new ideas have to go into version 2.0.
Of course as soon as version 1.0 is released you begin bug fixing and coding for a maintenance release of version 1.01 and so on... Perhaps version 2.0 never actually
gets released, but is used as an elusive goal and a parking place for features
that are good, but not good enough to delay the release of a working version.
The right question to ask is 'How can I give the developers a stable environment, while still responding only to high benefit feature requests.' A SCRUM like approach would be:
Stable environment:
Have the developers work on a small fixed set of features during a small fixed iteration interval.
Responding only to high benefit feature requests:
One person maintains a list of prioritized features. New features can always be added (Cuts down a lot of politics). However the features selected for the next iteration only are the high priority items.
Communication is key. In a relationship with a client, it must be clear to them that when a plan is created with a set of features, that is the set of features. It is only the fault of those interacting with the client who are either misleading the client or are somehow intimidated by the client.
As for developers contributing to feature creep, the key is to find a balance between making decisions on implementation and outright adding new features. Again, communicating with the developer on a regular basis will likely curb an issue here.
It might not be possible to avoid all feature requests.
But try assigning a cost for each feature request. When the next planning meeting or deciding the features for the next release comes around this will help to weed out the unnecessary ones.
IF you're not the manager or owner of the project, I prescribe the following:
If they want it, do it. Make sure they pay you on payday. I've learned that sometimes the battle to get things to conform to what you would like, isn't worth fighting. Enjoy life, after work and plan & code your own personal projects that do things the right way.
The answer to your question is broader than just GUIs. Feature/Scope creep will always happen, when someone isn't paying attention to what the contract has stipulated and when there isn't a formal process for handling change requests.
If you lack the ability to implement the formal process or influence its creation, I suggest you get all feature change requests documented in email, and that you notify your management of the possible consequences in email. This isn't to get anyone, but rather to protect yourself from the fallout of the eventual failure.
At some point, you have to ship something. Assuming you're going through some sort of a formal test process, as long as the product continues to change, testing is never going to be able to sign off on a working product.
It helps to come up with a timeline describing what features will be released and when. That way the people pushing for the new features have some idea that their requests will be handled. It doesn't mean they're going to be handled right now, but it should provide them some reassurances that the next version will address their concerns.