IT Projects: It Takes Two To Meet A Deadline
Or, what can be done from the customer’s end to help an external provider achieve on-time delivery?
Developers have a bad rep, at least according to the articles that pop up on Google’s front page when you search for “deadline violators.”
However, as the saying goes, “it takes two to tango” — and in this specific case, “it takes two to meet a deadline.” As a provider at the forefront of numerous coding projects large and small, Sibers has some tips to share that we’ve gathered while building a strong reputation for meeting deadlines. These tips will focus on what the client can do to help overcome problems and simplify cooperation.
Over the years, we’ve worked on more than 1,700 projects. From this respectable sample, we’ve pinpointed the most common delay-causers:
- The provider wasn’t aware of intermediate deadlines, i.e. investors’ meetings where a product had to be shown
- The project goals were unclear or easy to misinterpret, especially when the materials documenting the project did not reflect all the requirements
- Time allocation was estimated over-optimistically and risks were not assessed properly
- Communication problems from both sides: the provider failed to report progress, or the client took too long to provide feedback
Taken at face value, this list can be discouraging. But despair not! The following tips can help transform this into a “how-to” list, turning potentially rough waters into smooth sailing.
Don’t forget to inform the provider of your internal deadlines, especially if the product needs to be shown/demoed periodically. Also, we all know the devil is in the details, so make sure every detail is covered. For example: if the product needs to be showcased for investors, the initial focus should be on budgeting; if it needs to be shown to beta testers, the initial focus should be on getting useful feedback, and so on. It’s all about prioritizing the work so your internal deadlines are met. You don’t want to start with the entire database backend, when all you really need to show is a pretty UI.
In sum: if you have obligations to share samples with investors/upper management, talking to your provider will help to a) minimize overhead, and b) focus on the right things at the right time.
Bad news for all you ESP believers out there: even the best providers can’t read the client’s mind. As such, all app-related details should be laid out from the get-go, even the trivial ones. Without a thorough breakdown, the provider can only deliver what is agreed upon. If more features must be added later, additional man-hours will be added to the original estimate. In some cases, entire sections of the project might have to be redone because new demands have rendered them incompatible.
What you want is not the only thing that’s relevant. We also need to know how you want it. Let’s say you want a news list: the developers make a list with 10 news items per page, arranged in chronological order. At a later date, you explain that what you actually want is something akin to Twitter — a different beast entirely.
When estimating a project, it’s wise to add a buffer that covers unforeseen problems and touch-ups. Even when all goes smooth, some extra time for polishing is what turns a good product into a classy product. Learn more about classy apps from our recent blog post Functionality vs. Classy: The “90/90 Percent” App Rule. A good rule of thumb is to factor in a week of polishing for every month of development. In a similar vein, if the provider is working with pre-existing code then some extra time will be needed to squash compatibility bugs.
Also, account for the App Store release date in advance: for example, if you want your app on the store by September 1, be ready to deliver by August 15. It could take Apple a few weeks to make sure your app qualifies.
Finally, after the product goes live, it’s common to tweak a feature or swap one feature for another. As the project’s scope grows, so too does the initial estimate. The more prepared you are in advance, the better!
For further insights into the estimation process, see this recently-completed whitepaper: Software cost estimation: What factors are key in IT project estimates?
Communicate! It seems obvious, but it bears remembering: the most efficient way to ensure excellent results is to have consistent dialogue with your provider.
To this end, Sibers uses the agile system: every project is divided into phases, and on a daily basis our Developers and Project Managers discuss their progress and any potential obstacles. Sometimes, this means approaching the client. Be ready for this, and do not hesitate to contact the provider if you have a question of your own.
The more the whole team communicates, the more everybody will be on the same page. The ultimate goal is no missed deadlines.
This piece is not a “he said/she said” critique of shortcomings from the client or provider side. Rather, it’s an explanation regarding how the development cycle works and how it takes two to meet a deadline. Following these tips will save time, stress, and money on both sides, and ensure a mutually-beneficial collaboration with an IT provider like Sibers.