CIO as Chief Investigation Officer: Is Programming Failure as Key Source for Software Project Failure?

The high failure rate of IT project is always a hot debate point, from symptom to root cause, is programming failure as key source for software project failure?

1. Requirement management: Looking over analysis of projects which have either run well over budget or failed deliver on key outcomes, the root cause comes down to poor requirements analysis and feedback. Requirements should stipulate inputs and outcomes, have screen shots of the UI for each user interaction and be signed off by both end-user groups and the development team.  

2. Manage full project management life cycle well. No doubt programmers will produce "bad code", and often coding takes longer than estimated. But it's the processes and procedures around code development that cause these problems. What is the process for estimating software development effort? Who tells the programmers what to code? Who designed the systems? Who writes the specifications, and who signs off on them? Who specifies the quality requirements for the software? Was the specification given to the programmers complete, and accurate, and in sufficient detail for them to do their job? Who writes the test strategy and test plans, and who carries out the acceptance testing, and signs off on the results? Does the project schedule and budget allow sufficient time for testing and verification, including remediation of problems?  If you expect the programmers to do all these tasks themselves you have signed away the project, and it is set up for failure. 
   
   
3. It's not the bad code that screw you up. it is a lack of structure, observation, and progress measurement that permits bad code to persist until ripping it out becomes nearly impossible. Some amount of bad code is inevitable, because programmers are human. Too often, organizations can't be bothered putting the effort into these details, and just want to race into execution. When the problem is a developer, the leadership/management has usually contributed to the problem. Symptoms are: lack of job security leading people to withhold information and produce incredibly convoluted code that no-one enjoys but the insecure developer maintains for his/her own security.
   
   
4. Set up software development principles/criteria. If there are good team principles and a focus on quality there should never be an issue stemming from the work of a developer or programmer

1) First, you need criteria for telling bad code from good: specification and test plans.
2) Second, you need to evaluate code *in context* as soon as possible: integrate early, integrate often, and use partial integration testing.
3) Third, you need to check progress in small increments: use Earned Value Management or Cost Schedule Management

4) Fourth: Vendor review, some companies continue to hand large projects to the same system integrator who continues with their fault proven methods. The end result should be apparent, as Einstein said: To solve the problem, you need a different set of thinking than that which created it in the first place.

5. Use re-engineering techniques in looking at business processes in total. Some projects are for internal process improvement. To the IT organization a first release is project completion but to the user, it just represents a prototype to fuel their next ideas of innovating, the business process they are automating. But regardless of methodologies/tools/techniques if communication is not clear and some degree of flexibility designed in projects will fall short of meeting everyone's expectations.

5. Programming failure is part of IT project management failure; dispassionately examine all three fundamentals: People, Process & Technology. Project managers should get the team together regularly to discuss the mission in the project, risks/issues and reviewing the plan and progress. Do that, and success is inevitable. If project management fails to foster teamwork and creative thinking then they will eventually fail - this is inevitable.

• People: Educate engineers to think beyond coding, understand business context, the purpose of code, and the customer satisfaction. etc. 
• Process: Agile, or even more integral DevOp methodology/environment can help to enhance communication via iteration; reduce redundancy, and improve governance. 
• Technology: Modern PM software with embedded social/analytic features will empower the software team with the effective tools, resources and best practices.

Posted in: Lessons from Failures,Project Management