One big issue we strived to solve when starting P&D was to involve developers in the business analysis process. Pulling from our experience in the industry, requirements always seemed like a bad game of telephone. The business analysts would talk to the clients and users often through a series of tiring meetings or long site visits. Ultimately a pile of notes, thoughts, and sometimes written requirements make their way into a user story or some other kind of spec document which gets turned over to the developers. By the time work got started on a feature the requirements changed to a point of almost being unrecognizable. In turn, the feature that comes out of the other end is quite removed from what the client initially wanted.

The second serious issue we saw in industry was BA's who had little to no software background. While this can sometimes not be that big of an issue, the process becomes far more effective if the spec writer understands how software is actually built. With at least a cursory understanding of basic software methodology and architecture requirements can be written to be effectively and efficiently built. All too often we saw requirements asking for incorrect or simply impossible features that had no basis in something that could be effectively translated into software.

When the first projects came to P&D we decided to learn from the mistakes we had seen and involve our developers in the BA process directly. While some projects are big enough that we may utilize a dedicated BA resource to aid the team the overwhelming amount of work is handed directly from the client to the developer. After observing this for some time we realized even more benefits than initially predicted. We saw an immediate increase in how requirements were more accurately gathered and far more coherently written to drive development which ultimately pushed features faster. After some time we began to notice that this structure created a very open, bi-directional channel between the developers and the clients. Our clients felt as though they had a clear path to the people actually doing the work and the developers had a clear path to get important questions answered and make effective decisions.

Involving developers in the requirements gathering and business development aspects of our projects has helped us grow as a company while simultaneously helping our developers grow as employees. Our end products are delivered faster and closer to original specifications than ever before. Clients leave happy and well served with platforms that they can grow into for years to come.