Why we do things - ROI

Long ago, one of my professor's told me, "The purpose of education is to increase pleasure enjoyment." I've yet to fully grasp exactly what he meant (he was a professor of philosophy and often spoke in riddle), but I think it was something along the lines of, "Knowledge allows us to improve our station in life." It may take the form of allowing us to obtain better jobs, improve our ability to appreciate things or allow us to take better advantage of the opportunities presented to us.

Let's examine a familiar concept - investing. Whether it is because we want to be able to make a large purchase (a house or car), enjoy a comfortable retirement, or live out some of our dreams, most of us are putting money aside. This money is invested based on our individual risk / reward preferences. If you lie awake at night worrying about your investments, you may be outside of your risk / reward sweet spot.
Individuals who want to be safe, invest in financial instruments such as money market mutual funds, treasury bills or other assets where the risk of losing the investment is small (note that small risk generally implies small potential return.) Individuals with a higher risk tolerance purchase financial assets with higher potential returns.

The prudent investor analyzes their assets periodically to ensure a suitable return on investment (ROI) is being realized. There is a good guide on ROI available on SearchCIO.com explaining basic ROI concepts from a business perspective.

I want to introduce another concept - opportunity cost. Opportunity cost is defined as:

The cost of an alternative that must be forgone in order to pursue a certain action. Put another way, the benefits you could have received by taking an alternative action.

In business, all else being equal, you fund projects that have better rates of return for your company. Businesses use capital from their shareholders and money they've borrowed to fund their projects. Furthermore, a company is expected to invest in projects with ROI that exceeds their opportunity costs (e.g., projects that make them grow!) From the perspective of an individual investor you probably wouldn't be willing to purchase shares in a company that wasn't trying to increase its future earnings. Would you?

Thus, in business the ultimate goal is to increase profitability. A business does this by undertaking projects that are expected to yield a return above their opportunity cost. These projects have specific goals and objectives that support the business' strategy. This is why it is important to tie requirements back to business goals and objectives. As well as business goals and objectives back to strategy.In business and in our personal life, we do things to improve, to grow, and as my old philosophy professor would say, "...To increase pleasure enjoyment."

Webinars: PPM & ITIL

Here are some webinars that may be of interest. Note that you may need to sign-up to get access to them.

Project Portfolio Management for the Skeptical IT Organization
You want to run IT like a business; you know Project Portfolio Management (PPM) can get you there, but you are worried about long implementations, high price tags, and consultants taking residence in your shop. In this webcast you'll learn how a web-based model with the right level of functionality has helped organizations like yours get a PPM solution up and running in two weeks and producing value right away.

Part I: Introduction to ITIL for the IT Executive - Podcast - Expert Podcast
Based on a practical approach to addressing real-world challenges of IT service management, ITIL allows organizations to better package and deliver IT services to their customers. ITIL enables IT organizations to align their capabilities with business requirements.

Disaster Recovery, Requirements Management & Alignment resources

Here are some resources I've come across that may help you.

Requirements management
Best Practices for Enhancing Project Success is a recorded webinar that you can watch at your leisure.

More than 70 percent of software project failures can be traced to poor requirements management. The root cause: the gap between what the business team wants, and what is communicated to IT for delivery back to the business.

Disaster Recovery
CIOs lack confidence in their DR plans

IT execs are insecure about their disaster recovery plans.

That's according to a new survey by Rochester, N.Y.-based Harris Interactive Inc. that reported 39% of executives polled gave their plans a letter grade of C or worse, revealing a troubling lack of confidence in disaster readiness.

The survey results also indicated that this lack of confidence in disaster recovery planning is growing. A similar survey conducted in 2004 found that only 24% of executives gave their plans poor grades.

ALL-IN-ONE GUIDES: Disaster Recovery

This All-in-One Guide will get you on the path to a good, solid DR plan and show you what you need to do to maintain it. It starts you off with DR planning and design with understanding recovery capabilities and tools, and then takes you right through to DR implementation, security and testing.

Alignment
IT/Business Alignment

The IT/business alignment topics page provides CIOs and IT management with up-to-date information and resources on budgeting, IT governance, IT spending, leadership and strategy, and Return On Investment / Total Cost of Ownership.

1, 2, 3 align your projects!

What are the steps involved in aligning projects to a strategy?

1. There are many different projects that a company can undertake. The first step is to create a list and make sure that everyone understands what each project is about.
   
2. Determine the criteria you will use. Your criteria should match your strategy and be representative of the direction you want your company to follow. For example, if you want to be a low cost provider, one of your potential criteria could be, "that a project should reduce the costs of service or increase the efficiency of providing service using your call centre."
   
3. Some things are more important than others. Weight your criteria.
4. Let the project sponsors individually score the importance of the projects using your criteria. Tabulate the results to reduce bias that the sponsors may have towards a one project or another. Projects that score high align more closely with your company's strategy and direction.
   
5. Establish high-med-low groups of projects.
   
6. The groupings and individual rankings form a basis for prioritizing.

By the end of this process you will have determined objectively which projects align better with your overall strategy and goals. Note that there are factors other than strategic fit that determine which projects will ultimately be undertaken (e.g., compliance, ROI.)

