They can be night-owls, they’re intelligent, usually well prepared for most situations, and can be the modern-day equivalent of factory workers; working long hours through the day to get something finished by a deadline. As much respect as I may have for our development team (and trust me, it’s plenty), there are a few things that I know they are not.
Even though any good technology is virtually indistinguishable from magic, they are not magicians. They are also not mind readers, invincible, or infallible. They’re human. Readers of this blog may be inclined to ask “why are you mentioning this? Everyone knows that software engineers are just human like you or I”. To that extent, you may actually be surprised to find out that people often seem to forget the simple notion that communication is key.
I’ve been in this business for over 2 years now. The one thing that consistently comes up as a point of contention between client and vendor is the requirements game. Sometimes it seems that if we give an inch, people take a mile, and that’s not fair to anyone involved; neither client nor vendor. At Studio Symposium, we take each project and break it down into very specific chunks, which each serving it’s own very important purpose.
The first phase of software development can, at times, be the most difficult. Obtaining the requirements from a client in order to produce an application or website that represents their vision as closely as possible. For example, if someone says “this is pretty much everything” when giving a run-through of an application idea or concept, a word of advice: it’s usually not, and the things that are left out of that “pretty much” can make a very, very big difference, and can make or break the process. We recently had a project carry on for an unprecedented amount of time simply because the requirements were never nailed down the way they needed to be. This can be viewed as a mistake from both sides of the deal, but the percentage of time that was spent by my team to discover the requirements (something they had to largely accomplish by reverse-engineering the clients existing software without so much as a PDF of the processes the app follows) amounted to a whopping 75% of the total time put into the project, which had gone, when all was said and done, about 400% over the original scope in terms of hours.
Having a project go over by 400% because of requirements deficiencies is an extreme case, I’ll admit, but it serves a purpose: get everything you can written in paper, drawn out, sketched on a cocktail napkin, signed, approved, sealed and delivered before you even start the user interface construction. If you can do that, you’re in a much more advantageous position to make everyone happy, including your team.
As an extension of the requirements game, you also have to make sure that any estimate, contract, proposal, or quote that you may write up serves to protect both the vendor and the client in a manner that both can agree on. Make sure you take the requirements game very, very seriously in proposals, and let the client sign off on the document knowing full well that any extra work not specifically outlined within the proposal will result in an extra fee. Else it’ll be a case of the goal post being continuously moved, and that’s not fun for anyone.
It can be a zoo out there, just know that your development team can be the ones who are able to navigate it the best. Consider taking care of them and what they need before anything else.
- Chris
