Who is ultimately responsible when a project (with IT dependency) fails to deliver ?

Business had worked with IT to select the vendor who came with fairly good references and connected well with the team during the courting period. The CIO found the choice acceptable as the project was fairly straightforward and not much could go wrong in a project that was expected to last 4 months end to end. The CEO of the young smallish development partner took interest in the project with a large enterprise that promised more business in the future should this be delivered on time, budget and functionality.

The project started well with meetings attended by IT, functional teams, and project manager from the partner extending into long sessions; the subject was discussed, debated and look at from all angles to make a better wheel than the wheel required. The scope document went through multiple iterations as the subject matter expert (SME) kept changing parts in every meeting. Keeping in mind the need to push ahead, the CIO brought back the team to focus on the business need and speed to get the product to market.

The SME regaled in story-telling and kept the audience in attention with anecdotes unrelated to the discussion, hijacking the agenda and the project timeline. By the time the project was expected to complete, the team was just about getting ready for scope sign-off. Unfortunately other projects occupied the attention of the CIO which further pushed the timelines. Business had in the meanwhile moved on discounting the impact of the project; to compound the problem, the Vendor Project Manager quit.

The team and timelines were recast with the signed off project scope and the development team got started; the first wireframes were a hit, and the UX fell flat, while the development team struggled to get the new and to them unknown technology stack to work together. Frequency of review sessions reduced as the project red flagged itself on the CIO dashboard. Startled though not surprised the CIO called for an all-hands meeting to review challenges and determine if it made sense to continue the project.

The CIO and the vendor CEO decided to keep a close watch on progress; the solution was tested by the QA team and snag list identified for launch. The first field testing threw the team into a tizzy with UI that was unacceptable to the controlled group and bugs that surfaced. Speaking to the project sponsor, the CIO pushed the vendor and the SME to define the dates by which they expected the project to close. Both agreed to close the project within the next 10 weeks which appeared reasonable to all involved.

As the time drew closer, the vendor escalated pending issues with the SME and vice versa making it an extremely trying time for everyone involved; it appeared that the project would never end while costs had also gone out of hand. It required drastic steps for the project to come back to relevance to everyone involved. So the SME was eased out of the project while all payments frozen until firm delivery dates were met with quality that was the selling point for the vendor during the initial pitch to the team.

Another month later at its anniversary the project finally saw light and was launched quietly; it delivered success to the business despite some competitors having launched similar services. Much to the surprise of many, six months after the project was forgotten, the CIO decided to conduct a post implementation review to assess learning from the project to which he also invited the vendor to capture internal and external points of view, learning and accrual of benefits identified prior to project commencement.

It would be easy to stick the blame on the SME who caused the initial delay, or for that matter on the change of vendor Project Manager; development quality and testing could be touted as one of the causes or the fact that the technology stack was a new one ! What about bad UI or UX which would have been a disaster if launched ? CIO or Business Head not giving it enough attention or as many would say lack of leadership ? Did it matter as the project delivered value and everyone was happy in the end ?

It mattered to the CIO who meticulously documented the milestones, challenges, frustrations, and put them across for the group to review, sleep over and come back with their assessment. A detached view gave everyone the perspective of individual shortcomings and collective reasons for the project delay and the predicament that everyone experienced. The Organization was richer to the learning which raised the bar for future projects and institutionalized the Post Implementation Review process.

I wrote this piece after the feedback I received to my last week's article on CEO choosing an IT Vendor