How do large enterprises still fail to make the right IT investment choices? Why do line executives still feel disconnected from the priorities of the IT function? Why do CIOs and senior IT executives still struggle to explain their priorities in a way that is understood by the rest of the organization?
Our last article, State of the Art Portfolio Management Isn’t Good Enough Anymore, identified the problem: organizations continue to describe projects primarily as technical implementations or deployments of features. And this perspective is prevalent whether the enterprise is using waterfall or agile development methodologies.
As the previous article demonstrated, defining proposed project investments in business terms, measurable against a baseline, results in a robust, informed debate about the relative priorities and objectives of the proposed investments, which yields better decisions and buy-in and commitment in the executive suite.
The general intent is to shift our thinking about how we define projects – from those defined solely in terms of IT, to those defined as a business improvement project with an integrated IT component.
“Business improvement” does not need to be expressed in financial terms. While expense reduction, revenue increase, or margin improvement are often excellent measures of improvement, it is equally effective to measure project objectives in terms of defect reduction, cycle time reduction, or customer satisfaction increase.
Defining the business improvement and how it will be measured makes it easier to set the correct scope, budget, and resources so that the project can be executed successfully. Oftentimes this results in a less-expensive and shorter-duration project. It also makes it easier to ensure the committed participation of the non-IT organizations, a common complaint heard from IT executives.
Marrying this fundamental shift in mindset to the portfolio management and investment decision making process is the missing factor that will elevate your enterprise’s return on investment over its peers.
So, how do you make this a reality in your own organization? You may be surprised to learn that it is not difficult, nor costly, and that you can realize greater business benefits while reducing the level of IT investment necessary to achieve them.
As we’ve been stressing, your objective is to ensure that proposed projects are now defined as “business improvement projects with an IT component,” and contain objectives “in business terms, measurable against a baseline.”
This transformation will make use of several foundational capabilities, which likely already exist in your company and are designed to improve process performance.
- Business Processes and Process Metrics
Processes such as “Order to Cash”, “Requisition to Pay”, and “Record to Report” are all examples, and many organizations have associated process metrics to measure the performance of each of these cross-functional processes.
- Lean / Six Sigma Capability
Some enterprises deploy their LSS expertise via internal consulting organizations, some via an informal network of LSS practitioners scattered throughout the organization, some via long-standing relationships with external experts, and many via some combination of “all of the above.”
- Scoping & Business Case Phase for Projects
Standardized project execution methodologies can take the form of IT project lifecycle methodologies, DMAIIC or Lean methodologies, engineering and construction methodologies, etc. Many of them incorporate an initial “scoping & business case” phase already, and if not it is straightforward to define one.
When IT or business leaders in your organization are exploring a new project, they need to be directed first to answer the question, “How will the business be better off if the project is successful?”
Be prepared for an answer that still describes the project in terms of the technology or functionality that will be delivered, such as “this project will deploy the new supplier portal to 80% of our Tier 1 suppliers by June, which brings an annual vendor spend of $xMM under the management of the new system. The project will be delivered within the budget estimate of $x, plus or minus 5%.”
Give your team credit for creating a decent first draft — they have some quantified objectives for the project, and it looks as though they have used some good business judgment to set the scope to be “80% of our Tier 1 suppliers.” Not too many teams have a starting point this good.
However, a closer examination quickly identifies some gaps in the project definition. The most important issue to resolve — Once you have 80% of your Tier 1 suppliers and the associated vendor spend of $xMM under the management of the new system, how will your company have benefitted?
A project like this could be focused to deliver different benefits, such as
- PO requisitions directed to the suppliers offering the lowest price for the item
- Renegotiated pricing based on improved knowledge of the various prices being offered by different suppliers for the same item
- Volume for certain items shifted to one or two preferred suppliers, in return for obtaining improved pricing
- Business shifted to suppliers who offer the highest quality, shortest lead-time, or best delivery performance
- Identified supplier risk, and assurance that critical materials have viable alternate supply sources
- Improved productivity of the Procurement organization via automation
- A percentage of vendor spend redirected to diverse suppliers
- Sarbanes-Oxley or other compliance risk remediation implemented in procurement practices
The business sponsor of the project, not the IT sponsor, needs to answer this question. Be prepared for an answer resembling “all of the above”. This is a sign that the project still lacks required clarity and focus. It may also indicate that the project sponsor hasn’t committed to any specific benefits as part of the project, and is relying on actions after the system goes live to deliver benefits.
Help redirect the project sponsors to revisit the primary question — how will your company have benefitted? And provide a limited 1-3 objectives, expressed in business terms and measurable against a baseline. Generally speaking, having fewer objectives is preferred, as it improves the focus of the project. The adage, “If everything is a priority, nothing is a priority,” applies particularly well in this situation.
It may take a few weeks for the sponsors and the project team to conduct their analysis and develop a recommendation. It may also require a small amount of seed money to provide resources to measure the current performance, analyze how the project can improve the current performance, and prioritize the possible project objectives. If you have access to Lean/Six Sigma resources, this is a perfect way to use them. If you have existing measures of process performance related to the procurement process, this is an invaluable starting point.
After a period of hard, yet energizing work, the team and sponsors will come back with recommendations. If they’ve done a good job, the revised project definition might look something like this:
The objectives of this project are to
- Improve pricing by 5-15% on 20-25 commodity items representing $xMM annual spend. This translates to $x-yMM favorable price variance on an annualized basis. This will be accomplished by renegotiating contracts, selecting preferred vendors for these items, and enforcing vendor selection during the requisitioning process using the new system. These benefits will start to flow in x months, even prior to the go-live of the new system.
- Institute an ongoing contracting process to all Tier 1 suppliers, representing $xMM annual spend, providing favorable price variance of $x-yMM over the 3-year period post go-live.
- Deploy the new supplier portal to 80% of Tier 1 suppliers by June, and the remainder of all suppliers by October, within the budget estimate of $xMM, plus or minus 5%.
This is a very compelling project benefits case. It’s possible that the annual P&L benefits just from the first objective could exceed the capital and expense required by the entire project – thus making the project self-funding.
Let’s go into some greater detail about what the team likely discovered, based on the requirement that the project objectives be “in business terms measurable against a baseline.”
First, the team had to mine their existing data to create the baseline. As part of that work, they identified 20-25 specific commodity items that could be renegotiated. Furthermore, they realized that these renegotiations could begin even before the new system went live. That way, the contracts could be in place, and the benefits would begin to flow earlier. Once the system goes live, the benefits are likely to ramp up because the company will be better able to enforce a requisitioning process that directs purchases of these 20-25 commodity items to the preferred vendors.
Second, the team was able to outline, at a high level, how an ongoing contracting process would operate once the new system is in place to provide an easier way to analyze vendor spend.
Finally, the team realized the importance of an improved requisitioning process to direct PO requisitions to preferred suppliers. In the absence of this process, it is likely that requisitioners would continue to purchase from their favorite suppliers, and your company would have difficulty delivering on the preferred vendor commitments your Sourcing team makes.
You truly could stop here knowing that you have a very solid benefit case and scope. Because it is expressed in business terms, measurable against a baseline, instead of IT terms, you will be able to have a robust prioritization discussion leading to clear agreement and buy-in among the executive team about funding this project. Because the project sponsors and team are very clear about what they must deliver, and how success will be measured, project execution will likely be much stronger.
If you don’t want to stop there, there are further optimization opportunities to consider. A detailed discussion is beyond the scope of this article, but here is an example:
Since the team can analyze supplier spend without the new system, can you defer that part of the project to a second phase, and focus the first phase solely on implementing the PO Requisitioning process? Your Sourcing team can mine their data the old way in the short term, and identify a second wave of commodities to renegotiate. In the meantime, by focusing only on the requisitioning process, your IT team can deliver that functionality sooner, which means your benefits ramp up faster. Then, in a Phase II, the team can migrate the vendors to the new supplier portal, which will make it easier for your Sourcing team to analyze commodity and vendor spend for subsequent renegotiations.
With a small amount of up-front investment in developing project objectives “in business terms, measurable against a baseline,” you can increase the benefits, reduce both the cost and time of your project, and ensure informed buy-in across your organization about your project investment choices.
Chas Hartwig | TayganPoint Consulting Group | email@example.com | @chashartwig