Planet Midgard: Archive

Lately I've been forced to think quite deep issues of software producing and developement. I was suprised (not much) that 25% of software projects are cancelled and about 50% are challenged. So that means that oly 25% are more or less delivered as promised.

Generally finding requirements and making effort estimations is a quite challenging task. And with huge projects even minor mistake can delay the delivery by many weeks. So that's why it's very important to keep records of older projects since they can be used as a base of an estimation

I've recently heard an interesting definition of a project. Normally project is defined by scope, budget and schedule. But it is also good to know that the most important thing that it defines is the risk of failure and the quality of the software.

But how to control these risks? If you feel that things are too big then it's time to split them. One good method is to split a big delivery to independent incremental deliveries. It's up to you to decide if to start with most business critical parts or just with easy first victory in mind. Both ways are good.

Point with the incremental development is that  you have your focus in a one part of the project and you make it ready and deliver it. That means that by the end of the project the first deliveries are very stable (=if you correct the bugs and remember to regression test). And overall feeling and confidence about the project should be on much higher level.

Lately it has been interesting to read and hear about these methods from older very experienced developers and project managers. But still there has been one big issue. All these methods have been developed for very big companies and projects that have a very clear hierarchy.

Still somehow I'm confident that there are some good practises that can be used with smaller projects and companies. I just have to find them first. But the goal of these practises is clear. To minimize failed and cancelled projects and especially try to  minimize challenged projects and after project bugfixing. It's very expensive in the long term.

And about the first thing that I wrote about. The trio of scope, budget and schedule. I think that with partitioning of a bigger project you get a smaller scope that of course means smaller budget and schedule. But still I'm quite confident that it also affects greatly to the quality of the delivery.