Software Projects Limited by Technology
Do you limit the scope of new projects based solely on the technology you’re comfortable with?
Think about it. You or your team are technical experts on .Net with SQL Server and you’ve been asked by a customer to come up with a quick, but functional solution for a website marketing campaign. You’d use .Net of course - what other choice do you have?
In this case a Web 2.0 language might be more appropriate - take Ruby for example, a language that has the cult status for young developers that Java had when I started in IT. Your .Net team know instinctively that Ruby might be a better match, but this means they’re out of the picture as far as doing the actual work is concerned.
Having multi-language talented developers is the Holy Grail for software teams. This is harder to get than you’d imagine. Remember the old saying, “Jack of all trades, Master of none”, this is true for development teams too. Having no experts is risking when you get into trouble. Managing risk is a key skill for software project teams, so one way of doing this is sticking to your strengths.
This inevitably means that there are a number of software solutions out that there that might look good, and have met there deliverables from a project perspective, but aren’t appropriate from a technology point of view.
Not sure how this can be avoided, except by customers understanding the core competencies of the organisations bidding for their work, understanding the technologies out there, and asking the right questions. Then you get into a position where the customer is writing the technical requirements instead of focusing on the business requirements.
A hard question to answer, and one I don’t expect anyone could nail down even if they wanted to. Anyone have a comment?
Please consider the environment before printing this email.
How Much Do You Trust Your Mechanic?
Picture this: you need some work done on your car. You don’t know anything about engines, or sparkplugs or alternators. You just know that the engine is important, and you need someone with specialised skills to fix or enhance it.
Anyway, you take it into a garage - one that you’ve used before so you trust them. They tell you what needs to be done, and how much that will cost. What choice do you have - you have to trust them as you can’t verify that the work is acutally needed or not.
Now imagine you’re responsible for creating an online presence for your organisation. You know that this means you’re going to have to put your organisation on the internet, and what’s more you know that you don’t have the skills to do this.
There are companies out there that do this sort of thing; some advertise openly, some only through word of mouth. You contact one, and get an estimate for the work to get done based on what you’ve asked for. You can’t check the estimate as you don’t understand Analysis, Build, Test and Deployment, but these guys are professionals and wouldn’t lie to you - right?
This is the way I like to look at situations that my customers must feel that they are in. I try to give them as much information as possible to make them feel part of the IT estimation process without confusing the situation. Happily this seems to help most of the time, but I can certainly see that some organisations can feel quite vulnerable.
This is why many organisations will stay with one vendor, and getting them to change is very difficult. Even if you can show that their incumbent isn’t perhaps as frugal as they could be. Some complacency from IT vendors is there in the market, but along side this is a very New Zealand-like resistance to change from the known.
I’m not suggesting that this is wide-spread in the industry, but would like to point out that most IT vendors are honestly out there to do the best by their customers. We shouldn’t be complacent however as our clients must feel a little uncertain some times.