Tuesday, December 06, 2005
Thoughts on IT Porfolio Management
The measurement for return on IT investments has gone from yearly to quarterly and now sometimes even monthly. The velocity at which change occurs and the demand for innovation has caused many enterprise architects to think about IT portfolio management. Sadly, many of them are getting it wrong...
Managing information technology investments requires rational approaches to selecting, prioritizing, optimizing and aligning the IT spend to business drivers and the future direction (stated and unstated) of the particular industry vertical one plays in. Doing such not only requires achieving optimal benefit but also achieving a chaordic balance.
Better balance can be achieved by adopting service-oriented architectures, outsourcing appropriately (Nothing larger than a few projects and absolutely never more than 10% of the IT staff), data center consolidation, ubiquitous computing with nodes virtually everywhere, the adoption of open source software and agile approaches to software development.
Where most enterprises go wrong is that they attempt to get architecture teams to start thinking like project management folks and don't acknowledge that they are distinct disciplines. You can read in magazines such as CIO, that many of the IT executives that have failed didn't have enough business savvy. There is some truth to this statement, but the real problem upon further inspection actually lies elsewhere. I would challenge anyone making this statement that the real problem is the promotion up the ranks of folks with project management backgrounds which is really neither IT nor business...
Too many folks are getting it twisted so I have devised a list in prioritized order on exactly what they should be focusing in on when thinking about portfolio management. If you do them out of order, then you too will get it wrong:
IT portfolio management should be used as a framework (not stick) for better decision making regarding new and existing IT investments. Sadly, whenever a PMI certified type gets involved they will think of portfolio management in terms of the sinister act of time tracking (another form of list making). They will run out and purchase tools that solve this particular aspect of governance first that will lead others down the path of spending even less time delivering valuable working software for the business. They will never acknowledge that the problem is that employees are not spending time on things that are more important because they are so consumed with producing metrics. I wonder if these folk ever stop and take the time to ask are they really solving the right problem...
Enterprise Architecture and IT Porfolio Management both require a laser-like focus on the objectives of the process, avoiding getting mirred in superfluous information. Objectives should be attainable and grounded in reality. They both should synthesize potential business opportunities, assessing value, risk, costs and other parameters. Sensitivity analysis, what-if factors and scenario planning must be leveraged to manage uncertainty.
In the meantime, check out IT Governance Demystified and The difference between Application vs Project Portfolio Management...
| | View blog reactionsManaging information technology investments requires rational approaches to selecting, prioritizing, optimizing and aligning the IT spend to business drivers and the future direction (stated and unstated) of the particular industry vertical one plays in. Doing such not only requires achieving optimal benefit but also achieving a chaordic balance.
Better balance can be achieved by adopting service-oriented architectures, outsourcing appropriately (Nothing larger than a few projects and absolutely never more than 10% of the IT staff), data center consolidation, ubiquitous computing with nodes virtually everywhere, the adoption of open source software and agile approaches to software development.
Where most enterprises go wrong is that they attempt to get architecture teams to start thinking like project management folks and don't acknowledge that they are distinct disciplines. You can read in magazines such as CIO, that many of the IT executives that have failed didn't have enough business savvy. There is some truth to this statement, but the real problem upon further inspection actually lies elsewhere. I would challenge anyone making this statement that the real problem is the promotion up the ranks of folks with project management backgrounds which is really neither IT nor business...
Too many folks are getting it twisted so I have devised a list in prioritized order on exactly what they should be focusing in on when thinking about portfolio management. If you do them out of order, then you too will get it wrong:
- Communicating effectively, with appropriate agility to rapidly reprioritize and rebalance investments and assets. Communication is not call in a large insulting firm and having them back up the school bus and send in the kindergartners to devise a 'strategy'. Communication is best enabled via choosing individuals to lead (different from manage) that have characteristics of strong technical leadership. One must have intimate personal first-hand understanding in order to be effective. This cannot be proxied or moderated.
- Creating and cataloging a detailed, value-based, risk assessment of the inventory of existing assets. This does not mean the typical PMI certified project manager should go out and make lists and call their effort project management. Risk is best determined by the person most informed
- Eliminating redundancies while maximizing reuse. Redundancy usually occurs within systems at the code level, across applications and even within people (usually at the management ranks). Technical resources (different than those folks who call themselves IT professionals) usually are not only not redundant but scarce by their very nature. Reuse should occur with people, then processes then tools in that order. Finding redundancy should also occur at this level.
- Monitoring project plans (costs, schedule, scope, timing, risk/reward, etc) from analysis and approval through post-implementation including sunset. Many enterprises only monitoring initiation and usually stop when the application hits production. This is of nebulous value as we all know that from a TCO perspective 80% or greater of the total cost occurs after production deployment. The notion of stewardship throughout its lifecycle is mandatory.
NOTE: The priority of the list intentionally left elements that traditional PMI certified folk can participate on to the absolute last step. There is greater value in architecture than there is in list making.
IT portfolio management should be used as a framework (not stick) for better decision making regarding new and existing IT investments. Sadly, whenever a PMI certified type gets involved they will think of portfolio management in terms of the sinister act of time tracking (another form of list making). They will run out and purchase tools that solve this particular aspect of governance first that will lead others down the path of spending even less time delivering valuable working software for the business. They will never acknowledge that the problem is that employees are not spending time on things that are more important because they are so consumed with producing metrics. I wonder if these folk ever stop and take the time to ask are they really solving the right problem...
Enterprise Architecture and IT Porfolio Management both require a laser-like focus on the objectives of the process, avoiding getting mirred in superfluous information. Objectives should be attainable and grounded in reality. They both should synthesize potential business opportunities, assessing value, risk, costs and other parameters. Sensitivity analysis, what-if factors and scenario planning must be leveraged to manage uncertainty.
In the meantime, check out IT Governance Demystified and The difference between Application vs Project Portfolio Management...
