Showing posts with label projects. Show all posts
Showing posts with label projects. Show all posts

Tuesday, May 25, 2010

Improve Software Quality

I had got a privilege to attend a software code quality seminar. Few points I would
Like to ponder in future are

1. As line of code increases the maintain ace risk for project increases as well as probability of cost overhead.
2. Change management is very important aspect of big budget projects.

There could be 3 criteria for highly successful projects
1. Achieve the quality targets for the customer
2. Achieve revenue targets
3. Achieve the launch date targets

Model Driven design and analysis is very preferable than document based because of visual advantage

My next goal will be look at some static analysis tool

Thursday, October 15, 2009

Some analysis about project failures

My obeservation about the people in leadership who are driving projects with huge budget have big risk. They risk with big money of shareholders,careers of the employees reporting to them and also their own career is at stake. Odds are
always against them. We know that around 90% IT project fails. They are either overbudget or not delivered on time and do not satisfy the needs of the stake holders.
Such big projects have tendancy to get delayed due to human dynamics , lots of other factors which are very complex to analyze. The delay is caused by coflicts of interestes by people representing different departments. For ex. technical group is looking after the sound architecture, maintainability of the project in future. On the other hand management is looking after project as a cost or capital expandtiture so they are looking for less cost and earliest start of return on investments.

IT projects are complex in a sense that they are driven by humen ,for humen and but the IT system developed is of the company which wants to make a money out of the system in direct or indirect way to improve its bottom line. I feel this is first criteria to be analyzed before starting big project. Is the big project going to give any returns in furture or the IT department is going to burn all the budge with no end result.

Wednesday, September 30, 2009

some meditation regarding project failure

I try to push KISS principle in our project as System Architect. I would always try see if we can accomplish
our job with less tools and less languages for a particular project.
The complexity of the domain is always challenge infront of us but for that only we are paid to solve.
Non technical people for example managers and Business Analysts and clients who are end user hate the
technical complexity but what I have seen is that most of the developers add more and moretools and
technolgies which adds more and more complexity to projects. Most of the developers do this for thier own
benifit of desire to learn new technology to improve their CVs.

Some where I heard that for a company who has multiple IT vendors has their cost on the IT is function of
number of vendors. While pondering on this idea I realized that its kind of true I don't want to go into
arguments about validity of this argument but I kind of agree with this. Then I tried to apply the same idea
in the project I worked earlier or I heard all the project which were failed and I kind of agreed upon this.
In my current project also I see that change in the vendor is overall delay in all the deliveries which
increases overall costs of the projects.
If we apply the same rule on technologies used in project then we can think of that the cost is function
complexity which is universal truth and complexity increases due architecutre and technologies and tools used
in it.

Think of your last failed project due to technology....