Google   web blog

Friday, July 20, 2007

5 Harbingers of Software Product Failure

1. Lack of quality improvement. Another implementation and the same, not-so-high quality? Haven’t learned on your mistakes from the last quarters? Still hitting the ceiling with the application’s performance? Ops, it looks like you neither learn nor improve, but stand in the same place with your product over the time.

2. Constant, similar problems with finishing projects. Isn’t that fifth time in a row when deadlines are 100% overrun? Wasn’t that the last customer who was making the same problems with signing the final acceptance? Why all of them are so scrupulous? Oh, maybe getting things done (and I don’t mean 90% done) isn’t really as easy as you thought with that application.

3. No energy to overcome technology constraints. Haven’t we just mended that darn performance? Can’t we just do it right once and for all? How many times more we’ll hear about those darn technology constraints? Hey, try to take some time and plan (with details) what exactly you do need to finally leave known limitations in the past. And don’t be surprised with results – as far as you don’t cheat it’s likely to cost a lot of time and money.

4. Mediocre product placement. Have we just spent three quarters on that low-margin project? How come? Why losses when all projects looked profitable on the beginning? Can’t we have just a standard implementations instead of all those integration stuff? That’s just a guess, but maybe your niche requires all those integration work. That way unless you plan your projects to include integration work you’ll always underestimate the costs. What more, maybe your niche expects low price and you need a product which is well prepared to customization to sell it profitably.

5. Low level of stabilization in the team. Maybe it’s a good idea to use our R&D team in that implementation as the other free developers are fresh as grass during spring? How about hiring a couple of temporary programmers to make that one? Wouldn’t that be a great idea to outsource this part as we’re running out of resources? Hold on, I’ve heard investments in team competencies and knowledge pays off. I’ve also heard “every specialist can be replaced with finished number of students” paradigm doesn’t work as perfectly as it was believed. Maybe considering developers and project managers more like people than resources isn’t a bad idea?

0 comments: