The analysis and comparison of potential projects is a challenging exercise in Information Technology, for several reasons:
- Uniqueness: Projects are unique, and are often envisioned by different teams and/or in collaboration with different business units/departments
- Chicken & Egg: Resources are limited both in IT and in business groups, and fleshing out a project plan requires a significant amount of time from both. On the other hand, it’s only after that level of analysis has been performed that a clear view is formed of both implementation and benefits
- Mixed goals: Projects can be undertaken for a variety of reasons, including gaining efficiency, growing revenues, matching competitors to retain revenues, expansion horizontally (new line of business) or vertically (increasing owned share of the value chain), compliance, etc.
- Downstream/follow–on ROI: Some projects create capabilities which in turn shorten the distance to other goals and capabilities “downstream”, but traditional ROI analyses don’t factor in anything outside of the scope of the project under consideration per se
- Execution isn’t in isolation: Although project decisions are often made in isolation, they will be implemented or at least overseen by an IT organization that is also responsible for day-to-day operation of the existing systems, plus other project(s) in-flight
As a key part of our value proposition for clients, Innovation Vista has developed a proprietary approach for evaluating and selecting projects from a varied list of possibilities such as this engagement is developing. Due to limited information at the point of initial evaluation, no approach can be perfect, but our methodology does help mitigate the challenges listed above with specific aspects of the framework:
- Financial basis: To address the challenges of the uniqueness of each project and the mixed goals they target, we use an ROIC-based analysis to enable “apples & apples” comparisons across projects. This avoids common challenges where the most influential/largest/squeakiest-wheel groups get most of their proposals accepted, while support functions and small groups are neglected. It also avoids unfairly preferring small or large projects, depending on the risk appetite of leadership. Our goal is to truly judge where investment(s) of the company’s IT dollars will have the most impact
- Strategic factor: To account for “downstream” future ROI, and/or strategic themes/initiatives undertaken by the organization, a strategic bonus factor is used to raise the calculated ROIC for projects which align with strategic initiatives and/or bring followup benefits nearer
- Prequisite indicators: Projects which depend on other projects’ completion, or which are substantially simplified/enabled by those other projects, are marked as such, to make intra-project relationships clear, and to facilitate decision-making
- Span of control impact: To account for the variation in the implementation/oversight bandwidth needs for each project, particularly from IT leadership, a span of control factor is utilized to measure the % available oversight time each project would consume. This factor allows us to quantify the difference between projects which must be undertaken with internal IT, vs. those where surge/temp resources could be utilized, vs. those which could be outsourced with oversight only, and ensures that there is sufficient leadership bandwidth to avoid “gridlock”, in which multiple projects are waiting on guidance, decisions, etc. from a few key IT managers who have become bottlenecks to the process
Improved Project Prioritization Mindset
Viewed as a series of isolated decisions, it is typical for organizations to follow an approach along these lines in approving IT projects:
“Each project is judged on its merits, and those with a positive ROIC make financial sense, so we should approve them” (or at least where the ROIC surpasses the Cost of Capital)
Many organizations who undertake this kind of approach quickly find themselves in gridlock. In addition, this approach risks too little involvement and oversight of key IT managers, who should be ensuring that everything being undertaken aligns with the organization’s overall architecture, security, controls, and governance guidelines.. In general, the risks of project delays and mistakes are considerable.
Our Project Vista methodology brings several critical real-world considerations front-and-center for leadership, encouraging a more informed realistic approach to project decisions:
“Start projects with the highest ROIC and least oversight needs which can be started now, especially those which open doors for beneficial follow-ups – up to the limit of span of control of IT leadership and availability of qualified internal/external staff”.
Limited Approval for Planning & Design
Rather than initial “approval” being taken to mean funding and prioritization all the way through implementation, we suggest that only design and project planning be approved at the initial stage. Some organizations refer to this as “Provisional approval” or “Feasibility study” approval. There are several reasons we believe this is a wise approach:
- Reducing Estimate Uncertainty: to minimize upfront costs and business distractions, (and because of the large number of potential projects in consideration), only a surface-level analysis has been performed on each potential project, sufficient only to enable a “T-shirt sizing” of the effort and benefits, for the purposes of this initial prioritization decision. A detailed design and planning exercise ensures that actual “bottom-up” work estimates can be developed, as well as a clearer view of a project’s benefits in efficiency and/or revenue. Estimates appropriate for significant investments should at least have 30-100 detailed components articulated with enough detail for experienced staff to make an estimate on them for skill-sets and # days/hours needed, with appropriate load factor for collaboration. These estimates may or may not differ enough from the initial T-shirt sizing to change leadership’s view on a project, but even if the estimates are validated, there is value in having that confirmation before committing to the bulk of the project costs.
- Ensuring Quality Planning: with a limited approval and requirement to bring back a project’s design and project plan, leadership can be ensured that the planning effort is given sufficient attention and the design built in sufficient detail to maximize the chance of success of the overall project. Even in an Agile project methodology, the importance of this “iteration zero” phase is critical, and can surface both complexity and/or re-usable wheels which have enormous impact on the project approach (and estimates, as noted above).
- Additional Insights Before Committing: in addition to project details, sometimes corporate strategy comes into focus during the planning phase, particularly if several projects are planned in parallel. This provides an opportunity to factor in these insights before implementation begins on the project(s)
- No Impact on Overall Timeline: assuming that a leadership discussion can be scheduled on a timely basis (or asynchronously via email, etc.) there is essentially zero impact on the overall timeline for projects which “still make sense” after the design and planning are complete, since the team/vendor knows the assumptions made at initial approval and can therefore position to start implementation immediately after an approval by leadership, where such is expected.
Limited Discovery Approval for Outsourced Projects
There will likely be a few projects prioritized for which outsourcing is the ideal or sole solution. Some amount of planning may be offered at no cost by the service provider/vendor – especially for “turn-key” installations of their product for use at the company. In other cases, there may be a cost for a discovery/planning/feasibility phase with an outsource provider, just as there is when utilizing internal or surge/contract resources.
A few suggestions will help increase the chances of success with this approach:
- Be up-front in initial discussions with vendors about the project approach being adopted
- Encourage them to monitor the results of the design and planning process for alignment with the initial assumptions about the project – checkpoint calls may be necessary
Ask them to commit to a continuation of key project personnel for the implementation phase if implementation approvals looks likely.
A Model for Ongoing Leadership Optimization of IT Project Portfolios
We recommend making the project evaluation and initial limited approval process summarized above a recurring dialogue with leadership, IT, and business stakeholders sponsoring new project ideas:
- Initial analysis of new submissions – T-shirt sizing of effort, costs, efficiency, revenue benefits
- Span of control discussion as governor for how many new projects should be considered
- Approved projects enter design/planning, ideally to complete by next committee meeting
- Deeper analysis of projects designed/planned – effort, costs, efficiency/revenue benefits vetted
- Formal “approval” of build effort of team, engaging vendor(s), etc.
- Reject projects with degraded ROIC or span of control details vs. initial analysis
- Final accountability on completed projects
- Efficiency gains factored into budget(s)
- Revenue gains factored into target(s)
- Quality, compliance, security review to ensure implementation is acceptable
- Consideration of projects which had the completed work as prerequisite
Collaboration between business units across the firm and IT should continue on an ongoing basis, feeding new project ideas into this process for consideration, approval, and prioritization.
Please contact us to begin a dialogue about how we can bring our expertise to bear on your company’s strategic project prioritization and oversight…