Today, there are simply too many projects. Historically, CIOs have faced project backlogs, but now the to-do list contains both business and technology changes, plus those in healthcare are seeing significant regulatory changes as well. Technology analysts suggest there is just too much.

So how does a CIO survive this heavy workload and deliver critical projects on time, on budget, and with quality?

First, we need to establish a few key strategies:

• Review the project list. Does the project need to be done at all? Does IT need to do it?
• Prioritize the work. Work with business executives to determine what will get done with available resources. If additional resources or funding is still needed, collaborate with the business executives to address this additional need.
• Execute the projects effectively. A project management office adds value in overseeing the project workload. Use the appropriate project management methodology. In my experience, a lightweight project management methodology (let's call it "PM-EZ," like a 1040-EZ short form) was sufficient for most of our projects.

So why is project management important? Because project delivery is a key expectation of IT.

If IT cannot deliver critical projects on time, on budget and with quality, additional projects will not be requested. Alternatives such as outsourcing will be considered, and IT will not become a trusted partner of the business.

I suspect many of us, if asked, would say we want to make a difference, to have an impact on the business. Here is such an opportunity. Projects can make a difference in product, service, cost, growth and more.

With too many projects, where do we start? Let's begin with these four steps for attacking the IT project list:

1. Does the work need to be done at all?

Can the work be eliminated? Does it call for a business process change rather than an IT solution? In many situations I have encountered, the business user has already drawn his/her conclusion and simply wants IT to execute it. Before diving in, rethink the need using your IT knowledge and experience.

I recall an example in which IT was asked to speed up printing. When the user department was questioned about the underlying need for printing, it was to demonstrate to IT that the business had completed its testing of a product change. As CIO, I trusted the business team at their word that the testing was done, and no printing was necessary. The project was dropped from the list.

Do you have examples like this on your project list?

2. Does IT need to do the work?

Years ago in healthcare, our discretionary IT resource ran about 17 percent. These were resources we could allocate to important but discretionary projects. With the tidal wave of regulations, that discretionary number dropped to zero.

Regulations and maintenance were all-consuming. So it makes sense to ask who else might be able to do this project — the business users, a business partner, a technology vendor?

3. Prioritize the work IT must do

From the list that survives 1 and 2 above, apply one of Stephen Covey's "7 Habits of Highly Effective People" — put first things first. In case IT does not make it through the entire list of projects for some reason (resource issues, etc.), at least the most important projects will have been addressed.

Apply a prioritization process. Here is one:

• Look to the strategic plan, both enterprise and division levels, to make sure key projects needed to accomplish the plan are indeed on the list.
• Assemble an IT plan. Start with an overall technology assessment. Red means danger; something that will break if not addressed. Yellow is a risk and should be fixed if the budget allows. Green is OK as is. To address components that are red or yellow, add upgrade projects to the list.
• Rank the work in order. You may use a formula weighting certain characteristics, like revenue generation or cost savings. Involve business executives in the prioritization process. This involvement will clarify what is really important to the business, and it will help educate the executives on IT issues and constraints.
• Draw a line on the project list where resources are used up. Project completions beyond that point should not be expected. If key projects fall "below the line" and cannot be done, consider adding staff or adding contractors or outsourcing the work. With business executive involvement and collaboration, these decisions become company decisions not just IT decisions.

4. Execute the projects effectively

Establish or foster use of a project management methodology. This adds consistency to how projects are executed, tracked and reported. Projects are difficult; a methodology will help the odds of success.

Establish or foster a project management office (PMO). Reporting to the CIO, the PMO works with project leaders to reinforce the project methodology, and also mentor on its use. The PMO monitors project milestones and results, and provides a high-level status summary. Typically, this executive reporting can take on an executive-friendly, red/yellow/green format.

Leverage a light project management methodology, like a form 1040-EZ for taxes. In my experience, a full project management methodology may be too much for a given project. Ends and means can become confused, with an emphasis on completing the PM forms and not on delivering project results.

If you are not sending astronauts into space, you may consider using the following lightweight project management methodology, which I call PM-EZ:

• The Project Charter, like an overall statement of work, defines the project objective, key roles and responsibilities, milestones, communication approach (e.g., status reporting), overall schedule and costs. With sponsor signatures, this launches the project.
• The Project Change Request is the vehicle for changes in deliverables or time frames, with acknowledgement of the impact of those changes. With IT signoff, this form makes those changes official.
• The Status Report gathers status information on a regular schedule (weekly, monthly, etc.) on project costs, timing and milestones, and presents it in an executive-friendly red/yellow/green format. Where something is red or yellow, state briefly the actions you are taking to make this element green. This demonstrates that you are watching the total project, are taking corrective action where needed, and will report again on the defined schedule.
• The Issue Log tracks the various challenges that arise, who is assigned responsibility for resolution and the final outcome. This is helpful in assuring that each issue is addressed, and helpful in the Lessons Learned meeting at the end of the project.
• The Project Closure and Signoff recaps the charter and results, and looks for sponsor sign-off that the project has indeed met expectations on cost, time and quality.
• The Lessons Learned meeting recaps the project journey — what went well, what did not go well. How can the methodology be improved for the next project? Continuous improvement is the goal.
• The Celebration is the final step. Don't forget to celebrate! Invite the business stakeholders, the project team and vendor partners who were involved. The Lessons Learned session can be combined with celebrating the project success. Our celebrations typically involved cake. I personally served cake to attendees as a gesture of my gratitude for their efforts. This is effective in building relationships with all involved, especially the vendor partners.

Results

While we were early in the development of our PMO and our PM-EZ methodology,we were able to detect problems (e.g., heading over the project budget) early enough to take corrective action. We communicated status better and with greater consistency, enhancing our partnership with business executives, and IT delivered key project successes (and enjoyed cake).