Over the years, I’ve been lucky to establish strong relationships with a number of highly skilled contractors. So Brian McDonough from oDesk interviewed me to find out what I think makes a contractor great. I think it’s an interesting article and one that’s relevant to me personally in my role as a consultant.

http://www.odesk.com/blog/2011/05/finding-the-right-long-term-contractor/

Business Solves Unique Problems With Unique Software

First, make sure you define your project with the right people. In the beginning of this project, I was working based on a series of conversations with my client’s top executive. The top executive and I were on the same page, but the two directors were confused about what the project was doing. When I re-defined the project with the three of them together, we all started working towards the same goals.

Secondly, pick the smallest team that can be effective to meet your goals. This client has a very strong team based culture. While this leads to a high degree of staff empowerment, it also sometimes means that everyone expects to be involved in every decision. Knowing that previous projects had become bogged down in this bureaucracy, we comprised our core team of the strongest subject matter experts available. As we worked through various components of the system, we pulled in additional resources where necessary and made sure all the team members were communicating well to their colleagues. This allowed us to move rapidly through requirements definition, application testing, and finally projet approval.

Third, make sure you have clear expectations for your team. This may involve teaching your team how to do their work since they may not have participated in a similar project before. Even worse, they may have participated in a similar project that didn’t function well and have developed bad habits. On our team, we stressed that the team members were not expected to know everything. But they were expected to know who needed to be involved in each piece of the project and to pull those people in as appropriate. They were also expected to keep their supervisors and colleagues informed about project progress and to use their supervisors and colleagues to help resolve any issues.

Fourth, it is imperative to get the right technical skills on board. In Billings, there is a serious shortage of experienced programmers. So we used remote programmers through a service called oDesk. I managed the requirements definition, communication with the programmers, and primary quality assurance. This ensured that the client’s staff on the team were focused on their responsibilities…the functional aspects of the system. The approach allowed me to tap into the global talent pool to find the right skills, and helped my client keep development costs under control.

Finally, consistently confirm your understandings of your projects priorities (Cost vs. Time vs. Scope). In this case, the client strongly preferred a consistent monthly cost and a full set of application features to delivering on a specific date. As a result, we moved a little slower than was technically possible. When we had to adjust the schedule, I confirmed again with the client that their preferences had not changed. In the end, we delivered within a few weeks of our best estimate (on a 14 month project) and the client was very satisfied.

Most of these learnings weren’t necessarily new to me and they may not be new to you. But looking back, they were probably the key items that made the project successful. Hopefully, they’ll help you in your next project.

But I recommended they hold on the custom development.  They needed to evaluate MS Sharepoint’s capabilities before proceeding.  Why?  The basic corporate intranet portal has been built 100+ times already.  Sharepoint, Plone, Liferay, JBoss, DotNetNuke and many others are decent out-of-the-box foundations for an internal site.  So there’s just no reason to pursue custom development for this type of project. 

But why Sharepoint?  This client is also upgrading their core enterprise system.  Turns out that the system based on a MS platform and uses Sharepoint for document management.  Doesn’t it make a lot of sense to evaluate whether or not the platform used by your core enterprise system will work for the rest of your needs as well?

Right now, they seem to like Sharepoint and we’re now doing a test project to prove it to the company.  If the test fails, there are other options.  But custom development for an intranet should be a last resort.

I have a love/hate relationship with MS Access.  Way back when, I spent a lot of time doing Microsoft Office development and Access was a favorite tool of mine.  I liked that I could easily hook up to the enterprise databases, pull the information I needed and integrate it with any other application I happened to build. 

But people who do Access development full time tend to get trapped into that box.  When the task becomes greater than the tool, they simply find ways to make it work.  And that leads to problems.

Nowadays I spend a lot of time supporting an Access database that has outgrown its skin.  I’m rebuilding the application with a SQL Server back end, and ASP.NET and Sharepoint on the front end.  But it’s a really slow process because there are so many business rules hard coded into the VBA.  Identifying the code that has to be there versus what was done inefficiently is a real chore.  And all the while I spend time helping users through crashes, data corruption, and reports that aren’t tying out.

So, here’s my advice of the day.  Use Access.  Or Dabble or Zoho.  They’re great tools and fill a need.  But when you need more than a couple users, have rigorous security requirements, need sophisticated data entry forms, or have complex reporting needs, it’s time for a different tool.  Don’t put this off.  Your application will only become more complex over time.  And you’ll end up spending a lot of time and money supporting the application instead of improving your business.

So what does this mean to you, a business leader at an SMB? Well, I’m not a professional software developer, and I don’t try to sell myself as one. I focus on the business processes and then I find the right technology that will enable process improvement. I need to do my work in a way that does not box me into one potential solution. After all, if you hire an Access guru, you’re going to get an Access database no matter what solution will work best.

Once I understand your processes and can help you identify opportunities, I need to be able to quickly produce solutions that meet several criteria:

• The solution must fit in your environment with minimal additional investment,
• The solution must be able to scale with you as your business grows.,
• You must be able to use the solution without constantly calling me back for (billable) assistance, and
• If you do require additional assistance, you shouldn’t have trouble finding someone to support you should I get hit by a bus or win the lottery and retire.

Here’s an example. I needed to develop a multi-user application that would read data from a database and would write information to the client’s intranet. One of my client’s main concerns was that the application operate quickly. The client has no internal IT staff, and their intention to rapidly expand the scope of the application meant that distributing an application to PCs of the users was not a great idea. The database was MS Access, and the intranet was built on Windows Sharepoint Services.

A web based solution made sense for obvious reasons. I had never gotten much real-world experience with AJAX but the ability to process transactions without full page refreshes would certainly be appreciated. In a couple hours, I had built the required pages using the ASP.NET AJAX toolkit. We are now extending this application, and what I was able to produce in those few hours has enabled the client’s staff to think completely differently about their processes. Not only that, but the client is now moving their data into SQL Server 2005 Express. This application is remaining virtually untouched.

I certainly keep my eyes open when designing a new solution. If a client already has a significant investment on a LAMP platform, I’m certainly not going to recommend that they implement Sharepoint for document management. But more often than not, I find the client already has the environment in place to support a Microsoft approach. And I know that there are 20 other people in town that can pick up right where I leave off when my numbers come up!