How To Tell A Software Developer What You Want

A checklist for users (and for the developers who wish their clients would follow these instructions)

By Esther Schindler, ITworld.com |  Development, software development Add a new comment

Any business user who needs the help of a software developer -- to build a website, say, or to create a custom application -- needs to explain just what it is she needs and wants. Judging by the results, however, the communication is far from flawless. Clients and users often grouse about those irksome designers and programmers who delivered something far different from what was desired, which is how we end up with sites as popular as Clients From Hell.

It doesn't have to be this way. If you explain to your development staff or outside consultant what you want, in the right manner, you have a good chance of getting your project done on schedule and on budget -- with results that you love. These six steps can ensure the best possible outcome.

[ See also: Career advice: Making your mark in software programming and Programming magic: Rituals and habits of effective programmers ]

1. Define the business need.

The most obvious advice is to carefully explain what you want. But that assumes you know what you want, that you can articulate it in a useful fashion, and that you can keep your eyes on the objective. "If you don't know what you want when you describe it to us, it probably won't be what you expect when it is delivered to you," says programmer Paul Giegler.

If you start with a clearly articulated goal, you can easier measure whether the software fulfills the promise.

Start at a high level: What is the goal? Write down your overall objectives. Think of it as a project mission statement.

Before you even call a software developer, says Saeer Butt, senior software architect at Zaphyr Technologies, "Finalize the goal that this software will achieve once it's completed, such as 'Reduce invoice-generation time by 30%' or 'Increase teller output by one hour a day.'"

John Simpson, director of customer outreach at Jama Software, recommends users force themselves to articulate the goal in 100 words or less. "Developers are good at executing details but they do even better when they have visibility and context to the larger vision," Simpson says.

This exercise helps your developer, but it's also good for you and your business team. If you start with a clearly articulated goal, you can easier measure whether the software fulfills the promise. Try to include a metric for success in that goal, as in the examples above.

2. Don't tell the developer about the solution. Describe the problem.

Once you've identified the overall goal of the project, get specific. What does the software need to do?

"Describe to the developer what problem you need to solve, and trust her to help you find the right solution," says Veronica Yuill, joint owner of web development company Archetype Informatique, based in the south of France.

9 comments

    Anonymous 1 year ago
    I think this is a great article and provides a worthwhile toolkit for the developer to hand to their customer or a customer to use when starting a new software project. As a practicing business analyst, this is part of the service I offer to my clients -- helping them clearly document their goals, requirements, and processes, ensuring the communication with the development team is clear and issues are resolved. Given this, I think a great step 7 might be "And, if you are overwhelmed with the idea of fulfilling the first 6 steps, contact a business analyst for help before you hire a developer!" So often I see customers and developers struggle with this hand-off and it might be helpful for them to know there is a profession full of people who can help.Best,Laura BrandenburgBridging the Gap
    Anonymous 1 year ago
    As a development manager, I see it happen in far too many cases that the client will not have fixed a picture of their goal(s) in their head before meeting with IT to implement it. What happens time and again is upset, dissatisfied users and an IT department always on the brink of insanity.This article is a good start, and a great read. I'd like to see something from the opposite end of the spectrum as well, where we would discuss what developers need to do to ensure that they stop the process when there are insufficient requirements/goals. We have to take some responsibility to make sure we're giving the customer what they want as well, I think.
    Esther Schindler
    Esther Schindler 1 year ago in reply to Anonymous
    I shall suggest it to my editor!Though that's a people management skill you're talking about. It's always difficult to tell the boss or client that they're wrong. Particularly for consultants who don't have an ongoing relationship with the client. If we say, "I know you want to do it THIS way, but my expertise informs me that that is doomed to failure" the client might stomp off in a huff. Often it's easy to say, "Good; let them" -- unless you have a mortgage payment due at the end of the month.It's one reason that I like the idea of someone giving this article to a prospective user or client and making them fill out some sort of document that answers these questions. If nothing else, it may help the user recognize that her goals are murky.
    Anonymous 1 year ago
    Much of what was would help the SW developer but this would help as well... generally there is a system which is already in place and needs to be updated, modified and/or replaced.Let the developer know what works and what doesn't. Then prioritize what's new and needed.New code doesn't fix everything (although new code can attempt to just that). The workflow core needs to be defined so it can be refined to meet new requirements. If this is done, goals can be met on time and within budget.The nice to have's (the fluff and low in priority) usually can be implemented also within the same budget as the 'bonus' features. Only after defining the core (let's say the type of tree), now expectations are met; the fluff is if the tree is flowering or ready for picking.
    Anonymous 1 year ago
    Wow. As a developer, it's refreshing to see this article. It's really good, too. Articulates well best practices and how to approach programmers for projects. Will have to save this for later. =)
    Anonymous 1 year ago
    Great article.I'd also add the following. Don't presume things are easy, because you have seen them elsewhere - Google, ebay, Amazon, Apple, et al have vast teams of developers.Show some respect for people's expertise - Don't use the words 'it's only' or 'just', unless you really understand the issue. Consider how other people underestimate the complexities of your job.Focus on the stuff that will raise productivity or make money - I've seen at least one project collapse because the company insisted on a Big Bang system that was going to automate everything. We spent months developing a sub-system for something that would maybe happen 10 times a year, and could be handled by getting out a check-book. They would continually find another business process that needed to be included before they could start using the system. Eventually the company was acquired and the project canned.In the meantime, another customer bought the same system and started a business on it.
    Anonymous 1 year ago
    Esther - you nailed this! Every software developer should have a stack of these and hand them out before she charges a penny to a client. Well done!
    Anonymous 1 year ago
    I think that anyone who works with contractors and consultants would benefit from giving this article a read - Working with the right software developer makes all the difference, too. Looking forward to future posts on that topic. If anyone wants to see more content from Smitty Smith, check out www.identitymine.com/forward. He offers terrific developer insights.
    Anonymous 1 year ago
    Saeer BUTT. I bet you that kid was tormented in school but on the brighter side at least he got to be the 'Butt of Sire'.

      Add a comment

      Post a comment using one of these accounts
      Or join now
      At least 6 characters

      Note: Comment will appear soon after you have activated your account.
      Obscene/spam comments will be removed and accounts suspended.
      The information you submit is subject to our Privacy Policy and Terms of Service.

      ITworld LIVE

      DevelopmentWhite Papers & Webcasts

      White Paper

      HP NonStop SQL Fundamentals whitepaper

      This whitepaper offers a detailed look into the fundamentals of HP NonStop SQL solutions. See how this system delivers unprecedented levels of application availability with fail-safe data integrity and meets the needs of enterprises with large-scale business critical applications.

      White Paper

      Nebraska Medical Center case study

      See how the Nebraska Medical Center implemented a SQL solution to make information more readily available to streamline operations, improve patient care and facilitate medical research with an enterprise solution running on HP NonStop servers.

      White Paper

      Concepts of NonStop SQL/MX

      For DBAs and developers who are familiar with Oracle solutions and want to learn about NonStop SQL/MX, this whitepaper provides an overview of the similarities and differences between the two products-with a specific focus on implementation.

      White Paper

      6 Things Your CIO Needs to Know About Requirements

      If your organization is not predictably successful on technology projects, there is likely an issue in requirements. CIOs must take action and own requirements maturity improvement. There are 6 main things a CIO must know about requirements.

      Webcast On Demand

      User Experience Monitoring

      In this webinar, you will learn hints & tips for improving end-user response times from Forrester Research analyst, Jean-Pierre Garbani.

      Sponsor: Nimsoft

      See more White Papers | Webcasts

      Ask a question

      Ask a Question