Project prioritization goals

Continuing on from my post, Why prioritize projects?, prioritization is important because,

1. It provides focus to the more important initiatives. Companys can concentrate on what really matters to them and not be distracted by the latest fad.
   
2. Money, time and people are scarce resources. Proper management and effective use of these resources can only benefit a company.
   
3. In order to prioritize projects you much be able to compare them against each other objectively. This apples to apples comparison removes bias from decision-making.
   
4. Clear direction and visibility to everyone in the company, not just the main decision-makers. Everyone is on the same page. We all know what can happen when things are not clear.
   

Stop 'gathering' IT requirements

There's a post on Techrepublic titled, Project Managers: Stop "gathering" IT requirements.' It's an interesting read.

And when I ask why projects get bad requirements, the answers are, "Users won't tell us what they want," or "We don't ask good questions," or "What they told us they wanted turned out not to be what they really wanted." But I think that the problem is more subtle than any of those answers.

The author, Paul Glen's, point is that, "project managers should negotiate requirements among the stakeholders." My comments on the article are as follows:

• In order to negotiate well, a project manager really has to understand the nature of the project and client ask. If the project manager doesn't understand the ask (e.g., isn't familiar with the business), a strong supporting cast is needed to keep everything real. Are you more confident when you know your project manager has lead projects similar to the one you are on or is very familiar with the industry?
  
• Requirement 'gathering' means collecting requirements, however, a business analyst is paid to understand them, derive meaning from them and then communicate the underlying business objectives. To me, this is the core competency of the role. The article does not really talk about this. You do not need a business analyst to order take.
  
• The following comment from the article seems a bit over the top, "We should think of a set of requirements as being like a multilateral treaty among a group of nations." I understand the need to have clear understanding and expectations, but this sounds like something people do when they don't trust each other.
  

I think, if anything, this accentuates the need to have a strong capable business analyst.

Why prioritize projects?

Projects are initiated to capitalize on opportunities (the Chinese character for crisis is the same as opportunity I've been told) that a company faces. However, not all projects are created equal.

To quote George Orwell's Animal Farm, "All animals are created equal, but some are more equal than others." Some projects are more beneficial than others.

Prioritizing projects is very much like managing investments. In fact, it is the same. How likely are you to perform due diligence before making an investment decision such as buying a bond?

You need to understand:

• The anticipated returns
• The potential risk
• The timing of the returns
  

With this information you can perform a net-present value calculation to determine the value of one investment versus another. Combined with other factors such as your risk-tolerance and investment goals you'll choose the most appropriate ones for you. The purpose of all of this is to introduce objectivity into your decision-making.

Extending this principle to project prioritization means you should:

1. Understand how important a project is to you. How well does it align with your objectives?
   
2. Prioritize your projects early to allow for lead time for effective decision-making.
   
3. Introduce objectivity into your prioritization process. Just because someone yells loudly does not mean his project is the most important.

Do not take the position that:

• Prioritized projects must be executed sequentially. Some minor projects are dependencies for others. Some projects are easy to slot into non-peak times.
  
• You only prioritize when you need to make a decision. The earlier you prioritize, the more potential problems you can avoid before they become critical.
  

It's a bigger world

We've all encountered situations where difficult decisions had to be made concerning a project.

• Should we continue?
• What features do we need to pare back?
• Do we need more money?
• Are we missing needed skill sets?
  

These decisions are normal things that occur within any project. However, the ramifications for handling them may impact things outside of the project in question. What if an increased budget means another initiative has to go unfunded? Or perhaps the added resources need to be taken from another project's resource pool?

Instead of managing a specific project, decisions have implications across a collection of inter-dependent projects. The management of the collection is termed program management. The purpose of program management is to use the scarce resources and funds available to orchestrate projects to deliver maximum benefit. If you've taken basic economic theory you may remember the definition of scarcity.

The basic economic problem which arises from people having unlimited wants while there are and always will be limited resources. Because of scarcity, various economic decisions must be made to allocate resources efficiently.(Investopedia.com)

It's true, you just can't do everything!

One thing I was told very early about projects is that, "Projects end. If it doesn't, then it's not a project." If that's true, then programs, being a collection of projects, end as well.

But we also know that businesses constantly evolve. Their products and services are impacted by innovation and change caused by internal or external sources. If you will, the portfolio of service offerings evolves continuously. To me, I view this evolution as portfolio management. Clearly, this terminology evolved from finance however, it is also applicable to the management of a company's set of offerings and how they are transformed over the passage of time.

The art and science of making decisions about investment mix and policy, matching investments to objectives, asset allocation for individuals and institutions, and balancing risk vs. performance.

Expanding further upon the concept of program-wide decision-making is the notion that decisions across a portfolio can have implications in many of the different programs within it. A portfolio is governed by the higher level strategic goals of a company whereas program decisions are governed by lower level objectives.

For example, suppose one of your strategies is to become a low-cost provider for a given product. Your product development team may look at projects that reduce the cost of the materials used while your service team may reduce the number of agents who handle customer inquiries and beef up the self-help sections of your website. Together, these two programs work towards meeting your strategy.