Should the PMO be owned by IT or the “Business”?

Neither! We describe the “business” as if it is a single entity. The “business” is a collection of departments whose priorities and objectives frequently conflict. The functions of a PMO are best assigned to a corporate entity which spans the business departments and IT and is closely aligned with the overall business strategy.

The PMO should have oversight responsibilities for the entire life cycle of all projects (including non-IT). This will provide the best chance of addressing conflicting priorities, standarding across the enterprise, and aligning with the “business” objectives.

Application ROI

Calculating ROI for any application is difficult. If the application automates labor-intensive activities and reduces staff/costs for the business, it is easier. It is much more difficult to calculate ROI for applications that provide intangible benefits such as regulatory or quality control capabilities where you have to consider the cost of non-compliance. At the very least, the total cost of ownership should be calculated to include development/integration, operations and support costs and compare that to the estimated cost of performing the activity manually. You must also consider that some applications result in a net staff/cost increase because people are hired to input data and support the application.

When existing applications are consolidated, benefits and TCO should be calculated for the consolidated application.  Then you can compare against the indiividual costs/benefits prior to the consolidation.

Calculating ROI is impossible if an IT organization is not accurately tracking support and development costs and the business is not tracking the cost/value of the benefits obtained by the application. You can’t manage what you don’t measure.

Are you building “maintainable” applications?

Many development projects fail to deliver the desired objectives because project managers/architects do not consider operational and maintenance (post-production) requirements when they design a system. They complain about changing requirements because they are trying to “hard code” the requirements into the system. If they spent some time in maintenance, they would realize there will always be change requirements and the best solution is to build configurable systems where business decisions are tablized or parameterized. Trying to force the business to anticipate and specify all possible decisions and functions early in the project is impossible.

Successful project managers realize that future requirements cannot be anticipated or defined and that building flexiblity, configurability, and maintainability into a system is the best way to ensure long-term value.