Request a Demo

STEP 1- Choose the Software


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

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

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!

Delivering a Large Project in a Small Company

Delivering a Large Project in a Small Company

Delivering a Large Project in a Small Company is no small feat.

When it comes to software projects, smaller companies typically don't have a lot of resources to work with and are forced to do more with less.

This is true for all aspects of the project's life cycle, from requirements and development to testing and project management. We are currently working on a project to re-write CampWare, our accommodation management application, as a web app.

For better or for worse, we have decided that this project will be a success, and this is how we will get there.

1 - Client involvement (or a good subject matter expert)

You have likely heard this at least a dozen times, but it is so important that it bears repeating.  Often, the difference between a successful project and a failed one is having good client involvement throughout the project. Developers need timely responses to questions about business processes, as well as feedback regarding user interface decisions. Without a good subject matter expert to provide guidance, developers are forced to 'guess' what is best for the product, and this almost always leads to trouble down the road. For our project, we are very lucky to have both a very involved subject matter expert as well as a BA that can transform complicated business processes into concrete requirements we can use.

2 - Assembling a good development team

One of the best things going for our project is that each one of us has our own area of expertise. James keeps us all in line with regards to best practices and code clean-ups. Tibor is our subject matter expert in all things Angular. I bring web development experience to the table, Shadi is a pro at creating Angular components, and Justin is a wizard at styling and end-to-end tests. We all teach each other, learn from each other, and play off each other's strengths. That's how any good development team should be built.

3 - Supportive Management

Having a supportive management team leads to more open communication of issues - and there will ALWAYS be issues. When they are properly communicated, management may be able to help, or at least ease the burden. For example, early in the project we struggled with meeting deadlines due to delays involved in learning a new technology.  To help us, our managers brought in a technical lead, and that has made a world of difference to the project.

We still have a long road ahead of us, but the product is starting to take shape with each passing milestone. As our technical lead says,

"We are doing ok, as long as nobody quits!"

Connect with me on LinkedIn