Software

Responsiveness and service delivery: A terrible example

Marc Schiller looks at an example of terrible service delivery and asks what lessons IT leaders can learn from it.

OK everybody, this simply blew me away. I just received an e-mail, and I can't believe the words on the screen in front of me. My immediate thought: I have to share this with my colleagues on TechRepublic. But before I say another word, read the e-mail below and we'll pick up our discussion in a moment.

[A quick note of context: This e-mail was sent in response to a request my client made of its business partner to learn if they could get information about whether a certain project could be done and, if so, by what date. Except for masking the names of the people and the company to protect the innocent (as well as the guilty) I have reproduced the e-mail verbatim.]

Dear Jack:

After some discussions with our IT department, it has been decided that I need to submit a formal "Business Request" (BR).

What this means to us is that IT will need to size the change and submit a price and time estimate. It also means that the process has been taken out of my control and therefore I can no longer guarantee that I can get as timely a response.

The normal process for our IT department is to meet once per month and gather the BRs they have received and talk through the pricing estimate. If the business decides that they are willing to pay the price IT has given us, then the work goes into the queue to be scheduled.

The project is placed in the queue based on a point system, which weighs importance, level of complexity, and the resources required to work on the project and their availability.

At this time I cannot guarantee that I can meet your timeline.

Tim Braverman

Director - Customer Analytics and Reporting

XYZ Corp.

A missed opportunity

Clearly this company and its IT group are at least 20 years behind the rest of the world in terms of IT responsiveness and service delivery. What makes this e-mail even more troubling is that it was sent from a company (the vendor) that makes tens of millions of dollars a year from the relationship with the requesting company (the customer). In other words, the internal IT group at the vendor company is negatively impacting a multimillion-dollar customer relationship. Bad news!

What a sad case of an absolute golden opportunity missed, i.e., IT had the opportunity to play a truly significant role in delivering on a customer's request. Instead, they escorted the customer into the 1970's black hole of IT development.

What's really wrong here?

I'm sure none of the TechRepublic readers would defend this practice. But at the same time we all realize that there needs to be an orderly and sensible process for dealing with IT service requests. And the fact that it happens to be for a customer doesn't really change things a whole lot. There still needs to be a structured approach and method for moving a request through the development process.

So what is it about this e-mail that instinctively rubs us all the wrong way? I suppose it's the fact that while we all know there needs to be a controlled development process, all the customer was really asking for was a time and cost estimate for the project. And the long, drawn-out process described in the e-mail to get to this simple answer just doesn't cut it anymore.

Is this really such an unreasonable request?

What would you do?

I'm sure that nearly everyone on this site has to contend with this very question on a regular basis. And so, rather than tell all of you what changes I think this particular company should make, I'd like to take an opportunity to learn from your collective experience.

How would you advise this company to change its process in order to be more responsive to critical customer requests? Would you:

  • Make the IT meetings more frequent?
  • Make those meetings collaborative with the business?
  • Eliminate the company's point system?
  • Have the business submit a request with certain date and budget parameters from the start?

I think the value in hearing from everyone on this topic is not so much in finding THE answer, but in generating some conversation and in exposing a variety of possible answers, each of which has its place, depending on the organization and the specific situation involved.

So let's hear from you ... tell me what you would advise this company to do in order to establish a more customer-responsive approach to work order management.

Once I have a good number of answers, I promise to write up a synthesis of the best ideas (with a few ideas of my own, of course) so that you can use them in your ongoing challenges in this arena.

35 comments
minstrelmike
minstrelmike

