This post from CIO portfolio begins with a statement about the odd nature of IT project portfolio. As has been expressed in the past, there is no such thing as a purely IT project: projects conducted by IT are, most of the time, to help the business. They may use IT's resources and abilities, but they are in fact to enhance a tool that business uses. Fundamentally this means that the “IT project portfolio” would be empty of projects. But if you look past the semantics in that argument, you come to another realization: IT managers run many IT project portfolios in companies across the world, and that's because technology plays an enormous role in the success or failure of many efforts. As the post points out, IT has filled the gap in the absence of an effective enterprise portfolio. While IT does do a good job at managing the project portfolio by virtue of their focus on objective information and evaluation, there are dangers. With IT at the helm there is always the chance that too much time will be spent trying to achieve absolute certainty about IT costs before the benefits have been fully explored. Furthermore, there is a possibility that IT will favor making project decisions based on available resources rather than the higher level enterprise-wide needs of the business. In order to gain the benefits of an IT project portfolio while mitigating as many risks as possible, CIOs must demand and reinforce good practice around justifying the business reason for a project before determining the cost, occasionally take the executive sponsor role , and build a project portfolio framework that could be used by any C-level executive. Furthermore, the article post suggests (and correctly so) that portfolio management shouldn't be done just once a year. In order to gain the most value from the process it must be continual, real-time, and consistently optimized. The take away from the article, and perhaps from IT portfolio management in general, is that IT has an opportunity to optimize a process before it goes enterprise wide. In order to successfully do so, however, it must take into account the needs, understandings, and processes of other areas of the business.
Con frecuencia en TI suponemos que todos sabemos lo que cada uno hace, pero Fahrudin Golos sí sabe que ese no siempre es el caso. En respuesta a un correo electrónico reciente donde un lector pidió aclaración sobre las diferencia