Project estimation is one of the most difficult things that falls under the responsibility of  development team leads and project managers. Successful estimation requires mastery of an imperfect science where past performance does not always reflect future results. I’m sure that sounds familiar, especially if you’ve ever met with an investment advisor to plan for your retirement or have done any of your own independent work in investing. The truth is that planning project work and providing accurate completion estimates is every bit as difficult as successful investing.

 

Just like the ever-changing global market, every project comes with a new set of variables that were different than the last. Projects include both familiar and unfamiliar technologies; business requirements with varying levels of completeness; varying priority depending on the targeted audience or business focus; development team members with assorted levels of experience, skillset and domain knowledge; greenfield and brownfield requirements for internal, external or inherited applications; and varying involvement from 3rd Party development teams that might include consultants, corporate partners, offshore teams or all of the above.  Development leads must carefully weigh all project variables and apply experience, discipline and judgment to arrive at estimates that are not only accurate but attainable. Agile project management makes things a bit easier (if done correctly) by providing a framework for allowing teams to plan work in small 2-3 week increments rather than making an attempt to estimate the whole project at once. Agile also provides a means for teams to identify problems and impediments early in the development process and increase their visibility among interested parties hopefully resulting in earlier resolution. Agile helps, but it’s No Silver Bullet.

 

In my experience, the most difficult of all project variables to account for is involvement of 3rd Party development teams or work involving a 3rd Party application purchased by your organization but maintained elsewhere. Over the last several years, I’ve encountered these situations time and time again. And I’ve finally decided that I’ve learned a hard lesson for the last time when attempting to estimate this type of work. Historically my estimates have been entirely too optimistic. In the future, they won’t be… My past experience will lead me to provide more pessimistic estimates and maintain a heightened awareness for uncertainty whenever 3rd Parties are involved.

 

3rd Party Applications

This is probably the most common type 3rd party involvement you’ll encounter throughout your career. These applications exist in an organization because they solve a problem in a very specific problem domain or because your organization lacks the time and resources to build the functionality from scratch. Nevertheless, you will find yourself having to extend these applications or integrate them into your existing enterprise architecture. If you don’t own the source code, it will be almost impossible to debug. Adding ASP.NET Tracing where possible will help and so will Red-Gate’s .NET Reflector. If you or your company can spring for .NET Reflector Professional Edition, it will provide a means for decompiling the assemblies for debugging. Depending on your project, this could be worth every penny…  When estimating work on external applications, DO NOT take the vendor’s word on how easy it is going to be to extend the product or add a plug-in component. Remember that they already sold the application to you or someone else at your organization and will probably try to sell you something else if they can. You’ll probably get a lot of pressure from product owners for a quick turnaround on additional features, but remember the speed of this type of work depends solely on your knowledge and familiarity with the application.  Use your best pessimistic judgment in estimating and evaluate the product as closely as you can before attempting to implement or extend it. If the vendor doesn’t have good documentation or available consulting services to aid in your project, don’t bother until you can get at least one or the other.

 

3rd Party Development Teams

Working with 3rd Party development teams produces its own set of challenges… One major challenge, but one you’ll have the most control over, is communication barriers due to differences in  time zones. The farther away you are from other developers on your project, the harder it will be for effective communication. Skype, SharedView and schedule flexibility among all parties are essential in reducing communication friction. Other issues that will most certainly arise are conflicting views on technology, performance, scalability and application quality. There’s really only one right answer here – whoever is funding the development wins. The entity funding the project has the responsibility of ensuring 3rd Party teams adhere to its rules regarding performance, scalability and quality and not what the 3rd Party teams are historically accustomed to or immediately capable of producing. Anticipate this problem as the length and scope of the project increases. Lastly, I want to comment on an item that should be considered when involving 3rd Party development teams although there may be little or no way of directly controlling it. Differences in compensation and performance incentives depending on the organizations involved will surely result in differing focuses from participating development teams. In a perfect world, all participating parties are incentivized according to the project quality, ability of the team to meet deadlines and overall project outcome.