Don't let process between departments over-ride production of the entire company. We make/ask requesters, including average users up to top-level managers, to prioritize their requests when made. Low-level users get to choose between immediate or it-can-wait-till next-week or upgrade-request. Any upgrade-requests are prioritized and cost-estimated by a group made up of business folks and IT folks. The IT folks are expected to give rough estimates of cost and time and the committee prioritizes the usefulness of the work (estimated benefit). We don't waste a lot of time on getting exact costs or benefits since until you get into the code, you don't really know what it will take and until you implement the solution, you don't really know what the benefits will be. Get folks who are reasonably accurate in their swags and only worry about the comparative levels (between requests) of costs and benefits. It gets reprioritized every meeting (which occur every 3 months) but any business manager can ask for a meeting when needs change drastically.

ateaton2
ateaton2

Reading between the lines, it appears that Tim has provided Jack with a timeline guesstimate that he now realizes was faulty. While the BR process appears to successfully separate customer from service and is an issue all its own, what disturbs me about this e-mail is that 1) it indicates that Tim was unfamiliar with the his own company?s internal processes when he provided his guesstimate and 2) he has chosen to cover-up his failure by laying out his issues with his employer?s internal process as a way of explaining the difference between his guesstimate and the likely outcome.

schneider1a
schneider1a

The first problem seems to be that the process for placing the request is unclear. Why else would the IT department have to discuss how the request should be handled. Secondly we do not know what the customer's expectation is with regards to a timely response. Thirdly we do not know the urgency of the request. Furthermore "Jack" seems to anticpate that the suggested process can not deliver a timely repsonse. This leads me to the assumption that the process is inflexible and can not cope with expectations, urgencies and timely results. Therefore the process needs to be reviewed and improved. If agreement on price and time has been achieved the project should not be prioritised based on a points system. This is merely one measure to be used in the collaborative meeting to prioritised projects in the pipeline and active projects. The most important aspect for prioritisation is the benefit that the outcome of the project delivers to the customer.

DineshKurle
DineshKurle

Accuracy of quick and rough estimates depends on what is being asked. Routine work like setting a PC, minor screen changes are easy to estimate. But business wants cloud solution, without details discussions it is impossible to any estimates. Most of the time business do not what they exactly want. Business have rough image what they wants. Hence many times it difficult put those images in words. Those images should be given firm shape by regular collaborative communication between IT and business. I do not understand salesperson. He is trying to get sumpothy from customer by passing resposibily IT. Rather he should be arranging meetings with IT and business to speed up the process of getting estimates. For this reason many IT companies have pre-sales engineers who go along to salesrep and get necessory information for making proposals.

mlf
mlf

Create a standard request type that offers estimates with specific turn around times, defines minimal customer/business requirements (info needed from customer) and then what IT is expected to deliver to fulfill the request. Ensure management support, measure performance points watching for appropriate business requirements and compliance with turn around times and quality of the work product provided back to the customer.

mdunfee3016
mdunfee3016

I have several issues with this scenario, or since it is real, situation. What IT group only meets once a month? For that matter, what business meets that infrequently? Client need should be based on request and ability to pay, not some antiquated point system. I am a partner in a very small IT firm, and when a client sends in a request, it is responded to immediately. We take what the client is requesting and research what is available on the market, arrange the items in cost order, with the problems and consequences involved. With a company as large as you are describing, there should be a team assigned to read requests, put together a project plan, and assess the costs in relation to the customer?s budget. This isn?t rocket science, and the current way it is being done, you would think they are doing all their research at a library, or on a BBS. I just don?t understand, small businesses focus on each and every client, period. Apparently the big businesses of today no longer care about their client retention program, just their bank accounts. I wonder how much longer this particular client will remain with the company, and how many they have already lost to other companies that pay attention.

melachaman1
melachaman1

There are two issues here: First from IT. It seems that the IT organization does not differentiate between a quote and a project. Projects may need to be resourced and scheduled, but quote should be responded to immediately. If a supplier responded this way, they would never get any business. Second, from the business: Ultimately the business is responsible for business results. If one of their needs is to get something done by IT, it either fits with their goals and supports it, and they should escalate appropriately until it gets done, or the business decides that it is not important. The client should never be involved. The client may be told that we cannot or will not do it, but this is not an IT issue.

