Wednesday, March 02, 2011

what projects does the Enterprise consider to be most valuable?

...continuing from the previous post...

The key question then is: what projects does the Enterprise consider to be most valuable? And the follow-up: how does it determine the value of any one project, so it can be evaluated against ‘competing’ projects?

In private enterprise, the single common goal is sustained profitably , through a varying combination of revenue increases and cost reductions. Projects are often used to change how a company operates in the expectation that such change will deliver the desired revenue increase or cost reduction, and deliver it such that the value of the changes is not exceeded by the cost of the project itself.

So, we have two aspects of a project that will usually be used to determine its value:

1) Its impact on revenue or costs of the enterprise, commonly known as Benefits.

2) The Costs of carrying out the project (which some refer to as the ‘investment’)

Given these two dollar numbers, which is what they should always boil down to, you can then use them in one or more forms of what is commonly called a ‘Cost-Benefit Analysis’. However, neither number just appears out of thin air, and any numbers you do come up with will never be exact, because estimating is involved

Lets’ start with Costs (it’s easier than Benefits, at least); essentially you need to define what resources, services and purchases will be needed when executing a project.

IT Project Costs

A typical IT project will involve IT people resources, of course; analysts, designers, programmers, testers, trainers, etc... The titles may be different at your company, but the people will be performing these roles. The question, of course, is how much of the valuable time of these people will be needed, and how much that does that time cost? This is when the estimating begins.

My experience with estimating has led to always determining how accurate an estimate needs to be. When using cost estimates as part of a gating process, I find a reasonably supported estimate done in a short time will suffice. I have heard an initial estimating being referred to as “t-shirt sizing”; is it small or medium or large or extra-large, etc. Even this needs some context for a company, usually by classifying past project actual efforts the same way.

This supports the simple approach of “Is this new Project X the same size as a previous project we have carried out?” Assuming your company has kept the metrics about previous projects, and that is a big assumption, you can then extrapolate the size and cost of any similar new projects.

True, some one has to lay it on the line and decide if a new project is reasonably similar to previous projects, and the person doing that should probably define some assumptions about why they believe so. This allows the decision makers to agree with or challenge the assumptions as needed, until all are agreed on the assumptions and accept the resulting estimate.

If you have no metrics history to use, you may need to do some project planning to define the tasks likely to be carried out. Again, a whole other big discipline exists for project planning and management, and use of techniques of like Work Break-Down Structures (WBS).

The only thing I emphasize in this approach is that as much as possible, people who would do the work should help in defining the necessary tasks, and then they most certainly should do the estimating of effort (usually in hours or days) of those tasks. They know best what will be needed, and will make sure they are happy with the estimate because they will likely have to work to that estimate when the project starts.

In the end you will have a number of effort hours or days, and then you need an accepted price for an hour or day. Some shops will use a flat rate for all hours, while others will group the hours by role or seniority to get a range of rates. In either case, you multiply the hours/days by the price(s) and you have a cost. Other costs may be involved as well, especially one-time purchases of equipment or software needed by a project.

To go along with this cost, you will need an estimate of elapsed time for the project to execute and finish, because most benefits will not be realized until a project is over, and (later on) you will want to compute a present-value of future costs. More assumptions are needed; how many people will be assigned, what work can be done in parallel, etc. If you have used a project planning approach, you will have the advantage of defining many of these things already and will have come up with a project duration along with the project effort.

That's Costs... next time : Benefits

See more about Cascade on Amazon http://amzn.to/gbgYNJ ; On Sale(!) at lulu.com http://bit.ly/92k1gf

No comments:

About Me

Ontario, Canada
I have been an IT Business Analyst for 25 years, so I must have learned something. Also been on a lot of projects, which I have distilled into the book "Cascade": follow the link to the right to see more.