IT Employment

Be prepared for the hindsight critics

When you're asking for feedback about a project that is nearly finished, be prepared to hear a list of detailed problems unless you set some guidelines at the get-go.

You know the worst thing you can do? Ask for general input after an app or design project is just about final.

Something happens to people when they hear the words, "Take a look and give me your feedback." An invitation to criticize is like catnip to some people. Folks who had no input going into a project suddenly whip out the white gloves and develop an attention to detail that would put a rice painter to shame. Add a group dynamic, and you've got yourself a firing squad, because now everyone is showing everyone else how observant and knowledgeable they are by lobbing astute observations (aka criticisms) at your product.

It is in this atmosphere that people have been known to debate for hours the size of a toggle button or the emotional impact of a shaded text box. In other words, what they have an opinion on is completely out of proportion to what matters in the long run.

And do you ever notice how infrequent the compliments are? That's because most people are under the mistaken impression that negative comments sound smarter than positive ones.

Don't get me wrong: Feedback is necessary for business success. You need sign-off from the people who are going to be using the product or who understand the customer dynamic better than you do. But a free-for-all, "all insults welcome!" approach is not the way to do it.

Instead, you should be specific about the kind of feedback you're looking for. Make it clear you're looking for only big-picture issues. Ask people to answer only questions like:

  • Does it work?
  • Is it efficient?
  • Does it pull the information you need?

Or

  • Was anyone seriously injured when attempting to use the product?

Good luck!

Bottom line for IT professionals

When you're asking for feedback about a project that is nearly finished, be prepared to hear a list of detailed problems unless you set some guidelines at the get-go.

About

Toni Bowers is Managing Editor of TechRepublic and is the award-winning blogger of the Career Management blog. She has edited newsletters, books, and web sites pertaining to software, IT career, and IT management issues.

16 comments
dearrohit
dearrohit

What an article Toni! This is exactly what i have been facing. I have not asked end users of my applications for a general feedback since the users are usually between 50 - 500, i have asked supervisors for their feedback. And they have come up with jazzy stuff that don't make any business sense, and a waste of my resources. Or stuff like hiding a column so that the auditor does not see the figures.

mikifinaz1
mikifinaz1

When any one is looking to "improve the process" be wary. This is often tech code speak for let's find a scapegoat.

cmejia
cmejia

This is the best advice I've gotten in a long time. And so timely for my project. Thanks.

cln
cln

I am going to remember this!!

grande.christopher
grande.christopher

I agree completely with the author that asking for a review when a project is near completion is a bad idea. It gives those who, with the proper motivation (perhaps something as simple as opportunity or competition for a promotion) would tear anything you've done to pieces. CYA. Put everything in contract form before a project starts. Everything. Every UI, logic component, query, trigger, stored procedure, hardware purchase, hire, etc. Once you have the seal of approval from your superior your job is simply to follow through on the plan. If you've done your job and the plan is detailed enough, there won't be any room for harsh reviews towards the end of the project... at least not in your direction.

jbartlett
jbartlett

The CYA by extensive detailed documentation and sign-off only works if your manager is willing to back you when the snipers and nay-sayers come of the woodwork towards the end of a project. If your boss's superiors and/or peers are the ones that don't like getting what they approved in the first place it may come down to no more than your reputation or his/hers getting tossed into the recycle bin. Which way do think that will go? Perhaps I am in the minority, but I have had just one or two managers that would even consider taking one on the chin to back-up one of their direct reports. In my experience, many who manage to rise to the top in an organization are expert at making sure they are not ever in the "who to blame" box on the project plan (they have great "teflon" properties). I have much better success with well-accepted results by socializing the design and requirements with the various LOB and line managers to get their needs exactly right and set their expectations. This is very costly in terms of time but has a huge pay-off, if the users are involved at the planning and review stages they are far less likely to complain when the project work is delivered. This really helps to eliminate the upper management power-play of gaining "creds" by gunning-down the end result. If their own people can't substantiate their off-the-cuff critique then they will back down rather than make themselves look like a complete 'tard in front of their boss.

ksady
ksady

is when I'm given direction for a communication. I write it following the scope, only to have the stake holders completely re-write it with a completely differnt format and content. Now I just send off a simple few lines in the direction and let them go for it.

jsargent
jsargent

