This project is about managing large business transformation projects. I will share you 9 facts which you should follow to maintain positive ROI of your software projects.
"Computer programs are the most intricate, delicately balanced, and finely interwoven of all the products of human industry to date. They are machines with far more moving parts than any engine: the parts don't wear out, but they interact and rub up against one another in ways the programmers themselves cannot predict. [Gleik 1992]"
As a program manager, I have directly and indirectly participated more 100s’ of projects. I have seen dismal failure of projects (like Oracle APS to SAP transformation for a Telco). I also experienced on time go live of large programs like 3G launch in RCOM. Here are 9 facts for project stakeholders.
1. Accept the fact – Over time, over budget and/or lacking critical features and requirement are very common to software projects. The 10th edition of the annual CHAOS report from The Standish Group, which researches the reasons for IT project failure in the United States, indicates that project success rates have increased to 34 percent of all projects.
Asked for the chief reasons project success rates have improved, Standish Chairman Jim Johnson says, "The primary reason is the projects have gotten a lot smaller. Doing projects with iterative processing as opposed to the waterfall method, which called for all project requirements to be defined up front, is a major step forward." The Standish Group has studied over 40,000 projects in 10 years to reach the findings This is the job of the key stakeholder.
S/he needs to break the project in small parts. Need to write the complete existing process along with short comings of the existing business & system process. No software project can be successful without “As Is” & “To Be” business & system process.
What CIO should do?
Instead of presenting their teams with lists of features to build in a sequence, organizations should present their teams with business problems to solve. Provide constraints for the solution and any assumptions that currently exist about that business problem and its target audience. Most importantly, each team should be handed specific success criteria. These criteria should be quantifiable and point to specific outcomes that prove the customer's need has been met and the business problem has been solved.
In next post “learn from failure”, I will discuss why recognizing the inevitability of failure is absolutely prerequisite to achieving success in software project management.
"Computer programs are the most intricate, delicately balanced, and finely interwoven of all the products of human industry to date. They are machines with far more moving parts than any engine: the parts don't wear out, but they interact and rub up against one another in ways the programmers themselves cannot predict. [Gleik 1992]"
As a program manager, I have directly and indirectly participated more 100s’ of projects. I have seen dismal failure of projects (like Oracle APS to SAP transformation for a Telco). I also experienced on time go live of large programs like 3G launch in RCOM. Here are 9 facts for project stakeholders.
1. Accept the fact – Over time, over budget and/or lacking critical features and requirement are very common to software projects. The 10th edition of the annual CHAOS report from The Standish Group, which researches the reasons for IT project failure in the United States, indicates that project success rates have increased to 34 percent of all projects.
Asked for the chief reasons project success rates have improved, Standish Chairman Jim Johnson says, "The primary reason is the projects have gotten a lot smaller. Doing projects with iterative processing as opposed to the waterfall method, which called for all project requirements to be defined up front, is a major step forward." The Standish Group has studied over 40,000 projects in 10 years to reach the findings This is the job of the key stakeholder.
S/he needs to break the project in small parts. Need to write the complete existing process along with short comings of the existing business & system process. No software project can be successful without “As Is” & “To Be” business & system process.
What CIO should do?
Instead of presenting their teams with lists of features to build in a sequence, organizations should present their teams with business problems to solve. Provide constraints for the solution and any assumptions that currently exist about that business problem and its target audience. Most importantly, each team should be handed specific success criteria. These criteria should be quantifiable and point to specific outcomes that prove the customer's need has been met and the business problem has been solved.
Fact - Defining exact deliverable of a project is the job of CIO or key project stakeholders NOT the project manager.
In next post “learn from failure”, I will discuss why recognizing the inevitability of failure is absolutely prerequisite to achieving success in software project management.
