Consultant - The Human Tool

As a US Government employee, I am constantly bombarded by contractors wanting to provide their services and vendors who are constantly selling me their Custom-Of-The-Self (COTS) products. Therefore as a US Government employee, it is my duty to determine if I need consultants and COTS products for some of my organization's strategic activities. As a goverment employee, my primary responsibility is to accomplish my organization's strategic and/or tactical objectives while managing to be diligent stewards of US Tax dollars. Anyway here are some thoughts regarding consultants:

• Don't let the consultants drive the strategy for your projects - The consultants try to couple themselves to your organization processes and try to you dependent on their services.
• Be up front - Tell the consultants what your expectations are of him and how his performance will be monitored and assessed.
• Monitor their perfomance - Hold them accountantable to the project schedule and demand deliverables to be met on time.
• Take ownership of the Spend Plan - Don't let the consultants manage the spend plan for you. This is a big no, no. Take ownership and decide how you want to mange it.
  
• Define and demand deliverables - Define the deliverables and when they should be delivered to you. Keep them accountable for the deliverables.
  
• Consultant Scope Creep - I call this when consultants are working with you to know your domain and they might try to expand the scope the deliverables and push the date back. This is not a good idea.
• Believe in a Reward system where consultants can be retained because their project were successful or show them how they can retained with their good work.

In the end, consultants are nothing more they glorified Enterprise Architecture Tools. The consultants will do what they are told to do within the context of the agency. Having good requirements on sort of consultants should be done by interviewers and sharp managers would thinking about their potential reuse after this project. The only problem with the consultants is they don't have a new version available. :)

Is Open Source bad?

Don't get me wrong. I love working with open source software. I love working Java, Php, Spring framework, Struts framework, Eclipse Integrated Development Environment (IDE), Spring WS, Junit, Hibernate, FileZilla, Mozilla's Firefox, log4j, Axis, JBoss middleware, etc., and etc. I am currently looking at Grails, JRuby, Seam, and on and on. The journey never seems to stop. As soon I am familiar with some software, it is either outdated or obliterated with a new software which runs on new principles but it is faster and addresses the issues with the software I just became familiar with. From a developer or an application architect's perspective, open source software is the way to go; however as a decision maker for a company, I would be leery to use open source source. Okay, Okay, let me explain. In my current position, I see resistance from my managers to adopt to open source software. Their reasons, which I think are quite valid, are that there is no support for the software, there is no evidence that it is widely used in the IT community, they haven't been tested well, and our company doesn't have enough people, who know how to use certain pieces of software.

As I said earlier, these are valid reasons however I believe companies should allocate some resources who track and evaluate open source projects. The committed resources should be composed of software engineers, software architects, business architects and analysts. Each open source product should be scored on:

• Maturity of the software
• Adoption in the software in the IT community
• Is support being offered by companies and what is the level of support
• Stability of the open source software
• and determine the software's competition in the IT community and how the software's competition is doing in the IT community

Once again let me reiterate that I enjoy working with open source software since I have time to read the source code and make modifications if the software doesn't meet my requirement. This is a lot better than spending thousands and millions of dollars to buy COTS products and then realize the software doesn't work or the company needs to spend another chunk of money in hiring high priced vendors for the product. I have seen this happen with products from Microsoft, Oracle, Convera, Autonomy, IBM, etc., and etc.

In closing, I conclude that open source software isn't the panacea but it can be close to panacea if the company has the right set of resources, a culture for innovation and a willingness to take a risk. I look at companies like Google which thrive on individual and group innovation. I however don't recommend open source software for companies where policies quite frequently, they cannot allocate resources in researching open source products and as a company at large, they are financially loaded. If your company is in between the two examples I gave then I say please do your research and hire the appropriate personnel and then PICK YOUR POISON!