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 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 11 years ago.
Improve this question
Being relatively new to the software industry I have come across a question of deadline enforcement:
Back in the idyllic age of academia, the deadline was the end of the semester and the penalty was a well defined 'F' (or local equivalent). Out here in the real world we need to make code our current and future peers can work with, I face the situation where deadline comes, deadline goes, and the project is still not finished.
Now what? On one extreme we could fire everyone involved, on the other we could richly reward everyone involved.
What actions have you seen applied as 'penalty' for missed deadline, and which of these eventually resulted in more-good-code?
What project-management responses caused the project to fail outright,
What responses restored working order and resulted in code that could be maintained afterward?
What responses resulted in more-bad-code?
Deadlines are part of a fundamentally wrong idea about how to do software development. People new to, or outside of, the software development industry do not understand this:
Software is done when it is done, no sooner and no later.
If a developer has a task and a week to do it, and it looks like it will take more than a week, nothing can be done to change that. No matter how much harder the developer works, no matter how many people are added to the task, it will still take as long as it takes (in fact adding people usually makes it take longer).
Instead, read up on the agile development process. Software should be developed iteratively, and each iteration should be based on the results of the previous iteration, not on external requirements imposed.
Edit based on the extensive comments below:
I would never argue that developers cannot be held to some kind of delivery expectation. My point is in response to the specific hypothesis which the asker posed - that the nature of software development in business is somehow analogous to schoolwork, or any other kind of work for that matter. I contend that it absolutely is not. "Deadline" implies much more than a simple delivery date. It is a fixed point by which a fixed amount of work must be completed. Software simply does not work that way. I wrote a few more paragraphs explaining why, but honestly if you don't already believe that, nothing I say is going to convince you.
If you are working on a software project and it is clear you will not be able to reach your deadline, what can you do to rectify that? The answer is well-known by now: practically nothing. You can't add more people. You can't "work faster". It's just not going to get done on time. You tell the stakeholders, everyone adjusts, and keep working (or not). What, then, did the original date mean?
Anyone who claims software development is analogous to bridge-building or homework or that impending deadlines can still be met if the developers would just get their shit together and work their asses off, are deeply confused about their own profession.
Your first reaction should not be what to do in response to the missed deadline, but to analyse why you missed the deadline. The response to missing the deadline would then follow naturally from that as a consequence of the reason.
For instance, if everyone involved didn't do their job, fire them.
But if they did their job, and more, then why was it still missed? Too much other activities done by the same people? Too big a scope for the deadline (ie. unrealistic deadline). Or ... etc.
The top reason for missing a deadline in my experience is that people aren't allowed to work 100% on the project at hand, and thus any estimates you might have, although accurate on their own, aren't really useful at all. That, plus unrealistic estimates and deadlines.
Developers should never be penalized for Management's mistakes.
It's like a parent punishing a child because the parent had a bad day.
Reasoning:
Deadlines are a fact of life. People want to know how long something will take. The best we can do is estimate/guess. It is the role of management to try to figure this magical, never correct guess. When they create a deadline, they need to use the right tools (experience, ASKING FOR HELP FROM DEVELOPERS, lawyers, hr, etc)
However....
The penalty for missing a deadline should not fall back on the workers. It is the management's fault for missing deadlines. They should have said no, should have scaled back the project or should have motivated the workers better.
In a construction crew, if you piss of the workers, you start a fight. In my company, if we miss deadlines, the management gets in trouble. Not the workers. It's the manager's job to control the project and what is done. The workers are only doing what they can. The manager's are in charge of assigning roles and tasks.
I'm not saying the quality of workers isn't a factor, but the management should KNOW that! It doesn't take a genius to know that a project isn't well thought through or nicely controlled. Ask anybody if their manager has any idea what's going on and you'll find the problem.
We stopped missing as many deadlines when the managers realized it was their fault for setting/agreeing to the deadlines.
</rant>
Re: The questions:
1.What actions have you seen applied as 'penalty' for missed deadline, and which of these actually made things 'better'?
Manager has less responsibility. This person does not get promoted or publicly thanked. Most likely this person will be moved to a "less-critical' project.
2.What project-management responses caused the project to fail outright, and what responses restored working order and resulted in code that could be maintained afterward?
feature creep: manager keeps adding more stuff in the list. <- fight this off with a List of tasks ordered by priority. When you add things to the list, compare their priority with the things around it. Make new things harder to be set as "top priority."
too many bugs in the code: Manager need to require tests (atleast critical) and automation. Builds need to be standard and automatic. Real users need to see the code before it is "finished."
un-readable code: Institute peer code reviews. If someone has dirty code, ask someone to "help" them with a project.
If you have the salesman problem, where the salesman promises features that doesn't exist/work: Management needs to step in and explain the problem to that salesman. Also, not giving that salesman public affirmation for a job well done sometimes helps this.
Rather than a penalty, how about realistic estimates and rewarding on-time releases?
Inspired by the comments to my response
Maybe the question should be "How do I make realistic estimates?" For me, I use FogBugz estimation history and completion date plots. These give me data points of how long I estimated a task to take and how long it actually took. This has helped guide me to give realistic release dates in the long-run (it didn't happen overnight). I find estimating timelines to be an interative process: I
design
estimate
develop
find an shortfall in the design & iterate.
Death. Clean and simple.
Depends on whether developers set deadlines on each modification request, or whether these are set for them by management.
In the latter case, unless all your developers are sitting and playing Halo 3 all day, a missed deadline is often an indication of a mistake on the side of management or the team leads. So firing everyone wouldn't solve the problem. It might make sense to introduce better indicators into your software process so you could see that the deadline would be missed long before it happens.
If your developers do give time estimates, then I would be very careful about rewarding and penalizing developers for meeting deadlines or missing them. The result of doing this could be that they would adjust their "fudge factor" in time estimation. They would give themselves too much extra time (to reap the rewards), which messes things up if they are good at estimation. Your goal should be to get them to give good and reliable estimates, not to change the way they work to meet these estimates.
It depends on if the deadline was possible in the first place, maybe it was a fault with the planning and estimation of how long it would have taken. Make sure you know why the deadline was missed before deciding punishment
Oh, man...
First of all, there are external deadlines and internal deadlines, and they should be different.
What happens with an internal deadline is the frequency of activity increases as the deadline approaches, reaches a peak at the deadline, and then falls off as the deadline recedes. So plan the external deadline to follow the internal deadline by a couple weeks at least.
Then, make sure the deadlines are realistic. Partly you do that by involving the developers in setting them, and in deciding what will be accomplished.
Finally, I've mostly been a developer, but once when I took a stab at management, I would never want to take the latest-and-greatest version into a conference or presentation. I would want to take a version that was at least a few weeks old and that I knew where the problems were and that I could be sure would not contain unpleasant surprises.
In his wonderful book about project management - "Deadline" - Tom DeMarco tells us a story, about project manager from a western-world is managing a project in some fictional post-communist eastern European wild country (wild is a really good term, because the citizens are a bit.. uncivilized).
One day PM discovers, that something went wrong, some part of his project dramatically missed the unrealistic schedule. Previous PM established penalty for missing deadline simply by hanging responsible person on a butcher’s hook, but as schedules were unrealistic, one man already missed deadline.
So the story tells us about a day, when western-style PM is presented with a responsible person, and he should send him to be hanged on butcher’s hook. PM, as most people do, is terrified of vision of sentencing someone to cruel death simply because some was never able to finish his project in time. And – by all means – hanging this poor man does not advance the project. Since this is a fiction novel about project management, and not about tortures, our hero cancels the penalty.
But there is some big issue behind this story about hanging someone: if you set a deadline, and establish some kind of penalty for missing this deadline, the day will come, you will probably have to actually punish someone. And will you do it? No matter what the punishment will be: hanging, bonus loss, firing, breaking the deal or some fee – you may have to punish someone. Will this penalty do some good to your project? You have to answer it by yourself.
So: do not establish a penalty for missing the deadline, you will not want to execute…
As others have mentioned, before talking about penalties, start with "how do we determine whether these deadlines are realistic"?
Or as my boss once said, "We'll be happy to work a plan when you give us a plan that works".
I still think that should be on a t-shirt.
Once you've reached the point at which people have blown the deadline, you have to ask yourself (A) what the natural consequences of that are and (B) how you can best complete the task and maintain some kind of movement towards the business objectives (even if you're not running a business).
Explicitly penalizing people for blowing the deadline is unlikely to help unless they believe that they've earned it. This will not happen if the deadline was unrealistic, if there were elements of the team that were the primary points of failure, if there were serious problems with requirements, or if the majority of the team involved believes that the above factors are true.
In one case I was on a team that blew a deadline on a small deliverable by over three months - and the original deliverable due date was three months from start! We misunderstood the requirements, didn't sufficiently talk to the customer, and underestimated the time involved. Management was not at all interested in assigning blame. This was partially because it would have been counterproductive to finishing the deliverable, partially because none of us were "problem employees", and partially because management knew that we were all highly-motivated to fix the problem and satisfy the customer. So we got it done, the customer was as happy as could be expected, and we moved on with our lives, with some valuable lessons on how to avoid the situation in the future.
So far in my career I haven't seen any real penalties for missing a deadline (and I've missed plenty). I imagine it's different for companies building software or games to be sold in stores where the company has made promises to the public.
But in the custom software development realm, it's so hard to accurately estimate how long a project is going to take. And often times this fact is reluctantly accepted by companies everywhere.
No penalty. "Deadlines" and estimating have been and continue to be one of the hardest and most challenging parts of software development.
It is ridiculous to impose penalties on developers for this issue.
While I have never seen any disciplinary action or firings I have seen lots of "mandatory" overtime and peer pressure to work longer hours.
I almost got fired as a manager for telling the team that reported to me NOT to come in on weekends and work late. I know those things are detrimental to the project and to morale.
Generally the "punishment" is in the form of making people feel guilty or anxious, but I am sure there are places that do more "official" things.
The world is full of idiots. Management is no exception.
I think the question it self demonstrates a misunderstanding of the role of management and project management.
There is, unfortunately, a common perception in the minds of many with the word Manager in their title that management means putting the heal to/kicking the butts of lazy workers. It fits with those that believe in Parkinson's Law as well.
It's not. It's about making it possible for works to do their jobs - be it being the communication channel between them and some other part of the organisation, getting them resources, or running interference (moving the furniture out of the way).
To wit, the PM should already know the project/task is going to miss it's deadline. They should be asking questions, and know what's going on. They have the power to either cut tasks or increase/rebalance the resources to get the job done (or say to the sponsor, if you don't give the resources, it ain't getting done on time). And as such, the penalty goes to the PM, whether it is nothing, tongue lashing, demotion, or termination.
Sometimes the delay is unavoidable. This is why we build in contingency time. Sometimes, it's a known risk; and so long as you have a backup plan - you are OK.
As for the responses, you have four parameters: Scope, Time, Money, and Quality
Scope - you can cut to make the deadline.
Time - is fixed. You might be able to get your staff pull a week or two at 60hrs, but your productivity will begin to suffer after that. And it also costs more money if you are paying them fairly.
Money - You can buy pieces from someone else to speed up the process. You could even hire more people, if the work is disjointed enough that you don't have to have a lot of communication with the existing staff - see Brook's Law
Quality - Idealistic fools claim you can never skimp on quality. But you can. You don't have add bugs (one form of anti-quality); but you can put less quality in. Do you code your function so it can handle unlimited length strings, or is 100 characters good enough for this version? Do you make it easy for the next upgrade to bolt on a new module, or do you weld it shut and worry about adding a plug-in module when you do the next version.
Not doing these things aggressively enough (when required) will surely lead you to a failure.
It's certainly not a cut-and-dry answer. Here are some things which I weigh and things I do/encourage in order to make sure things get done on time.
1.) Set priorities properly. Projects will always have various degrees of completion. It's not a binary "done"/"not done" switch. If the highest priority things are done first, it's easier to swallow. Ideally, you should quickly get to the point where it works, but it doesn't do everything we need it to do and it doesn't look pretty. Once there, it can be released if it absolutely needs to.
2.) I've found that the best way to handle it is to make the releases as small as possible. This makes the estimates more accurate. If your boss or "the market" dictates that your estimate is unacceptable, consider assigning more developers to this task if possible. Sometimes a task can't really be divided up easily, or there's only one person familiar with the code. If it's not a high priority just tell the powers that be that it's going to take longer. Setting reasonable goals and managing expectations is key.
3.) As for motivation, rewards, and punishment... there are many doctors who have written entire books on these subjects. In my experience, giving programmers something which is challenging and letting them have some freedom to do it their way is a good start. Listening is something managers need to do well in order to succeed. If the developer is seasoned, you should be able to just explain the problem and let the developer come up with the solution. If their solution isn't as good as what you had in mind, you can suggest it and go from there. Just dictating how to do something, even for new programmers, is seldom effective. Making the developers think about things will help them be able to solve problems on their own. This is related to delegating, as that only works if the developers can do the work on their own.
4.) Reduce turnover by paying people well if they're doing well. It usually costs much more to find good people. It takes time to get familiar with a large code base and the hiring process can also help avoid spending time on people who can't cut the mustard.
5.) Ask (don't demand) if a developer can stay late/work weekends. Only do this when it's something very critical (for example a security flaw which gives user access to data they ought not be able to access; a new law/regulation passes which you must comply; etc.). If they say no, don't hold it against them. It's likely not their fault that things didn't get done; and even if it is, it's reasonable that they made plans for time when they aren't expected to be at work. If they are willing to come in, make sure they know your sincere appreciation. Compensate them well for helping out when they aren't obligated to, buying lunch doesn't cost much and it's a very nice gesture. Don't make a habit of expecting people to work late/weekends unless it's part of their contact/agreement (or if they like doing so).
6.) Understand why things are running behind schedule. Did you promise something which wasn't possible (given the people available, quality expected and time allotted)? Did some other project come up and take up resources and the deadline wasn't adjusted? Was the code just harder to do than expected? Giving time estimates is difficult. You need to plan everything out, have experience and know how long each developer will take for the task. Compensate for unexpected problems which will likely arise and give the programmer a sooner deadline than your boss or the client. It's always OK to be done early. And if you're almost always done early or on time, that one time that you missed your deadline will be more understandable if you have an explanation of some sort.
7.) Remember, it usually boils down to time, quality and money. You can generally pick any two, but the third one will need to balance the equation. So if it needs to be done quickly and on a shoestring budget, you can expect the quality to suffer. If you need it done quickly and of high quality, expect to pay a lot of money, and so on.
8.) I'd say the #1 thing which works for me is listening. If your too busy barking orders then you might not even know about problems with the company. Now just because a developer says "the code sucks, the design is terrible and we need to re-write everything if we want to get anything done in a timely manner" doesn't mean that it'll happen. But if you hear comments like that and explain that we can't afford to do this or we'll get killed in the marketplace, it'd be way too expensive. And ask what can be done to make sure things don't get much/any worse. Ask if there's a way we can clean it up over time. Can we just (re-)write one class and build new stuff based on that? Can we slowly migrate to a new design one feature/segment/module at a time? You understand where they are coming from and vice versa, you can probably solve at least some of the issues. Just remember that compromising works both ways.
9.) Negative re-enforcement seems to result in higher turnover, which is costly. Having a bunch of people who aren't familiar with your code doesn't help deadlines either. Money is one motivator, but I've quit a higher paying job to go to one where I'm happier before, and I know I'm not alone there. Free food when the team does a good job isn't really that expensive. I'm not too keen on group activities since they're either cutting into an employees time, or taking away from work time. It works sometimes, but cutting into an employees personal time so they can hang out with co-workers instead of being with their friends isn't that great of a reward. Having everyone stop working is also expensive... so it just depends on the company size, culture, etc.
Hopefully that helps answer your question. The other answers in this thread are also good suggestions... design plays a big part in how quickly code will be written.
Once a project is late, there is not much 'management' (good, bad, well meaning or malicious) can do, that will not result in the project being even later
... the only exception possibly being the removal/avoidance of exterior distractions.
If you're missing your deadlines, fix your estimates.
Taken from a corporate development standpoint...
If the deadline came from someone other than the person performing the work, review the situation to determine the cause of the overrun. In these cases, it is often related to incomplete requirements, scope creep, poor management, etc. No punishment should be given for missing a deadline that the person never provided in the first place.
If the deadline was provided or agreed upon by the individual performing the work, then that person needs to explain the factors that led to the delay. In addition, this person should be reminded to notify their supervisor, project manager, or other responsible party as soon as they are aware that a deadline may be missed. This information should not come to light after the deadline has passed. If this occurs repeatedly, your company's disciplinary process should be followed. This may involve write-ups, suspensions, or termination.
People tend to take real ownership of deadlines when they are the ones setting them. When deadlines are placed on them without their input, deadlines tend to become meaningless to the person performing the work.
Your question is inherently flawed: it assumes that punishment is the best way to manage people. In general, that people don't respond well to punishment or threats of punishment; it brings out the worst behaviors, make the motivation external, and distracts from internal motivation. Rewards and bribes (threats of reward) are the other side of the same coin, and do no better.
These forces are built in to work for hire, however, so you'll never get the best creative work out of your programmers, but you don't have to make it worse by punishing them when they miss a deadline.
Instead, meditate on the creative process, the chaos of multiple people doing creative work, and what tools are effective in managing chaos.
To manage any chaotic system, do lots of measurement and be ready to change course quickly. In the case of programming:
Take the smallest steps possible. Don't "break the task in to small steps", as you'll waste a lot time planning steps that won't work out like you planned. Chaos, remember?
Pick the smallest steps that deliver the most value.
after a short period, reevaluate your plan based on what you've learned
deliver working software to actual, real customers as soon as possible, so they can tell you what you should really be doing.
You may recognize this as the thinking behind SCRUM.
Flogging
There are two possibilities:
The deadline was missed because someone didn't do their job.
The deadline was unrealistic.
Rather than thinking in terms of penalties, I would suggest doing a post-mortem to determine what went wrong and finding ways to improve the next deadline estimate.
You ask "what should the penalty be...". It would appear you are asking from the perspective of "inside the company".
In real life, the penalties are often swift and severe - loss of business, lawsuits, bad reputation in the industry. These are the REAL penalties imposed by clients who were promised something by a certain date that was not fulfilled.
Internally, you can often do whatever you like. But once you start involving paying clients, then managing those clients becomes a critical part of the overall job.
Penalties such as I described can often be avoided (or lessened) by "on top" communication with the client. If the client wants something added (so-called feature creep), then this should immediately be answered with the impact these changes will have on the project (costs more, delivered later, whatever). The client should be encouraged to triage all such requests against their deadlines and projected costs (i.e. let the client manage feature creep, not you).
If other things change the delivery time, then as soon as you know there will be slippage, you must inform the client. If done early, clients are remarkably willing to work with you. But if you don't say anything until it's too late, they are less likely to forgive... especially should they discover you knew a significant time earlier and didn't tell them.
Cheers,
-Richard
I've seen executives leave a company shortly after some deadlines were missed. This changed everything but didn't necessarily make things better or worse. I've seen some contractual obligations like clawbacks as a way to penalize someone for missing a deadline that I'm not sure how well they work.
When one completely changes what a project is supposed to do midway through the alloted time for the project that tends to cause the initial trajectory to no longer be valid and thus the project will fail because it likely will not meet the initial deadlines within budgets. Replanning the project into short increments of at most a few months is a response that I believe is a logical direction to take a project to get good results as a lot of project may have to accomodate changing requirements which can easily change deadlines, head count or time worked.
What should the penalty be for setting an unrealistically short development timeframe against all of the advice of the developers and their leads?
Coincidentally, this seems to happen almost as often as development teams missing ship dates.
This is not really a programming question, but more of the management question.
Missed deadlines are rarely developer's fault. As a developer you should try your best to do as good work as you can, but in the end everyone is capable of only so much. If developers put in honest effort and despite this the deadline was missed, it means that the deadline was unrealistic to begin with.
Dealing with deadlines is responsibility of managers. There are different approaches but none of them include "penalizing" developers for doing their job. An important thing to understand here is the so-called project management triangle. What it means is that software project can be good (i.e. meeting requirements, good quality), fast (meeting deadlines) and cheap (headcounts, tools). The trouble is that only 2 out of these 3 properties can be chosen.
So if management want something good and fast - it is not going to be cheap.
If management want something good and cheap - it won't be fast.
And finally if management want cheap and fast - guess what, it won't be any good.
So the correct response to missed deadline depends on the chosen scenario. Good and fast requires adding some extra help, better tools, investment in above-average developers and more.
Good and cheap by definition assumes that deadlines are going to be missed (Blizzard, makers of World Of Warcraft are good example of this approach)
And finally cheap and fast usually means cutting features and releasing with bugs.
The main goal of project management is to plan how an application is going to be built, in time. You should not start your project development if you don't have a schedule showing what you're going to be doing every single day the project will last.
This way, you can detect that you're going to be late, as long as you follow the project's evolution on a regular (weekly if not daily) basis. And the earlier you know it, the sooner you can act accordingly.
You usually have two options :
Catch up (by hiring additionnal workers, working more, or removing features).
Tell your customer that something went wrong (even better : what went wrong) and you're gonna need more time.
For the second option, I'm not meaning there won't ever be penalties. But from my personal experience, as long as the customer is informed in advance and offered solutions (preferably three : give more money for additional workers/remove features to save some time/accept the project being late), they'll be open to negociation. Which is always better than conflicts :)
Perhaps the better question is if deadlines are meaningful in the face of inaccurate estimates? Businesses do a lousy job of estimating software--that is a fact. Both management and developers play a part in this and neither one seems willing to own-up to their responsibility in this problem.
But to answer your specific questions:
1.What actions have you seen applied as 'penalty' for missed deadline, and
which of these eventually resulted in
more-good-code?
The 'penalty' I've seen for missed deadlines for managers and developers range from nothing, to promotion, to simple transfer. The most severe penalties I've personally witnessed was a manager "transferred" to a less important project and for the business-unit to lose a financial bonus.
The only time I have ever seen someone fired over a missed deadline was when the employee was already going to be fired--the deadline gave the business a legal reason to fire the employee.
2.What project-management responses caused the project to fail outright?
This is a whole separate discussion on its own... but there is some inherent bias in this question--project management is at fault.
The three top things I have personally seen PM's do that sabotage a project are (in order of severity):
Ignore data/recommendations/warnings from their technical staff.
Ask for estimates early in the development process. This results in estimates with an error-bar of 10x (it'll take one month, give or take ten months).
Reject/modify/demand software estimates so that they fit an arbitrary budget and schedule. This is not to say Developers should ignore business demands--but rather the business demands need to be set equally by Developers and non-Developers.
3.What responses restored working order and resulted in code that could
be maintained afterward?
I have yet to see a functional software development organization. So the fix is usually a lot of blood, sweat, and tears from a couple of heroic developers working with a highly-capable PM who knows how to defend against politics within the company (i.e. deflect BS from their staff).
4.What responses resulted in more-bad-code?
Yelling. Cursing. Insults. (Sadly, this still happens in some workplaces)
More "project management"--either by way of people, meetings, status reports.
Getting software estimates earlier in the process so "we can plan better." Estimates need to come later when your staff has more data and a better understanding of the problem.
Coddling the developers (it's not your fault, the manager screwed up).
Coddling the project managers (it's not your fault, the developers screwed up).
Adding additional, unqualified staff to the project.
I got fired for missing a deadline, I was 98% finished with the product, external forces and deadlines that are that firm don't allow software to be developed properly. Even I can admit I wrote some poor code under the circumstances, but I also wrote some good maintainable code as well. No consideration was given for feature creep, infact no technical specifications were detailed upfront and adaptation of functionality was required as limited and buggy versions of the software became available for managements review. I could have communicated better, but when I did communicate it was emphasized that deadlines are non-negotiable.
Two obvious questions come to mind when a deadline was missed:
Was the deadline feasible?
Did external factors impact performance?
Obviously, if someone presents you with a deadline that doesn't make sense then there shouldn't be any penalty for missing the deadline. Also, if someone misses a deadline because they were called up for jury duty that also shouldn't be held against them as well.
In the event those questions don't apply then the next thing to do is to figure out what went wrong. If you based your estimate for how long something would take, and thus the deadline, on the developers estimation of how long it would take them to write the code then perhaps they were too optimistic in their responses.
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.
It seems to me that whenever a GUI (Graphical User Interface) is involved, the look and feel of the interface nearly always trumps the performance of the application.
Is this a universal phenomenon?
Sufficiently bad looks trump any level of good performance.
Sufficiently bad performance trumps any level of good looks.
This boils down to the psychology of your target audience and about the architecture of your application. If the GUI reacts quickly and is laid out in such a way that it is intuitive to the user (as opposed to the developer), then the underlying layers may not need to perform so well. If however, the user wants to get data from a database and they're left hanging while the data loads, they're going to feel very differently. Compare 2 web applications just as an example:
Application one feels quite responsive but under the covers things take longer than it appears on the surface - it uses AJAX to talk to Web Services. The Web Services aren't the quickest, but everything happens on callback (asynchronously), so the user isn't held up while fields populate. It doesn't impede their workflow. On a bad day when network performance deteriorates the background performance, sure it's noticeable, but user activity isn't impeded any further than normal.
Application two doesn't feel quite so responsive. Everything happens on postback, there's no AJAX or Web Services, on a good day the page loads are fairly quick. Of course, on every postback the user's workflow is impeded while they wait for the page to reload. On a bad day, network performance causes performance to deteriorate noticeably, further impeding the user.
Application one is far less likely to get complaints because the user isn't held up even though fields aren't loaded so quickly. The user can enter data and move on. Everything is handled asynchronously. Of course, in the background, the Web Service process may actually be slower than the full page refresh but the user isn't going to care so much.
From many thousands of hours writing software and directly interacting with my users - frequently those who aren't necessarily as computer literate as your average 10 year old I've noted these points that are key to getting acceptance from just such an audience [written from a user perspective]:
It must do what I want how I want it: Don't just read the spec and expect your code to meet exactly what it says on the paper. Really read what it says on the paper and understand what the user meant by that. Design to the underlying meaning of the words not the black and white of the ink on the paper. If you don't understand exactly what I meant, come and talk to me and I'll explain it until you do. I'll be less happy if you deliver software that missed my whole point than I will by your questions. I'll feel much happier if I get the feeling you're on my side by really trying to understand me.
It must assist my workflow and not impede it: It's great if all I have to do is push one button to complete what would've taken me an hour to do before, but if it freezes my computer for the 20 minutes it takes to complete the task, I'm not going to be a happy camper.
It must be intuitive to use: That means I don't want to have to wade through the documentation you didn't provide me with in order to figure out how to use it. Neither do I want a 20 minute explanation that I'm going to forget 3 minutes after you walk out of the door. Design the software such that my 10 year old could figure it out as easily as they can program the PVR. It means that I should interact with it in a manner that seems logical to me as the person that will be using it day in day out. It doesn't matter if it's functionally correct, if I can't figure out how to use it, I'm not going to use it, much less pay for it.
It must be responsive: I don't want to have to click a button and then wait 10 seconds for a list to load and then select an item from that list and then wait for another screen to load before I can select an action to complete on that item which then takes 5 minutes to complete. Find a way to load the data quickly - if you can't load the data quickly in response to my action, then figure out a trick to make it feel like the data is loading quickly - perhaps by loading it in advance in the background and only displaying what I need displayed in response to my action... my point is, I don't care what you do, just make it appear like it's doing it quickly.
It must be robust: It doesn't matter what I throw at it, it should accept it and move on. If I do something wrong or put something incorrect in a field, tell me - IN PLAIN ENGLISH!! I don't care about buffer overflows or IOExceptions thrown at line 479 while attempting to open a file. Just handle it and tell me what I did wrong in language I understand.
Give me documentation: Okay, I know I'm not going to read it, and I'm more likely to pick the phone up and call you than remember where I put it when you gave it to me. But knowing its there makes me feel warm and fuzzy inside. It shows that you cared about the software enough - and me enough to write instructions that I can reference oustide business hours when you're not available.
Price: This depends entirely on your audience, but in my experience, if you met all of the above points, price tends to be far less of a concern than it might appear on the surface.
Although "you can't judge a book by its cover", people often do with software. I don't know if I would say this is "universal", but certainly common.
I don't think it's even a true phenomenon. I don't care how zippy the "look and feel" is, if it takes second to echo a keypress, the UI experience will suck. If it takes a long time to repaint the page for small changes, the UI will suck.
Now, as long as the response time of the application is less than some amount, then the look and feel will be a big part of the satisfaction.
Check out some of Jakob Neilsen's books on this.
Isn't it a bit of a false dichotomy? If the look and feel of an application isn't clean, well-organized and effective then you don't have a high-performing application. No matter how fast it may be.
I've found that the best combination is a snappy and easy-to-use GUI. This doesn't necessarily mean your app has to have great performance, but having the GUI freeze on you is a kiss of death. The iPhone's Safari does this well--you can continue to scroll around the screen even if the rendering engine can't keep up with you. Yeah, the no-content hatch marks are ugly, but at least the user knows he's in control.
I think it depends on the users. I work in a medium sized company in the IT department constructing web based software for consumption by the employees of said company. The users range from Human Resources, Manufacturing, R&D, Sales, Finance, to making applications for the CEO. Each of the different departments and users within those departments seem to have different criteria for what makes a quality application.
For instance, a Human Resource department usually deals with a lot of textual data. They spend heaps of time inputting things into forms like employee information, entitlements, recruiting etc. These types of users might opt for the look and feel of an application for this purpose, they want an aesthetically pleasing design that is easy to navigate and intuitive.
On the other hand a department like finance might favor performance in their reporting tools. I have had a few experiences with large SQL tables with complicated queries that took a considerable amount of time to execute. Users that run these kinds of reports many times a day soon get fed up of waiting and would gladly lose a bit of interface intuitiveness in exchange for time that could be spent on other tasks.
So, i would say that you can't make a blanket statement like "All users prefer a speedy application" or "All users like pretty applications". It really depends on the users preferences, their job requirements, and the applications purpose.
Balance is everything.
The UI needs to look respectable, professional and flow similar to other applications so the user has a common experience, thus little learning curve. It shouldn't have unecesssary whistles and bells unless specifically requested.
The performance should be at least tolerable. If you have extra time in a project, I would spend that time speeding it up unless the user specifically asks for UI enhancements. Many times, whistles and bells can compromise performance as some UI enhancements require additional CPU time AND sometimes add awkwardness to the app. At first glance, some of these apps look cool but long term usability suffers in favor of the NEATO factor.
Important for the user is that using the program is fun. The program should not only be able to do what I want it must feel good to use the program.
Making the user wait at moments the user does not understand or foresee isn't fun.
Crashing and making errors isn't fun either.
But looking good and helping me doing my task through the look and let me work fast and without work flow interruptions is fun.
Programmers often think that programs that are slow and use much memory are bad and they measure all their software on memory usage and the use of the processor. But most of you users won't start top or the windows task manager and look at the footprint of your program they will use it and if if feels good to use the program, and the rest of their computer with the program running they will fell good to.
One thing I read about often is the usage of as many CPUs as possible to get a task for the user done in the shortest time. Is this high performance? Your program is very fast. But the Computer is very slow at the moment and switching to the email program because I know the task will take its time is a pain in the ass. So sometimes you may want to free some resources to improve the feeling of your program. Even if that would slow down your own program.
The most important are price, functionality, compatibility, and reliability.
Looks and performance are both, relatively unimportant and in practice they are both therefore unable to "trump" anything:
Compatibility: for example, in the real world I use MS Word, not because it's fast or pretty but because it's compatible with everyone else who uses it.
Functionality: when I want to book a train in France, I use http://www.voyages-sncf.com/ not because it's fast or pretty (or even outstandingly reliable) but because it has the necessary functionality.
Reliability: if an application crashes then I'm probably not going to use it again, no matter how fast it crashes, or how nice it looked before it crashed.
Price: etc. (say no more).