leedcc
leedcc

On the one hand, the process is working, the requests are being prioritized, on the other hand, there needs to be a process to manage those requests that are required to jump the queue. For that, the point system, may take that into account and give the requests more point, thereby making it "bubble" to the top of queue. Setting the criteria to "bubble" the queue, will require buy in from business stake holders ...on who goes first!

pbarkley
pbarkley

There are several fundamental problems here in my opinion, although as others have noted we don't have all the details. First, the internal custom software development shop (um, call it the CSD department under IT) should be set up as if it were a profit making operation, even if 95% of its work is for internal clients, and it should be in competition with outside vendors for all work. If an outside vendor is used, however, the vendor needs to follow CSD development standards or chaos will result. Even internal clients need to be charged back for their CSD work; otherwise, it's like saying "free programming" and they'll often act irresponsibly in commissioning work because it doesn't cost them anything. I've seen this repeatedly in organizations where I've conducted IT assessments. Competition means that CSD will respond to internal or external requests for projects in a timely manner; one month is not even remotely timely. Depending on the size of the project, and the size of CSD, a viable contract-ready answer can be prepared in a few days. Obviously really large projects will take longer just to add up the pieces for the detailed estimate. In all cases, a standard CSD contract vehicle should be used that states the terms and conditions, thus dramatically decreasing the amount of time to prepare one. The main work on any given project is describing the project overall, and then preparing a detailed estimate of the effort. Scheduling is another matter--it needs to be given in terms of, "If the contract is signed by next Wednesday, June 30, 2010, work can be scheduled to begin on x and be completed by y, if there are no change requests once work begins." You can't schedule it until you know it's going to happen, but clients, internal or external, need to know when you can get it done. It also pushes them to sign because if they don't, they know you'll reschedule it. However, no one can accurately respond to any request like the one in the email until the specifications are completely understood and documented. That can be through a Requirements document, a set of Use Cases, or other methodologies. We use both along with a data model. And you can only estimate from the initial conversation how long the analysis and design phase will take. It might only be 10 hours for a small project, using efficient senior personnel who have adequate automation tools to produce the standard documents. The other alternative is to just give a wild guess and start down the endless path of prototyping--that's another discussion entirely. Some clients may be willing to engage in an open ended project like that, but in my experience most aren't. OK, so that's the basic process that has worked well for me in many years of developing software, ranging from very small (100 to 200 hours, say) to moderately large (25 people full time for 5 years) projects. But...that's NOT what the original email was about! I included this for background about how I see the process working properly. The original email is asking whether a certain project can be done, and by what date. That is a classic sales situation, although no, I don't recommend that sales make up the answers since we know how that will turn out. The client needs to be apprised that there is a process, and given the datasheet that describes the process, including the fact that the work will not be undertaken without the CSD contract, even if it's part of a larger client contract, since it specifies the work in detail. But to give them what they want, which is an idea whether this project is even feasible, you need a senior analyst who is familiar with CSD's process and schedules, as well as the outside vendors already in use for custom work. Ideally the analyst also knows the client organization. The analyst meets with the client, either in person or in a phone interview, and gathers enough data to understand the scope of the project. Based on this meeting, which might only be 1 or 2 hours, the analyst confers with colleagues as needed, and within a day or so prepares a standard written "ballpark" estimate, loaded with qualifiers, including the statement that "This is an estimate based on preliminary discussions. Once analysis begins, it will be revisited up to the point of completion of Phase One (analysis and design). Any change in scope will result in a change in the estimate. Be advised that 80% of projects that we undertake experience an increase in scope of as much as 30% over the initial estimates based only on a single conversation. 10% of projects experience an increase in excess of 50% and are generally abandoned during analysis." (Use your own statistics, which hopefully you're gathering.) The sales department will hate that, but enough caveats usually get the attention of the client. My experience is that a savvy analyst can usually (but not always) figure out where the risk areas are and probe for those in the initial conversation, thus creating a reasonable overall scope. NO project is undertaken without doing the analysis and design first. Some projects are abandoned, perhaps within the first 8 hours of detailed interviews when it becomes clear that the preliminary conversation didn't define the scope properly. This gets everyone out of a potentially disastrous project after spending very little money on it. The result is the ability to deliver ballpark estimates that allow the client to determine whether or not to even start, and that controls the scope throughout the project lifecycle. It balances getting new business, which we all want, whether internal or external, with doing the work responsibly.

