Today in the world of business technology we have “managed” everything. Managed has become not just a buzz-word but rather a different way to do business. We see everything from managed services to managed switches and quite a few things in between.
When it comes to custom software development there is something else we need to manage; Expectations. At the heart of every custom software development is uniqueness which earns it the name “custom.” One of the most important aspects of any software development project is managing everyone’s expectations. Despite the importance of this, it is something which is often neglected.
1) Who is “everyone”?
Well it’s pretty hard to manage everyone’s expectations if we don’t know who is included in this group called everyone. Defining this is critical. Does Sally in marketing really need to have input in the warehouse management software you are designing? So you might say that’s an obvious no. But, what about the end-user of the software you are designing? Does every user need to give input or maybe just power users? Or, perhaps, it is only executives or supervisors who should be directing their input.
So that covers those consuming the product, now we have to remember those producing it. If the expectations of the end user is not in line with the expectation of the developer, then you can rest assured that there will be some changes needed in the future. Communication is what is necessary for these expectations to be aligned.
2) What Are The Expectations?
Again, this comes back to communication. Clear communication between all parties will result in everyone knowing and understanding the expectations. It has been said before that a failure to plan is a plan to fail. I’d say that expression holds true here.
I have been a volunteer firefighter for about 12 years now. Over the years I have seen calls that go really smooth and some that go not so smooth. There is one thing that is consistently true of every call that I can remember that went somewhere south of perfect. In all of those cases the call started badly. Maybe a critical piece of equipment broke down, maybe accountability was forgotten, or maybe no one took command at the beginning of the incident. A fire scene is hectic to say the least and there is a lot of room for error.
Software development may not be as hectic as a fire scene, but it is every bit as complicated and there are plenty of places where an error can occur. Starting a project with good communication, a solid plan, and detailed documentation will greatly improve your chances of success.
Some Practical Advice
Here are a few practical things I suggest. Take some time to really evaluate your needs before you ever bring the developer into the conversation. Make sure you explicitly define who this project will affect and more importantly whose voices are most important in influencing it’s direction.
When it comes to documentation prior to starting the project, I always recommend pictures. Sketch out on paper what you want the user interface to look like. If it’s a report, uses a spreadsheet or word processor to mock up an example of how you would want the report to appear.
Be specific about everything. It’s not enough to say, “I want an inventory on hand report.” When defining the project, specify that you want a report that shows all items with their item number, description, and current quantity on hand. And, I want an option to order the report by item or description, as well as an option to filter by item number range.
During your planning process it’s good to create a timeline with specific milestones in mind. When the milestone is reached, review the entire project from start to milestone and then review the remaining plan that is in place. If any expectation, whether past or future, is not being met discuss it and create a game plan to fix it.
Most importantly, don’t wait till a milestone is reached to discuss an expectation that is not met. Talk about problems early and as often as they arise.