';


Request a Demo

STEP 1- Choose the Software

ILLUMYSCIRYSCampWare

Delivering a Large Project in a Small Company Part 2 – Keeping Costs Low

After my last blog post on 'Delivering a Large Project in a Small Company', I received questions about some of the things our company is doing to reduce costs in developing software with the limited resources of a smaller business. Here are a few key strategies we have used to keep our costs and overhead low, while delivering a high quality product.

Keep the team small and agile

According to the law of diminishing returns, each person that is added to the project adds less and less incremental value to the product as communication has to increase. For our project, we have 5 developers, a database analyst, a subject matter expert, and a business analyst.

Keeping our team small has allowed us to keep the project agile. We are able to quickly re-evaluate when we discover better ways of doing things.

Being part of a small company also allows us to avoid relying on multiple departments to complete our product. We don't have to deal with conflicts associated with internal politics which can often hinder projects in large companies. Small companies typically have fewer departments and groups to collaborate with, which saves time and money on the bottom line.

Don't harass your developer team

Easier said than done. If your project is important to the success of your company, leave your developers alone to do their work without drowning them in meetings, emails, and distractions.

For our project, we have a 15-minute daily scrum to communicate, go over progress, and discuss potential issues. That's it.

Keeping developers out of the day to day tasks, such as support issues, random pet projects, or endless meetings ("just in case we need to consult you"), allows them to focus on getting the work done for the scrum deadline. Having a focused and single-track developer team is absolutely crucial to meeting deadlines and keeping the project on track.

Project manager?  What project manager?

As I mentioned in my last blog post, we have a small team. We don't need to consult with a lot of internal departments, and the project has the support of our management team. Because of this, we do not need the help of a project manager to move the project along.

According to the Project Manager Institute, a project manager will cost about 7-15% of the project cost.

This is a significant cost savings to our project, and also helps to keep our team small and agile. Keep in mind that any project will encounter barriers such as hardware issues, learning curves for employees, etc. Typically it is the project manager's responsibility to address and remove these barriers. Since this project is so important to our business, our higher-level managers remove these barriers for us. This strategy only works for us only because our managers are willing to step up and advocate for the project. If you have a management team that is busy or unwilling to make the project a priority, you are much better off hiring a project manager.  Otherwise the project team will be stuck dealing with non-development related issues, which impacts both timelines and morale.

Automated Testing

For our project, we are implementing both unit tests and end to end tests. Implementing automated testing is a long-term cost savings. It requires a larger time commitment up-front to implement, and also requires buy-in from all the developers or the strategy will fall flat (as we've had to learn the hard way a couple times).

As the project matures, the cost savings from the automated tests are being realized.

With help from the automated tests, we are catching bugs before our managers see them. This will save us money down the road when supporting the project after release. As well when onboarding a new team member who may not be familiar with the product.  Thanks to our automated tests we don't have to employ a designated tester, which also saves money.

These are a few specific ways we have been able to keep our costs low without sacrificing quality. And in some ways our project has just been 'lucky'. For example, we haven't had much employee turnover in the duration of the project that would have slowed progress. I wouldn't recommend these strategies for every situation each project is unique, but so far they have been working for us!

Leah is a software developer at Gemstone. She enjoys the complexity of large development projects, especially when they allow her to learn and experiment with new technologies.