The last few year have been terrible.  It doesn’t matter what industry you’re in, your education level or place of residency.  The latest economic down-turn has been rough on all of us.  However, there are signs of an upturn and you need to be prepared for it.  How do you position your teams to respond and meet the demand of your business?  Getting smart about outsourcing might be the key!

The next upturn is going to present a few realities that you will need to come to terms with.  The first, is that  your company has ‘right-sized’ your organization at some point.  Translation, you have less resources than you did before the bust.  The second is that the economy is starting to pick-up.  Translation, you will lose talent.  The third, and most important, is that your company will want to be ahead of the curve and implement technologies and products so that they can gain the most by the upswing. 

The challenge as an IT manager is how do you ‘ramp-up’ for the upswing?  You will face the challenge of fleeting talent as well as increased demand.  You need to develop a resource strategy that is scalable and forgivable.  So what is the solution.  Outsourcing.

Outsourcing is probably the one word that will have all IT pros see red.  I think it’s a natural reaction giving the recent experiences of most IT pros.  However, now is the time to leverage the ‘right-size’ outsource solution so that you can continue to meet the demands of your company’s IT demands and best position your team.

So what is this mythical outsourcing phenomenon I speak of?  It’s coming to the realization that you don’t have enough team capacity nor the time or energy to meet the current needs.  You don’t want to bring on full-timers that you will have to layoff  when the demand levels off, you owe your employees more than that for sure.  So now is the time to start to develop outsourcing relationships.  And make no mistake.  These arrangements are relationships. 

Develop Level 1 Outsourcing

Phase one of an outsourcing relationship is simple.  Get some contractors in that your team manages.  Not all firms love this arrangement, but guess what, the economy is tough and they will do it.  The benefit is that you can release or add contractors as your demand requires.  You don’t have to lay anyone off, and the vendors begin to learn what your standards are and what you expect.  You can also use this to see what the strengths and weaknesses of each vendor are.  I call this the ‘getting to know you phase’.  The main advantage is that you can increase the capacity of your team without having to hire an FTE.

Develop Level 2 Outsourcing

This level is a bit more challenging and requires you to have a level of trust.  You have gotten to know a vendor and now want to outsource a project because your team just does not have the capacity to complete it when the business needs it.  It is critical that you make this distinction.  This is not about cost savings, it’s about increased capacity.  Your team needs to have tight control, good project definition and good management in place.  When considering moving to this stage I recommend giving a vendor the easiest or best defined project you have.  At this point your success is tied to theirs and theirs to yours.  I recommend managing risk though the statement of work, verifying work with your own QA resources and assigning your own technical resource to oversee the project. 

The best strategy when negotiating this: Fixed Bid.  Why fixed bid?  Fixed bid is a shared risk.  Each party has skin in the game.  They want to make a profit, you want the project completed.  It puts you and the vendor in a shared  risk relationship. 

Develop Level 3 Outsourcing

I know what you are thinking, level 3 outsourcing is complete project outsourcing.  Something I’ve learned through trial and error is not an optimal solution.  Level 3 is all about reducing cost and freeing up resources.  It’s not project driven.  When you get to level 3 you should be looking to outsource the remedial tasks that your full-time staff does day-to-day. Also known as application maintenance.  At level 3 you want to move maintenance to a lower cost resource so your internal resources can continue to spend time managing Level 2 while keeping IP in-house!

The economy is picking up.  Now is the time to start implementing these strategies!

Interviewing technical people can be challenging.  What is the right mix of experience and ambition?  What level of expertise do you need?  I’ve built several technical teams and I will tell you that the ‘magic’ always starts with the core team.  These are the folks that will set the standard for your team.  So how do you find these folks?

Iceberg Test

There are thousands of books out there that discuss interviewing techniques.  All guaranteed to help you find the perfect candidate.   The main issue I find with these techniques is that they are perfectly inept at discovering true IT talent.  So what makes a candidate a great find?  A passion for technology.  This can take many forms.  Some candidates blog.  Some are always learning new technologies.  And others have ‘side interests’, read: side businesses.  

The most difficult thing about interviewing candidates is pulling this information out.  I think most people are taught as young adults or professionals that talking about your external interests during an interview is taboo.  I disagree.  As a hiring manager I want to see that you live, breath and consume your profession.  And for me, finding out about your outside work is pivotal in that determination.

This is how I came up with the iceberg test.  Based on my experience a solid technologist will only have about a third of their relevant experience represented on a resume.  The challenge is to find out if there exists a layer of experience that is not represented.  If you have the good fortune to come across a technologist that passes the iceberg test I would highly recommend you seriously consider extending an offer.

I’ve recently been reading a few articles about the future of application development and IT infrastructure management.  I believe that one of the main issues that face most IT pros is that we get caught up in the buzz word factory.  Today’s latest: Cloud computing, Web 3.0, etc.  What we fail to realize when we speak about the future of our architecture is the changing dynamic of our end users.

