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.

Key Learnings: Business driven runaway projects

A scenario where cash rich LOB continues to invest and drive projects with no foreseeable return on investment.

Typically in all major corporation there is at least one major Line of Business that is cash rich, i.e. this business unit tends to exceed their revenue forecast and is looking for ways to spend money during the last two weeks of quarter/financial year.

Best Practices:

• LOB should invest on Projects that is beneficial to both their business unit as well as the Enterprise
• The "IT-Board of Directors", which includes the cash rich LOB - decides which projects get funded
• Business and IT need to jointly develop an ROI before embarking on any large projects
• LOB-IT should make technology decisions in collaboration with the CIO-Staff and the EA teams
• Engage Business Consultants or Systems Integrator to provide business and technical advice/best practices

Symptoms:

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

• LOB sponsors the project but not willing to wait for other LOBs which may be swamped implementing a strategic project themselves or overhauling their business process/organization
• LOB determines it knows what is best of the enterprise and starts investing in what it terms as Enterprise wide project, even though there is no buy-in from the other LOBs, CIO or the Enterprise Architecture team
• LOB is a huge proponent on the divisional LOB-IT
• LOB is very critical of the CIO and/or the IT as a whole
• LOB-IT uses technology what it understands the best, without consulting the EA team. Examples: Leverage EAI tool to move huge volumes of data instead of using an ETL tool, developing data quality tools in-house instead of using appropriate tools, etc.
• Attempts to resolve Business Processes at their end, instead of working with other LOB
• LOB-IT leadership attempting to make progress in their career paths by transferring to the LOB
• The targeted end-user community is very small

Project Approach:

• Such a project typically begins with LOB initially coming to IT stating that they would like to start a project ASAP to conduct a feasibility study for looking at one of the major business process withing an enterprise.
• As IT projects are planned at the beginning of the year - IT agrees to bring in an SI to run this project (with PMO Oversight).
• Based on the feasibility study - the SI (rightly) identifies the potential issues with the business process and recommends that this be resolved at an enterprise level - presents a phased approach - PMO, Enterprise Architecture team and CIO agree to this.
• Implementation phase begins - but other LOBs are not ready to participate and redefine the end-to-end business process.
• EA recommends to both SI and LOBs that they wait until the other LOB are ready to engage (this is where the organization dynamics begins :) ).
• In order to start generating revenue SI pushes for project to begin and fix some of sub-business process later (as-if this will really work)
• The Business project manger - in order to gain executive visibility agrees with the proposal
• The other LOB teams feel sidelined and stops participating
• To avoid having a difficult conversation with the LOB, The LOB-IT agrees with the LOB and SI, against the advise to the Enterprise Architecture team and the PMO

Recommended Course of Action:

• The best course of action for the PMO and the Enterprise Architecture team is to support the project as best as they can
• Continue to ask the LOB to define the objective and ROI for every phase
• The most noticeable aspect is the objective of the project is redefined - "To understand the issues with the business process" - instead of having a real objective or ROI
• The overall cost of the project is no longer published - instead only the SI cost is published
• The projects moves through the life cycle phase - even though it never meets the predefine and agreed upon exit criteria with the PMO

On completing a couple of phases of the project, it would be abundantly clear to the CIO (provided of course the PMO does its job) whether the project is a failure or a success. Based on this data - the CIO has enough data to push for stopping the runaway project.

In short - "Support the project the best you can and let it run its course. If it was bad idea from the start - it will eventually fail and someone" (but do not expect anyone to be held accountable :) ).

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

Next Topic:

Key Learning's: IT driven runaway projects

Battle of the Js: Jaxtr, Jangl, and JaJah

I found an intersting post on Battle of the Js: Jaxtr, Jangl, and JaJah. Once GrandCentral (Google) opens up - I do plan to play with it to determine whether I stick with Jaxtr.