Picture the Monday morning meeting that you have to attend after coming back from Symposium. It’s you and your CIO and SVPs. The Topic: What is one innovative/mind blowing idea should we (WE MUST!) start doing/implementing now.

For years we’ve heard about such topics as Real-Time Infrastructure, Server Virtualization, VOIP, Service-Oriented IT, ITIL and others.

I would submit that these topics are NOT innovative. To borrow a term, these topics are “birthright services” for I&O.

For some companies there are significant benefits to be gained by improving their implementation of some of these topics but you are not success in today’s game if you’re not doing this stuff! Every CIO has heard (heard the words but maybe not gotten the message) about these topics. Rehashing these same themes is not going to make an impact.

What’s innovative these days?

(Question from “capstick” on the Gartner Symposium Forums)

Honestly, I don’t believe that there’s anything really new. But there are a lot of “old” opportunities that a lot of IT groups aren’t exploiting.

The biggest one that I can think of is true collaboration with the business and a sense of partnership at all levels of the business and IT. At the top, that includes making sure that IT has a seat at the table. There needs to be a continuous dialog concerning what opportunities the business has and how IT can help to exploit them. Tools that provide the visibility (both ways) and facilitates that communication are part of that. But the behavior is the most important thing. Everything else is just an optimization exercise to squeeze out more work at less cost.

There are a few “game changing” technologies, but the real Innovation comes from process and culture changes, not from the tools themselves. IT should be a facilitator of Innovation and should be engaging the business to find the application and business value in the tools. To do that, we need to get out of the commoditization mindset and back into one of business partnership.

In rank order, what are the criteria you use to drive prioritization of the various projects and programs in your portfolio?

Question received via Gartner Symposium Forums

1. Discretionary vs Non-Discretionary

This requires the discipline to accurately categorize your projects. “Non-Discretionary” simply means that if you don’t act, something in the organization will break. Whether it’s a process, tool, or technology, there is a better than even chance that a failure to approve the project will result in damage to your business. This doesn’t mean that you miss an opportunity or you fail to make a sale. It means that you will suffer some sort of loss or degradation of your operation. A technology refresh is discretionary unless something is very likely to fail or put you into a position where you will be harmed by not upgrading.

Most organizations don’t have the stomach to draw the line that distinctly. “Non-discretionary” becomes “politically prudent” and “Discretionary” becomes “good to do, but nobody is really pushing for it”. The problem is that if you follow that model, you’re very likely to start cutting into Non-discretionary projects when money gets tight and there’s no way of knowing what was *really* critical to your survival. By definition, a non-discretionary project is something that has to be done or some other risk mitigation takes place. It can’t simply be rejected.

2. Required timeframe (is there a critical window of opportunity or risk?)

This applies to all projects. Again, many organizations put arbitrary schedules and timelines in place which undermines the ability of the portfolio manager to understand what the “real” time constraints are. When you establish your portfolio, there needs to be a clear distinction between a “requested date” and any actual time constraints on the project. Unfortunately, most tools that I’ve worked with don’t make that distinction.

3. Benefit (or risk avoidance)

Once you’ve determined the criticality and hard time constraints, then you can start looking at benefit realization or risk avoidance. Most organizations start here by prioritizing strictly based on ROI. However, the PMO and the project teams have to address the critical time-constrained projects in the margins to keep the company running. If your house is on fire, you need to deal with that first and not worry about selecting new carpets.

4. Cost/Cash flows

This and the next category are what’s going to control the actual flow and scheduling of your projects. Once you have your prioritization sequence in place, you can start allocating your cash flows for the next month, quarter or whatever planning calendar you work with. This allocation will end up being iterative with the next category. However, it’s important to recognize that resource constraints can often be addressed with external consultants or some other form of outsourcing. Budgetary constraints tend to be firm.

5. Resources

Once you know what you have to do, the windows for doing it and what money is available to do it, resources are the final gate. If you don’t have resources in-house, consider planning for the development of new resources in-house (time permitting), acquiring staff or outsourcing as appropriate. While this is the biggest practical limitation on executing your project, it’s also the one where you have the most flexibility.

Other factors such as strategic fit, synergies between projects/programs, missed opportunity costs, balancing the availability of critical resources, etc. all come into play as the portfolio is optimized. In addition, this is a recursive process. So sunk costs, project performance-to-date, and other metrics are also included in subsequent review, but may not be part of the official “checklist”. Instead, they become factored into the other elements like the anticipated benefits, risks and risk avoidance.

What’s more important in business process improvement initiatives – spending money on the technologies that enable them, or spending time changing the behavior of those involved in the process? And what are some best practices for doing the latter?

– Question from Gartner Symposium

Good tools just allow bad processes to fail faster and more efficiently. I’ve been part of a number of BPI/BPM initiatives and those that have tried to drive a process with the tool have ultimately failed (usually blaming their failure on the tool) while those that have built the processes and behaviors independently have been successful. In addition, tools come and go. Once the tool is gone or changed, the organization will backslide if they don’t understand and embrace the underlying processes and behaviors. Just ask any CMM, CoBIT or ITIL consultant.

The most pleasureable and smooth projects that I’ve worked on have been “bottom up”, allowing the people that do the work to be part of the process definition, analysis of the pain points and ultimately driving to a consistent set of processes that they feel pride and ownership in. Then the tool becomes just that; a tool to implement “their” process. We broke this down into a 6 step process:

-Develop Awareness – Explain why BPI and what’s in it for them. VERY IMPORTANT to be honest and direct as to why you want to do this. A lot of people assume that it’s a precursor to outsourcing/offshoring.

-Understand – Identify how they do things today and what their “pain points” are. Document the processes as they are and any issues. Don’t solve the problems. Just listen and document.

-Envision – What would make things better? In a perfect world, what would be changed? Define the ideal processes, procedures and workflows. Focus on what they can change and don’t let the group descend into complaining about things that they *can’t* change.

-Focus – Stress the goals of the overall BPI initiative and work with the workers to prioritize the proposed process changes.

-Implement – Implement, measure KPIs and publicize the successes. Address issues as things to be resolved, not as failures. Make sure that the team continues to be recognized for their improvements.

-Automate – Bring the process into a tool. While it’s generally easier to drop in a tool and use it to drive process, there is a bad habit of making the process fit the tool rather than the other way around.