Response to: The Progressive CIO’s Model for Project Success

I scanned my Twitter feed on Monday May 16th and found a post by Todd Williams called The Progressive CIO’s Model for Project Success.  After the last couple of months of having to put our IT Services PMO team in place to rescue “business” led projects, I am compelled to question approach proposed by Todd.

Todd makes the point that IT organizations have been unsuccessful in building systems that meet their customer’s needs and fail in schedule, usability and scope.  This is a true statement as long as it is taken in context.  These symptoms of project failure (note: I did not say IT failure!) represent organizations that have a low levels of IT and Project Governance in their IT departments and in the rest of their organization.  Todd suggests that “progressive CIOs” need a new approach which is opposite to today’s practices.

I disagree … progressive CIOs need to recognize that IT touches all parts of the organization and that IT is one of the only places in a company where a broad enterprise view can be well understood and supported. Growing and maturing a PMO (project,program,portfolio mgmt) in IT is the first step.  Then moving that mature PMO out of IT to serve the entire organization should be the mission of a progressive CIO.

Next Todd suggests that because a business unit can use MS Office tools like Excel and Access to build small departmental applications on time, schedule and budget that we in IT should consider handing this work back to the business and concentrate on infrastructure.

If the user is better at creating useful applications and IT builds better infrastructure, then create an organization to mimic that model.

This is a huge generalization and does not come close to the complexity and scope of what an enterprise system project can entail. I will have to write a different post about the massive technical debt that our organizations carry due to all these departmental systems built with Microsoft Office tools!

There is a reason for having specific departments in organizations and that is to deliver on their specialized services.  Human Resources should deliver HR services.  Finance should deliver financial services.  IT should deliver IT services.  PMOs should deliver project services.  Creating redundant Project Management services and IT implementation services in multiple departments adds cost, complexity and creates silos within organizations.  Another big problem is this approach causes issues in departments that end up relying on individual experts who get sick, go on vacation, on training or leave the company.  This makes the department vulnerable to not being able to deliver on service commitments to the organization.  The level of risk of not being able to deliver a key departmental service is not something any senior leader should accept for their organization.

The next section of his post is called “Like The Business”.  Todd makes some excellent points here.  First he presents a model that he found from Jim Highsmith‘s post Beyond Scope, Schedule, and Cost: The Agile Triangle which I really like.  Here are two comments that resonate with me:

IT should not be run like “a” business, but, rather like “the” business, aligning to their goals, understanding their pain, and rapidly responding to their needs.

The concept of the IT project has vanished, there are just projects using IT resources.  The business owns ensuring the value, the architect owns the quality (robustness, reliability, technical debt, extensibility, etc.), and the project manager must tune the triple constraints to meet the quality and value needs.

Absolutely true and very well said.  This is exactly how we deliver projects to our organization.  A progressive CIO sits at the leadership table as a contributing member so that from the highest levels, IT is part of the business.  Having strong IT and Project Governance addresses value, quality and the triple constraints of scope, budget and schedule.  I completely disagree with Todd’s suggestion of:

… IT’s business analysts, developers, quality assurance, and project managers must be placed in the business unit.

One other key factor that is not considered in Todd’s post are the fiefdoms and politics that occur when business units lead projects that span departmental boundaries.  Inevitably, the lead department will put their requirements ahead of others to the detriment of the overall enterprise.  A level of independence and objectivity is needed that a separate PMO can bring.

Here is an example,  a department in our organization conducted an environmental scan to replace their home grown MS Access system.  They used SMEs from IT Services, Finance and other departments to help with the evaluation.  In the end, the team chose a vendor written system that fit our enterprise architecture to replace the MS Access system.  The department decided to work directly with the vendor and only rely on IT for infrastructure services like servers and databases.  The departmental project delivery was behind schedule, over budget and reduced scope while ignoring the needs of the other departments that supported the business process.  Not only that but a key stakeholder walked away from the project because “we were not being heard” and “they were dumping their work on us”.  Without this department’s participation, the project can not succeed.

After meeting individually with all stakeholder departments, I called a meeting of everyone involved and asked for all the issues to be brought forward. During the meeting, we reviewed the issues, and we came to a unanimous conclusion that the department-led project was in trouble and needed a project management structure and a clear communication processes. The end result was that our IT Services department PMO will be taking over the project and applying our project management methodology to rescue this departmental project.  I am convinced that our PM practices will rescue this project and ensure that all stakeholders needs will be considered and addressed.  This is another example of how a centralized, independent PMO approach establishes trust, navigates the politics and builds credibility in our organization.

So, sorry Todd … no sale here!