Overcoming Proposal Objections

  • Comments posted to this topic are about the item Overcoming Proposal Objections

  • Timing is everything, and having an honest company structure

    Too early in a project then you can be seen as the doom-&-gloom merchant.

    Too late and it will be seen as being reactive.

    Too dishonest structure and people will lay the groundwork down to prevent the idea from gaining traction.

    Years ago a company a project was going live and I suggested that we find from the supplier what the top 10 data repairs were so that we could code a solution. Suggested it a bit too early and using the suppliers numbers worked out that we would need about 15+ people full time doing the repairs. Well the Project Manager did not take it well, whereas the Business Continuity Manager agreed after the initial shock.

    As a result the PM blocked all comments going up, didnt want to be see the costs going up, or that there would be problems with this new project.

    When I left that company for pastures new, the system was about 25% capacity and already had 12 people hacking the database doing repairs, all outsourced. Apparently these standard repairs were too adhoc to be coded, or at least this is what the upper management were told.

  • Fortunately, most people in IT that I have come across have little interest in personal accolades. Kudos from their peers is a different matter. Basically, most people in IT have little interest in climbing the corporate ladder but gain a great sense of achievement in having good work (including ideas) recognised by those whose opinion they value i.e. other IT practitioners.

    This makes it easy to make suggestions which end up being viewed as coming from someone else.

    Gaz

    -- Stop your grinnin' and drop your linen...they're everywhere!!!

  • Gary Varga (12/5/2014)


    Fortunately, most people in IT that I have come across have little interest in personal accolades. Kudos from their peers is a different matter. Basically, most people in IT have little interest in climbing the corporate ladder but gain a great sense of achievement in having good work (including ideas) recognised by those whose opinion they value i.e. other IT practitioners.

    This makes it easy to make suggestions which end up being viewed as coming from someone else.

    I like accolades I get from my clients and users. That tells me what I am doing is satisfying them. It's OK if I get an atta-boy from a peer. But, I like pleasing my customers more than my peers. And, occasional recognition from above is nice, too.

    Tom

  • During a round table discussion a senior developer working in a small company posed the question, “How do I get my Finance manager to release funds for me to do improvements that would really enhance the company applications?” Several people offered suggestions but none were based on the actual problem, i.e. communication.

    Some proposals, like upgrading to the next version of SQL Server or initiating a new project, obviously require a substantial financial investment. However, when the proposal is simply something like refactoring an ETL process or a handful of stored procedures, and the investment is time spent by a single developer, it is frustrating to frame it within the context of capitalizable versus non-capitalizable time.

    "Software development costs that add future value are typically capitalized. Expenditures that do not increase the value of the asset are expensed."

    Often things like database development, particularly refactoring of existing code, are not seen as "capitalizable", despite the fact that it certainly adds value to the IT product or service.

    "Do not seek to follow in the footsteps of the wise. Instead, seek what they sought." - Matsuo Basho

  • OCTom (12/5/2014)


    Gary Varga (12/5/2014)


    Fortunately, most people in IT that I have come across have little interest in personal accolades. Kudos from their peers is a different matter. Basically, most people in IT have little interest in climbing the corporate ladder but gain a great sense of achievement in having good work (including ideas) recognised by those whose opinion they value i.e. other IT practitioners.

    This makes it easy to make suggestions which end up being viewed as coming from someone else.

    I like accolades I get from my clients and users. That tells me what I am doing is satisfying them. It's OK if I get an atta-boy from a peer. But, I like pleasing my customers more than my peers. And, occasional recognition from above is nice, too.

    Tom

    I am with you, on the whole. Clients (of all sorts) are often grateful when you have done the simplest of tasks that blockers have refused to do for a long time (from a client's point of view) which usually means that one has recognised a simple avoided task. Peer recognitition on the other hand usually takes into consideration the skills and efforts to achieve something. Praise from above is rare and far too often based of a reconigition of duty as opposed to true belief.

    Of course I could be wrong.

    Gaz

    -- Stop your grinnin' and drop your linen...they're everywhere!!!

  • Two questions: First, what is "SWAG estimates"? I've never heard that term.

    Second, when you suggest writing a proposal do you mean to write it and print it out, and then hand it in?

    Rod

  • Doctor Who 2 (12/5/2014)


    Two questions: First, what is "SWAG estimates"? I've never heard that term.

    Second, when you suggest writing a proposal do you mean to write it and print it out, and then hand it in?

    SWAG: Scientific Wild *** Guess

    Tom

  • OCTom (12/5/2014)


    Doctor Who 2 (12/5/2014)


    Two questions: First, what is "SWAG estimates"? I've never heard that term.

    Second, when you suggest writing a proposal do you mean to write it and print it out, and then hand it in?

    SWAG: Scientific Wild *** Guess

    Tom

    The A$$ got blotted out.

    SWAG: Scientific Wild Arse Guess

    Tom

  • Sometimes there's a hidden and perverse reason for not accepting a proposal that seems perfectly reasonable to you.

    One place I worked had a rotten system that needed constant attention from the programmers to 'unstick' records. A significant number of their hours each week were spent manually changing records in the database. We could have easily re-written that system from the ground up in a month and saved the users a lot of frustration. But the answer was always "No, no, NO!" from the IT manager.

    It turned out that all the database 'tweaks', day after day, produced chargebacks to the users departments. We were unknowingly pushing to shut down his little gold mine, and of course he couldn't admit the reason for his refusal. Sometimes when there's no good reason for denying your proposal, there's really a reason, but it isn't a good one. Office politics. :crazy:

  • The way I've heard it, a "Wild A$$ Guess" is making up a figure that sounds good to you. A "Scientific Wild A$$ Guess" involves basing your guess on a bit of actual data, but then multiplying it by a guess factor. The bit of actual data makes it a scientific guess. But it's still a guess.

    You might time yourself and find you can write 2 lines of code in a minute. Then you guess that the module you need to write will take 500 lines of code. So it will take 4 hours to write, 12 hours to debug, and 60 hours of user training.

  • What is good for the department is not necessarily good for the company 🙁

    Gaz

    -- Stop your grinnin' and drop your linen...they're everywhere!!!

  • In general I think this was a good article, but I think the line

    Where we fail in communicating is in a lack of understanding of the business’ goals and objectives and how we can integrate our solutions into those goals and objectives.

    is a gross oversimplification of the issues involved. In many companies I've witnessed first hand the business people themselves have trouble determining what their goals and objectives are. Needless to say, some of those companies don't exist anymore or were bought out by others.

    Yes, in general there are communication issues, but they go both ways. I've even seen some places where the technical people understand the "business" better than the business people. I've also seen places where IT seems to be in its own world and develop solutions to the wrong problem or make it more difficult for people to do their work than before.

  • I had a very candid conversation with someone at board level. Someone at board level of a company quoted on the stock exchange is always likely to be looking for their next move. Ditto an ambitious business manager at much lower level.

    In general they are interested in what can be achieved in the next 12-24 months because that is how long they intend to stay in their current role. Propose something that will deliver outside of these timescales and they won't be interested. There is little scope for that deliverable to add to their CV.

    I know it sounds horrible but you don't climb the greasy pole by ignoring self-interest.

    There is another side to this as well. An ambitious and highly competent young business manager runs a project that involves an IT deliverable. IT don't deliver in the expected timescales and ambitious young manager voices their disapproval. As the business manager is highly competent they get promoted and now their disapproval of IT is more than just noise, it is disapproval from someone in considerable authority.

    The harsh reality is that unless you can articulate reasons for late delivery in terms that the business manager will not only understand but also accept (and ambitious people are prone not to accept failure) then you are in a world of pain.

  • I went back into programming in 1995 to avoid office politics.

Viewing 15 posts - 1 through 15 (of 19 total)

You must be logged in to reply to this topic. Login to reply