If you are in an IT department in one of the bigger organisations working in the major verticals of banking, telecommunication, insurance, retail etc... you are probably looking at a portfolio of work which has major bumps in the curve when starting a big software initiative and a steady state when those initiatives move to a steady state of enhancements and bug fixes (a.k.a Business as Usual (BAU) ).
If you are someone responsible for delivering this portfolio of work you probably are tied under the typical IT budget constraints of a big organisation. Hiring highly skilled people quickly to deliver the bursts of projects that come along is going to be difficult. Given this scenario it is more than likely that your attention goes to the right end of the curve where you see the amount of work in the portfolio reducing within a number of years. This is when you think "Why do I need to hire more permanent staff, I can get things done by hiring contractors who can then leave when most of the work is done."
This might probably work if the contract staff form a very small percentage of your overall organisation. You might even be able to find some real good contractors who specialise in certain niche areas which might be temporarily beneficial to your company.
But the moment you start relying on contractors to do most of the work in the pipeline, it is the beginning of a big world of problems. Because here is what will most likely happen.
- You decide on hiring contractors to get some major pieces of work done.
- Since these contractors are temporary, you ensure that you have enough permanent staff to oversee the work the contractors are doing. You have most of the permanent staff in all the important decision making roles.
- The contractors come in and start working alongside your permanent staff. The good ones want to drive new initiatives within these projects but soon get frustrated by the red tape approval process created by your permanent staff.
- Your permanent staff start feeling insecure about their jobs once they see some contractors who are better at the job than themselves.
- You might try to hire these brilliant contractors which creates an ugly set of dynamics at work.
- The contract staff becomes frustrated and start working just the hours required for their contract. If you hired really cheap contractors then they are probably in this mode from day one.
- The permanent staff has issues with the quality of work done by these contractors and sometimes vice versa.
- You add rigorous shortlisting processes for contractors in a bid to weed some bad ones out. But you still end up with some bad contractors because of budget constraints.
- Your project ultimately might go live but chances are that the quality of the architecture, codebase, user experience , performance is worse than ever. Your business stakeholders are unhappy.
- The contractors leave and you inherit a horrible quality system.
- Your permanent staff feels terrible maintaing this poor quality system. They either suggest a complete rewrite of the system again or suggest outsourcing the maintenance of the system to contractors.
- Another project comes along and you are probably still choosing contracting firms in the never ending grind of work.
So is there a better solution ? Let us look at the assumptions again
- Most systems you are building are of strategic importance to your business.
- There is more work in the pipeline than the permanent staff can chew and to be delivered in an aggressive timeframe which does not allow you to hire more permanent staff.
- The inflow of work might reduce after most IT systems are up and running in a few years.
and of course the more important long term goals that
- You need to be build a high quality system or platform which scales well to serve the business needs.
- You need to build an IT department with skilled technical people who are able to deliver and maintain the systems required for the business
So it is in your best interest as someone tasked out for delivery to build good software and at the same time set out to build an organisation which can do the same repeatedly in the future.
This is best done by hiring good people in first place, but if for various reasons you cannot, then at least try to partner with people who are passionate about the craft of building software than people who worry about billing the 8 hours of work.
To scale, try to find companies with whom you can partner with for their delivery services knowing how culturally passionate the partner company is about delivering the work for you. (And believe me , there are many good consulting companies out there which can help you out).
And by partnering, you engage with them at levels where they have a decent voice in decisions made on how to deliver the project. There is transparency and a drive towards building a win win collaborative culture within the team. You treat them as strategic partners rather than augmented resources in your delivery organisation .
It takes time to find such companies to partner with. You need to validate their delivery capability and culture fit over a period of time. But once you have done that, try and build a lasting relationship with them because in reality you will always have a backlog of work given the dynamic nature of your business.
After all, you are building long term assets for your company and it can best be done by partnering with people who care about it the same way you do. So invest in finding a good software delivery partner that can work for you instead of risking long term failure by using low cost/quality contractors.
