Assuming you got through the rough stuff of defining costs and benefits, the analysis should be simple. What you want to know is if the benefits of the project will exceed the costs, and by how much. Since costs and benefits may be spread over long periods of time, Present Values of these amounts are also usually calculated to compare the amounts in “today’s” dollars.
When I did my first Cost-Benefit Analysis for a major project, I had to work with a spreadsheet expert to do these calculations; now you can probably download something for free or a nominal fee that will do basic and advanced calculations. The key things these tools need is the cost and benefit dollar values, and the length of time of the analysis. The latter is usually defined by accounting standards at your company, and the most popular time periods used are three years and five years, often based around your company’s depreciation procedures/periods.
Given that, you can usually get calculations like:
• Break-Even Point, the point in time when the benefits realized exceed the project cost
• Various rate of return and yield values, like IRR.
These calculations may be used to determine if a project passes a funding hurdle; it’s not enough that a project makes money, it has to make more than investing the equivalent dollars of the project cost in securities or other investments.
After all this is done, a project can now proceed into the gating process to see if it has enough expected value to warrant its being initiated and carried out. Of course, if your analysis has determined already that the project does not have positive return or does not surpass the hurdle rate, you can stop now and move onto the next project idea. Determining that a project is not good for the business is just as valuable as finding those projects that are good for the business. Resources should not be wasted.
And that's it for now, comments welcome.
Wednesday, March 23, 2011
Wednesday, March 09, 2011
Defining the benefits of an IT project is a different issue from defining costs;
...continuing from the previous post...
Defining the benefits of an IT project is a different issue from defining costs; the latter may not be easy to calculate, but it can usually be done. However, benefits are usually in the mind of the people who want the project done, and generally are not easy to get defined and get a dollar value assigned to them.
In fact, the definition of benefits for IT projects does not exist as recognizable discipline. If you go searching for it, what you will always get is the answer that business sponsor/owner has to tell IT what the benefit is. If they can’t reasonably describe and quantify a benefit, then the project will not happen.
In the early days of IT Projects, the stated benefit was usually the automation of manual effort; this was not always as simple to propose as it sounds, because automation usually was translated into reduced head count for the business. If the staff in the area affected by a project perceived it could lead to lay-offs, this could kill a project because you almost always need those people as the business experts for the business scope of the project. I wrote many project proposals that had reduced manual effort as the prime benefit, but further described these savings as allowing the enterprise to take on more business without adding more people, or freeing up people to do new more valuable work for the enterprise; reduction in headcount was never mentioned.
However, automation of manual work as a benefit could usually be quantified in dollars in potential saved salary costs. The problem today, however, is that all the obvious automation projects have probably already been carried out at your company. This leaves smaller or less obvious cost-cutting projects (taking orders on-line saves on paper costs...whoopee!), or, projects that are expected to increase revenue/income.
The question becomes: how much will such a project contribute to increased sales of products and/or services? This is difficult to predict, and most business people are leery of attempting to do so. Just like IT Project teams are held to a project estimate or be considered late/costly, business people who estimate revenue increases can be held to task if it is perceived that the expected increase did not materialize. An interesting corollary development is the increase in the number of companies that are evaluating projects some time after they complete (six months or so) to see if the promised benefits have been realized. This can make business people even more wary of putting their names to what is and should be treated as an estimate.
In the end, however, some dollar value of benefits needs to be proposed and agreed to, if a cost-benefit analysis is to be performed. All I can say here is that, like all estimates, stating your assumptions and having them agreed to as the basis of your estimate is crucial. If reality proves that one or more assumptions turn out to false, then everyone involved in the project shares responsibility.
Next time: Cost - Benefit Analysis
See more about Cascade on Amazon http://amzn.to/gbgYNJ ; On Sale(!) at lulu.com http://bit.ly/92k1gf
Defining the benefits of an IT project is a different issue from defining costs; the latter may not be easy to calculate, but it can usually be done. However, benefits are usually in the mind of the people who want the project done, and generally are not easy to get defined and get a dollar value assigned to them.
In fact, the definition of benefits for IT projects does not exist as recognizable discipline. If you go searching for it, what you will always get is the answer that business sponsor/owner has to tell IT what the benefit is. If they can’t reasonably describe and quantify a benefit, then the project will not happen.
In the early days of IT Projects, the stated benefit was usually the automation of manual effort; this was not always as simple to propose as it sounds, because automation usually was translated into reduced head count for the business. If the staff in the area affected by a project perceived it could lead to lay-offs, this could kill a project because you almost always need those people as the business experts for the business scope of the project. I wrote many project proposals that had reduced manual effort as the prime benefit, but further described these savings as allowing the enterprise to take on more business without adding more people, or freeing up people to do new more valuable work for the enterprise; reduction in headcount was never mentioned.
However, automation of manual work as a benefit could usually be quantified in dollars in potential saved salary costs. The problem today, however, is that all the obvious automation projects have probably already been carried out at your company. This leaves smaller or less obvious cost-cutting projects (taking orders on-line saves on paper costs...whoopee!), or, projects that are expected to increase revenue/income.
The question becomes: how much will such a project contribute to increased sales of products and/or services? This is difficult to predict, and most business people are leery of attempting to do so. Just like IT Project teams are held to a project estimate or be considered late/costly, business people who estimate revenue increases can be held to task if it is perceived that the expected increase did not materialize. An interesting corollary development is the increase in the number of companies that are evaluating projects some time after they complete (six months or so) to see if the promised benefits have been realized. This can make business people even more wary of putting their names to what is and should be treated as an estimate.
In the end, however, some dollar value of benefits needs to be proposed and agreed to, if a cost-benefit analysis is to be performed. All I can say here is that, like all estimates, stating your assumptions and having them agreed to as the basis of your estimate is crucial. If reality proves that one or more assumptions turn out to false, then everyone involved in the project shares responsibility.
Next time: Cost - Benefit Analysis
See more about Cascade on Amazon http://amzn.to/gbgYNJ ; On Sale(!) at lulu.com http://bit.ly/92k1gf
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
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
Friday, February 25, 2011
Who"owns" IT Projects?
Who “owns” IT Projects?
I said I would post on this topic, but it is really more of a history piece. Here is an excerpt from my book “Cascade”:
CHAPTER FOUR– Pick the Right Projects for the Business
…
Early computer projects were run in the realm of the IT department, likely better known then as the Data Processing department. Business departments had been happy to get their worst drudge work automated, but the techie geek image of IT started at this time as well; so, the business would deal with IT as little as possible to get what they wanted, but otherwise considered IT as being on another planet. In this environment, one idea about using computers could snowball into a big project if enough people liked it.
So, projects proceeded into more complicated areas of the business, and they started to break down, some failed, and now Management wanted to know why, and also started asking if all these computer projects were worth what they cost (because costs were not assumed, they were measurable); and how did they all get started anyway?
(… because the business looks around and sees) a lot of current projects being carried out, that no one can remember when they started and, even if some target date has been set, no reasonable expectation exists that they will end soon.
(This has to change to get these projects under control, including a new awareness…)
That awareness should include:
1) A recognition that IT projects do not belong to IT, they belong to the Enterprise as a whole, even if various non-IT parts of the Enterprise are assigned responsibility for some sub-set of projects.
2) An understanding that projects still originate the same way: a problem, challenge or opportunity is identified, or a new idea to improve the business is suggested. Sources for suggestions range from front-line staff to objectives stated in the Enterprise’s Strategic Plan.
3) The realization that dozens or more project ideas may be in play at any one time, but the average Enterprise does not have the resources to do them all; it must pick from the candidates which projects will get to proceed, and it must continue to do this as current projects are completed and resources are freed up.
It all boils down to best use of limited resources. The term that has emerged to describe all this is Project Governance. The most common analogy used to describe this governance is “gating”; a number of things, like project ideas, enter into a process at its ‘wide’ point, but only a small number emerge through the narrower gate at the end of the process. The projects that make it through the gate are initiated, the rest wait for another chance when more resources are available, or are eventually dropped from consideration.
It is the nature of IT projects that their size and cost start out small, but increase in size as they proceed through standard Analysis and Design tasks into actual development (commonly called Construction). As a result, a mature governance process will be comprised of several gates that continue after a project has been initiated. More will be known about the project as it approaches the next gate, where it is evaluated again to determine if it should continue. Sometimes a project will have made it through one gate but, after proceeding for a period of time, more information has been gathered and it is clear at the next gate that the original decision to proceed is no longer viable and the project should be stopped. This is NOT a project failure as described above. It is a success of the governance process to prevent wasting precious resources on continuing a project that will not be of value to the Enterprise.
The key question then is: what projects does the Enterprise consider to be most valuable? (That’s for next time.)
See more about Cascade on Amazon http://amzn.to/gbgYNJ ; On Sale(!) at lulu.com http://bit.ly/92k1gf
I said I would post on this topic, but it is really more of a history piece. Here is an excerpt from my book “Cascade”:
CHAPTER FOUR– Pick the Right Projects for the Business
…
Early computer projects were run in the realm of the IT department, likely better known then as the Data Processing department. Business departments had been happy to get their worst drudge work automated, but the techie geek image of IT started at this time as well; so, the business would deal with IT as little as possible to get what they wanted, but otherwise considered IT as being on another planet. In this environment, one idea about using computers could snowball into a big project if enough people liked it.
So, projects proceeded into more complicated areas of the business, and they started to break down, some failed, and now Management wanted to know why, and also started asking if all these computer projects were worth what they cost (because costs were not assumed, they were measurable); and how did they all get started anyway?
(… because the business looks around and sees) a lot of current projects being carried out, that no one can remember when they started and, even if some target date has been set, no reasonable expectation exists that they will end soon.
(This has to change to get these projects under control, including a new awareness…)
That awareness should include:
1) A recognition that IT projects do not belong to IT, they belong to the Enterprise as a whole, even if various non-IT parts of the Enterprise are assigned responsibility for some sub-set of projects.
2) An understanding that projects still originate the same way: a problem, challenge or opportunity is identified, or a new idea to improve the business is suggested. Sources for suggestions range from front-line staff to objectives stated in the Enterprise’s Strategic Plan.
3) The realization that dozens or more project ideas may be in play at any one time, but the average Enterprise does not have the resources to do them all; it must pick from the candidates which projects will get to proceed, and it must continue to do this as current projects are completed and resources are freed up.
It all boils down to best use of limited resources. The term that has emerged to describe all this is Project Governance. The most common analogy used to describe this governance is “gating”; a number of things, like project ideas, enter into a process at its ‘wide’ point, but only a small number emerge through the narrower gate at the end of the process. The projects that make it through the gate are initiated, the rest wait for another chance when more resources are available, or are eventually dropped from consideration.
It is the nature of IT projects that their size and cost start out small, but increase in size as they proceed through standard Analysis and Design tasks into actual development (commonly called Construction). As a result, a mature governance process will be comprised of several gates that continue after a project has been initiated. More will be known about the project as it approaches the next gate, where it is evaluated again to determine if it should continue. Sometimes a project will have made it through one gate but, after proceeding for a period of time, more information has been gathered and it is clear at the next gate that the original decision to proceed is no longer viable and the project should be stopped. This is NOT a project failure as described above. It is a success of the governance process to prevent wasting precious resources on continuing a project that will not be of value to the Enterprise.
The key question then is: what projects does the Enterprise consider to be most valuable? (That’s for next time.)
See more about Cascade on Amazon http://amzn.to/gbgYNJ ; On Sale(!) at lulu.com http://bit.ly/92k1gf
Wednesday, February 23, 2011
Maybe it is time to define "customer" in IT Projects
IT projects and methods seem to big on the word "customer" these days...
Common definitions of:
customer - one that purchases a commodity or service
purchases - the acquisition of something for payment
So let me propose this definition: unless you are selling software as a product for real money, your IT project does not have any customers.
I have spent my career working on IT projects for companies that need systems to run their business more effectively/profitably.I have worked with many a sponsor, and many business people who will use the systems, but none of them paid me directly for doing so; we all worked for the same organization, with job titles and salaries to go with those titles.
Most of these organizations used some kind of budgeting/cost allocation to align the cost of the systems to the revenues of the parts of the company that would use the systems. However, this is not purchasing, it is management.
However, some of these organizations used a definition of an internal form of exchange - 'gray money' or better known as "funny money" - to not only allocate cost but to measure managers' effectiveness and often their bonuses. The main company I saw this at is no longer an independent organization, as it fell on hard times and was acquired/assimilated by a more successful company. One of the reasons was management choices like the following:
Two similar business units (same product, different market) needed new systems. One (Unit A) got a head start and developed a functional system. The other (Unit B) saw the system and said "we could use that too". Unit A asked for payment in funny money of half the cost of development. Unit B balked, and spent a lesser amount of real money to buy a package, because that looked better on Unit B's cost reporting... real money spent that should not have been necessary.
So, within an organization, there are no customers and there are no purchases; acting like there is can be detrimental to the organization as a whole.
But we are talking about customers of IT projects, surely that can't be the same; yes it is. Call someone a customer and they will act in their own best interest, however that is measured, and with disregard for the success of the whole organization.
IT projects should not have buyers and sellers; they should have teams of business and IT people working together to reach a common goal. So you see, the definition of "customer" in an IT project is that there isn't one.
Common definitions of:
customer - one that purchases a commodity or service
purchases - the acquisition of something for payment
So let me propose this definition: unless you are selling software as a product for real money, your IT project does not have any customers.
I have spent my career working on IT projects for companies that need systems to run their business more effectively/profitably.I have worked with many a sponsor, and many business people who will use the systems, but none of them paid me directly for doing so; we all worked for the same organization, with job titles and salaries to go with those titles.
Most of these organizations used some kind of budgeting/cost allocation to align the cost of the systems to the revenues of the parts of the company that would use the systems. However, this is not purchasing, it is management.
However, some of these organizations used a definition of an internal form of exchange - 'gray money' or better known as "funny money" - to not only allocate cost but to measure managers' effectiveness and often their bonuses. The main company I saw this at is no longer an independent organization, as it fell on hard times and was acquired/assimilated by a more successful company. One of the reasons was management choices like the following:
Two similar business units (same product, different market) needed new systems. One (Unit A) got a head start and developed a functional system. The other (Unit B) saw the system and said "we could use that too". Unit A asked for payment in funny money of half the cost of development. Unit B balked, and spent a lesser amount of real money to buy a package, because that looked better on Unit B's cost reporting... real money spent that should not have been necessary.
So, within an organization, there are no customers and there are no purchases; acting like there is can be detrimental to the organization as a whole.
But we are talking about customers of IT projects, surely that can't be the same; yes it is. Call someone a customer and they will act in their own best interest, however that is measured, and with disregard for the success of the whole organization.
IT projects should not have buyers and sellers; they should have teams of business and IT people working together to reach a common goal. So you see, the definition of "customer" in an IT project is that there isn't one.
Subscribe to:
Posts (Atom)