How to hire a contract/outsourced architect for

Question

The company I work for has a legacy application that we are looking at rewriting and enhancing using more modern technology. We are a very small company (5 people) and do not have the resources to hire a full time permanent architect so we are looking to hire an architect as a consultant for a short term (about 6 months) engagement to help us design the software and then we will take care of (or use additional staff augmentation) of developing based on the design.

We have compiled a list of general high level requirements as well as some other lists of more specific functional requirements.

How feasible is what we are trying to do? What kinds of information should we have prepared so that we can provide enough information to potential candidates for them to determine if they will be able to come up with a design for us that we can take over and develop from? What should we ask for from them to base our hire decision on?

Answer 1

Yes, it's feasible -

Start with the domain of the application and a high-level description. Any reasonable consultant should be able to tell you if he/she can help in about five minutes.

Talk to several candidates, and throw out any that you don't like, aren't comfortable with, don't understand clearly, or for any other reason do not like.

Look at the background and track record of the remaining candidates; Google them. Check them out on LinkedIn. Talk to some of their past clients if possible. Make sure you are confident in their abilities, that you like them, and that you are excited about working with them

Then do a feasibility analysis with your shiny new consultant - limit the time/cost up front, and define exactly what you want him/her to produce. This will inform a preliminary design and establish the working dynamic among the consultant and the team. Agree on structures for production, payout milestones, team dynamics, authority, system access, and anything else that will make it easy and enjoyable to work together.

If at any point you become uncomfortable with the consultant, confront them about it immediately. Make an effort at mutual understanding to get back on track and in the comfort zone, but if you can't then fire them early and quickly if they're not working out.

Do not make a long-term commitment. Be extremely leery of consulting firms that offer to do 'free' RFPs and analysis and proposals, because the backside of this is generally a long-term contract commitment - before you know exactly who you will be working with, and if you like them.

Good consultants (and contractors) understand that every day is an interview.

Answer 2

Be careful making a selection.

I have worked for companies in the past that have brought on consultants to do architecture and design and every time it was a complete and utter disaster. Most of these places have awful talent and canned solutions that they try to shove down their clients throats even if the architecture or design they propose really doesn't fit into their model.

Its a risky choice and if it were my company I would take my chances with a design or architecture that came from my talent within the company, even if it isn't cutting edge.

Answer 3

I am on the opposite side of this coin. I am leading a team of developers working on a large re-write / upgrade of a companies legacy application. When we were brought in 9 months ago, the company had a list of general high level requirements as well as some other lists of more specific functional requirements along with UI mock-ups.

But as we progressed, I learned that everything that was provided to us were more guidelines rather than hard functional requirements. It took six months before we even understood the business and could actually see what the company was really doing with their application and their line of business. In the first six months we built an application that was an utterly complete failure. Luckily we were able to circle back around and abandon that application and take a new approach using the knowledge that we had gained from both the prototype and from the knowledge of what worked and what didn't.

Right now we're in our third month of development on the second try and we've made larger advances now than we did in the prior amount of time.

My suggestion, look at a long term engagement with someone who not only take the time to watch and listen to what the business is but how business is actually conducted. I have found that internal developers/project managers/ and staff can't see beyond what they do on a daily basis and miss a lot of the larger picture. New eyes will reveal things that have gone on for years without being thought of or documented. When getting ready for the actual project kickoff, think of it as a series of short iterations. Get something out the door and get feedback on it as quickly as possible to validate the idea. As the iterations accumulate the real requirements will start to show up.

Good luck and hope your company succeeds in with their new direction.