Can someone really give some valid reasons why someone would need to ask for feedback from their peers after a project has finished? (Customer feedback is always welcome but from your peers I don't know.)

cassanovaej
cassanovaej

Whew, I thought I'm the only one having this problem. Everyone's complaining it is not user-friendly. So I ask them what need to be done to make it so. I implemented what they requested. A few months later, they are whining about the feature they requested. --- It seems that they don't even know what 'User-friendly' means.

blockb
blockb

Dear Toni, I like your down-to-earth terse coherent style. As for me, when it comes to seeking feedback, either people tear work apart in a Monday-morning quarterback style, or they have no relevant opinion because the true review was not done. I think this can be attributed to a number of things: 1- the management style of the person heading the group is one of lack of knowledge OR lack of sufficient coaching of staff OR lack of interest 2- insecurity of people who are reviewing...if they criticize the project item, maybe they will gain in some sort of political interoffice stature (maybe in their minds?) 3- again some kind of political maneuver to tear down possible competitors (for what? I've never really been clear about what people are after who behave like that) I think your 2nd alternative of humor hits the spot and disarms people. You sound like an excellent manager/coach, by teaching people to be practical and keep their perspective by keeping a sense of humor. I always feel that when people smile, laugh and have a good time, they work better and produce more - at least with the people I've worked with: both bosses and subordinates. Fun is the key, make the project a game with an objective and higher motive and people just scurry along. My slogan: it is always easier to revise than to devise something - at least intellectually. In IT sometimes one has to junk a system and begin anew because the planning and manifestation just wasn't sufficient. Beatrcie - IT Security Consultant & Educator

BALTHOR
BALTHOR

I never made it past your EULA.

Dr Dij
Dr Dij

you are supposed to create projects in iterations. instead of the waterfall theory you have the smaller project iteration steps where the stakeholders OK the design at that stage or make changes then instead of waiting till the end. ALso using visual prototypes for requirements with software such as iRise that doesn't require you to get the back end working. It is solely for collecting reqts, displaying them visually and getting feedback on layout, and use cases.

toni.bowers_b
toni.bowers_b

Have you ever made the mistake of asking for general feedback near the completion of a project or product? Unless you set specific guidelines, you're going to have your product picked apart from end to end. In this blog, we talk about what to expect: http://blogs.techrepublic.com.com/career/?p=303

seanferd
seanferd

I really enjoyed the article, and I believe it is true and valid. I've seen it happen, but outside of IT. Unfortunately, the majority of experience I've had with any RFC-type situation was with very poor managers, so the near-opposite of the situations you describe were what would take place: Managers would ask for feedback, usually when it was too late to make any difference, then proceed to nay-say any idea offered, many of them good ideas. The same held true with other managers who were directly affected by this guy's "projects", and real money was involved. That being said, I still recognize the validity of your article, maybe more so. (See various threads on this site involving enterprise software.) :D Edit: For parenthesis.

IT.Consultant
IT.Consultant

I just left a workplace for some of the reasons mentioned. There, my team consisted of other developers launching the next version of an enterprise application. As territorial as they were, my teammates would find a part of the application that interested them the most and fiercely guard it. Most would not only refuse to do work outside their comfort zone, but also rarely consulted others for advice, even if the outcome of their tasks affected others' work. The worst part of me was I was given the solo assignment to do one of the most time-consuming and difficult tasks. When asked, the architect offered me no guidance. Nor did my project manager show any support. As a result, my work needed to be redone given the tight timeline. All I got was criticism and condemnation from my fellow developers, who could do no better than me. After the rework, the funny thing was that a major part of my work was kept because it isolated alot of the ugly complexity from the rest of the application. You'll find this happening in environments with no accountability, no team coherence and with people who can only criticize because they can't suggest or even do the work themselves.

The Scummy One
The Scummy One

Ok, I was going to critique your blog, but I decided against it. Apparently you have had a bad support day recently.. Hmmm, I take it back -- here goes "You know the worst thing you can do? Ask for general input after an app or design project is just about final." Yes, I agree, but it is not just in an app r design project, but for ANY project. "Folks who had no input going into a project suddenly whip out the white gloves and develop an attention to detail that would put a rice painter to shame" -- LOL :^0 :^0 Good one, I gotta remember that for later use -- thanks "It is in this atmosphere that people have been known to debate for hours the size of a toggle button or the emotional impact of a shaded text box" Ya keep on bustin me up with this -- emotional impact -- LOL Is that like painting a room to find out that 2x a day the shade is not the 'best color' for the room?? I had that happen "we should paint it a better color" -- yeah, right.... All in all, good reminder/blog -- Thanks