We, as a profession, need to realize that the end user is really what keeps us working.  It used to be that the goal of any application was to cater to the least common denominator, the weakest user.  If we could get that person to be productive and make less mistakes while using the software we wrote, then it was a success.  I believe that the paradigm has shifted.

I attend meetings every day where a user has created an application using Excel or Access.  Typically these applications have a degree of sophistication that amazes me given the lack of formal training and IT processes.  I’ve come to realize that most of the folks that work on these have ‘grown up’ in a technology enabled life.  I’m not just talking about 20 something's here.  The level of sophistication spans all generations.  For example, my father called me the other day to inform me that he updated his weather station so that it automatically FTP’s data to his website.  We are talking about a guy who no less than five years ago would ask me how to configure his email account. 

As a technologists we need to start thinking about embracing this trend.  We need to stop thinking about the lowest common denominator and begin thinking about how to enable users to ‘mash up’ or create their own technology solutions.  We can see this trend in BI trends. Analytic capabilities are being pushed to the end user.  No longer is a static report acceptable.  Users need and want the ability to drill through data, create their own reports and share with their peers.

Perhaps we, as technologists, need to re-explore the promise of SOA.  Not as core architecture, but a way for end users to plug-in, utilize the centralized logic and resources so they can leverage tools to make applications that work for them.

My advice for IT pros and lowest common denominator of users is the same: Adapt, or become obsolete.

I’ve recently had the pleasure of working with Microsoft’s 2008 BI stack. I say pleasure because Microsoft has really pulled out the stops.  The architecture is sound, the performance is outstanding.  Gartner has ranked Microsoft’s BI offering in the top quartile of providers.  This puts them in the same league as Cognos (Oracle), Business Objects (SAP) and usual players in the space.  I have used Cognos and Business Objects in the past and have had the opportunity to use or see most of the other vendor offerings.   Each Vendor offers tradeoffs.  Below is my experience with Microsoft’s BI solution up to this point.

Microsoft’s BI offering is centered around SQL Server.  In this case my team and I used Microsoft server 2008 and SQL Server Enterprise 2008.  I wish I could tell you it was because we wanted to take advantage of the performance improvements, However our logic was simpler.  If you’re going to build a new stack just use the latest and greatest.  The most important thing to the team was to use SQL Server 2008 so that we could take advantage of what R2 was going to provide.

The first thing that really struck us was the modular nature of Microsoft’s strategy.  SQL Server is the core, but in terms of delivery Microsoft relies heavily on the fact that most business users utilize Microsoft Office as their main office productivity suite.  It’s a safe bet considering that Microsoft has an incredible penetration rate in this space.  However, external facing customers might prove to be challenging in terms of delivery.  We chose to put a proxy between our Reporting Services implementation and the outside world.  This allowed us to implement URL rewriting and offer another level of security.  Unlike Cognos, which offers an easy to implement portlet we had to custom make a solution for implementation into our ALUI portal engine.  Of course all of this can be solved if you just use Microsoft Share Point.  This was not an option for us.

Typically I’d view this module nature as being a hindrance, or even a lack of integration features.  What we ended up finding is this is actually a strength of the Microsoft BI stack.  Microsoft has a great API/services to access all the functionality.   Building out a custom solution for integration was not that bad compared to the limited options for customization that other vendors offer.  For example, Users can natively access cubes and analysis right from Excel 2007.  However, because the API was so rich, we chose to write our own ‘Excel tab’ to make accessing and running analysis functions as brain dead as possible.  A solution that users appreciate.

So far, as a strategic play, Microsoft’s BI offering is proving to be a good investment.

I’m going to tell you the tale of two software shops.  Both shops have incredible Engineers,  great Product Managers and excellent processes.  The only thing that separates these two shops is release night.  One shop knocks out the change in minimal time, the other is working through the weekend to fix issues.  This anomaly has nothing to do with platform choice, complexity of the stack or location.  The problem is universal across all of these.  The difference between these two shops, a release engineer.

Typically a release engineer is a person, or team of people, who are familiar with the build, deployment and configuration of a product.  This is important because one thing I can tell you for sure, your production environment is not exactly the same as your lower environment.  Even more sure is that your production support team has even less knowledge on how to trouble shoot release issues.  You absolutely need someone who is familiar with your configuration.

Unfortunately release engineers are somewhat of a luxury for many shops.  They are an unappreciated component of a successful software shop. If you can’t get the budget to hire one I have a suggestion that has worked for me time and time again.  Appoint one of your developers (and a backup) as the designated release engineer.  This makes on person solely responsible for the success of your pushes. 

There is a cost associated with dedicating on of your developers.  I generally find it amounts to 10 hours a week as the developer builds and defines the process, approximately 6 weeks total.  After that, maybe 1 hour a week to maintain the process.  It sounds like a modest investment, but it will pay off the first time you have 6 developers working all week to make a deployment successful.