alistair.k
alistair.k

If the customer is asking "I want you to migrate my legacy CRM and on premise ERP into a unified communications social network modelled cloud based SOA SaaS solution" or some such pile of ill defined buzzword strune leviathon of a project then, yeah, lets get a very good idea of what is involved before making any kind of commitment, however vague, to handle it. If they are just asking "I need a price for three installs of MS Office" then its a process from a horse's behind. Either way the response to the customer sucks. If a subordinate of mine sent that to a customer we'd be having words. Possibly in the presence of a HR rep. It sounds like the company could do with streamlining its processes for scoping and risk analysis and pricing. Something replacing formal meetings (work flow control system of some sort may be a first stab, but I'd need to talk to the stakeholders before commiting to anything :-) ) However in anything where a full architect's solution is needed then its going to take time. Again: what is the saize, scope and nature of the request? A shop I worked in years ago had a big sign. "Poor planning on your part does not constitute an emergency on mine." If the customer really needs an indicative price and outline design for a big piece of work turning round in a few days then they (or at least this representative of their company) looks disorganised...

cferjani
cferjani

Tim is just passing the buck. Many of our business users want to provide scant Business Requirements and expect us to pull a miracle out of ... He should have tried to coordinate with a member of IT and the customer to extract more detailed business requirements if he was incapable of doing this himself. He probably just sent a one paragraph email as requirements to IT and expected them to provide him with a solution. In this day and age, more non-IT staff need to become more savvy in understanding systems if they are the go-between IT and the customer. How Tim should have responded: Dear Jack, As I am working with the IT Department to provide you with an appropriate estimate and timeline, I need to meet with you to work out a more detailed Business Requirement. Due to the shortness in your timeline, would you and any of your staff be available for a phone conference or face to face meeting in the next couple of days to discuss your needs?

Ponosby Britt OBE
Ponosby Britt OBE

This is the norm at IBM both internally and externally. Try finding somebody who knows how things work. After its explained to someone in India, you may get an answer in 4 to 6 weeks, a rough order of magnitude.

emile.vandermerwe
emile.vandermerwe

Marc, These individuals appear to be stuck in the procedural, mainframe era; the time when IT still dictated to business what can and can not be implemented. An organisation that has not shifted from being IT centric toward a more business centric model is already yesterday's news. As IT leaders, we need to understand the business value before we can start looking at what IT tools will satisfy that requirement and it's through business understand the IT impact of their decisions and IT understanding the business value of their activity that synergy is achieved. Something that is critical in this day and age is having an iterative approach to development. I don't see any of that mentioned here. My suggestions to the subject would be: 1. IT meet with business on a regular basis. They appear to be quite distant from business 2. Completely revamp the scoring system. Where is the economies of scale in that evaluation? This system is very short-sighted. 3. Either create a partnership with IT, or consider contracting a solutions provider. 4. Take a good hard look at the business and, through that process, formulate an IT vision and mission for the organisation that relates to the organisation's broad vision and mission. Strategically align IT with business.

JJLyonsII
JJLyonsII

The problem with most IT departments is that they forget about what their purpose is. Few treat the above scenario as a repair call. Suddenly we get lost in implementation of corporate policy and treating simple requests like they were treaties with foreign governments. For more than 20 years I owned service companies that dealt with the vending machine business. Since switching over to IT, 14 years ago, I began to understand the similarities of problems that customers had but the way management treated them was completely different. Again think in terms of a service call. This would include any updates be it equipment or software. The prices charged and the customers ability to "pay" should be done in advance of a request ever coming into the help desk. Monthly meetings should be for Enterprise Planning and Analysis of Performance; not deciding who should get what. Joe josephlyons@nyc.rr.com

MichaelPO
MichaelPO

I agree with an earlier comment that someone hurt Jack's feeling and he is passing it on. Two things come to mind. Jack is adding no value and needs to be removed from the process. The request needs to go to someone with enough knowledge and empowerment to provide a quick response ( I use an immediate small/medium/Large and if the interest is still there follow up with a more accurate estimate.

mnstine
mnstine

The committee should be agile enough in their schedule to accomodate priority requests. Also a request from a customer has the potential to have a much bigger business value than other internal request. These values should have been weighed when the request was submitted to IT to determine the schedule and priorities.

jkameleon
jkameleon

If the company is very quarterly bottom line oriented, such approach could be the best for it, no matter how strange it might seem. Yeah, sure, a lot of opportunities are missed, but at least it's cheap. > Make the IT meetings more frequent? I'd somehow imagine that there are too many meetings there anyway. > Make those meetings collaborative with the business? I'd somehow imagine that these meetings are dictated by business. > Eliminate the company?s point system? In that case, the company would be forced to trust somebody's professional judgement. Perish the thought! > Have the business submit a request with certain date and budget parameters from the start? That seems like the only viable option.

Kiran C
Kiran C

This shows inexperience on Tim Braverman's side.There are many ways to handle the situation. Considering the company's policy if the meetings were not possible for few weeks he could have requested the client company to give more and complete detail about the project so that they can have better idea of the cost and time required to complete the project, then based on the requirements he should have discussed some points with the client to make them more clear. I believe this would have given him few weeks, by then he should be able to conduct meetings with his staff and decide the time and cost. Moreover if the whole of IT department was not available for the meeting he could have discussed it with few of his colleagues and seniors which could have given him rough estimate of project time line. For increasing the cost of the project or whatever reason it may be, he would have given a bigger time line instead of declining the project because this may at least maintain the relationship between the company. Most of the grading system, priority or complexity depends(or is inversely proportional) upon the cost the client pays for the project, so any discussion on that is useless. good luck Tim, hope your seniors doesn't know this

h.krishnan
h.krishnan

looks like the director made a commitment without checking with IT the work involved. Now he is trying to shift the blame to the "SYSTEM". Was he unaware of the system in place for Software development. A critical business requirements need to be discussed in a formal REGULAR forum ,involving IT, and decided then and there, the timelines , budgets(at least rough cut budget) so that all are in the loop.

G-Hash
G-Hash

It would be nice to change the point system by seperating the opportunity "weighting (measuring)" from the rest of the process and adding a mechanism of "call-to-arms" the IT-team for really cool opportunities

putchavn
putchavn

I do not knwo how many of the members of Tech Republic are also members of Requirements Engineering (RE) Group of Yahoo. Some software professionals RE argue that software development is not Engineering YET and so "Responsiveness and Service Delivery" cannot be guaranteed. There are many software companies that some how manage to not only survive but thrive. It woudl be nice to know what the Engineering Response is. Putcha V. Narasimham

rdevereux
rdevereux

Sadly I don't think this kind of response comes from 1970's but comes from a culture where IT has to be defensive because the rest of the company has taken liberties for far too lonmg and this is their way to re-grasp a degree of control over the situation. However deplorable the outcome and the affect on customers, the sad fatc is that businesses today expect far more from fewer IT Staff and in the interests of clearing their own workload sales and other staff are far too willing to agree to unreasonable deadlines and unrealistic demands - read Dilbert for a week to get the idea! Maybe your correspondent needs to consider this element in his estimations?

LightVelocity
LightVelocity

The Title and designation tells me that the request landed into a wrong person. Rather than forwarding it to the right person and establishing proper connections, the reply just seems bizzare. To judge and assess an organisation or a department based on this email is too big an extrapolation. Some of the practices sighted in the note are followed in many companies and been with a company that has some of these procedures, I see valid reasons behind them. IT department too, just like other groups need to optimise their resource deployment into activities that are of higher impact both to customer satisfaction and revenues, so having a procedure to evaluate this is by no means wierd. The topic needs more context and details before one can get to a conclusion if the practice is good or bad or outdated,and before one can provide a recommendation.

Kruger.henning
Kruger.henning

This is basically the same way the process works between us and the customer. The only difference is that we work in per-team per-week buckets (with available hours for the team-week bucket) and the Customer decides what goes into which bucket. We also do the time estimates for each request and that gets worked into the week buckets. Each request gets broken up per time needed by a resource to enable parallel work where possible. The Customer decides the priorities of the work and what goes into the team-week bucket. (We can change the available hours per team-week bucket within limits, to a low for resources' leave and training but only before that week has been committed.) Normally buckets are committed 2 to 3 weeks in advance to allow planning in both sides but may change on request of the customer if anything critical are needed. Remember that our time is the customer's time. This is not the type of reply you send to a customer. Rather log the request for the customer to the correct person to get the process started and then refer the customer with that feedback to the correct person to follow-up on the request status. (I have been there and learned from my mistakes.)

bergenfx
bergenfx

If you catch the undercurrent of the message, it seems like its author is intentionally putting things in a negative light. It seems like he got bruised on a turf war, lost and then went and cried to the client that he is not in control and can't be blamed for internal inertia ... really petty, if true.

JosB
JosB

That's not a response you can give to a customer... "It's out of my hands, I cannot control" without pointing to someone who has control is bad. And as customer I don't care much about the process, I care about the delivery of my business needs. If you cannot provide I can always start to look somewhere else. Next I'm not sure Tim got the question right to IT. The customer wants to know if something is doable, a rough estimate. Not something that should be discussed in detail in monthly meetings. On the IT side: sure they take long time. Maybe they should have a team or person who can quickly look into requests and give a rough estimate. Taking in account other projects that need resources. This depends on the complexity of the request, maybe others need to be involved. Furthermore on IT side: try gather as much information as possible you need to estimate the project. Put that in a form for business so they can fill it out before making the request. Make sure this is handled as 'request for information' and not as 'request for change'.

icinfo
icinfo

I wonder what the Sales people will do to the IT people when they find out... Sam

JosB
JosB

Assume we are dealing with financial or investment software that is used by hundreds of customers worldwide. Do you really want to base on request and ability to pay? The impact of a request could be huge and break things for other customers. So you 'fix' for one and all other customers leave because financial software must be relyable.... Development of requests for this kind of software can take up to several years. While customers want things today. Is it nice to have or mission critical for your customer? And if this customer wants it, do other customers perhaps also want it? It's the response that sucks, not the message. Monthly change meetings are not that rare, long delivery time for specific features are also common (even longer when you have to hire a specialist). But Tim should have made clear that the request has a huge impact and therefor cannot be estimated easy. Without giving all kinds of details why others make that he cannot deliver what he wants....

don.gulledge
don.gulledge

This story is more of an out of context event than a comprehensive description of it. When dealing with client concerning a "Can do and how much?" it's a mine field strewn with failure. Even the most simplist project can go down in flames or go way over expectations. So, being quick and inaccurate to satisfy an opportunity is not a very likely to be successful. If this company has many ongoing projects with the client, then giving a quick and inaccurate response to them might affect what other money making work they are doing. Since they already have their foot in the door, then it is more important for them to be careful about doing a project that fails or looks way to overrun with cost. Many projects require three contracts. The first to build an assessment of the work and define the cost. Second, to do the work and build the product and third, to give training, production support and long term support to the product. In this senario, it would look like this isn't the case. This looks like a services agreement with on-going work by project under an overall contract. Something many clients prefer nowadays. Be it as it may, any company that gives an uneducation guesstimate on work to be done is committing to client no matter now much is known or written down. No good programmer, project manager, or even business manager should be giving uneducated estimates without first doing some homework. Since we don't know the complete circumstances of Jack's situation, it's too easy to project our own bias into it and formulate a looking backwards opinion. However, all things being equal, I think Jack did the right thing because it's been my experience in many organizations and companies that making deals (providing estimates) to clients is a very filtered process and not given to but only a few. So many times employees have stepped over their boundaries and given estimates or quotes that a company has a hard time backing out of or changing no matter how legally binding it is. My vote is for Jack. Better to error on the side of caution than not. And, we know from the discussion this is just a small part of a larger scope of work. One bad apple can spoil the whole barrel.

phawtrey
phawtrey

A request from a customer should go through the sales organization with the job of protecting customers from internal processes like the one described here.

AlphaW
AlphaW

I have seen this done over and over again, in order not to lose credibility with the customer IT is shown as the bottleneck. Often it is the business unit itself causing delays or not being clear with priority or business requirements, but IT is an convenient scapegoat.

jbgraffiti
jbgraffiti

.... I agree it's a cop out but I have been in exactly those situations with internal and external customers faced with a wall of IT bureaucracy and very little influence to control the resources. I would arrange a meeting (depending on the importance of the client) to discuss the nature, purpose and detail of the requirements Make a commitment to come back to them with an initial estimate of scale, doability and priority and provide options what they can do next - become their ally in the IT behemoth I do feel very emphatic with the middle man here though as he is very much caught between a rock and a hard place but business partnership is much more than a request processing machine....

Ron_007
Ron_007

when you said the request went to the wrong person. The "Director - Customer Analytics and Reporting" is not the person to be asking sales type questions. The customer should have asked their dedicated sales/tech support people. The Directory should have passed the request on to a sales weenie to provide the standard salesman quotes (aka LIES!). The process and timeline he described is typical of companies I've worked for, for internal software development. On the other hand, it does sound a little unreasonable for a sales query, especially for a customer worth millions of dollars of business. That kind of purchasing/spending power should reasonably be expected to buy priority in any profit oriented sales/manufacturing organization. On the other hand yet again (I'm getting a hand with all of these "other hands") ... I can completely sympathize with IT. All too often I've seen requests for "quick and dirty" estimates turn into "firm quotes" in the client's mind. As far as I am concerned, a "quick and dirty" estimate comes with a confidence of +/- 100%. When the client decides to go ahead with the project based on the initial estimate and provides the full requirements for IT to do a proper analysis and design on the request, they are invariably "surprised and outraged" at the final project cost. They can't understand why the initial "fast and dirty" estimate was so low. Because they didn't provide enough information (they always think of more stuff once you get going) and IT did not have time to do full impact analysis. For example, as a "new programmer / employee" I was given a "simple task" to get me started. The "fast and dirty" requirement and design specification I was given was ... "Add this 1 character field to this 1 screen" (plus a little supporting info). Initially it sounds simple, change 2 programs (client and server side) and 1 or 2 copy members. Any idiot could do it in a day or three (allowing for learning curve). Sure the request was simple, except once I started working on it, that simple change ended up impacting 21 separate pieces of program and copybook code. It took significantly more than "a day or two" to make the code changes, setup the all of the test data and do initial unit testing for that "simple change". The client was "not pleased" with the delay (and increased development cost). They hung on to the initial estimate, even though they were involved in helping me confirm the expanded scope AND they approved it before I did it. As far as the client and upper management was concerned I was "way over budget on delivery date and development costs".

inouyde
inouyde

We've found that clients and business unit owners will pepper us with terms and phrases of what they think they need. It's much easier on us IT guys to ask "What do you want to be able to do?" and then design/budget solutions around that. People have asked for web portals when all they needed was an email tunnel.

Editor's Picks