Frequently Asked Questions, Part 2: Project Timelines, Change Control, and Red Flags

In our last Q & A post, we addressed questions about SOWs, cost, and budgets for custom software projects. Today, we dig into how long your project should take, how to handle project changes, and red flags to watch out for.

Here we go!

How long should a project take?

As you can probably imagine, the answer to this question is, “it depends.” There are a lot of things that impact the time it takes to develop custom software, including:

• The size and complexity of the application—Does the app do one thing or is it a full-featured platform that does 25 different things?
• Clarity of the goals of the project—Do we need to spend time up-front clarifying the desired outcome or is it well-defined going in?
• Clarity of the application’s features—Do we have a 30,000-foot view of the application’s requirements or a 3,000-foot view?
• The size, experience, and availability of the development team—Is the developer a free-lancer who works off-hours or do you have a team working full-time? How much relevant development experience do they have?
• The availability of the client to participate—How available are you to collaborate with the developer? Can you respond to questions within 24 hours or could it take you two weeks to get back to them?

For custom software developers, no two projects are exactly the same, so it’s pretty hard to say how long something will take at the very beginning of a project. That said, experienced developers should be able to give you some idea of how long your project might take within a fairly narrow range. Even when you’ve been given an estimate, though, it’s wise to remain flexible. There are always unknowns going in to a custom software project—always. And those unknowns can derail a timeline in a hurry.

If timeline is an important consideration for you, there are ways to accommodate it. You’ll just have to be flexible with your scope. Understandably, shorter timelines typically mean less—and/or less-complicated—functionality can be developed in the allotted time. We always recommend clients prioritize functionality based on value, developing the most valuable features first. But it’s especially important when the timeline is tight.

What if I change my mind in the middle of a project?

This is a great question, but I would amend it slightly to say, “What happens when I change my mind in the middle of a project?”

Except for the very simplest of applications, there’s a 99.999% chance you will change your mind about something during the course of a custom software project. It happens all the time and it’s one of the primary reasons so many software developers use the agile scrum framework. Scrum is designed specifically to increase responsiveness to changing requirements. Working in short sprints allows the team to continually reprioritize functionality based on value, ensuring changes can be absorbed more easily.

So, if your developer uses scrum, changing your mind shouldn’t be too big a deal. Note, though, that it may impact the overall cost of the project.

If your developer doesn’t use scrum, they should still be able to adjust to mid-project changes. You’ll just want to understand what their change control process is, preferably before the project starts, so you know what to expect before the inevitable happens.

How can I tell if I’m being taken advantage of?

We talk to a lot of people who’ve been burned by software developers before. It happens more frequently than it should and it’s unfortunate.

The best time to figure out someone’s taking you for a ride is before you get on the bus. As you’re evaluating software developers, be on the lookout for the following red flags:

• They don’t ask about your goals for the project
• They don’t ask about the users of the application
• They can’t articulate the problem you’re trying to solve
• They talk over your head and/or are difficult to understand
• They don’t answer questions to your satisfaction
• They seem annoyed by your questions
• They don’t ask about your budget
• Their quote sounds too good to be true
• They don’t ask you to sign a contract
• They want full payment in advance

Investing in custom software is not a trivial thing, so it’s important that you find a developer who’s a good fit for you and whom you can trust.  Make sure they’re a good match for you personality-wise, that they’ve demonstrated they have the experience and expertise to solve your problem, they communicate frequently and in a way you can understand, they understand and are sensitive to your budget, and they have a clear understanding of the problem or opportunity you’re tackling.

Finally, make sure you’re seeing clear evidence of their work early and often, and that you have the opportunity to interact with the software yourself throughout the process.  We’ve seen too many cases in which unscrupulous developers have collected lots of money without producing anything except some mocked-up screens with nothing behind them. Armed with a little knowledge, you can avoid becoming a victim yourself.