Software development is a risky endeavor, with many things that can go wrong. At any moment, you may find that your budget or schedule targets have been completely missed and your developers and customers disagree about the scope and functionality of the project. In fact, numerous studies state that up to 60% of projects completely fail or massively exceed their budgetA recent study by McKinsey found that on average, most software projects over $5 million exceed their budget by 45%, turning that $5 million application into a $7+ million application.  As responsible software systems developers, we have to constantly ask ourselves – how do we prevent this from happening to our projects?  The answer is to reduce risk. Read More…
Dynamics CRM 2013 is about to be released and if you have already made a large investment into SharePoint as a development platform, you may be asking yourself why Dynamics CRM matters.  After all, you are already using a wildly successful platform that underpins collaboration tools, intranets, your ‘corporate’ social media and quite likely a base of custom applications and tools. Why would you need yet another platform if SharePoint is capable of handling everything you throw at it?

First off, let’s clear up a misconception that everyone generally has the first time they hear about Dynamics CRM: it’s not “Dynamics versus SharePoint,” it’s “Dynamics AND SharePoint.” Dynamics CRM offers some pretty significant benefits that are not available when using the SharePoint platform alone. Likewise, SharePoint has capabilities that Dynamics CRM simply wasn’t designed to even begin to replicate. The trick is knowing when and how to best leverage the benefits of each tool. Simply put, both tools need each other to offer a truly complete platform that offers you the best of everything: a collaboration tool, an intranet and content management tool, a repository for unstructured data, an application platform, and a quick and easy way to rapidly and efficiently build applications to manage structured data. Read More…

Technology is advancing rapidly, and with its advance comes new and useful ways to complete everyday tasks. In this post I’d like to talk about some of the benefits of replacing the paper- or desktop-based ways of an employee whose job is performed primarily in the field. (Home health workers or field service technicians, for example.)

Quality custom software that’s designed to meet the specific needs of a business is easy to adapt and should have minimal adoption time and training costs. Workflows that are built according to an employee’s ideal task flow should encourage thorough service calls and better communication flow in all directions.

As an employee who may have to make several service trips per day, mobility is essential. Paper can be completely eliminated, pictures no longer lost or need to be transferred by media card, forms can be filled out by simply speaking into a microphone and tapping on some check boxes. Signatures can be captured easily just by swiping a finger on a screen, bar codes can be read and captured. The possibilities for becoming more productive are expanding each day. Read More…

In order to meet ever-increasing customer demands and compete on a global scale, many organizations need to be able to fold new systems and/or new features into existing systems quickly and cheaply. These organizations — and perhaps yours — have portfolios of existing systems and infrastructures that were implemented literally decades ago.

These “legacy” systems, while well-architected for the demands and market conditions of the past, have often become increasingly complex through the years and more costly to maintain. What’s more, these systems are based on technologies that simply don’t provide the flexibility and disciplined agility that modern programming languages and frameworks can. Read More…

N-tier development is not a new methodology. I remember learning about it in 200-level courses back in 2000, and I used it in ASP.NET development before I jumped on the SharePoint bandwagon. However, one of the things I’ve noticed over the years as a SharePoint developer is that most project development is done in the SharePoint object’s code behind or a few helper classes. This isn’t always the case —sometimes the solution isn’t complex enough to warrant a tiered approach (i.e. a single Event Receiver). But a recent project highlighted the power behind N-tiered architecture.

The client has a custom solution that they provide as a service: A master document (Microsoft Word) is split into section documents (also Word) by a project manager. Each section is assigned to a person to be modified in Word (the client also provides a Word plug-in for this modification). Once the sections are properly marked up, the master document is recreated from the sections. We were brought in to implement this solution in SharePoint 2010. Read More…