communication, realistic approach

Question

I work for a mid sized Architecture and Engineering firm, our sub group focuses on developing tech solutions for engineers, mappers and technical managers. So we're heavy on desktop based apps for GIS and Civil/Env Engineering (some web). The company sells the services that our Engineers and mappers produce and our team develops tools that aids in them being more productive, efficient and help in adding value to their decisions and products, we DO NOT sell the technology.

We are going through growing pains where initially we used to be extremely responsive and could rapidly prototype apps for engineers which immediately brought budgetary savings. That mindset has worked for us in the past. But this year we won a huge contract and our client base has basically quintupled (5 times?). What we are finding is that this rapid prototyping culture is hurting us, where project managers have started to expect short response times for tool development and robust production ready tools for all our engineers and GIS analysts. We've grown organically and now it seems that we are running into these issues were it appears we have to scale back our speed for more stability.

Is this a legitimate tradeoff? Is there a win-win? How does one push back the engineer, project manager and analyst when they are our clients, they fund us and yet we need to be able to push back and tell them that if they want stability they have to be realistic about time frames?

This isn't Microsoft Word, these are specialized GIS software and Engineering models with a ton of interop components for other industry standard models, they aren't idiot proof tools, they need informed inputs and we can only test things so much.

Has anyone dealt with similar growing pains? Recommendations/advice on a communication stance, books, blogs?

Answer 1

First of all I think the basic idea of quick development and delivery is fine and if you can keep it then great, do so (it is the gist of the Agile Movement).

Question is why you have problems now? Is the problem that you cannot deliver as fast because you have more clients to share your time? Is the problem that the new employees cannot produce new code fast enough?

My personal guess is that you've found that "talent doesn't scale" and that you now have too few experienced programmers to do what you did before for more clients.

---

EDIT: If so, you need to acknowledge this fact, as it is impossible to throw additional people at the problem to keep the scaling (Brooks's law). Your experienced people will need to mentor new apprentices, and that will take some time.

Answer 2

This is basically a management problem, not a software problem. You will need to hire some more people to handle the new demand. You will probably also start having to build a QA team, at least informally. Depending on your product line, continuous integration & continuous unit testing might be feasible.