You are a typical IT services company.

Ever noticed how near-identical the website of any standard small-to-medium sized IT services company is? They all say the same thing in different words.

Here are a few stereotypical statements:

  • We have a well defined SDLC/Agile methodology: No, you do not. What you have is the following:
    • Incomplete requirement specs
    • Templated design documents
    • Superficial project plans
    • Inexperienced coders
    • Missed milestones
    • Artificial deadlines
  • We are quality-oriented: No, you are not. Continuing from the above, what you have is:
    • A QA team that tests everything manually and whose test cycles are counted in weeks.
    • Delays in QA release builds from development team.
    • Increasing pressures on QA teams to compromise on their testing to meet above-mentioned artificial deadlines
    • fights between engr and QA teams about deadlines and definition of bugs.
  • We use industry standard best practices: No you don't. You either:
    • do not have a single document that actually outlines what that "best practice" is.
    • If you do, it is a vague document created by someone is response to a past crisis.
    • It is lying on a backup file server and nobody has actually ever read it after it was created.
  • Our engineers are the best: No they are not. You have 1 or 2 "HR executives" who work their butts off coordinating with recruitment agencies that flood you with unsuitable resumes and setting up interviews with overworked senior developers who have their own deadlines to meet.  Your engineers are whoever you could hire in the one-month "ramp-up" period that you wrangled out of your customer.
  • We are customer-oriented: No you are not. You have a process that requires at least weekly conference calls with customers because your team is incapable of coming up with the right solutions on their own and want customer validation every step of the way.
  • We are low cost: - no, you are not. You have a top heavy team with non-billable mid-level management layer that contributes the most to your project costing. You try to make it justifiable by explaining that they are a shared cost across multiple projects. In times of crisis, this same team will gather in a meeting room and cast accusatory looks at the poor innocent coffee machine lying in the corner.

Are you really different from the rest?


Nirmalya said...

I am wondering why did you put the qualifier 'small-to-medium size'? Isn't it true for biggies too? Do we really believe that some or all of the observations of your are not applicable to them too?

Renji Panicker said...

Well, only because my experience is limited. My knowledge of what happens in the larger places is anecdotal so while I believe it is applicable, I don't know for sure.

देवेन्द्र यादव (Devendra Yadav) said...

I have worked in all kind(Small,Medium and lager) companies and based upon my experience...

You can categorize quality/process based upon size of company. quality/ process depends upon the kind you work you are doing and kind of people you have in your organization. Typically Service based companies(of any size)do the faking business just for the billing and getting more clients.

if you have worked in product based company. Document/process are not he key things, they are just a tool to maintain the quality of product. process is good thing till it's adding value in your work once it becomes burden there is no point in following them.

Another point i have seen - many organizations claim that they do agile development while they actually follow the mini-waterfall... they need to understand what agile is... just giving releases in short time does;t mean that they are agile...


निखिल जोशी said...

Adding to the list from my exp
You think you know/are agile but you are not as

-You decide the features of the sprint AND the deadline before the start
-You think you can get away without designing anything and starting to develop directly
-You think every project has to be able to use agile to complete (even OS)
-Your daily scrum meetings are actually sitting meetings with meeting rooms booked where everybody starts discussing their technical problems and dont finish in 15 minutes

These end up in following mini-waterfall as Devendra rightly pointed

Bhavanesh said...

finally everything boils down to GP and GM (Gross Profit & gross Margin) managements want to look best at board meeting ,HR wants to looks best at management meeting and its a vicious circle of greed and margins

Shiv said...

Absolutely true. I feel IT companies are like "A duck in a pond". on the top they pretend to look different to clients and below the surface there's another story.

Sukesh Marla said...

i strongly agree what u have written, But its again a perception.
People take decisions without understanding either domain difficulties or technical difficulties.
One thing i will prefer if anyone want to establish a good company is , First He/She should be technically updated and good so that when it comes to domain implementation they should b clear about the facts which technology will be used and people of which caliber need to be assigned.