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.
Related
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about programming within the scope defined in the help center.
Closed 9 years ago.
Improve this question
I'm time+cost estimating a semi-complex software solution, that hasn't got specific requirements in about 75% of features. I would still like to make as good estimate as possible, by getting additional data from the client. There will still be parts that may end up not being able to develop, since there's too many dependencies with other products/technologies and lack of definition. I also have a very tight schedule to produce this estimate.
There will also be other contenders on this project. Client expects a price+duration (and probably also features) and I know everyone will be off. I know that's impossible, but tell that to marketing people. Another problem is that I'm talking to middle-man and not directly to the client. I can get confidence with middle-man only, but not with the deciding client. Which is a different problem altogether.
What disclaimer/info can I put in my price plan/contract not to kill team with this project, so when project starts slipping (in terms of cost/time/features) we will be covered with some sort of payment. I would of course like to be paid by sprints or releases with relation to time, but I doubt client could be convinced in this. I'm sure we can finish this product before deadline and also create a great product, but how can I convice client to believe me?
Question
What can I do to get this project and avoid death march situation at the same time?
Any suggestion welcome!
EDIT: Outcome
In the end we (me and my co-worker) convinced the client we need at least a week to evaluate the product. So we did. We also pushed (and got) a slot for a few hours long meeting with the client to clarify any outstanding requirements' questions. So we did. Meeting was done after we made the first estimate draft, so we were sure we have all the questions to point out specifics that were either completely misunderstood or too vague to estimate. I hope we get the project, because it would mean 8 months of full time work for us, plus a reasonable pay. We'll know in about a week and a half.
Of course I also pointed out that the way we'll be delivering this product will get them exactly where they want to be with a product that will actually be what they wanted. And also that we only commit to price and time, but not functionality, because it is and will be subject to change. I think we made a good enough impression.
In this economic environment, there are a lot of companies competing for a little work. Someone is bound to give them a very sweet bid that will
Not be able to deliver on,
Kill their team with, or
Both.
When they can't deliver at the agreed price, they will start to cut down on the quality in order to deliver something and get paid.
Your challenge is to present that fact to your prospect in a professional manner, and convince them that you will work very hard to deliver at a reasonable cost, but also to deliver exactly what they need. The fact that you're going back for more detail, and the method you approach the project with (agile... but be sure and explain the business benefit to them) helps ensure that they will end up with what they really need.
Remember, they want to get the software delivered that they need at the lowest possible price.
Convince them that you will deliver exactly to their needs, and that your price is reasonable.
Welcome to the world of fixed priced development services :-)
Techniques for to win this project and avoid death march situation at the same time:
Don't underbid a project. Bid for what you think the project will take and add some percentage for things likely to go wrong.
If you are missing 75% of the detail, odds are the project will be significantly different than you currently expect. Document some reasonable detail assumptions within the outline of the defined work. When the project actually starts and the details don't match the assumption, you have an opportunity to negotiate the costs for the changes. At that time, you may also be in a better position to know how much you are over/under and attempt to compensate with this quote.
Your goal in an SOW (statement of work) should be to define enough details so that it gives you an opportunity to renegotiate the cost of changes when you know more about the project. Write these as positives, as much as possible. Note, it is unlikely that people that actually understand the project will read or understand the SOW...I base this on the point that you are given few details to quote. This means it isn't a consultative sale and neither party is really focused on building the 'right' solution.
If you can get a contract as T&M (time and materials) great. I doubt you'll get it or unable to get it without some restrictions that essentially defeat the purpose of a T&M. Your potential customers look at this as them accepting all of the risks around your abilities.
Hopefully, you aren't the first at your company to do this. Find out, historically, how projects have been and the typical result rates. Many software development groups charge an hourly rate that is significantly higher than cost...but their quotes tend to be lower and not actual hours. Customers often will argue more about the hours/days than the actual quote. Enterprises tend to be used to paying high hourly rates.
Figure out your department's expected margin (profit you need to gain from the job). This may help you to understand how much of a 'death march' you may face when your project slips.
In the SOW specify the level of detail that will be required in a specification before you begin work. While Agile and other customer focused processes take an approach that oriented at finding the best solution, they aren't designed to keep costs under control in a fixed bid environment. You will need to take a waterfall approach to requirements and then build in an agile fashion so that you can adjust along the way. The specification, like the SOW, will give you an opportunity to bill for changes. While the customer won't like this, it will put the burden and risks associated with requirements on them and not your team.
Note, to be successful with these negotiations, you needs a supportive management, sales and project management team. If you don't have that, you are bound to always be on 'death marches.' Even if you forgo quality, process, testing and other items, you'll find there's never enough time for a project.
EDIT:
Addressing the middle-men situation. I think the best course of action would be to submit a list of risks along with your bid as a courtesy to the customer. Kind of like giving them a heads-up on what their project limitations are. This will cost you some work up front but I think it could help you win the project.
you have two options
make a best-guess and double or triple your estimate (your competition is probably doing the same thing.)
explain to the customer that you can't bid work like this, and tell him that everyone else that gives him a fixed estimate is probably not being completely truthful.
At the end of the day, if you can't make money on the work, the there is not point in trying for it.
Personally, I prefer the latter, up-front and honest communication with your customers will take you farther than any bid tricks ever will.
A few things I'd say you should think about:
Assumptions: There's no one disclaimer you can add but you need to fill the gaps in the requirements with sensible assumptions and document them. Nothing major or scary, just a section in your spec/bid with a list of bullet points saying what you assumed to be true which was missing (e.g. users details will be pulled using LDAP and no admin screens will be written to cover user admin).
This gives you clarity in estimating as you now have a full scope to work from, but it also means that if the client comes back with things which are wildly different you have a fair basis to start talking about raising change requests and varying the cost. Alternatively they may come back during the negotiations saying this assumption or that one isn't true and you have more information.
Out of Scope: A specific case of assumptions - list things which you aren't including (e.g. No integration will exist with system X). Again this allows you to have a full scope and a reasonable case for potentially varying cost at a later stage.
Assumptions and out of scope are particularly applicable when things are mentioned in passing but not really followed up, or for things which they say could wait for a second phase. These are often the things the client will believe are being done as part of the main project but the project team don't.
Hopefully the thoroughness and insight from the assumptions and scope you define will help inspire confidence with the ultimate client too.
Contingency: A tricky one but you should add contingency in two ways:
(1) for specific risks. For things which might mean something takes longer than you've estimated then put in an amount to cover that weighted by the chance of it happening. Add all these up and that's your risk contingency.
(2) Shit happens contingency - unpredictable shit happens on IT projects. Add between 10% and 20% to cover this.
Whether you hide contingency from your commercial people and the client or not depends on your relationship but if it gets removed they need to understand what that means (essentially you WILL over run).
Understand the relationship between effort and cost: As a technologist your role is to provide an estimate of the effort based on the information you have. You need to then communicate that with assumptions, level of contingency and so on to your commercial team who can convert it into a monetary value. The thing to be clear with them on is that if they want to drop the cost that doesn't change the effort.
There are loads of good reasons for writing down the cost to the client (to build a relationship, because you'll end up with stuff you can reuse later and so on) but people need to understand that unless the scope changes the effort stays the same - the reduction comes out of the profit.
i have a blog article which may have a few tips in it for you:
http://pm4web.blogspot.com/2009/06/surviving-under-resourced-project.html
one of the other posters here has a good point to. there will always be someone who will offer a lower price to get the work. and the developer will suffer for it later (i.e. having to do a lot of free work to satisfy the client).
some clients need to have this experience before it clicks that you cant do IT projects on the cheap without paying some kind of price.
LM
Go for realism. Avoid promising too much, then make a point of it.
A lot of customers out there have been burnt by unrealistic offerers who fail to deliver as promised.
Emphasize the need for a specifications sprint. Convey a focus on core functionality and commitment to deliver rather than a feature bonanza. Offer a primary development phase to deliver core functionality.
Communicate the power and safety of the agile approach. Credit the customer with the ability to see good sense.
In short: Strive to come across as realistic and serious (more so than your competitors). The most important thing for any serious customer in the end is not the price, but a confidence that the product will be delivered on time and budget.
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
Steve Yegge's wisdom notwithstanding, most developers are faced with requirements which were gathered from non-technical customers. Sometimes there are project managers who deal with the customers and translate their requirements, other times not. In any event, the fact that the requirements will change is an inevitability.
Most of what consititues "good programming practice" has to do with developing systems which are adaptable so that they can withstand changing requirements. Principles like YAGNI, DRY, loose coupling, etc. contribute to this. Iterative development processes such as Agile also attempt to address the concern of trying to hit a moving target, and of course having a system under test makes it infinitely more feasible to make changes.
Nonetheless, it seems that for many of us changing requirements can not only hurt the quality of our software, but can also drain our motivation and make us want to stab someone.
This question is about how to manage the customer to make it possible for them to change their requirements in the ways that they need, while discouraging arbitrary or frivolous changes. How do you do it?
Do you have project managers to insulate the devs from the customer?
Do you have a formal change management process? Change managers?
How difficult is it for the customer to get a change when they really need it?
Conversely, how easy is it for a customer to get a change when it's "frivolous"?
How much detail do you give the customer when explaining the cost of a change?
How quickly are you able to give the customer this information after receiving a request for change?
What factors can torpedo the process (e.g. PM's who can't say no to the customer?)
What works for you?
If you are looking for the ideal world where the customer never changes his mind or you get the ideal spec - you are in the wrong business. That being said, the most effective mechanism I have found for managing customer expectations and change requests is to institute an accurate system of measurement.
This is how I run my team:
1) We start with user stories. The customer is involved in writing them and the development team estimates how long each user story will take in a relative manner.
2) Using prior experience I take these relative estimates (story points) and create a rough schedule for when major milestones of the project will be complete.
3) Within these milestones we run 2-week iterations. The customer is involved in setting the approval criteria and whether or not the story has been approved. A simple burn down chart shows the customer how close we are to meeting the launch goal.
4) Often time during the approval sessions the customer will request a change because the feature did not turn out how he expected it (even though it met his original approval criteria). At this time you generate a new story with a new estimate. You can also adjust your milestone dates appropriately. This then puts the ball back into the customers court:
Often times they realize their change request isn't worth it (they'd have to get approval from their boss) and we'll kill the new feature
Sometimes it is important so we'll delay the due date to get the feature in
And finally, there's always the option to kill another not so important feature that will take an equivalent amount of time.
The key is not to run away from change requests, but to establish that every change request has consequences on the product. There's no such thing as a free lunch.
I work as indpenedent developer and so contact with customers directly. It's normal that most of the time they have no idea what they actually want. So we start slowly and I give them prototype early on to play with and then the changes will be gradualy made. If I think that customers wants "frivolous" change then I tell him that this change doesn't work or is not needed. If it is 5 min of work then I might even do it anyway.
It helps to add later on to the contract some maintenance clause to get money for those small changes that will come up later on. For bigger changes you just charge by the hour.
Managing the customer is hard, and it is something that very easily can go wrong.
I find that as early as possible you need to gain the trust of the customer. For me I think you can do this by:
Ask the customer to appoint a product manager - who is clear thinking enough to communicate the requirements he/she wants, and look to build a strong working relationship with him/her.
Really try to understand their business - you don't need to be a domain expert, but you need to know where the customer is coming from.
Ask pertinent questions about what they want - don't assume what they ask for (at first) is what they really want.
At first welcome all changes. This is not the customer being annoying and fickle, it as an opportunity to better understand what the customer really wants. If this costs you time/money, then you may need to accept it as a loss leader.
Deliver a prototype early, and incorporate as much customer feedback as practicable.
Give the customer a kick arse product.
Once you have done this, and the customer trusts you, then you will be in a position to start knocking back unreasonable changes, or ask for extra payments/time for things that were previously considered out of scope.
Of course, you won't be able to build this sort of relationship with every customer, some are idiots (in this case see if you can have a different product manager appointed) but you should always do as much as you can to build an effective working relationship.
You can’t expect customers to know what they want at the start, so you must be adaptable. But also you need to stop change for changes sake.
This is for ‘internal’ customers.
I have found that bargaining with the customer is an effective way to go. They can have whatever feature they want if they wait for it, or if they sacrifice some other (yet to be implemented) features. This forces them to think about the value of the change they are asking for in relation to the system as a whole.
Sometimes this works well and a good compromise is reached. Other times the customer throws their toys out of the pram and goes however high they have to get the feature implemented and quality is reduced.
If the customer is paying, it is a different ball game. They need to be made aware that change costs, and that the cost increases as the product nears completion. This means that you have to do a lot of up front analysis about what you will deliver and make sure the spec is agreed upon. So then you can measure what has changed. This may not be the most effective solution for either party but it does keep things cut and dry. So they are not dissatisfied and you don’t end up doing loads of work for free.
In software engineering, change is just a fact. It will happen. For us, everything comes at a price. We'll make just about any change the clients wants, but there is always a time estimate and a cost associated with it. Do we ever tell the client no -- not normally, but sometimes the changes request comes in at a very high cost. We do draw the line at potential security threats etc. in which case we calmly explain to them that we can't accommodate the request.
How much do we explain to the customer, we explain where the money is going to be allocated, this much for development, this much for analysis etc. We don't explicitly tell them why something costs the way it does. Now I will admit, this does vary a little with some of our clients. Some of them get very detailed billing as to exactly how many hours are spent where. To get the contract we had to agree to it, although this is very rare for us.
We have sales people who can't say no at times, and that can cause problems. We have spent a lot of time working on that, but unfortunately it still crops up. We combat it by explaining how much money they cost us by quoting something without researching what it will take. Transparency is key at all levels. Everyone has to know how their decisions affect the bottom line.
Do we do frivolous changes? Yep. What you have to remember is that when you bill hourly most of the time a 5 minute change is billed at a full hour, so that is quite lucrative. We explain all of this before like we do with any change request so they are aware of it, but it tends to help discourage such behavior unless it is really important. The fact is that we treat all changes the same. We don't assume we know what is considered frivolous to them no matter how absurd we think it might be. We have a formal change process where the customer asks for something we write it down and get them to sign off that is what we evaluate it and present a Cost of Work Estimate. They either agree in which case they formally sign a document letting us know it is ok to start, or they rescind the request. We try to be diligent, but we let them know that it will take a few days for us to get a response to their request.
A coworker of mine gave me the best advice I have ever heard about managing customer relations ships. It's a give and take. To make the customer happy, you have to be willing to help them when they need something, but at the same time, you have to be able to say no. When dealing with people they want you to help them, but they also want you to have a spine and stand up for yourself. It becomes a win-win situation that way.
I’d prefer a term of evolving requirements to “changing requirements”. Professor M.M.Lehman (http://www.doc.ic.ac.uk/~mml/ and http://en.wikipedia.org/wiki/Meir_Manny_Lehman) has done a considerable contribution into research on software evolution; his works also suggest that not all types of requirements evolve. One might consider themselves lucky if they happen to work on one of these systems, where requirements stay the same (i.e. math libraries etc).
To the rest of us experience suggests that developers prefer as much information about requirements up front as possible, whereas customers or end-users value an ability to specify or adjust requirements as late as possible into the development process. The former need the detailed information to help planning and designing the solution, the latter can gain a strategic advantage through changing a requirement late, because it gives customer some room for manoeuvre to respond to the changing environment or information gained on as a result of the earlier stages / iterations of the project. A trade-off between the ability to have a detailed plan and change things largely determines the development process itself (waterfall, agile, spiral etc).
Some practical advice managing the evolution of requirements:
Build in some room into the initial plan to account for evolving requirements, multiple check points or iterations.
Either put volatile requirements into the beginning of the project so that some kind of prototyping or feasibility study is likely to clarify them or plan for the change late into the project.
Monitor that the requirements are still relevant.
Have an up to date, prioritised list of current requirements handy. Nothing else helps to keep evolution in control as a good visibility to all stakeholders of current “must haves” including their relative priority and cost.
Keep managing customer expectations on how long things are going to take; this also helps to keep focus.
Introduce a formal process for changing or adding requirements if you need. The process description needs to specify roles of these involved, frequency of reviews etc. It could serve as a good safeguard against some political and most opportunistic but not essential requirements.
Build in some time for refactoring even for the first version. You’re very likely to throw all or part of the solution as a result of additional knowledge gain during the development.
The customer comes to you to do something because they either don't have the time to do it or they don't know what to do (and want to pay you to do it for them). If you have changing requirements, it's because of the latter. In other words, they are paying you to figure out the details! And they know what they like and don't like but they won't know how it works.
Recognize this and whatever the solution needs to be falls in to place.
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 8 years ago.
Improve this question
I am a junior programmer. Since my supervisor told me to sit in with the client, I joined. I saw the unsatisfied face of the client despite the successful (from my programmer's perspective) delivery of the project!
Client: You could have included this!
Us: Was not in the specification!
Client: Common Sense!
As a programmer, how do you respond in this situation?
What you should do to avoid this situation:
Explicitly spec out what will be included and what will not be included.
The problem probably comes down to the unspecified parts of the spec:
The client thinks that unspecified stuff should be in, i.e. it was implied.
The developer thinks that unspecified stuff should not be in.
For future specs that you have, you should have a catch all statement, that explicitly states that if something is not specified in this document, it can be done after the original specification is done at an additional cost.
What you should do in the current situation:
Other than learning from your experiences, you should come to some compromise with the client.
Example: I will do this feature that you feel is common sense, but for all future additions/changes it will have to be spec'ed out explicitly.
I.e. you will have to do a little more work, but it is worth it in return for the catch all explicitly spec'ed agreement your client will enter into.
Bad spec?
Was it necessarily a bad spec? No.
It is impossible to mention everything your clients may expect, so it is critical to have this catch all statement mentioned above stated clearly and explicitly in your spec/contract.
Other ways to reduce the problem:
Involve the client early, show them early prototypes. Even if they don't demand it.
Try not to sell the client an end product, but more of a service for working on his product.
Consider an agile development model or something similar so that tasks are well defined, small, paid for, and indisputable.
This would be one of many reasons why I switched to an Agile development philosophy. The only way, in my opinion, to successfully avoid this scenario is to either be omniscient or involve the customer heavily and release early/release often to get feedback as soon as possible. That way you can develop the software the customer really wants, not the software the customer tells you they want.
Client: You could have included this!
Us: Was not in the specification!
Client: Common Sense!!
Us: We do not attempt to go beyond what the client has specified - we follow the specification. It's as important to NOT implement features not specified as it is to implement features specified. We will never second guess our customers, who value the fact that they can completely depend on us to correctly and completely implement the specification on time and under budget.
As others very rightly point out, the situation is almost always more complex than the simple exchange I've described above.
However, the above is valid if the implementer has a specification with the customer's signature on it which essentially implements an agreement that says "once the software provably implements all the features in the spec then it is considered complete", and anything additional is outside the specification and therefore outside the contract.
The contract itself may have some input here as well - if you don't have a signed contract than it doesn't matter what's in the spec - everything so far has been done on a handshake, and the entire deal (including payment) can go down the toilet based on any dissatisfaction on either side.
But if you have a contract and a specification, and the customer has seen and signed both, then they have no wriggle room to ask you to go further.
Now, as to the question of whether you should implement it:
AWESOME! You delivered a product and they only had one complaint. Implement the feature, call it a 'freebie (make sure they understand you're working outside the spec and contract and explicitly send them a bill for the work with the discount shown in dollars) and have them sign off on the project as a whole.
It will explicitly demonstrate that the project is ended, that you went above and beyond the call of duty, and that any further 'surprises' are outside the contract/spec, which gives you a nice layer of protection beyond what you already (ostensibly) have.
If it's a UI issue, then you're in murkier water.
Does the spec adequately describe the UI? Does it have mockups? I wouldn't fault a customer for this complaint about the UI if the spec did not very closely describe the layout, usage, and include mockups.
Either way, I think you can understand the customer's position - if they haven't played with UI mockups, then they're going to be disappointed with the result regardless - there's no way, psychologically speaking, that you and your customer could have possibly had the same idea in mind (nevermind the fact that common sense isn't!).
Quite frankly if this is the first time the customer has thought about checking out the UI before the work is finished, then it's at least partially your fault for not explaining good UI design processes to them. This is a key feature for their app, and it's very tightly coupled to what they've imagined - no one can be satisfied in such a situation unless they've 'grown' their internal representation over time to match what the reality is.
This disconnect is solved only through frequent user and customer testing, which is obviously missing. This is a problem regarding client education and communication, not whether the specification was met or not.
-Adam
Expect last minute changes of scope - they always happen, so be ready.
Review progress frequently with client - to minimize surprises.
Contract: Functional Spec, plus Time & Materials with initial cap (so client feels control).
Then when changes come along, re-negotiate the cap if necessary.
Never say they can't have what they want. They can get that answer for free!
Always give them a little more than they asked for, so they know you've got a positive attitude.
Relate to the client as being on the same team with them. Don't accept being legalistically painted as an adversary.
They may think of contractors as not loyal, compared to employees. Show them you're as dedicated to their success as their employees are, and you'll go the extra mile.
Classic case...
There's not definite answer to this one, but it all turns around communication. There should have been preventive measures put in place (like weekly reviews or something like that).
For sure, you can't redo the whole thing for free.
Two ways: Or to tell them to ** off or you deal with it.
If you choose to deal:
First, empathize, respect the client.
Have a look at what can easily be changed.
Have a look at the contracts.
Maybe create a new agreement.
Don't do too much.
Make them see the progress and the work it takes.
Find workarounds for the missing features (maybe using other great features, or available tools.)
Use your common sense, it is so common, its not even funny.
This is one of the many drawbacks of a fixed bid arrangement. Any time business needs or priorities change, or there is even a simple misunderstanding, it results in anything from an awkward situation like this to calling lawyers in. If you have an arrangement where you get paid for development time, you can always react to any change and get paid for whatever time it takes to make that change. Also, having a by-the-hour arrangement does not preclude having a plan or making an estimate.
Once you are in a fixed bid pickle, though, your options are:
1) Do it at an additional cost.
2) Do it free.
3) Don't do it.
Option 3 is the worst, and Option 1 is the best. If you have a good trusting relationship and decent communication with the client, it's usually easy to arrive at Option 1. If the relationship is bad, then you've got bigger problems. At that point, just try to avoid laywers.
A final point - any project that has something known as "The Delivery Date" inevitably runs into the problem described. Projects with said date usually involve retreating to a cave for several months to develop in hiding followed by an unleashing of the product all at once in front of the stakeholders. This is abrupt and leaves plenty of time for client expectations and the actual product to drift apart. If, instead, you show intermediate versions of the product and gather feedback every few weeks, two things happen. First, you get better feedback, minimize misunderstandings, and make a better product. Second, there is no single point in time on which a massive amount of expectation is laid. The potential difference between what the client is imagining and what actually exists is much smaller. No surprises.
Good luck.
"how do you react?"
Question 1 - do you want to continue this relationship with this customer? Seriously. If they are going to claim that unspecified features are "common sense," this may not be a good relationship to maintain or enhance.
If you want to disengage, then that's easy. Ask for them to highlight each part of the specification that you failed to comply with and play that game. Get specific test criteria for each missing feature. Pull Teeth. Be confrontational in determining what's missing. Don't ask why. Just ask for all the details up front. It's slow and unpleasant. But you don't want them anyway.
If you want to engage, well, you're going to have to change the relationship. Currently, you have a Passive Aggressive Customer. They won't say what they want, but they will say what they don't want.
This may be a habit with them; this may be how they win concessions. Or this just may be sloppy specification on their part.
If you want the relationship, your reaction has two parts.
Short-term. Get something they're happy with. They have to identify specific changes. You have to score each change with a "cost to do" and "fit with specification".
Some things are cheap and a good fit. Do those.
Some things are cheap to do, but a bad fit with the specification. Think twice about enabling a bad specification to lead to rework. In a sense, you purchased the specification from them; you may need to raise your standards, also.
The expensive things which (sadly) fit the specification are a problem. You're in trouble with these, and pretty much have to do them.
The expensive things which don't fit well with the specification are lessons learned for everyone. Detail a plan for these, including specification rewrites and approvals.
Long-term. Make sure they you're not PA'd again. Review early and often, use Agile techniques. Communicate more, prototype more, release more.
Well, it was not successfully delivered. Somewhere along the line there was miscommunication. Without knowing the specifics I would suggest this is not a developer injected problem and this is probably not to be blamed on the customer - the requirements gathering task was insufficient. This is a classic example of what happens when the software side does not have domain experts or the requirements discovery process doesn't do all that it could...
If it was me I would correct the problem and figure out how to avoid similar issue in the future.
How you handle this can very well determine the future of this contract/business with the client. Taking responsibility and correcting the issue is a huge opportunity for your company.
EDIT:
This is a good time to evaluate how this happened to help correct it. Some companies choose to totally revamp everything they do which is a mistake I think. So is ignoring it. Blaming people for the problem is also a mistake.
It is a good time to walk through how this happened, what the process is, and maybe how it could have been caught. I would not make huge rule changes or process changes - but coming up with guidelines for future work is a great thing. Your company had a clear lesson about a shortcoming. Losing the opportunity to correct this problem and to correct your process would be a waste of a good chance.
ZiG, I've had to deal with this problem on several occasions at my current place of Employment. My group (3 developers) tries to approach things in an Agile manner. We're used to getting mid-stream and even last-second requests (which we then treat on a case-by-case basis).
However, we make it clear that resources (particularly time) are limited and if it's not in the spec we can't make promises. If it's judged important and it can't fit into the current release, we generally plan a followup release. If it isn't important, it goes on a list.
One thing I've found is that you can get users to agree to Spec S at Time T. However at Time T + N, getting them to remember they agreed to Spec S, or getting them to acknowledge that they did so (with the documentation you've been keeping, I hope!) can be trickier than it should be.
Speaking to the OP's subject and question:
If you are an employed programmer, then I would hope that other resources are in the meeting with you. Possibly "higher ups" in the organization.
If this is the case, then your job is to answer DIRECT questions, and to keep your emotions in check. Yes, you may feel injured because they don't love your code, but showing any emotion with bosses present is not a good thing. Rather, try and look neutral and let the others handle the session.
Now, if they "hang you out to dry", then I would recommend the following questions:
a) "OK. I see. Why exactly to you feel this is common sense to include this feature? I'd like to discover why we didn't include it." (force them to explain their thought process. Common sense to one person is rarely common sense to anyone else.)
b) "Well, I'm sure we could include that in the next release. I'll leave it up to XXX (the bosses) to come to a mutually agreeable approach" (i.e. don't talk cost or freebies with bosses present. EVER.)
Again, this assumes you are a programmer WORKING for a company that delivered the product. Now, if are more than that - i.e. you ARE one of the higher ups, then many of the suggestions here are excellent.
However, if you are the higher-up or are a consultant programmer, then first and formost
a) Apologize for the process that did not catch this requirement. Promise to work with the client to prevent this from recurring.
Then on to the other strategies. It really doesn't matter if you charge for the fix or not - the apology is the most important action to the client. Again, it bears repeating - you are not apologizing for the missed feature. You are apologizing for the faulty design process that let it slip. Clients are usually pretty accommodating when you start this way and then seek a solution.
Cheers,
-Richard
Use SCRUM like approaches to avoid this deathtrap: involve the client in the dev process early, frequently and in informal, restricted commitees -> risk reduction and improved agility.
In terms of your literal question, how to react, the best way is to ignore your ego ("what?! After I worked so hard on this and met the spec?!") and instead focus on some active listening and working to consensus.
Client: You could have included this!
Us: Was not in the specification!
Client: Common Sense!!
Us: I understand that you're not happy that we didn't go beyond the bounds of the specification. Seeing how you feel about this, how can we make you happy? Let's see if there's a process we can create together that will help everyone.
Essentially, you don't want to turn this into a "you said/I said" death match. The only way to resolve those involves lawyers and then nobody wins. If you can agree that the spec or the process was to fault, work together to fix those.
This approach actually just worked for me: wait for the guy who doesn't like your software to leave and be replaced by the guy who does like it.
Obviously you can't really rely on this, but if you're sure that you did a good job and that your software really will satisfy the business needs of the people who hired you, it does pay to wait it out. Sometimes the client's initial reaction will not be their final one, especially if you can quickly incorporate their concerns.
Don't try make the client feel like it is their fault. It might be their fault, but making them feel that way will not produce constructive results, and could just annoy them.
Instead, you should realize that clients only complain about software they use, in most cases because they like it. Nobody complains about software nobody uses. It is inevitable that a client will complain about the software you deliver, even if you deliver exactly what they ask for. So don't sweat it. Software is never done.
Total failure on the part of the person in charge of requirements collection, no doubt about it. Additional failure of the project management to not iterate the deliverable and have check-in meetings with the client.
However, you have a signed-off spec, and what you've delivered matches the spec. So, your company has two choices: write off the cost in the name of business development and make the change for free, or charge them for the change request.
If it ain't in the spec, it ain't in the spec. As a developer with no specific domain knowledge, 'common sense' is an irrelevant concept. Different industries work in different ways and one approach might be quite appropriate for a particular domain but completely unacceptable in the other.
Writing good specs is an art-form. IMO, you can either take an agile 'analyst/programmer' approach where you make small iterations or write and maintain a detailed, unambiguous specification. Both are highly skilled tasks, and are still iterative. You still have to evolve the specification.
Either way is not as easy as it sounds and both require the ability to establish a good working relationship with the client.
You cannot know what your customer think in his head. This situation occur often with client that haven't got any experiences with programming project. What I suggest to you is to simply show him that "common sense" isn't very accurate as answer in engineering (or programming if you prefer).
Show him other example in life that will show him that you cannot build something that aren't written. Example: building a new house, the guy who build the house need a plan with all detail... he won't put optional electric plug because in the living room it's more "common sense" to have some extra...
I had this once. And luckily it wasn't me that created the design because that proved to be the problem.
It is of vital importance that the communcation between your company and the client is as perfect as possible. Be sure you understand each other. Ask questions and let them ask questions. Do not let anything open in the design. This will be the problem point at delivery. And have regular meetings during the project (preferably with a prerelease).
Unfortunately a lot of developers are bad at communciation, and a lot of clients are not aware of their own needs. But if you can minimize the gap, you have found yourself a happy (and returning) customer.
This is why I/the teams I worked with always used a prototype-style approach, that means:
after collecting the requirements, you show the client an early and basic release of the software
the client says "you could have included this"/"it's common sense"
you change your design to reflect the client's desiderata
iterate from point 1 till the official release
You have to start it early on; tell the customer, early and often, that the spec/use-cases/user-stories are a contract which define what will be delivered. in an agile environment there are plenty of chances for the customer to observe some "common sense" feature they want and ask for it, which is one of the advantages of an agile approach, but if you start accepting "common sense" additions at the end, you are preparing yourself for infinite extensions, probably at your expense.
Some customers expect this; the more and better you tell them they can't, the easier the eventual arguments will be.
As a junior guy, I realize you can't do this -- yet -- but one of the hard-but-necessary lessons is that sometimes you have to fire a customer.
You learn - everything is learning and nothing is personal.
We are experts in our area we know better than customer what he need. And next time for next customer we will suggest all useful features in advance and make him happy and will make him pay more money because we are the experts and we know better.
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about programming within the scope defined in the help center.
Closed 8 years ago.
Improve this question
You must have heard the archetypical story of a failing/failed project:
A team of inexperienced programmers work 24x7
Bugs are fixed only to introduce new bugs
Customer is screaming that he could not even do the basic stuff (Saving/Querying) etc.
Programmers used to having the spec handed down struggle to improvise
No automated unit tests aggravate the situation
Architecture document that looked nice on paper was not followed in practice
Third party components used become bottlenecks not having been tested for fitness in the first place
Milestone after milestone missed
The team is not able to come up with a delivery date as nobody agrees as to the quantum of work actually needs to be done
No technical leadership / or a Cowboy Coder that can take on the technical issues
Now, If you were to be brought in as #10 what would be your first steps?
Update: First of all: Thanks to you all for chipping in. Well... I'm being brought in as #10. I was the original Architect anchoring the solution when we made the proposal to the client. Then, unfortunately, I couldn't take on the delivery responsibilities as I was assigned somewhere else. :)
Let's say it's a webification of an existing desktop application. I'm now being brought in as #10. Running away, sadly, is not an option. I'm sure this can still be reversed by following agile best practices and just wanted to tap the community for ideas.
The larger question perhaps is this: If the development team does not have specs but only the (baselined) code for a running application, the original solution called for looking at the code and extracting business rules on the fly. Now, the inexperienced programmers are reluctant to look at VB 6.0 code and want documents! So how do you fight this if you were to instate Agile processes?
Vyas, I feel like I could have written this question. My previous job involved resurrecting a KVM project that had failed after a year's development. Specs were in the form of a user manual and developers' experience with similar products. I ended up teaching C to 3 assembly programmers and re-architecting from scratch. We brought the product successfully to market in 4 months. (Then I resigned. Go figure.)
Some of the things I'd do again, particularly with an inexperienced team:
1. A team of inexperienced programmers work 24x7
10. No technical leadership / or a Cowboy Coder that can take on the technical issues
Give them a (short!) break from the project to "recharge." Maybe a day, maybe an afternoon, or maybe a long lunch on you. It will mark the end of the "old" project and the beginning of success.
Get their agreement to work their butts off when they return, and promise that you will be their go-to guy, cheerleader, and flak jacket. You, collectively, are a team, and your job is to forge their path, eliminate distractions, and lead them.
Plan an immediate success, no matter how small, and maintain a "can-do" attitude.
8. Milestone after milestone missed
9. The team is not able to come up with a delivery date as nobody agrees as to the quantum of work actually needs to be done
3. Customer is screaming that he could not even do the basic stuff (Saving/Querying) etc.
Take small bites! Break each piece down as far as possible, then deal with the small components. You'll identify "gotchas" early and be better able to scope the whole project.
Define your interfaces. Anytime you can isolate a chunk, do it. This allows parallel development, because you've already decided on parameters, preconditions, assumptions, what happens inside, and return values. You can stub it out, and build other modules and tests independently.
Prioritize. Focus on the defects and issues that affect the customer first. New features come last. If necessary, defer features rather than delivering buggy code.
Assign responsibilities. Volunteers are preferred, each in his/her area of expertise, but one person must be accountable for each task.
Track defects, and record everything that will help you reproduce, locate, and fix them. Document any that remain at delivery time, so the customer won't be surprised.
4. Programmers used to having the spec handed down struggle to improvise
6. Architecture document that looked nice on paper was not followed in practice
You will create the spec details as you go, each piece just before it's needed. It needn't be pretty, complete, or even written, as long as everyone understands the current task and you've got the big picture.
Discuss the implementation, one piece at a time, when the developer is ready to code it. Write the skeleton yourself if necessary, and let the team fill in the "guts." You want to keep them focused on each task, without "improvising."
Be available to answer questions as they arise. Your primary goal is to keep the team productive.
2. Bugs are fixed only to introduce new bugs
5. No automated unit tests aggr[a]vate the situation
Plan and start unit testing ASAP. If possible, enlist resources outside the team.
Fix small problems before they grow larger--or get hidden. Confidence in each small piece builds confidence in the whole.
7. Third party components used become bottlenecks not having been tested for fitness in the first place
Brainstorm solutions when you're not coding. Don't let them stop your progress if at all possible. Can you encapsulate or code around them? Replace them?
General suggestions:
Stay ahead of the team. Anticipate and try to solve problems before your team hits them. Gather any necessary information before it's needed.
Communicate constantly. Make it clear that you want no surprises, and solicit concerns, questions, status, roadblocks, etc throughout each day. Encourage collaboration and share "discoveries" across the team.
Celebrate every success. Compliment a clever solution, bring donuts when a problem is solved, demonstrate a new working feature ... anything that shows the team you appreciate them.
Get each task done, then move ahead. Don't waste time tweaking, enhancing, or reworking anything that isn't a direct barrier to success.
Keep your promises to the team, the customer, and your management.
Good luck -- please keep us posted!
Run away or find a new job. This is a death march and they need a scape goat.
Often, the death march will involve
desperate attempts to right the course
of the project by asking team members
to work especially grueling hours,
weekends, or by attempting to "throw
(enough) bodies at the problem" with
varying results, often causing
burnout.
Freeze releases, and start fixing issues with the program.... deal with the customer complaints by priority (the business side of the company can prioritize) and get the program running. Once you get the biggest issues out of the way, start cleaning up the code. Assign tasks to other developers, and start enforcing coding practices on all new code.
If you can do whatever you want, then look at what the real issues are and deal with them. If that means putting together a new team to develop the software all over from scratch, so be it. But you should try to at least fix the major bugs. Don't bother introducing new features, they only compound the problem, and a program that doesn't work and the problems aren't dealt with lose you clients.
Number 10 is obviously the worst problem, or at least the root of all others. Find someone with some creativity and ability to deliver a project, and give them free reign to do anything - including start over.
I hope you are getting paid really well. In any case, my plan would be something like these steps in the following order:
0) Stop adding features or functions across the team. Allow bugs to be addressed while the following steps are taken up to step 5, then stop bug fixing & resume feature development:
1) Apply what I call the Inverse Staffing Law: Weaker team members slow down the better and faster ones and generally a late software project needs people removed, not added. So, you need to assess the quality of the team members as individual contributors. Eliminate weaker staff from the team because presumably there are some. This is best done by reviewing their code and examining their bug fixes and figure out who is making the code worse vs. better and chop them for the team. This is not a time to mentor, you are going to need the best folks to have a change of "fixing" the situation in a optimal period of time. If you can't fire them or reassign them, have them getting coffee or something for everyone else left.
2) Assess the code itself. Identify areas of the code that are not constructed well and/or not well abstracted. If a area code is not constructed well and/or is obviously brittle at it what it is supposed to do, target it for a re-write. This feels painful at this point, but it will save you time in the long run. Recurring bugs and/or history of fixes will help identify the code that can't be salvaged. If a code area or module is fundamentally constructed well, but not abstracted well at the interface level, it should be suitable for re-factoring. This will save significant time and is useful code. Keep a list of the re-write areas, the re-factor areas, and the suitable areas.
3) Define a new reasonable architecture that you believe will result in a robust and complete solution to where you want to eventually be in features and functions. The architecture might not be optimal as starting clean, but in effect match up what you have with where you would like to be.
4) Work with the stake holders to decide what will make an acceptable first release attempting to table as many features as possible for "later" releases. Maybe you can't cut anything, but if you can, now is the time to do it.
5) Stop the background bug fixing efforts and assign the defined work out to the (remaining) team to estimate out a reasonable new implementation plan of the rest of the functionality. They need to own the schedule. Roll up the schedule and be fairly conservative. Now you have a reasonable prediction of when you could actually have something workable and robust.
6) Implement the remaining features and then harden up the release by tackling the remaining bugs. I am assuming all the normal good software development practices are observed here like source control, unit tests, etc.
7) Remove as many barriers as possible to keep the team cranking out stuff as fast possible.
8) Monitor for issues, and assist by getting your hands dirty where ever your can. Offer to take on the nastier issues to the extent you can help and still keep all members of the team as productive.
Good Luck!
This isn't about technical leadership any more, it's now about project management.
You as the technical lead will just be shifting deckchairs on the Titanic. So here's what I would do if I was the de-facto project manager.
1) Identify the project sponsors and stakeholders - both the official ones and the real ones.
2) Go to them and request that the project "goes dark" for a week.
3) If they don't agree, walk away from this project.
4) If they do agree, call a project time-out for a week - everything stops.
5) Spend that whole week talking to the important people on the project to identify the real project state.
6) Whilst engaged in those discussions, start formulating a project recovery plan, emphasising possible trade-offs between scope, schedule, budget, and personnel.
7) At the end of the week, decide which (if any) of your possible project scenarios are feasible.
8) Take the best of these scenarios back to the project sponsors and stakeholders, and start negotiating.
9) When a way forward is agreed, reboot the project and pray - possibly not in that order.
Common sense has already been pointed out to you by Maxim (Quit the death march). But if for reasons unknown you wish to persist, let me regale you with my experience in a similar situation - perhaps it might come useful.
It was my first job in a sleepy old town where good computer jobs where hard to come by and I despertely needed one immediately after college. I was hired coz the management thought i was enthusiastic enough and might be better than nothing (I offered to bring in my own comp to save them a cost of giving me a PC and offered to work for the experience alone)
The project had been abandoned by its creators due to the death march situation and had gone away after deleting all the comments in the code and performing other obfuscations. Nobody knew win32 / MFC stuff either.
I simply started studying the code on good old paper and pencil (lots of rubbing and corrections) until within 20 days time i knew the entire code including the variables by heart and what and where things where happening.
Armed with this knowledge i was able to make a critical piece working which had eluded everyone before. Of-course this was nothing but a drop in the ocean but it enabled the management to buy the clients confidence "smart fellow - got him with great difficulty - already got x working - u will have ur stuff working within y time".
Once the client was convinced and we where able to buy some time, some pressure was taken away. This got some hope back into the team and we started to hammer away for good. 6 months later i got promoted to project lead and 9 months later we had our fix shipment (lots of progress demos and a visibly more and more satisfied client in between).
As you can see, the elements of success are not directly duplicatable. But i would summarize that you need to breath some hope into the project first - show some progress and win confidence - that of your peers, management and the client. Once that is in place the technical stuff should be corrected too - there is nothing to replace this part of the equation.
If that does not seem likely, all that hard work (oh yes - lots and lots of work like you never imagined - why do you think its called a death march) would be a waste and you had better quit even before you start.
I had no choice and i was hot blooded and desperately need a job. The technical details where something icould work magic upon, and everthing just clicked into place. I really earned a lot of good will and self respect with that piece of work but in the long run its just a story i can narrate with great aplomb and nothing more except for those few in the know.
Things might be different for you but its for you to decide.
Good luck
Make sure you aren't the scapegoat
Cut scope creep
Trim functionality "requirements"
Implement a faster dev cycle (maybe Agile/Scrum/XP/whatever)
If you can, run away.
If not, you need to stop all activities that make the project unstable - including coding and fixing defects.
Assess where you are
Break up the requirements into much smaller "milestones"
Read some practical books (Mcconnell's "Software Project Survival Guide" comes to mind.
Identify all the problems and risks. Communicate all those to all involved.
Work on each piece one at a time.
Celebrate improvements and milestones as they are reached.
Good luck. Your scenario sounds pretty bad. It may not be salvageable - and things have to change to get better.
If you really had to get it on track (if bailing isn't an option)
Start off by accepting that it's a failure in management. You might then want to go on to implementing a strict but light process.
I'd suggest some form of Agile, since it's the easiest to successfully implement without a GURU, but you have to be VERY strict about it, including Pairing, Ruthless Refactoring, Reviews, Spiking functionality, Visibility, TDD, one-week cycles, 8-hour workdays (Yes, longer than 8 tends to harm productivity more than help, as you seem to have noticed)...
Don't be cutting anything out either. Parts of Agile rely on other parts--without the pairing, refactoring and testing you cannot eliminate upfront design (one of the biggest agile failures).
Don't forget about the management side of it. One week iterations to start (demo EVERY week). Constant adaptation. Very short stand-ups every day to address issues. (Keep to 15 minutes max, table longer issues, etc) Burndown charts, core-team with a client on it.
You can't just have a 15 minute meeting every week and 2 week iterations and call it Agile, but if you do it right, it just MIGHT give you a chance. You might get a GOOD agile consultant in to train you on getting started.
Also, constantly evaluate what works and what doesn't. Be prepared to fix what doesn't work. Weekly meetings to analyze that weeks' development successes and failures.
Overall it CAN work, and can bring a flailing team into line, but it's not trivial. The nicest part is that you can implement it without taking huge chunks of time out of your current development. You just keep developing, but you do it better.
Tough situation, you have zero customer trust and basically can't be successful under that situation, no matter what.
For all intents and purposes the project needs a reboot; the unfortunate fact is that incumbant shops usually don't get this oppurtunity to start over and re-evaluate everything that is there.
I hate to say it, but you need to halt development and spend a month working out what went wrong...
The result needs to be a plan for a feasible 6month - 1year delivery really making them focus on what the must-haves are and real trade studies on your third party components. And trashing the code base needs to be an option; start a new source control project and when you get to a particular module port peices that make sense and leave the garbage behind.
Agile is great and all, and a valid approach once you get a real plan in place; but its not going to fix a broken relationship with your customer... or all the junk that's already there.
Here's the summary of key learning after reading through your experiences:
Maxim
1: Make sure this is not a "Death March"
Ellie
2: Make sure what's delivered works
3: Refactor & Realgin codebase to Architecture / Best practices
4: Look at what are the real issues: Is the team technically competenet to deliver?
Kendall
5: Ensure availaibility of Technical Leadership
Bill K
6: Implement Agile Processes (At least automated unit tests if not TDD, short iterations that make progress visible)
7: Get customer buy-in
8: Be prepared to throw out what cannot work (wishful thinking aside)
Warren
9: Make sure the team memebers that remain given a chance to start over
Tim
10: Motivate team and as improvement becomes visible reward them
jsl4980
11: You need buy-in on schedule from your team (most imp.) & customer
[This raises more questions. What if your customer asks whether the team is competent enough to stick to your schedule? What if you yourself know that the timelines the team is proposing just shows their lack of understanding]
Ather
12: Is the team commited?
13: Do you formally QA?
Patrick
14: Start over, redesign and reconform to Architecture/Design best practices for modules yet to be developed.
The summary has 14 items. You can't do them all. So, what's the first step?
Here's what you have to do first -- get one thing improved.
You've got fundamental quality issues. (#2-5)
You've got architecture and component issues. (#6, 7)
You've got schedule problems. (#1, 8, 9)
You can tackle quality. Formal unit testing, heading toward TDD can help. This might be hard because architecture issues slow testing down.
You can tackle architecture. This might be harder because it will probably involve rework that will not appear deliverable. But it may fix quality issues. Or, it may be compounded by fundamental testing problems.
You can tackle schedule. Without other corrections (i.e., quality or architecture) you may not get any traction with fixing schedule issues.
I think that overall improvements in people's attitudes come from starting with one success -- any success -- as early as possible. What's the lowest-hanging fruit?
One long-standing bug? One unit test suite to find and fix that bug?
One major architectural feature? Would a diagram that everyone can post in their cube help? How about a presentation clarify things?
One new use case? One new feature that actually works?
Here's a good book on the subject:
Catastrophe Disentanglement: Getting Software Projects Back on Track
First off, be resolved that you may fail -- if you can't accept that, don't take the challenge. And that includes being a scapegoat (it does happen). Management won't look at it in those terms (i.e. they're not intentionally/consciously 'setting you up'). But that is a reality of a corporate environment; if you take on the responsibility (often with more pay than those that don't), then your head is for the block if things don't work out. You have to be ready to stick with it for the long haul too. I was once placed on a client site for 8 months to fix a waning project. And as you saw, one of the other blog-posters here spent 9 months before a release version was ready.
Now, assuming you are okay with the possibility of it going all pear-shaped in spite of your efforts, this is what I suggest:
a bug tracking system is going to be your number one best friend, it will allow you to regain a semblance of control. you can't hope to understand a complex system as a whole, so 'chunking' it will help. and a bug tracking system allows you to unitize problems and distribute them to the other guys you are working with.
you have got both technical and political challenges to deal with. the technical generally aren't so bad because you're a coder and you know how to do this. the political ones are much trickier, you're at the helm of a ship thats gone hopelessly off-course, and you're in the Bermuda triangle. the biggest challenge is often stemming the tide of negative sentiment amongst the client (e.g. client: "these cow-boys don't know what they are doing", "they promised me this and didn't deliver", "i have no confidence in these guys to any more").
for starters, apologize to the customer and tell them in concrete terms what you are doing to do to re-right their project, e.g. you: "I'm sorry about the delay on your project, I'm getting stuck into it now. I've looked at the project history, and personally, I would be angry too if I was paying good money for this system. the first thing I'm going to tackle is..." <- bingo, you've just taken responsibility for the project which means there's no turning back - its all or nothing now.
a few other people have said it here, and I agree; stop adding new features. what they haven't mentioned is that you may have to do this to keep the client happy (remember, there's a technical and political side to the challenge).
understand the business domain as best you can. read through any requirements documents you can get your hands on. you are at a massive disadvantage by coming onto the project late since you don't know what was originally discussed. the devil is in the detail. this is what sunk me on a late projects I wasn't able to salvage, everyone was on edge, and i missed a minor requirement. at the time, it wasn't a big deal and could have been corrected easily, but politically speaking, it was the straw that broke the camels back. one tactic which may help is to go out on client site for a few weeks.
understand that time is money. its not just a technical issue. the client has paid for something which isn't right or has not been delivered. your company has expended resources, possible having already used up all the project budget - the business is now losing money. and this is where the issue of new features come in again, yes - people are saying don't add them, stablise. but adding new features can be a politically helpful tactic, management will be happy because new money is coming in for off-spec work.
I'd recommend against you or your coding crew working ridiculous hours to deliver. if you normally leave at 5pm, leave at 6.30pm or 7pm instead. you and your coding boys can consistently maintain an hour or two of extra work for many weeks on end and perhaps 4-5 hours over the weekend. working until 9pm or 10pm every night will result in burn-out in roughly 2 weeks (some can go longer). after that point, your extra time on the project is doing more harm then good. in the unlikely event your boss takes issue with this, make a choice; do what they ask (i.e. work more hours), or say "I've already committed extra hours to working on this project - I'm here for the long haul and im going to get this project done if its the death of me. but that is the limit of how much time I'm willing to put in. i have other commitments to keep outside of work" <- but be ready for the consequences (remember, political situation as much as a technical one).
there are people here that are saying "stop and write a spec, stop and do this..." - I'm sorry guys, i just cant agree with you here, its unrealistic. the project is already stagnating, the last thing management or the client wants to here is "we have to stop everything and...". I've tried this before, where I've said to the client and management "the bugs will keep coming until we stop and i write up a detailed system test plan. it will take me two weeks" - the client didn't want to pay for this, and management wasn't willing to wear the cost. as it happened, the bugs kept coming.
learn to 'juggle' - you have to map out tasks ahead of time so programmers aren't waiting on you. this will generally mean you do less coding yourself. generally this is best achieved by having a project schedule before coding starts. programmers should know what they are doing next after they finish what they are currently working on, and they shouldn't be coming to ask you "what do i work on next?", they should already know.
build-in recovery utilities, especially if the software has recurring problems which are hard to pin-down. for example; it may take 12 hours to track down a bug and fix it, it may take 2 hours to put in utility (read 'hack') to fix the problem for the time-being. time and momentum are of the essessen, and unfortunately bandaid fixes may be needed.
be very observant of the clients mood. they need to know you are 'on their side' (e.g. client: "the product is unacceptable", you: "i agree, i would kick our asses to if i was in your position. all i can tell you is im on it and wont rest until its all working"). when the client is back on your site, they will actually start helping you. for instance, they may shield you from pressure from your management.
lead your guys by example. something along the lines of "I'm staying back a bit to work on the project, I'd appreciate the help if your willing to stay back too" and "i know its not our mess, but we're still going to clean it up anyway. i want the client to get some good quality software". programmers could generally care less about the company that got them into this situation, but they may care if its about one of their own or the client ('may').
many of the suggestions I've seen here assume a fairly high degree of power (e.g. 'stopping the project to restart it properly' or 'say no to new features') - you are starting the project already hamstrung, and as a programmer, you will traditionally have less power to affect change then a true manager. this doesn't mean 'give up/don't try' - it just means you are going to have to be creative and do things you don't normally do (i.e. use 'soft' or people skills).
a lot of people here are saying bail on the project, run for the hills. I have been on 3 hopelessly late projects to date. i managed to fix 2, and 1 I couldn't fix. personally, it doesn't bother me to take on a late project. after all, the worst that can happen is you get fired :)
If you were involved in the project from the beginning, I hate to say it, but the company should replace you (and the entire team).
It should be reanalyzed with a competent team with real project management processes and lead by a project manager with experience in this situation.
None of the original coders should work on the 'new project' of saving it. They can move to other projects (they don't have to be fired) but to get a fresh look at the project, everybody should be replaced.
And of course, management has to understand and be on board with the fact that the project is going to be much later than expected. If management doesn't agree with this (replace team, find experienced leadership, take a step back and start again) then #Maxim is right - get out of there.
1) The first thing I will assess is whether the people on the team are committed to the project or not? If not, it is worthless to do any other thing. Nothing can prevent the disaster unless I get a dedicated and committed team.
2) I'll make sure that there is QA on the team.
3) Come up with a reasonable plan of iterative and incremental releases to the customer. With the mess we are in, there is no way customer can get everything soon. Based on the priorities of customer, we'll deliver smaller increments of functionality to him frequently. This will keep customer engaged, a bit less-edgy since he is seeing something happening.
What ever you do, do it step by step.
First, it's not about addind features, it's about fixing the app. Don't add anything new. Just refactor. Say no to any new stuff somebody ask you to introduce in the system.
Don't try to improve the whole app. Take your team, make it focus on one aspect at the time, with the best practices you can, especially using unit test.
Use test driven development only. In that case, it will immediately show you what part of the behavior you don't understand (you can't code a test if you don't know what to test.
So here are the road map :
Identify the critical part you need to change
Isolate the code that implies this behavior
Find any occurence of this code in the rest of the code
Refactor using this knowledge and massive TDD
Integrate, test and fix until this particular part works
Go back to step
Make the situation clear to your boss : it will take time, money and will be painfull. Explain why, what you will do, and that you have no other way or it will fail AGAIN.
A above all, don't try to make it clean the first time. Refactor what you can, but don't expect to change the entire architecture of the part you are working on the first time. You will have to iterate the process on the whole application several times.
No miracle. Just method and patience.
Been there, followed these steps:
Stabilize
gather the real story: how good/bad is the codebase, how good/bad are the developers, what really needs to get done (bare bone min.), when it needs to get done by
reduce overtime (tired people, good or bad, don't work well)
remove the bad, input new/good - err on the side of replacement (many could be burnt out and appreciate even a forced change)
remove access to bad/un-required code (focus on the 20% of the code base that provides the 80% of the value)
put base code practices in place ensuring only good code is getting in (don't damage the base anymore)
Control
implement teams focused on the app components (decouple as much as possible)
put code management, release management, risk management, QA, etc. in place (build your environment so you can succeed)
get on your clients/sponsors good side - delivery a win, even if it's a somewhat stable very very small release - and then put in change management (control what gets requested)
Move forward
develop a plan (planning is essential, plans are useless according to Ike - you need to plan to find what is missing and to set a target, but don't expect to tell the future) - continuous planning is required
aggressively manage your people - good people make good product - make sure you get and retain the best
refactor over time - clean up code as you go - you may not have the luxury to fix everything at once so do it overtime to provide for a cleaner code base
move forward bravely - overtime be more aggressive with your deliveries test (but not stress) your team
Agile refactoring. Identify and prioritize what customer wants and then create the most important stuff in short sprints out of existing code. Good luck man :)