How a Software Development Project Can Get Dragged Out Indefinitely

I had a conversation recently that was related to going 2 years over the proposed timeline. The question that I was asked was, “how does this even happen? How is it possible to go a couple of years over the proposed timeline when building software?” My response was, “it’s a lot easier than you think.” I went through a couple of scenarios with this group and I think I’ve finally made my point. I wanted to list out some of the key-points of our discussion.

No Requirements

One of the craziest projects that I’ve ever worked on was with a company that stated, “we don’t want to provide you with any requirements. You’ve built this type of software so you tell us.”

Every time any questions arose, the response was always the same: “you tell us. We’re not here to guide you.”

There are many areas of the business that the software development company just does not understand about your business. If, for example, you’re building an e-commerce application for a particular business, there are some basics that can be assumed. There are other things that can’t be assumed. For example:

• Where are you required to collect sales-tax from?
• How are you currently keeping up with nexus requirements? Both economic and physical.
• How do you charge freight currently?
• Do specific accounts require specific freight-carriers and specific shipping methods?
• Is this application going to be communicating with your on-prem application for inventory management or is this something that you’re going to manually keep up with?
• Do your customers have tiered pricing? Do you want those displayed on the website?
• Do you ship overseas?
• Which currencies are required to be displayed?
• Do you want to do real-time FX conversions?
• And so on.

An extremely bizarre way to approach a software agency, but I’ve seen it first-hand. That agency must be laughing each time they get up.

What happens towards the end is that the agency is forced to make assumptions. When those questions are now raised from the company, well those are all out of scope. The project timeline drags on and the software-development agency takes you for everything you got. It’s not their intention, but it is a consequence.

Not Wanting to Work with a BA

I’ve had clients that did not want to work with a Business Analyst. When speaking with them, we notified them of what the BA’s role is. They rejected it and instead wanted to work with a UI/UX designer.

Okay. Here you go. We’ll bill you at the rate until you’re happy with the designs. After about 6 months, the company came back and stated that they’re now happy with the designs and wanted to ask when we could have them built. We looked at the designs and stated that there was not enough information for us to begin just based on the designs.

Client: “What do you mean there’s not enough information?”

Me: “There isn’t. We don’t know anything about what the action on this button, for example, is supposed to do.”

Client: “Well this is what it’s supposed to do.” (proceeds to go on a rant).

Me: “That’s fine. We’ll need to capture all of those requirements during a requirements gathering phase. That’s where the BA comes in.”

The thing is, we tried educating this client but they refused. So now, a project that should have taken us about 1 to 2 months to complete UI/UX for, has taken 6 months + an additional month of requirements gathering. The backend was significantly more complex than what they believed.

Go through the BA process. It’s well worth it.

Hiring Their Own Project Manager

I love it when companies bring in their own project managers and refuse to work with the software development agency’s PM. There’s a process for a reason and the software development agency will use their PM regardless. The PM might not be client facing in this situation.

As long as the client is willing to pay for time and material, the software development agency will take the money. The client is actually putting a lot more work onto themselves for taking this route, especially if they’re not collaborating with the software agency’s PM.

And guess what happens. The client is constantly out of scope. There are too many assumptions that can easily occur and the developers are not there to call out out-of-scope work. They’re not trained in that process like a PM would be.

If you’re planning on taking this route, and you should have your own PM, make sure that you’re working with the software development agency’s PM as well. It will save time and hassle and if done right, can actually complement the team that you’re working with.

Conclusion

Projects can quickly spiral out of control. Most clients don’t know what an MVP application is, let alone how to approach it. The agency that you’re working with will gladly take your money for indecisiveness and the pursuit of perfection. Work with the agency closely to keep them in line, but know that they do have some quality individuals working for them that know their stuff; particularly take advantage of the PM and BA roles.