If you are currently working with a software development team or are in the process of choosing one, then there are seven tips here that will help you avoid trouble.

I want to save you from unnecessary pain with project advice born out of direct experience managing and executing software projects for all types of companies. Let’s demystify software development projects right here and now and help you identify the seven tells.

What is a tell? If you play the card game of poker, you know that other players can give you “tells” about their hand strength and confidence based on tiny ways they behave. It is true in your business with development software projects. Some are subtle, but I know what to look for.
 

Tell #1 – Development team needs more time.

You believe you are getting the exact thing you ordered initially, and suddenly the development team says they need additional time. What’s weird about this is that nothing has changed from your business side or what you told them you wanted.

Most likely, the developer changed what they needed, which delayed the project because they did not ask you enough questions about your business at the beginning. It is a big red flag if your software design/development team is not crawling deep into your business with frequent questions. It happens more than it should.

Tell #2 – They say your project Is more complex than they previously thought. 

Your dev team tells you this after some initial weeks of work. It is your signal that they have a less than talented software analyst. A skilled software analyst would have caught the complexity of your project at the initial project scope and design. A great analyst might even challenge the core viability of your idea and run early models to stress-test, so you don’t waste money.

The team you hired could be in over their head.

Tell #3 – They tell you that your database has performance problems. 

The developer is blaming your database. “It’s not me; it’s you.” It indicates that your software team picked the wrong tool to solve your problem. It is an example of excuses that are hard to argue because you are not an engineer.

Tell #4 – Lack of regular communications from your software team.

You do not hear from the dev team very much, and when you reach out directly and ask them how the project is going, they say, “things are great, and we are on time.”

You should expect problems to occur on your project, as that is only natural in the build-out process. They might be the silent type because they did not ask you enough questions along the way; if that is the case, look again at Tell #1.

Tell #5 – There is no measure of regular status updates for your project. 

You should get concerned if you are not seeing basic metrics such as lead time for changes, deployment frequency, or the number of defects in the code.

Or if you are indeed receiving these reports, but the performance line items are declining over time, then you need to challenge the developer.

Tell #6 – Your engineer is replaced with a ’new, great team member.’ 

In this scenario, your contractor will have “the DEV A engineer” continue to review the code while remaining with the company. Then “DEV A” leaves the company. A fresh graduate from a “DEV B” school completes the final product delivery. It’s a common tactic within some outsourcing companies. They sell the best engineer to sign-up the client, and then the work is switched over to a junior developer much inferior to the original one.
.

Tell #7 – Minor software changes are deemed “Hard, or not that simple.”

For example, you may only have ten customers to apply the software solution to, but the developer says, ‘it’s not that simple to make the change.’ You ask for a small change, and there is fierce pushback upfront from your developer. 

It tells you that the software that the developer is building is more likely to be of inferior quality. It has terrible design and architecture and too many written premature assumptions about what it will be.

It is all about achieving a product market fit for the client. It allows the client to take advantage of new market opportunities. Software developers must iterate fast in a startup’s first 2-3 years. They need to break up the entire project into bite-sized pieces.

It is time to use your newfound powers, and the above software project development tells are your guide.

Now you are a better poker player. Or, in this case, a better software poker player. Use your newfound awareness to challenge either the process tracks your current developer is on or even to cash out of the game entirely and hire a more competent development team. The stakes could not be higher for your business.