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 3 years ago.
Improve this question
I am a reasonably experienced C# developer (about 5 year experience) that has recently been put in charge of my first development team as technical lead (varying between 3-5 other developers). Over the last 4 months in this role, one dilemma that keeps arising is trying to find the right degree of sharing awareness of the communication that goes on between the project manager, account manager, clients, designers, CEO and myself (especially via emails).
On the one hand, I know the more awareness each developer has of the overall direction of the project, the better they can understand the scope that their particular functionality has in the big picture.
However on the other hand, a lot of my time seems to be lost in the sea of emails between all the different stakeholders and managers, so I like to think that isolating the developers to just "what they need to do their current bit of work" will keep them free from interruptions.
I have considered just BCCing all the developers so they can filter these emails and essentially "opt in" to all the emails, but I'm concerned that some of the developers will just see this as extra noise to deal with. It may open the door to "too many cooks" if all the developers want to contribute to too many discussions. Yet on the other hand, other opinions can help me reach better decisions (i.e. House MD style).
Phew... so much to consider. Anyone have some wise guidance in this area?
Answering late, but still believe there is something to add to the superb advice given so far. To answer your question we need to go a level higher, hence the long response.
You’ve been made a tech lead responsible for team and although many aspects of your everyday job might seem to resemble your dev days the way you need to go about them has changed. In software development environment there is usually not that much of a tangible change when you appointed a tech lead (you’re probably still seating at the same desk, wearing the same outfit) as opposed to becoming a foreman on construction site or a factory. The flattering change though is that you now get invited into all these meeting and start getting all these e-mails and phone calls from people outside the dev team.
The lack of tangible change might trick your mind into thinking that you just need to keep treating your job mostly the same. This is not the case and you need to be conscious about your actions and re-actions in the new capacity. It might seem you’re now a bit “more respected” externally and you might be inclined to share some of that “respect” coming your way internally, play a bit of democracy and generally be fair.
Well, this is not that much about fairness or respect, the new job is to:
Direct the dev team (mostly by personal example and creating imagery depicting the goal).
Be an abstraction layer between the team and other organisational units.
Pretty much like in programming you often create an abstraction layer to encapsulate and hide complexity, the same happens in organisations. You’re the layer, the interface that has to encapsulate the dev team. And any good encapsulation from an outsider point of view:
Hides inner complexity that is not relevant to the task at hand (such as concrete implementation of an algorithm) from the outside observer.
Makes things that could affect the outside user explicit (exceptions that can be thrown, any limitations and constraints etc).
Always gives meaningful feedback.
Acts consistently.
These principles are equally applicable to the team’s outward communication. It’s not an easy task to follow these principles; actually it involves a lot of concrete work, such as deciding what details are internal and what facts need to be communicated and when, how the feedback needs to be best structured and be presented in a consistent manner and who should be notified externally of what, and who needs to followed up and when. This is a lot of work, even if some of it seems to be just trivial admin.
Now to internal, inward communication. One way is to broadcast. But it clogs the internal network and everyone has to spend their time on deciding whether the communication bears any relevance to them. It is like having a very generic algorithm that regardless of input always does the exact same amount of work. It’s sure possible, but why would you want to do that? A more efficient way is obviously to adjust processing depending on the input and here it has to be someone’s job to make a decision how the team should go about something, to dispatch, or convert the input:
Decide what sequence of actions needs to be taken,
or just acknowledge and store for future reference,
or follow up,
or put an issue off for a later review and then make sure it is reviewed and fed back into the decision-making loop.
This is not a small job either and someone has to do it. Obviously now it’s your job to manage the outward and inward communication, and you have to spend some of your brain’s processing power to do it well, so no one else has to and devs can concentrate on their tasks.
There are some other good reasons for not CC-ing or BCC-ing everyone regardless of your job title:
TO means “take action”, CC — “take note for future reference”, BCC — “eavesdrop or mass mail”. You should be careful when you use one or another e-mailing a group of people:
E-mailing a single person is a straight forward “TO”, when E-mailing a group of people only “TO” these who you need to take action (including a simple acknowledgement). This is default meaning, in any other case explicitly tell them what is expected (i.e. FYI, no action needed etc).
CC only these who you want to take note of the information for the future reference. If you expect a number of e-mails to go back and forth before an agreement is reached or issue is resolved don’t “CC”, it’s best to send a summary confirmation later to other parties that need to be notified. Besides saving everyone’s time and avoiding misinterpretation due to someone taking note of a non-final communication that will help make exchange more personal, flow more naturally, and reduce formalism and red-tape. Often CC-d e-mails treated formally and this isn’t always a good thing (but sometimes exactly what you want).
Using BCC is almost never ok. The knowledge of someone eavesdropping on your conversations if come to light will easily ruin your trustworthiness. It is simply a question of “when”. And should your team worry then that you might be BCC-ing their conversations to someone else? Mass mailing through BCC in most cases is also wrong, it creates an impression that e-mail is specifically addressed to the recipient.
Forwarding, CC-ing and BCC-ing require little effort, but multiply noise and dilutes signal. It is worth to give some thought to what exactly you need a person to do and what they should know to act on your communication before composing it.
Some conversations are best taken completely "off line" (phone or better still face-to-face), because it gives you more room for maneveour. Broadcasting or formalising in writting is just like putting yourself into a corner. You can always confirm in writing latter.
Moving to the second part of a tech lead responsibility (directing the team through personal example and imagery depicting the goal). To accomplish that you don’t need to pass on to the team every single piece of information that happen to end in your inbox. You have to create a story and any good story is an abstraction of real events that consists of only relevant and interesting detail for a particular audience. Creating this brief story on the basis of your everyday experience and judging what is relevant and interesting and then presenting it regularly to the team is also quite a job.
But don't forget that by directing the team and serving as abstraction layer you help developers and outside world to interact more efficiently, accomplish more and tackle greater complexity, the job has a point.
The engineering team needs to understand the business reasons of why they are asked to do things on a macro-level. The engineering team will gain understanding and motivation from this. But too much chatter is a no-no, as you note, part of your job is to filter, and part of that means not exposing them to tons of noise. Your developers likely have opinions and insights as to how to do particular things or why to pick particular technologies, and they should be fielded for their expertise in those areas.
Definitely don't create a culture of BCCing.
One option is to have separate mailing lists that interested parties can subscribe to, but of course, not all chatter will be on those lists.
And of course, a regular company meeting is a must. Let the engineering guys know why the business depends on delivery of a stable, complete product (or whatever the upcoming milestones require). 20 minutes, no slides, no bullshit is what works for me. Your team & situation may vary.
It sounds like you're technical so I would give you this advice: Follow Joel Spolsky's advice on what Program Managers do. Basically, try to isolate your developers as much as possible so they can be as productive as possible.
He just mentioned this briefly in this recent article, How to be a program manager, but he has gone into more depth on this topic before. Look through his past writings for more info:
Once the spec was finished and the development team got down to work, I had two responsibilities: resolving any questions that came up about the design, and talking to all the other teams so that the developers didn’t have to.
If you aren't technical then you need to select someone from your team to help with the design work and they will have to interface with the customer a little to figure out what the requirements are and what the best design is.
EDIT:
On Joel's home page there are two sections titled Tech Lead and Program Manager. Look at the articles there for some more info on program managers, especially Human Task Switches Considered Harmful.
I'd be using a Wiki, you don't want to add to the email storm, and your developers can also contribute and change things. It's also really useful for sharing documents, and if done well it will become self-supporting.
BTW Cut/Paste from email to wiki seems like an odd thing to have to do, does anyone know a lightwieght .Net wiki that I can email content too?
One way might be to not forward all those emails and once a week compile all the relevant information, design changes, and so forth into a weekly meeting. I definitely wouldn't send out a barrage of emails to the developers. Of course, if something critical is discussed, then that should be put to their attention. However, try for a weekly recap and discussion of relevant details.
I'm seeing this question one year after it's been posted, however I can add my experience with some specific data for my case. For 2-3 developers on the project, I mostly do one-on-ones. Lot of times I do this over the IM or phone since most of my team spends a lot of time in home office. Meeting from time to time is inevitable, mostly when project is starting (1-2 developer meetings tend to be enough to kick off reasonably complicated project), but as a rule, all communication with the rest of the company goes through me and developers get a digest. Only exception is when I connect developer directly with the user (not management!) to work out details of the project.
I tend to avoid regular meetings (weekly or daily) and schedule meetings only when at least two of these happen, in this order:
Important info comes in (depending on urgency this can wait up to a week)
Developers are in the office, preferably for other reasons (developer-to-developer meetings)
Client is available (not much choice there, but I try to do meetings and connect developers with single hands-on expert on the client's side later)
I need design advice (since I'm a technical lead, I'm responsible for most of the high-level architectural decisions)
For teams of 4-8 people (8 people usually means two teams) I found out that short 30-minute meeting roughly once a week is more then enough to keep everyone up to date. This, of course, is in addition to one-on-ones which I do daily for junior developer and about twice a week for senior developers.
For one-on-ones, I prefer that developers contact me when they're looking for more to do or when they're have questions on task they just started doing. This is also a great way for me to keep eye on how things are going without developers needing to think about keeping me up to date. I tend to avoid e-mail when IM is enough, otherwise switch to phone (when there's something to explain or discuss) and to e-mail when:
Customer reported bug via e-mail
There are a lot of important small details and developer will probably go through that e-mail a lot of times during implementation
There are also developer-to-developer meetings when they need to coordinate on something (for example, when Java and Javascript developer need to work out interface details).
This way of working means that I have to respond to IM as fast as possible, and that I usually deal with a lot of interruptions so that developers have to deal only with interruptions for me or other developers. Which is OK, since important part of my job is to make developers effective.
If I need peace for coding (and can afford it) I found that delegating client communication to non-technical project managers and even beta testers (who are much better with distractions than programmers).
Ask them what they'd prefer. I assume they would rather not be cc'd on every email and would opt for a short verbal update on a regular basis.
Related
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 9 years ago.
Improve this question
I recently got promoted to be the Project Manager/Supervisor. What do you think the leadership style a managerial role in Programming Dev't should have?
What's your style?
Hands-off, servant leadership, unofficial or "tribal" leadership over traditional management, seem to be all the rage these days.
Basically getting out of the way and allowing the team to get their job done seems to make sense to me, but it all depends on the culture.
I would say an effective manager would already have a style, and know how he wants to work, whereas a less effective manager would probably learn from other senior managers and simply emulate "however things get done around here". Actually in a lot of places the latter is the only choice.
If you have the freedom to do things the way you want, I would probably prefer to borrow ideas from the agile/lean camp than the more traditional PMI/Prince2/PMBOK camp, but it all depends really.
The job of a manager is to get out of the way and let the developers do their jobs. If they encounter an obstacle it is your task to remove the obstacle.
I do not believe to simple management guidelines. In an ideal world, the job of a software manager would be to just provide food, computers, electricity and salaries, but we are hardly in an ideal world.
In a way, being a manager is a highway to frustration. There are few opportunities for a direct contribution to the project, you spend most of the time on planning, meetings, writing reports, and proposing future projects. In a nutshell, you have the responsibilities, while they have the joy of building things. In order to avoid quitting the job due to lack of fun, one needs to find a proper motivation which would justify the troubles.
Now, different people are motivated by different things. Some people like to participate in group efforts, some like the achievement in building things which can't be built by a lone enterpreneur, some like the power, some like the money. I think that a management style should be tailored to the intrinsic motivations of all of the involved parties. For example, it is useless to try to motivate your coworkers with money if they are primarily interested in building cool things (and vice versa).
A key competence in managing people is being able to address conflicts as early as possible. The conflicts range from trivial (X keeps committing buggy code to the repository) to critical (we need to hurry up in order to hit a deadline). I think it is very important to be able to express such concerns frankly and clearly, regardless of the managements style. Thus, at the end of day, oral communication capacities would be at least equally important as the management style.
I dont think it matters alot what style you choose. When leadership is "broken" it usualy is due to more basic things not done right.
Consistency: stick to your style unless you are sure it doesnt work out.
Honesty: Might seem obvious but when "fooling arround" too much with carrot and stick it can get out of control
Respect: Tech-Guys have all different characters but grasping what they value is easy - being passionate about technology and using it in professional way will open hearts. Waveing about your iphone showing off fancy looking but technologicaly trivial apps might result in the opposite ;)
Lead by example: You techs do extra hours? You do extra hours too!
Motivation: You dont need a jungle camp every 3 weeks but you can still help everyone to feel better about seeing each other more often than the family. Implement a friday afternoon beer-session if that is acceptable (be strickt about times though, no drinking before 6pm for exmaple). Show interest in what people are working on even if you are not part of operations. When working on abstract subjects people can have a hard time to put into relation what value they add to the company and to the team. When "in the jum" programmers particularily can become like lone astronauts - Having a broader understanding about your business you will need to remind people about the mission (though thats PM tasks mostly, but no PM is perfect too)).
In the end you are good leader when your team says "WE did it!"
There are plenty of methods with catchy names, but in general I prefer the management style to be lightweight and encourage communication.
I suspect a lot of us have had the experience of having to spend more time filling out forms than actually developing. Than is both frustrating and unnecessary. Controls are important, but a new form is not the solution to every managerial problem.
As far as communication goes, many managers seem to believe that it will work if everyone reports up to them and then they send the collected information back down. That can really lead to disaster. The team needs to communicate with each other well and often.
Finally, I'd like to throw in that as tempting as it is to take a new resource for a project and get them developing as quick as possible, I think it will always work out better in the long run to hold off and get them properly trained and oriented to the project.
My style is a combination of Attilla the Hun, Napoleon Bonaparte and Nelson Mandela. Whatever you do, don't try to adopt my style.
More seriously, to be a good leader you have to develop your own style and you have to integrate that into the culture of the organisation you work in. So, the answer to your question must start with asking yourself some penetrating questions and giving honest answers to them. You must also take some time to understand the traits of the individuals in your team and figure out what makes them tick and how to motivate them as individuals. What works with one may not work with another.
And, while I'm writing, I'll direct a passing kick at the respondents who suggest that it is a manager's job to get out of the way and let the team work: it's the manager's job to manage, you have people you work for who have certain expectations of you and you have to pay attention to them as well as to the losers on your team.
I write 'losers' because you have just been promoted and they haven't. Sure, you have to lead them to great achievement but you won't do that by keeping out of their way, you'll do it by leading them in the right direction, with the right mix of carrot and stick. Oh, and don't let them know that you think they are losers, it will upset them.
First of all; if you try to adopt a "style" that's not your own, you will most likely fail. You basically just have to be yourself! (That's probably why you got promoted in the first place) That said, there are some theorems to embrace, one beeing "you can always be a better leader" ;) I guess that's part of why you posted this question. My advise is to support your co-workers, and remember that it's your job to make them as good as possible. Try to keep yourself on top of all that happens within the project and encourage communication within the team. Agile style development helps with that. Also, try to put yourself in your co-workers shoes and try to imagine what they expect and want from you. Best of luck
There is no one "style" that you can or indeed should focus on. The reality is that you are now a people manager and people are all different. You need to learn to recognize the differences in the people you are managing and respond accordingly. This is a technical role, so if you have some technical understanding then this will assist with gaining respect of the team.
Some people need to be told what/how, some people need a gentle prod and some need full ownership of a task. Learning to spot the differences is where you need to apply yourself.
Typically people fall into 4 distinct camps with different names depending on the management course of the day :)
Beginner, highly motivated, not much experience, needs a more directive approach
Learner, more capable, but may be experiencing frustration, needs coaching
Performer, very capable but may lack confidence, needs supporting in their approach
Achiever, capable and committed, needs delegation of tasks
Management 3.0 Leading Agile Developers, Developing Agile Leaders by Jurgen is a book dedicated to answering this questions. http://www.management30.com/. His home page is here http://www.jurgenappelo.com/
In his book and class, he refers to Martie, the Management 3.0 model. It is composed of
Energize People
Empower Teams
Align Constraints
Develop Competence
Grow Structure
Improve Everything
An excellent introductory presentation can be found here: http://www.slideshare.net/jurgenappelo/what-is-agile-management
Jurgen's two key takeaways.
A software team is a self-organizing system. Support it, don't obstruct it.
Agile managers work the system around the team, not the people in the team.
Enjoy.
Closed. This question is off-topic. It is not currently accepting answers.
Want to improve this question? Update the question so it's on-topic for Stack Overflow.
Closed 9 years ago.
Improve this question
How do you cope with that?
Is it normal to allow the costumer to change the software as often as he wants? I´m working in a environment where there are no specs and constant requests for changes.
For every new costumer we have to create a new branch and makes so many changes that by the time I finish I have a complete different product. I´m pretty much losing my interest in programing because of that.
So, am I wrong to say that the costumer should not be allowed to change the software at his will?
English is my second language, so please excuse any mistake.
Related:
How to deal with poorly informed customer choices
EDIT: I originally missed the part that you have many customers and are customizing a single piece of software for each. I'll leave my original answer for reference, but it's not really applicable to this particular situation.
In your case, I would suggest that you need a different tack to addressing customer concerns. One technique I have seen used is that any changes need to be consistent with making the product more useful for all customers. This would mean that you can say yes to many changes. For example, making the UI customizable via templates. That would benefit all customers, but may be driven by a particular customer's desire to fit the look-and-feel into their standard. But it would also mean that you need to say no to some requests, or modify them in a way that they are generalized to be useful to all.
You may also want to have your customers use something like UserVoice to make feature (and bug) requests and vote on them. This allows your customers to have some direct input into the direction of the product, but forces the requests to be filtered through all of them. Again, you need not always accept the highest rated requests and you can accept some lower rated requests. The guiding principle ought to be making your product useful to the widest range of customers.
I don't think that it's practical to have a separate, custom branch for each customer unless you plan to have only a limited number of very high-paying customers. Eventually, your version control system will become your bottleneck and not allow your company to grow or even serve your current customers well.
Once you get into a more sustainable feature selection mode, my original answer may still apply. Hope this helps.
Original
I'll say up front that some customers are just not worth having. Only you can tell when this is the case.
Typically, though, it's our job to discover what the customer actually needs and deliver that. I'd recommend following an agile development methodology to do this. Rarely does a customer actually know up front exactly what he needs. Even more rarely does a developer understand what a customer needs before they start writing code. Agile methods embrace this reality and follow practices that make change less damaging to the process.
First, agile methods employ lightweight processes and delays making decisions until the latest possible moment. There is "just enough" up front planning to lay out a basic architectural framework, but for the most part it is design-as-you-go. This is not as freewheeling as it sounds as the techniques used in agile methods, such as TDD, pair programming, refactoring, etc. are sound techniques that encourage good design and design improvement.
Second, agile methods are light on documentation. While not documentation-free, these methods keep document maintenance to a minimum. One of the worst aspects of change is that documentation becomes dated and must be constantly updated to be correct. Agile methods identifies those documents that are truly useful and maintains those, but other documents that become out of date can be discarded. They are used in the moment as needed, but you are not tied to them. Agile methods put a premium on the code, and tests, being self-documenting.
Third, agile methods encourage a cooperative form of development based on mutual trust. This goes both ways. The customer must trust that you have their best interests in mind, while you must trust that the customer knows or, at least, can recognize what he needs when he sees it.
Lastly, the hallmark of agility is release early, release often. Getting the product in the customer's hands early is the best way to get feedback (again, early) on what he really needs. Once you have a concrete product you'll start getting information on the changes that really matter. By planning to release early and often, and coupling it with other agile practices, you'll also build a framework into which change can fit more easily.
Even when following these methods, though, as I said earlier: some customers are not worth having. If your customer doesn't trust you enough to follow your advice when a change is bad or if the customer doesn't know and can't recognize what he truly wants, then there may come a time to sever your ties with them. I'd suggest that talking with them and letting them know that you want to get them what they need, but they need to know what that is. Spend some time talking about it so that you both have a better understanding of the goal and put into place agile methods to deal with the reality of change. If they are still unreasonable, then perhaps it's not going to be a good fit for you.
am I wrong to say that the costumer
should not be allowed to change the
software at his will?
Who owns the software? You or them?
If I own a house, I can hire someone to paint it in a different color every week if I want to. If the painter complains, I can get a new painter. If I run out of money, maybe it is because I am an idiot. But the painter did nothing wrong in painting my house, getting my money and using it to feed his family.
If I own a certain software, I am allowed to do whatever I want with it. And if you don't do it, then I'll ask someone else.
specing out the app is as important (more even) then implementation. Giving the customer at least a base line document, UI mock up or something like that i think is critical.
you have to accept change requests as the system evolves and matures, otherwise the system will suffer from entropy and any hard work you have put in will be lost forever. if it is a more commercial product try and restrict to changes that all your customers want. then everyone is getting added value.
If you have baseline documentation you can then charge for customization. the less you want to do the customization the more you charge :P make sure you document and estimate all the change requests. (i use fogbugz for this but there are many other tools out there) If the customer is paying for the changes then at tleat you will be getting renumerated for the pain of changing the system.
Your company is running itself hopelessly into the ground.
You should go job-hunting immediately.
before i put forward my suggestion, i should say i personally believe that a business is there to make money. so if a client is willing to pay for something they want, figure out how to accommodate them (rather then turn them away).
now, a solution:
i was at a company where they had a software package which they sold to many government organisations - each with their own particular tweaks and features.
i asked the managing director how they avoid version hell - considering they have to maintain a specific version for each client. he said "we dont, everyone gets the same version". they simply maintain one version for all clients, but switch off features which arent specific to a client.
LM
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 3 years ago.
Improve this question
I read
what-payment-structure-do-you-use-for-small-projects
and I wonder how you guys are dealing with bug vs. feature. I once had a situation where a client wanted static reports. Then near the end of the project after most of the work on reports had been done he said he had always wanted dynamic reports. That change was not easy, because framework we choose did not support dynamic reports. It was a weird situation, because client had a programming team, so they should have known. Maybe it was just a lack of communication skills.
How do you guys deal with clients trying to make you add features, because they forgot, change their mind, or were misunderstood?
I mean big features, not small ones.
EDIT:
He stated that the budget is fixed and can't be changed and that this feature (like every) is critical and without it they wont accept the system. (just worst case scenario)
In my experience, having been on both sides of this issue, this is usually more about economics than it is about programming, process, or project management.
We, the client, often say "it may be a feature, but if we call it a bug, maybe we can get them to do it for free."
In the end we, the programmer, charge or don't charge based more on whether it will help or hurt our chances for future work. We, the client, dangle the carrot of future work as the incentive to get the programmers to do the extra work for free.
I don't believe any of that will change just because we have a better process for saying "this is a bug" or "this is a new feature."
It is important that both sides understand what they're getting for their money very early on in the process of software development. The Agile methodology is an excellent tool for managing this process. If you have your team's velocity, you can fairly accurately determine how many features it will be possible to add during each iteration. Estimate the tasks, and keep the customer involved in prioritizing what features are to be added and what things are less important. Be sure to have a customer demo after each iteration to show the working functionality you both agreed would be working at the end of the current iteration. Should the customer want another feature or significantly change one that you have already agreed upon, estimate the number of story points necessary (units of work used in Agile) to make this new change or rework a current piece of functionality. This will help them remove another feature that they consider less important than the current one they have just suggested. This keeps everyone happy and there are no surprises when the product "ships"
There is no point in trying to argue them out of the feature. After all, communication issues or not, the mission is to deliver what the customer needs in the software.
I'd go with an Iron triangle argument as follows:
1) Obviously we want to deliver the product you need, so lets work together.
2) We all understand that regardless of how we got to the current point, we can only go forward from where we are today.
3) We also understand that implementing changes will take time and money which has to come from somewhere.
4) At this point your options are these (pick one)
* Replace the work that was planned for some other functionality with the work required for this change to stay on budget and schedule (sacrifice other features)
* Extend the deadline (increase cost/shift deadline)
* Add resources (increase cost)
Warning: Although C makes logical sense if you are doing manufacturing type work (build another 1000 pencils), in R&D work like software engineering it usually is just another flavor of B where you the cost and deadline shift is magnified.
If it isn't in the project plan / written agreement it's out of scope.
We have the spec in writing and have the client sign off on it, agreeing to pay for the features described in that document. If they change their minds later on something simple, we will usually work in the changes for no extra charge, but anything like what you described would require a new purchase order.
Well, simplest answer is that the budget or contract stipulates the requirements. Changes to those requirements have to be submitted as an extra and then go through the same process as the original project. They have to be budgeted for and estimated.
Once all that is done, if the client wants it close to the original launch date (and that's feasible), add extra for overtime hours.
At least, that's what I've done.
I charge them.
I would recommend making sure that the requirements are ironed out as much as possible, and that both sides understand exactly what is being promised. It keeps the client happy because there's fewer situations like you describe, and it keeps you happy because you don't keep getting yanked around.
The question is about two topics: negotiation and project management.
As far as project management concerned you need to manage the risk of customer changing their mind or misunderstanding an agreement in advance. Here is a list of preventitive measures one would normally take in a software development project, it can be used as a checklist when planning or revisiting a project:
Avoid most of the risks by having a written spec aproved before you start. In case you do smaller iterations have a spec for iteration approved. It doesn't need to be overly detailed but should set customer expectations and serve as a reference point. Detail things you're not certain about in the spec.
You might have an opportunity some other ogranisation that reports directly to the customer to do certain risky bits.
Put some contigency time and budget into the plan, exlpain to the customer that any contigency is going to be used only by agreement with them.
Explicitly offer alternative solutions to customer on the planning stage, discuss pros and cons and document the decision.
Even if you do waterfall build in several milestones into the project where you will make a litte demo to the customer or clarify requirements. Take that opportunity that customer is still ok with the proposed solution.
As pointed out by Webdtc always confirm outcome of phone and face-to-face discussions by sending a short summary e-mail.
Keep deliverables, their acceptance and payments spread out for projects longer than a month. Even if customer pays at the end of the project make sure you get evidence of their approval of interim deliverables.
Hopefully, following these tips won't ever put you into a tough situation when you need to negotiate deliverables with customer post-factum threatened by a non-payment. But if nonetheless you found yourself having to stand up to unreasonable demands the info you would have accumulated by then would have given you very strong leverage. Tips for negotiation:
Start with understanding the exact reasoning behind customer demand. And exactly what their position is. Confirm with the customer you understand them correctly.
At this point it can be either your fault (unlikely if you managed the project correctly), customer's fault (sometimes they do change mind their mind) or a cock up on both sides (most likely).
When it's all your fault most likely you'd need to swallow the pill and learn your lesson. However you'd need to negotiate with customer new deadlines to prevent the problem costing you even more. Always consider suggesting an alernative solution to the problem built on top of the software you've got now.
When it's customer's or mutual fault start with "no". Push back to let them understand you not absorbing the cost, not fully at least. Don't let them convience you that they can easilly walk away, this is never true. By this point even if they haven't paid you a penny their investment into the project will be sizeable: time spent evaluating bids, taking part in meetings, the effort they made communicating requirements, their and their customer's dependency on the project being completed mostly on time and within budget etc. You still might have to split the costs between the two organisations, but start with "no" to make it clear that they are as responsible for making an effort to timely clarify requirements as you are for discovering what is needed.
It sounds to me like the client may be looking for an excuse to get out of the agreement without paying anything. If he can arbitrarily add features and insist on them for final acceptance, without additional cost, he's got a way to make you break the contract.
There's two obvious ways to avoid this.
One is payments throughout development, so that the client can't wiggle out of much of the payment, and you're more or less compensated from what you've done at any point.
Another is a good contract. For any reasonable software project, a few hours of lawyer's fees is cheap insurance against something like this. If you are confident that you can sue the client for agreed-on fees and win, the client is less likely to make trouble, and if all else fails you can sue.
I don't know what the contractual arrangements are that you're working under (and I'm not a lawyer anyway), but in a situation like that I'd get a lawyer and see what sort of situation I was in. Even if you're in a dubious legal position, it's possible that a letter from your lawyer could help resolve things.
And don't get into that position again.
Well, if it's the truth, just go by it. What's to explain if you agreed to one thing and now he wants to do extra? Are you receiving push back?
I would make it clear that we originally designed a static report and that was what was signed off on. It can be extended to dynamic reports and that you can provide a quote if he would like to know the specifics.
I often use the analogy of building a house. Either the client is changing the blueprint, or the finishing materials that are requiring more time, materials to get done from what was originally agreed to.
Hope that helps!
What I do in this case is look at prior documentation and communications.
For example, if documentation/communication says "Create reports". If there is no specific mention of dynamic reports I would not give in to the client.
If there is any documentation saying "dynamic reports" then the client would be right and I would have to develop the reports at no cost.
If there is communication about "dynamic reports" I would have to look at what the final outcome is. This is where it might get harder because a lot of times a client might as "Is it possible to create dynamic reports?" and a developer might say "Yes, that is possible." (meaning it's possible, but does not mean we will do it). This is where I would have to explain that although discussed it is not in the scope of work. There has to be concrete agreement that a feature will be developed.
If you do not keep documentation and prior communications then I would say you are at a loss and would need to decide if you are going to give the client what they want or risk losing the client.
One of the worse things to me is a client who insists on telephone communications. These clients are the ones who usually play it fast and easy with their requests. What I usually do here is to always do a written follow up with the client on everything that is discussed during a face to face meeting or phone call and require the client to respond to make sure we are on the same page on what will and won't be done.
There's no right answer - just a few wrong ones. Specs and requirements have more white space than information - there's always room for interpretation and misunderstanding...what it really comes down to is:
future work - is there future work with this client or potential reference for future work? if so, you give in a bit, try to un-grey other areas of the deliverables that, based on this instance, could turn in the right direction.
payment - are they holding payment based on this? and is the work still within your buffered budget (you did add a buffer for this type of work - right? well, next time you will - future clients pay for past client mistakes)
deliver quickly and often - IKIWISI -I Know It When I See It - if it's in front of the client sooner then later, then the 'interpretation'/grey-areas get reduced...iterative deliveries (even incomplete ones) work wonders
After the fact you can't do much, if it comes down to legal action, you lost this client and a good reputation (potential) - be careful in how hard you push it
I'm in a situation where this happens on a regular basis. We write web applications that do complex tasks, then after we've completed it according to specification the user will then turn around and say "We want not just X & Y, but we want Z too". Z wasn't in the project scope and thus isn't achievable in the current system, therefore it must be rewritten to acommodate for the newly introduced "features".
The way we work around this is simply as follows. Treat the user like they're an idiot, and understand the system better than they do. I know this sounds really mean, and at first when my boss introduced me to this I told him straight that I would never treat a user as such - unfortunately I learnt the hard way and now have to know more than the user to complete my tasks. Mitigation is of the utmost importance, and foreseeing major changes which could be introduced is a skill learnt over time.
I now mitigate for these unplanned, but probable changes.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 5 years ago.
Improve this question
I want to avoid the situations when my developers do not share the common knowledge (solutions for the problems they encountered, cool tips, common mistakes, shortcuts for achieving particular goal, configuration issues, partial requirements, etc.) with each others. I'm taking about the situation when such lack of communication is accidental (a result of the misunderstanding or improper management) - I'm not thinking about the situations when developers deliberately keep the knowledge for themselves.
I believe that the following techniques are extremely useful to improve the information flow within the developers team:
XP pair programming - due to the knowledge exchange within the pair (and due to the regular pair mixing).
stand-up meetings - due to the occasion to tell the others on what you're working on and what problems you encountered.
trainings/presentations/coaching prepared by the lead-developers to the rest of the team/department.
"web 2.0 tools" - techie blogs for the company/department, dedicated twitter account of team leader, wiki's and stuff like that.
Any further ideas? What techniques do you use (or did you) in your company? How would you encourage developers to share the knowledge between themselves?
Trust.
You are allowed to 'seem stupid', but please ask if you don't know, or don't fully understand what I'm saying. And please tell me if I'm wrong (I didn't realize it because I'm equally stupid.)
I worked at one company where every Friday we had lunch meetings for developers. Management would provide food while developers had to share their knowledge; present some tool or technique one learned recently, or give a demo of a project you are working on, etc.
It wasn't restricted to the technologies that were being used by the team at that time, developers were encourage to learn new technologies and give a demo to the team.
And at my current job we have monthly IT group meeting, where sometimes developers from different teams demo off the projects they've been working on.
An internal twitter-esque utility. Maybe a wiki if you can get it to work, I personally find it a little too much. But twitter is different. "just added an extention method to escape a like clause in a rowfilter" and stuff like that.
Some people may find it a little overbearing, but a common location for utilities so you know where to look and string.CountOccurrences isn't scattered throughout the codebase.
I'll add a few more
Hire the right people - This is essential if you want to create a great dynamic (asocial people require a lot more effort)
Pre-mortem and post-mortem. We use the wiki for this, create a page for each of your projects, split it into section of recurring things (both goods and bad). At the end of each milestone, have the team meet to do a post-mortem. At the end of the project (or after a fix lenght of time), have project coordinator compile this into something easy to read for posterity (and put it on your wiki)
Daily stand-up are a must! You already said it, but I find it so helpful!
If you have multiple teams in the company, organize conference about one of their greatest achievements. If possible on a regular basis, even accros department, you would be surprised how artists can be interested into programmers work.
Lunch is a good time to share, in our company we have the president breakfast, project leads lunch, end of projects supper. I love them all, mix and match for greater results.
Offsite meeting with the whole company is great, we do it at least once a year (morning we present what's coming up in the futur, afternoon, is activities to learn about the projects)
Wikis are great, but beware of informations that can become false over time (this is a reccuring problem with any written informations)
A few more things to my mind:
Patterns & Practices meetings - These don't have to be every week but there should be some time devoted to where the team can discuss various outstanding questions and have concensus for things that may save a lot of people headaches.
Culture factor - Does the work place provide enough socializing to help the team gel or could some team-building exercises, e.g. an obstacle course or cooking together, be useful in getting some dynamics established. Is there a humility among developers so that there aren't big egos that can be a problem. Another factor here is to think about how you'd answer this: Would you go to a local pub and have a drink with your fellow teammates? If yes, then you have some good points here while if not, then there may be some investigation to do here.
Retrospective follow-up - How are ideas presented during retrospectives considered and implemented? How are meetings handled in general?
Demos within the team - If some story got finished and involved some big code points, then perhaps there should be a little demonstration of this for the team to see what was done and allow others to see what was done so that the knowledge does get spread around. This can dovetail with my first point in terms of being something that helps to further communication.
I'm a big proponent of working in pairs. It is a good way to transfer knowledge and keep communication lines open. Try mixing up the pairs for each project as well.
I've tried many approaches, and am a big fan of working in pairs on projects, as well as doing regular discussions or meetings with the team.
However, I've also found that the single best thing I can do is foster a culture of constant communication between the developers. I try to have all of my developers communicate with each other as they work - not even necessarily waiting until a weekly or monthly meeting.
For me, this is a little trickier as most of my developers are not in the same location, so we have a single XMPP chat room setup, and all of us are always logged in when we're working on the project. Some of the developers (including myself) will login during our off hours, as well.
I do the same with the people in my office - we tend to be a fairly quiet bunch, but I'm very open to having people interrupt each other with questions, or grab a chair and sit down to brainstorm at any time.
Part of why this works, though, is I try not to restrict the communication to the work at hand, or any specific project. My feeling is that people are going to talk about other, non-work related things, whether or not I foster that. I'd rather have the "water cooler" talk in an official channel, though, than outside.
This makes everybody feel more at ease to ask the questions that "seem obvious". Also, people ask questions continually, since they're right there, and used to talking to everybody. It's easy to ignore if needed, but also much easier to just throw out a general question and see if anybody has ideas without feeling like a pain, etc.
My experience is that the time lost due to interruption is much smaller than the time saved due to having a group that is always eager to help solve a problem at hand.
If you have a small enough team, using adequately SVN commit comments, and exploit them a tool that generates an RSS feed (like Trac for instance) can be an easy and efficient way to promote communication.
There are several requirements for this to work, which are quite easy to attain:
- commit frequently (that is good in itself, as it allows everybody to benefit from each programmer's local changes, and to identify problems early);
- use verbose comments (which is good to, as it allows to trace more easily what was changed, in case anything breaks down);
- ensure everybody actually reads (better even, keeps posted to, through an RSS reader) the feeds.
Of course, there is no way to "reply" to such comments, but if someone really needs to reply, it's probably between that person and the committer, so mail is usually enough.
An other useful tool is to ask each developer to, let's say, once a week, write a 10 or so bullet point list of recommendations for fellow coders, on a topic he/she is really familiar with.
Time.
Official
Getting out of your dusty office to clear your mind, really taking the time to go to a lecture or training, it all helps to spread knowledge.
It's also easy to budget: N developers go to meeting for T hours.
Unofficial
"On the job" training... The things you need for your specific job can only be taught by someone who knows the job.
In the current climate, under the current pressure (must ship now), no-one takes time to fully explain something. Only when people are relaxed, they are readyfor information sharing. People are relaxed when they have enough time.
Apart from that, you need to bump into some specific linker error before you really start thinking about it. Without the time to think, ask, read, you won't be able to get the knowledge. You can't postpone it to an official linker-training.
Way harder to budget: developer Mary asked developer Sophie about dynamic linkage for an hour and a half. The day after, she went back with some questions. Experienced developers will spend more time distributing, while younger will need more time learning.
no walls - Have all of your developers in one large, non-walled room - where everyone can see and talk with each other.
common goals - ensuring your team has a good understanding of goals INCLUDING the goal of self-improvement
rewarding - rewarding - even if nothing more then communication - reinforces what you are looking to accomplish
Socialization and common goal always encourages exchanege of information.
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.