CIOs and their Project Portfolio

Continuing on our series of “Making IT Projects a Success”, we now take a look at the role CIOs can play in making their Project Portfolio a success.

To highlight the relevance of this article, I shall start with a brief background of the CIO’s role.

A question often asked is, at what point would an organization consider hiring a CIO? In this Tech Savvy age, all Fortune 500 companies have a CIO on-board but what about the ones that have revenues in tens of millions? When do they have the luxury of hiring one for the C-Suite? Do they follow a popular practice to “Rent a CIO”? Some Organizations hire an IT Manager and in due course of time give him/her the title of a CIO with neither of them understanding the true change in the role.

While the IT Manager is vital for the day to day Management of IT issues, he does not have the business acumen to guide the Organization through strategic initiatives and ensure Business Systems and Processes are in place to support growth while achieving excellence in IT delivery and innovation.


Well, there are a few criteria that can be put in place to understand the need for a CIO. They include:
the revenue the company is generating
how far and wide it has expanded across regions
the number of employees and IT systems in place
the volume of transactions being made by their Customers
the need to integrate various systems within their IT infrastructure as it becomes complex a requirement to transform the way IT is run
a need to align IT’s strategy with that of the Business
someone who spends quality time understanding the Business and its Customers who is able to see the big picture and help solve broader issues
who can stabilize day to day IT Operations
ensure that IT expenses are not too high or low and is in line with their competitors
oversee IT measures to be taken before an IPO or a Merger and Acquisition exercise and
guide the firm through Regulatory & Compliance requirements such as SOX, HIPAA, PCI DSS among others.
Once the need to hire a CIO has been ascertained, central to the success of this individual would be his ability to effectively manage a “Portfolio of Projects” and put in place IT related Business initiatives that can create value.


As discussed in my earlier article on "Making IT Projects a Success", it is a Business Project that is being delivered by IT. Hence, the Business owns the project while the CIO is held accountable for it. The challenge here is to get the Business to do its part in making the Project a success which is often times like pushing a rope.
A good starting point would be for the CIO to take up the role of a Relationship Manager to build alliances with the various Business Units and influence their users.
Following are a few additional guidelines that CIOs can consider while handling their Project Portfolio. Some of the below duties could be passed on to the Project Management Office.
1.Ensure that Projects are aligned with the strategic direction of the organization & have clear business objectives. Present Business cases to the Board with a clear detail of the possible Return in Investment.
2.Manage a Portfolio that has a mixed bag of projects that enhance the strategic position of the Business, contributes to operational excellence, covers IT infrastructure upgrades (hardware & software) among others. Prioritize these projects without under or over estimating their complexity and provide directives to the Project Office.
3.Ensure that there is no diminishing visibility and vigour from Business Sponsors through their constant engagement in IT programs. An IT program that does not have the same Business Owner from initial planning to its completion is more than twice as likely to be cancelled as completed.
4.Check if long IT Projects are consistent with the Business Change cycle. Define what could be a reasonable duration for a project based on the current state of the Business and the speed at which it is moving. There is also the possibility of external market forces changing the course of the Business which should be highlighted as a risk. Be on the lookout for events such as your Organisation going on a Merger and Acquisition spree or any similar exercises which would affect the ongoing projects. Define “Time to Market” based on changing Business priorities.
5.Gauge the maturity of the organisation, its resistance to change and measure the level of impact that critical projects can have and brace the Business towards it. Business Projects enabled by IT that are transformational in nature need People & Processes that are ready to undergo that required transformation. Else, the post implementation review (ex: one in six months) would suggest poor adoption of the deliverables by the Business user due to their reluctance to change.
6.Understand that new technology can be a double edged knife. Early adoption of new technology can give one’s organization a competitive advantage but also can expose them to several risks and possible failures.
7.Ensure that Organizational Politics & Red Tape does not affect the functioning of the Project Office and the delivery of its Projects. Translate the language of your IT team to the Business Executives and Customers and vice versa.
8. Define Project Success Criteria and put in place other Key Performance Metrics to ensure successful delivery. Reward the Project team accordingly.
9.Attend Project Board meetings to ensure projects are still relevant in a Business context. 10.If a decision to outsource some of these projects has been made, then selecting which projects can be and should be outsourced is critical. Your decision could be based on various criteria such as the competency of your team, availability of resources, budgetary constraints among others but the risks involved need to be analysed. For example, the possibility of a vendor falling behind in schedule is a known risk but not having measures in place to ensure their quick recovery is poor foresight. Needless to mention, it is often times easier to deal with your internal resources than with vendors.
11.There should be no reluctance in requesting expertise in assessing your outsourcing contracts.