Key Learnings: IT led runaway projects

A scenario where Business has approved a large IT project with the timeline keep moving out with no end in sight.

This is a case where even though Business is really interested in deploying the next generation Information Systems/Applications but IT is unable to deliver resulting into a runaway project

Best Practices:

• Set clear objectives at the beginning of the project
• Engage System Integrator to capture business process and/or requirements
• IT Architecture team is responsible for the high-level design, estimation and architecture standards
• Program Management Office (PMO) responsible for ensuring project governance
• System Integrator engaged for developing the solution, especially for packaged applications (not a core competence of IT departments)
• Engage vendors for periodic review and recommendations

Symptoms:

Following are some of the symptoms of a potential runaway project.

• One System Integrator selected for capturing business process/requirements and other for development
• Requirements handed to the architecture team for high-level design and estimation
• Architects not involved in any of the requirements gathering meeting with the business
• Business Analyst (SI) accept requirements and commit to timelines without engaging the PMO and/or the Architects
• Development handed off to multiple vendors with each of them responsible for detailed design and development
• Architecture team not engaged with the development team for ensuring the detailed design and development complies to the original business requirements and architecture standards
• Each team uses its own development tooling, builds, testing tools and approaches
• No consisting integrating testing plan or procedures put in place
• Product vendors are not engaged during the periodic reviews
• No QA process put in place for accepting code from the various (contracted) development teams
• Cost is the only factor considered for identifying developing (contract) development teams
• Builds teams unable to recreate any of the previous builds - system or sub-system levels
• No integrated process or issues tracking procedure adopted by the PMO
• Major issues not escalated up the chain by the project manager
• No clear User Acceptance criteria defined at the beginning of the project
• No clear responsibility for integrated system testing

This results in the project being delayed with the business learning about this just before the roll out. IT loosed complete credibility with the business.

Recommended Course of Action:

Following the the best course of action to resurrect such a project.

• Reconstitute the entire team - starting from the project manager
• Ensure that there is a clear defined Project life cycle defined jointly by the PMO and the Architecture team
• Ensure that the Architecture team is not an "Ivory Tower" and engaged throughout the life cycle of the project, starting from the requirements capture to the final deployment
• Architecture team consists two sets of architects; Core Architects: Responsible for understanding all the requirements, technology and process at a detailed level and Sub-System Architects: Responsible for understanding the detailed requirements, design and work on a day-to-day basis of the development team to ensure that the system meets the business requirements
• Architecture team responsible for identifying common (reusable) components
• Based on the list of common (reusable) components, create a dedicate team to build this out (preferable by the IT department)
• Identify development teams based on on cost and skills - not just cost
• No delivery commitments made to business without PM and Architecture teams review and accept the requirements
• Make sure that the major vendors are involved in some of the PMO meetings
• Clearly define the architecture standards, QA process and knowledge transfer for accepting code from (contracted) development teams
• PMO responsible for identifying a systems integration testing team as well as ensuring that a consistent build and testing procedure is adopted
• Periodic PMO meetings to track progress, issues and open items

This fictitious scenario is based on multiple conversation with my peers in the industry.