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 5 years ago.
Improve this question
What are common empirical formulas that can produce a rough estimate of project duration for waterfall methodology ( up to 20% fluctuation is acceptable). If it helps in narrowing down the answer, you can assume that following is more or less known :
Number of devs is known and fixed, most devs are above average in terms of know-how, however some learning about domain-specific issues might be required.
Known and fixed max. number of app users.
Technology stack to be used is reasonably diverse (up to 4 different languages and up to 6 various platforms).
Interfacing to up to three legacy systems is expected.
Please feel free to provide estimate methods which cover a broader scope than the above points, they are just provided for basic guidance.
Do yourself a favor and pick up Steve McConnell's Software Estimation: Demystifying the Black Art. If you have access to past estimates and actuals this can greatly aid in producing a useful estimate. Otherwise I recommend this book and identifying a strategy from it most applicable to your situation.
Only expect to utilize 70% of your developers time. The other 30% will be spent in meetings, answering email, taking the elevator, etc. For example if they work 8hrs a day, they will only be able to code for 5.6 to 6.5 hours a day. Reduce this number if they work in a noisy environment where people are using the telephone.
Add 20% to any estimate a developer gives the project manager.
Lines of code is useless as a metric in estimating a project.
Success or failure depends on concise requirements from the customer. If the requirements aren't complete, count on the customer being not happy with the finished product.
Count on the fact that not all of the requirements will be dictated by the customer. There will be revisions to the requirements throughout the project.
Step 1. Create a schedule that is as granulated as is reasonably possible.
Step 2. Ask the people involved how long their features will take.
Step 3. Create an Excel spreadsheet which maps predictions to actual times.
Step 4. Repeat steps 1-3 for all new projects. Make use of an aggregated mapping from previous instances of step 3 to translate developer estimates to actual estimates.
Note that there are tools which can do this for you.
See also
Evidence-based-scheduling.
This project is not going to be cheap...
Number of devs is known and fixed,
most devs are above average in terms
of know-how, however some learning
about domain-specific issues might be
required.
This is a good thing. You don't want to flood the number of developers into the project. Though if you go above around 10 people, do count every 2 as only 1, as the rest will go up in overhead. Unless you can split the task into something that can be handled by two totally separate teams. Then you could have a chance of getting some traction.
Known and fixed max. number of app
users.
This means that you can with more certainty land your architecture early on, as you can estimate how much effort you must put into scaling your solution. This is a good thing. Make sure that you work within these limits and never ever fool yourself into thinking "it's fast enough". It almost never is if you doubt that it could be too slow...
Technology stack to be used is
reasonably diverse (up to 4 different
languages and up to 6 various
platforms).
This isn't as important as to do your people know this stack/set of languages? If there are any learning involved, raise the estimate x2 or x3 if you don't perform a proof of concept up front to learn the technology. Or even better, take the pain and get some coursing. If the language for implementation or technology to be used is unknown, then it is quite likely that you will misuse the technology and do things that will screw stuff up.
Make sure that the technology is proven or you'll end up getting bitten by it.
Are the source available for the tools/technology?
Do you get support?
Do you understand the product and or used it before?
Have the customer used it before?
If too many of these questions get a no, add some (or a lot of) additional time to the sum.
Interfacing to up to three legacy
systems is expected.
This is really a kicker. For legacy integration ask yourself:
Has anyone else integrated with them?
Do you have access to people with knowledge of these systems?
Do they intend to share this knowledge with you?
Do you have to wait for changes being created in these systems?
Are there test systems available for you to use?
Are there development systems available for you to use?
Again, if too many of these questions has a "no" on them, then be afraid. You should also know that actual integration takes about 3-5 times longer than you actually think.
This isn't a project that I would have given a table grabbing estimate for. Do yourself and your customer a favor and do this by the hour. If not, you will as times go by start cutting corners to cover up your lack of progress/underestimation... And both you and your customer will suffer.
There are many cost estimation software tools that can greatly ease the pain of cost estimation, we use ProjectCodeMeter. I know these tools are not perfect, but they do save time getting started by pointing towards the right direction.
Try this list of estimation tools on Wikipedia.
Related
How do you deal with a client who has different time estimates for the software product than yours?
I am going to describe a scenario that is not mine, but that captures broadly the same problem. I am working as a subcontractor to a large company that has a programming department. The software project we are working on is in an area that the department believe they have a handle on, but because their expertise and mine are very different we tend to get different results.
Example: At the start of the project I suggested one way of development which they rubbished as being unrealistically difficult and suggested integrating a different framework (one they are familiar with) with the programming language we are using (Python) to get more or less the same result.
Their estimate for this integration: less than a week (they haven't done the integration before).
My estimate for the integration: above two weeks.
Using my suggested way to get the result needed (including using matplotlib among other libraries used elsewhere within the project): 45 minutes. This is not an estimate, the bit was actually finished in 45 minutes.
Example: for the software to be integrated with their internal system, they needed to provide a web service for me to use. They provided a broken one, though it does work with their internal tool (doesn't work with .Net or Java mainstream packages among other options). They maintain that it is my fault that the integration has taken longer than the time estimated.
The problem is not that they don't know, the problem is that they have enough knowledge about programming to be dangerous (in my opinion). Is there some guidelines for how to deal with this type of situation? A way for expectation management? Or may be I shouldn't get involved in such projects from the start and in this case what are the telltale signs?
If a client isn't happy with a time estimate, don't do the work. If they think they can do it better or faster, tell them to go ahead.
The one thing I never allow is for my estimates to be modified. That's something that caught me out early on in my career but we learn our lessons.
If clients were so good at doing the work, they wouldn't be hiring me. I'd simply point out that they hired me for my expertise so why are they disregarding that expertise. Of course, if they were to allow the scope of the project to change (i.e., less work), that would be another matter, and one up for discussion.
If you didn't lock in exactly what they were meant to provide as part of the deal, then it's a "he says, she says" situation and, unfortunately, the customer controls the purse strings. However, often, the greatest power you can have is the ability to just walk away.
No-one says you have to do the job.
Of course, all that advice above is worth every cent you paid for it :-)
I don't know your specific circumstances.
Or may be I shouldn't get involved in such projects from the start and in this case what are the telltale signs?
My answer for sure. If you can avoid those projects, do it.
Some signs : people thinking they know how to do things when you can guess they can't. The "oh no let's not use this perfectly suitable tool because I don't know it" is a major indicator that the person is technically challenged.
first of all, it is no fun to be in such an environment.
So, if you like to have fun at your job, and you do not need to take this job for extenuating financial reasons, then simply do not take the job that is not fun.
Since that is hardly realistic in many cases, you will end up with the job and need to manage the situation as best you can. One way is to make sure there is a paper trail documenting your objections and concerns with the plan. Try not to be overtly negative, but try to be constructive and present valid alternatives. Here you will need to feel out the political landscape, determine if the 'boss' will be appreciative or threatened by your commentary, and act accordingly.
Many times there are other issues that management is dealing with that you are not aware of. Be cautious of this fact, and maybe ask the management team if this is the case, again without being condescending or negative.
Finally, if you have alternatives that take less time than the meetings it would take to discuss them, just try it in a sandbox, and show it off. This would go a long way to 'proving' your points. Caution here is that you could be accused of not being a team player, or of wasting resources, or not following direction. Make sure this is mitigated by doing these types of things on your own time, or after careful consideration of how long you are spending on these things as well as how vested your boss seems to be on the alternatives.
hth
I ran into the same problem with integration. Example: for the
software to be integrated with their internal system, they needed to
provide a web service for me to use...They maintain that it is my
fault that the integration has taken longer than the time estimated.
Wow very similar to what I was experiencing with a client. The best thing I can suggest is to keep good documentation. In the end that is what saved me. When it came to finger pointing I had all of the emails and facts in order and was prepared to defend my self.
One thing I would suggest is to separate out a target/goal and an estimation. I would not change my estimate unless it involved actually removing features or something is revealed that would make it easier. Tell them you will try to hit the target in anyway you can and you care about the business goal. However, your estimate will not change. If its getting no where and they are just dense then smile and nod and take it if its the only gig around.
Was just writing about this in my blog
How to estimate the WRONG way
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
We have heard the adage, "Cost, schedule, quality: pick two." It has been my recent experience on big government projects that quality often suffers due in part to schedule constraints. In fact, sometimes project managers choose schedule with little apparent regard to quality and sometimes little regard to cost.
Are you asked to compromise? What are your experiences in commercial worlds? When you are the program manager - perhaps you are self-employed or work on projects at home and on weekends - and you control cost, schedule, and quality, do you "pick two?" Do you have favorite parts of your development methodology(ies) for which you never compromise (e.g. automated testing)?
Finally, which development methodology do you suggest for a team forced to choose schedule and cost over quality? Thanks in advance.
I suggest we vote up well-reasoned comments.
It's been my experience that rather the opposite is true: concentrating on quality (especially early on) tends to reduce cost and schedule. From what I've seen, I'd say most projects that have serious overruns do so mostly because they get close to what they thought was the end, and they find that their code doesn't work. At that point, they try to fix things by putting in lots of extra time debugging and such, but it's really too late to do much good. Worse, they have to undo quite a bit of what they did, because some parts depend on poor design decisions elsewhere and such.
"Cost, schedule, quality: pick two."
That's the traditional statement, but aren't there four parameters not three? There's low-cost, short-schedule, high-quality, and high-quantity: you can maximize any three of these if you can sacrifice the fourth.
Are you asked to compromise? What are your experiences in commercial worlds?
When someone asks something of me, my cost is fixed (i.e. my rate per hour or per year), so ignoring costs.
The quality varies somewhat: some kinds of reliability look for additional written design and documentation associated with the software, whereas for other types of software they might say "as long as the software works we don't mind whether you write any documentation". I always experience an implied minimum quality level (e.g. any/all noticeable-at-runtime software bugs must be fixed).
I tend to insist on short schedules: other people might have long-term, multi-year plans, but I typically "sign up" or commit to doing something for the next few days or few weeks: longer than that and I'm not comfortable estimating it (and it probably isn't well-defined).
Therefore, the sacrifice is quantity: I want people to give me a little bit at a time, preferably one job at time (see also the words "sprint" and "iteration").
When you are the program manager - perhaps you are self-employed or work on projects at home and on weekends - and you control cost, schedule, and quality, do you "pick two?"
I sacrifice schedule; I don't care how long it takes, so long as:
Cost is fixed/zero (i.e. I'm the only one doing it, pro bono)
Quality is acceptable
Quantity (or functionality) is as planned
I may reach a point where I run out of schedule, i.e. I decide that I can't afford to continue working on the project: at which point I sacrifice (the remaining unimplemented) quantity. Planning for this eventuality, it may be relevent to remember that it's sometimes better to have finished 50% of the project than to have half-finished 100% of the project (i.e. better to have half the functionality finished and usable than to have finished nothing).
Do you have favorite parts of your development methodology(ies) for which you never compromise (e.g. automated testing)?
Source code that's tidy enough for me to understand: software runs as expected on the computer only because I was able to, first, run it in my head.
Also I insist on testing software. It doesn't have to be unit-tested (instead, system-testing is OK) but in spite of my bravado about about its running in my head I won't guarantee anything that isn't tested. My boss used to say, not "you get what you expect" but "you get what you inspect".
For a long-running project, the tests need to be automated. I'm willing to refactor (see point 1 above) and I therefore need to run regression tests. If the tests were manual then the cost to run them would be proportional to the amount of code, so the time required for testing would increase as O(n squared), i.e. it would be too expensive if it weren't automated.
In my experience, you will always be asked to compromise something. It will differ based on different clients.
You can personally refuse to compromise on certain aspects, but sometimes the only way to do so will be to change projects or jobs.
SCRUM and other methodologies are ways of managing the compromises and making them apparent to your managers and clients. They do not prevent compromises.
Lastly, remember that these are not binary attributes. You will balance how much "quality" can be compromised in different aspects of your project (DB vs GUI, Reporting vs Computation etc), and balance that against speed and cost. You don't "pick two." You make thousands of different decisions to meet the needs of your client or manager.
I recommend Scrum. It's an agile development framework, focused on iterative development phases, whereby at the end of 3-4 week development intervals, you have a tangible product at the end of each 'sprint'. Then at the end of each sprint, you go over as a team what worked last round, what can be improved, and you mitigate any changes in requirements you may have.
It's really good in a government environment where people change their minds all the time as they come to a better understanding of what they want from developers, in terms of what the final product should look like, because if the product lead completely changes his or her mind, the developers can still have a sense of accomplishment for having handed off a deliverable that should be usable.
http://en.wikipedia.org/wiki/Scrum_%28development%29
SCRUM with adequate SCRUM software.
SCRUM is an agile Software Development methodology where all the tasks of a project are simplified down into task-groups called sprints. It's an excellent way to keep track of all of the tasks for a specified person, and the number of hours of project planning it's saved is is absolutely invaluable.
Give it a go - you wont turn back, I'm sure.
If you're choosing schedule and cost then worrying about methodology is the wrong thing to do. Go code. Code as fast as you can. Feel free to do dirty hacks that work, so long as they allow you to make the schedule without bringing on additional developers. Remember, if quality actually doesn't matter then maintainability and testing is not really important since those are both quality issues.
Somehow, reading that, I doubt that you actually want to ignore quality completely :)
I live in the world of the classic waterfall SDLC, and we have client-driven deadlines. So for us, schedule is top priority. Cost isn't really so important to us because we estimate and bill the client before work begins. To balance the two and still achieve decent quality, we developers try to overestimate the amount of work any change will take, giving us adequate time and resources to do the job well. It's a bit slimy but it's a good workaround.
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
We're a medium sized engineering shop (10-20). We are great at prioritizing and structuring work on our user facing stories and making customers happy. But the cobbler's children have no shoes. If it isn't about customers, we have 0 process.
I'm looking for systems to ensure we correctly prioritize and accomplish the non user facing work to keep a dev shop running: QA environments (pretty heavy, in our case), continuous integration systems, the packaging, and so forth.
Now, resources are always limited. We don't want to give the cobblers children 10 pair of the fanciest shoes, and specialized bike shoes to boot. We want to do the right, necessary work, with the same scrummy discipline that is applied to the rest of our development.
Tell me what system works for you: how to you prioritize and organize non-user facing work ? I want systems that are simple and integrate smoothly with scrum.
(I'm aware of a red box at the top of this text, indicating that Stack Overflow's automated question parser thinks this is a subjective question that can't be answered - I think there are likely 2 or 3 excellent answers that can be or have been proven viable - and process is integral to programming. So here is some psuedocode representing our process. Fix this algorithym).
IBacklog GetBacklogForWork(IWork requestedWork)
{
if(requestedWork.IsUserFacing) return new PrioritizedBacklogRepository();
// Everything else. Priority largely based on spare time and who thinks its a neat idea
return new RandomizedPriorityRepository();
}
void HandleIncomingSuggestionsForWork(IEnumerable(IWork) ideas)
{
foreach(work in ideas) GetBacklogForWork(work).Insert(work);
}
Someone involved is using and depending on the results of the project. This is necessarily true; if it weren't true, why would you be doing it?
When you identify the person who most depends upon, or cares most about, the results of the project, you have the "user" that your project is facing. Make that person the customer.
IMO something like "QA environments" is, in a sense, user-facing work.
Quality is admittedly a "non-functional" requirement (so there isn't necessarily an associated "story"). But, you may have a non-functional requirement like "the software must be tested before it's shipped". You can assign a relative priority to such a requirement ("how important is it that software be tested?"), and then execute as usual (decide how to implement that requirement, estimate how long it will take to implement, schedule the implementation, assign the implementation, etc.).
What we do where I work is to have a percentage, right now around 15% give or take a few percent, that is spent on internal tasks that are non-user facing work. This way the technical debt is handled and if the task backlog becomes rather large then a sprint may be spent on it instead of new functionality. The way that last one would get pitched to the user or customer is that there will be a time where just maintenance and preventive work is done so there aren't any new functions coming after the next sprint.
That's one idea that can be tweaked a bit though it isn't necessarily fully flushed out yet.
The way I've seen it work more or less ok is to try to do as much as possible of the non-functional/non-user-facing as PART of a related user-facing activity, or the first user-facing activity that requires it.
This is the easiest to cope with, as it just reflects the needs of the development organization in order to maintain sustainable velocity moving forward.
Additional work which cannot be related will be done using a percentage as described by JB King.
The alternative of pitching it as an investment with such and such ROI to the PO is a theoretically sexy concept, but with real life POs I've seen it rarely works.
Its very hard to get POs to understand the investment, not to mention actually being strong enough to delay functionality for it.
Its sometimes the difficult role of the development teams to be the guys that "slow things down" in order to keep a sustainable situation.
Dev managers sometimes feel really bad about this whole sitation, regardless of the chosen approach. My recommendation both as someone who's been in that spot, as well as an Agile coach, is that as long as you feel you are doing the right thing for the business, focusing on non-functional work that is required NOW and has a relatively quick ROI, you should feel ok about this.
Cautionary note: This is an area where self-organization is really put to the challenge. Organization needs to trust the team to do the right thing, and the team needs to earn and not abuse that trust. Its a sign of maturity for an individual or a team to know the right balance.
In my very short time working in the programming field, I've seen two extremes:
Projects where little to no planning was done and thus become maintenence nightmares.
Projects that are perpetually in the planning stages and don't move from there.
It seems like the latter oftentimes happen as a reaction to the former. Where is the happy medium? And more importantly, if a project is moving in one of these directions, what is the best way to move it towards said happy medium?
In my own personal experience, I have found that 'decisions' are my bottle neck.
If this is the case, then :
List all your design options
Pick an option(s) (pick a few if you can't decide on one)
List the risks of the best option(s)
For each risk, brainstorm a solution, then design a conclusive proof of concept and write it.
If your proof of concepts proves it will NOT work, then toss that option, and pick another one.
A 'Proof Of Concept' is a minimal app to prove something. (mine are usually 1-6hrs)
If you have a situation where 2 or more options are equal, give yourself a time limit (like 5 minutes, not 2 months) and make a decision ... any decision, and don't look back.
And trust yourself to be able to deal with any problems you will hit which you did not take into account at design time.
Initial planning should be roughly O(log n) where n is expected total development time.
If you have to push in a week, sketch something on a napkin.
If you have a month, the first day is for initial design.
If you have a year, spend a week.
This does assume that you revisit planning iteratively, and don't just go all commando-style on your codebase, without adult supervision :-).
Analysis paralysis can have many symptoms. One that I have noticed is that same questions are asked each meeting and no resolution is reached. If you can point this out to people that might be able to help them admit that the planning process is stagnating.
If you can, at the start of the project, state that you want to cover a certain percentage of the requirements in the planning stage, say like 80-90%. This way there is a clear goal and you aren't trying for perfection. You can revisit the planning and analysis later just don't let it hold things up.
I think it depends on 2 factors:
The length of the project
Is it a 1 week project?
Is it a 1 year project?
Or somewhere in between?
The risk of the changes being introduced in the project
Are they architectural in nature, potentially affecting a lot of the original code?
Or are you simply adding a new feature?
Obviously, it's a combination of the above 2 factors. It simply doesn't make sense to spend 1 month designing a feature which will take 2 days to implement and is of little risk to the architecture. I'm picturing a matrix here of length/risk/design time tradeoffs.
There was some interesting advice in Code Complete 2, which I am currently in the process of reading. I can't remember the exact wording, so I am paraphrasing here, but it said something along the lines of:
The 2 biggest mistakes you can make in a design are:
1. Attemping to design EVERYTHING (you will fail)
2. Designing NOTHING before implementation
Finding the happy medium between these 2 is the key to successful design and planning.
Great questions - with no absolute answer - this is what makes experience meaningful. Experience including:
how much detail can you actually get from any user/sponsor and from this specific group
how much detail does your current team need (technical/business specific skill levels)
how open are your sponsors/users in helping during the development (how agile of a team do you have - does it include the sponsor/user?)
how good are you are identifying gaps
A big factor is the system being developed - the more 'life' critical the more details you will need (heart monitor compared to a web page).
The more complex, cost/time constrained, life-critical the more up front work - the less the more you can detail out as you do the work (prototype to production)
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
Suppose you're working on an enterprise project in which you have to get management signoff in order for you to develop a new feature set. Usually your management has no problem signing off on some bright shiny new UI feature. Unfortunately they have a hard time appreciating some behind-the-scenes issues that are crucial to the application's well-being such as transactions, data integrity, workflow routing, configurability, security, etc. Since they're non-technical and these issues are not immediately visible, it's not obvious to them that this is crucial.
How have you convinced them that these infrastructural issues have to be dealt with and that it is important to their business process?
Every craft has its unsexy sides. Things that HAVE to be done, but nobody notices them directly. In a grocery store somebody has to organize how and when to fill the grocery shelves so they always look fresh. In a laundry you need somebody who thinks about how the processes should be optimized so that the customer gets his clothes in time.
The tricky part is: The customer won't notice when these subtle things have been done right UNTIL HE NOTICES THEY ARE MISSING! Like when the laundry is not ready on time but two days late, or the veggies in the super market have brown spots and look terrible.
Same goes for IT. You don't notice good transactions until your major customer knocks on your door and tells you that an important and expensive project has failed because the database entries of your product were mysteriously mixed up. You don't notice good security until customer credit card information shows up in Elbonia (and soon after word is in the national newspapers warning customers of your company).
The thing you really have to hammer in again and again and again is that software is NOT static. It has to be cared for even after its initial development phase is over. It is not just a product you buy once and forget about. Every car manufacturer knows that services is of prime importance to the products they build, simply because things WILL occur that have to be fixed and improved. It's the same with software.
So make a presentation, visualize, verbalize, translate your technical information into benefits. Business people don't care about your wish for code aesthetics in a refactoring project, but they WILL understand that your changes will help the product to become more reliable, gain a better reputation and reduce the amount of future service requests. Make them understand by showing them the benefits!
Same thing folks have been doing for thousands of years: draw pictures. Diagram the problems, use visual metaphors familiar to your audience, drag the problem into their territory.
Assuming they're not being intentionally obtuse...
A big +1 for analogies and metaphors. If possible, find one that will resonate with the personal interests of your audience (if it's 1-2 people). For general metaphors, I often find myself using commuter traffic or subways, for some reason.
e.g. We are currently migrating an app from an OODB to Postgres/Hibernate: the bulk of this work is done in Release '4'. Many domain experts have been asking why there are so few user-facing features in R4. I regularly tell them that we have been 'tearing up the city to put in a subway. It is very expensive and undeniably risky, but once it is done, the benefits in R5+ will be astounding, truly.' The true conversation is more involved, but I can return to this theme again and again, well after R4. Months from now, I hope to say "You asked for X and it is now very easy -- precisely because you let us put in that subway back in R4".
The surest way to get upper level management to buy off on development work is to present it in a quantifiable way. Ideally this quantifiable measure is in $$. You need to explain to them the consequences of skimping on data integrity, security, transactions, etc. and how that will affect the customer\user community and eventually the bottom line. You should be careful in these situations because sometimes management expects these non-functional requirements to "just work." If this is the case, you should either estimate high and work on these items alongside the visible UI work (ignorance is bliss) or you need to document these areas of need as you communicate with management so if things do go bad as you anticipate, it's not your job that is on the line.
Unfortunately, it usually takes a disaster or two before this stuff gets the attention it deserves.
It really depends what your management is like, but I've had luck with good old honest-to-goodness fearmongering. If you go through a couple of disaster scenarios, and point out someone's going to get blamed if they occur, that can be enough to make their arsecovering instincts kick in and finally pay attention :)
Car analogies.
Everybody knows that 'system' and it's sufficiently complex to depict the dire situation.
I'm battling with essentially the same kind of situation. Whether it is sign-off by management or acceptance by a user/sponsor, the problem remains one of different vocabularies, priorities and perspectives. I asked a simmilar question here.
I also got diverse answers, tantalizingly close to useful, but not quite definitive enough. Browsing and searching SO using relevant keywords led me to find usable insights in various answers spread out over many unrelated questions. To find and extract these gems led me to pose this question on site-mining.
It would have been useful to be able to flag the various answers and see them all in a single list, but alas, that functionality is not yet available in SO. I suggested it on uservoice.
Hope you find something you can use from the references I gave.
The right kind of countering question is the secret.
Is it okay to crash every 5 web pages?
Do we have to protect the credit card numbers?
Is is okay to have to pay contractors to deploy a patch every weekend?
Did you want it now or did you want it to work?
Robustness. When it comes down to it, you need to talk their language, which is how it affects their bottom line. If its a security or correctness issue, you need to tell them that customers aren't going to want incorrectly acting products, no matter how nice they look.
I like the idea of Technical Debt, because it enables technical issues to be translated (albeit loosely) into money issues -- and money is something most managers do understand.
Although the idea of technical debt was originally applied to architectural issues, it can be used more broadly for any type of situation where there is pressure to take a shortcut -- that is, go into technical debt -- rather than do it right the first time. (Doing it right is the equivalent to saving up to buy something -- it takes time -- rather than buying it on credit and going into debt.)
Just as debts can be good (e.g. home loans) and bad (e.g. credit cards), so technical debt can be good and bad. I won't try to characterise the differences completely, but good technical debt can be tracked accurately, so that you know how much in debt you are.
So, try to explain your important, non-UI problem in terms of technical debt, and the cost of not fixing it in terms of paying interest on that debt.
A descriptive picture really helps non-technical people understand what you are talking about. For example, below is an example from Sun describing how information is processed in one of their somewhat complex applications.
(source: sun.com)
Trying to explain this application in words would be impossible to a non-techy. Pointing at the diagram and say look, this part is our weak point, we need to improve it. That will make sense to them. If they feel like they have some understanding of what you are doing, they will be far more willing to support your request.