The 3 critical questions to ask your software development company
Editor’s note: This piece was originally published in 2014. It’s been so popular that we decided to update it in 2020.
In our 20 years of business, we’ve been asked all sorts of questions by prospective clients. In hiring our team, we’ve also had the opportunity to ask a lot of developers questions. Through this experience, we’ve learned that there are three really important questions to discuss.
Now, we’re certainly not recommending you only ask your potential software partner three questions. But I think the answers you get from these particular three questions can go a long way to help you figure out which software development company is the best fit for you.
1) How do you ensure that you fully understand the requirements of our software project?
A 2008 study by IAG Consulting looking at the success rate of all IT projects, including software development, claimed that 68% of these projects fail. We think one big reason for this is that developers often misunderstand the business problem the client expects the software to solve. Worse still, the developer may give no thought at all to how the client expects the software to work from the user’s perspective.
Many software developers see the project requirements in a Statement of Work (SOW) simply as engineering problems. But that approach will only get you so far. Because human beings will use the products, and if the needs of those human beings aren’t met, your project will be among the forlorn 68% of failures.
It doesn’t just matter if a feature or function works, it matters how it works for the user. For this reason, we commit ourselves to build every project exactly twice.
That’s right. Not once. Twice. We start by building what we call a ClickModel, a fully interactive, clickable prototype of the finished product. Prototyping allows the stakeholders most concerned with the success of the project to actually experience the software before paying to have it built.
The ClickModel is where we close the gaps—and there are almost always quite a few—between the client’s vision for how things will work and our developers’ and designers’ interpretation of that vision as described in the product definition.
We find time and time again that even the most thorough product owners gain invaluable clarity from a prototyping step. We uncover requirements that might have been mistakenly excluded or treated as “givens” in a Technical Specification document. A prototype will also surface hidden opportunities that could significantly magnify the return on your investment.
So, how do we ensure that we fully understand our customers’ requirements? We assume that we don’t. Instead, we build a functional prototype that makes it easy for our clients to clarify their expectations before we waste any time and money getting them wrong. We encourage you to look for a software partner who uses something similar to our ClickModel approach.
2) How do you limit “Work in Process?”
In a factory, the raw materials coming down the assembly line are known as the Work in Process (WIP). Limiting the amount of WIP is the most important function of any factory. Too little WIP leaves workers idle. Too much WIP can slow down production, hamper quality, or, in severe cases, bring it to a standstill. For more on how this analogy relates to custom software development, we highly recommend The Phoenix Project.
When developers have to split their time and attention working on multiple client projects simultaneously, it’s analogous to too much WIP. Putting aside one piece of work and picking up a new one consumes a lot of a developer’s time and energy. It’s especially frustrating when a developer is close to a breakthrough solution. Will he or she be able to pick up where things left off? Not always, unfortunately.
Like all creative thinkers, developers work best when they can devote large blocks of unbroken time to a task. For this reason, we use a team approach to development. While a development team may be assigned tasks on multiple projects, no single developer ever needs to drop a task on your project to pick up a task on another client’s project.
Furthermore, the team approach entails thorough knowledge sharing. So none of our clients’ projects are at risk if a single developer leaves our agency. And team members review one another’s work as a matter of course, reducing opportunities for error.
Working in development teams helps us adjust to the inevitable ebb and flow of work that any service business experiences. It also provides an environment where each individual developer can do his or her best work. We think it’s the best way to manage Work in Process, and we recommend you look for a software partner who operates in a similar fashion.
3) How does your agency deploy code from development to production?
People are often surprised when we say this, but the biggest source of risk in a software project is often when the code is moved from the development environment (the computer where the developer coded it) to the production environment (the server where the code will “run” during use). This process is called deployment. You want a software partner who practices automatic deployment versus manual deployment.
We have found that manual deployment increases the risk of data loss and corruption. Even in the best cases, it often requires costly engineering time to meticulously work around discrepancies between the development and production environments. Many times, only the developer who coded the software has the knowledge to overcome these discrepancies. If that developer is not available, the project can’t be deployed until he or she is. A bottleneck like this can cause a world of hurt when it comes time to go-live.
As we’ve written elsewhere, automatic deployment tools avoid these headaches. They allow development agencies like ours to work in uniform development, testing and production environments, so potentially damaging discrepancies are eliminated from the start. But more than that, they allow for “continuous delivery” of code into any environment, even a “live” production environment, without affecting uptime.
Your software partner can deploy your new site or application instantly and flawlessly, as well as roll out and test new features at will. Want to test a new feature or a special offer for a few hours? Turning them on and off is easy.
Remember: Automatic deployment. Ask for it by name.
Learn more
If you are actively seeking a software solution to deal with a problem or expand on an idea, schedule a free consult with our team and we will walk you through the process personally.