The idea of privacy has changed dramatically in the digital age. Humans have long valued their privacy – since about the time we moved out of communal caves we have looked to have our own little corner of the world that we can call our own and in which we can be protected from the intrusions of others.
A century ago, your privacy in your home was taken for granted. Outside the home it was more a matter of physical security from outlaws or others who did not mean us well. Your identity was a matter of pride and need not be hidden in any way.
Your name, unfortunately, is not unique. Governments like to keep track of their citizens, so most of them give their tax payers (i.e. everyone) a number that is unique. In the US and many other countries this is known as the Social Security number.
Even 10 years ago, your social security number was simply the number used to identify you to the Social Security Administration and the tax man. Many private agencies like health plans used your SSA as identification as a matter of convenience.
Then a strange thing happened – suddenly the Social Security number became a valuable secret that should never be divulged to anyone. How did this come about? The problem was identity theft – Someone pretending to be you and opening credit card accounts or even emptying your bank account.
The thing that propelled identity theft and much of the concern about privacy was the rapid proliferation of electronic means of commerce over the public Internet. We can buy and sell seemingly anything, access our bank accounts instantly, send money quickly to anywhere in the world at the click of a mouse and carry out all manner of other transactions. We love the convenience – so long as nothing goes wrong.
I would venture to guess that anyone reading this has at some time in the last few years had a credit card stolen and had some stranger – pretending to be you – charge things on that card that you had nothing to do with. It has happened to me three times. Each time I have been able to report the crime to the credit card company and I have not had to pay the charges myself. But it was a hassle, sometimes requiring that I provide a notarized statement.
Notice I did not report the crime to the police and I doubt that the credit card company did either. Both parties just considered this the cost of doing business. The credit card company may or may not have been able to stop or reverse the payments on the fraudulent charges. Most likely they just wrote it off.
Over this last decade our number one concern regarding privacy has moved away from simply shielding ourselves from prying eyes to being a defense of our hard-earned money.
But even though the worry about losing our wealth is perhaps at the top of the list of privacy concerns, it is not the only privacy issue that we are contending with. Consider the recent story of a school district accused of remotely monitoring students through the webcams of their school-provided laptops.
I’ll explore more of these privacy issues in future blog posts, along with a discussion of how privacy relates to identity and the impact of both these hot topics on how Information Technologists deal with them. And I will be presenting an overview of all of this at Enterprise Data World in San Francisco on March 17. I hope to see some of you there.
Wednesday, February 24, 2010
Wednesday, September 2, 2009
The Promise and Danger of Agile Project Methods
The Agile Manifesto (http://agilemanifesto.org) is a “great leap forward” in thinking about how software can best be created. It’s four basic values are simple and sensible statements of where priorities should lie in any software project and can even bee applied to projects outside of software development.
Of the for values, only the last (“Responding to change over following a plan”) would have any serious argument from most Project Management Professionals. At the base of everything a PMP does is the creation of a plan and then following that plan. The plan is constantly reviewed, of course, but it is always there and it is followed. If circumstances demand that the existing plan is no longer valid, then the plan is changed and the new plan followed. But the plan is always followed.
No doubt followers of the Agile methodology would say that they do not reject all planning, just that responding to change is more valuable. My observation, though, is that those seeking to apply Agile methods to projects tend to throw out planning altogether (they often throw out processes, documentation and contracts as well).
In some descriptions of Agile development you will find that the Project Manager has been relegated to an administrative role - making sure that there are enough white boards and scheduling meetings with senior management . They are actually project expeditors and not managers at all.
The fact is that the planning function in any project is so important that it is always being done in any successful project. It is done usually by someone by default who has the leadership potential and the experience to do it. He or she may do a lot of the planning behind the scenes and informally, but the planning does exist and is followed. A plan is pushed ahead through force of will and cajolery, or it is not followed and the project fails.
I have seen some embrace Agile mainly because they cannot plan, document, negotiate or use processes or tools effectively. They see it as their license to jump in and start coding. We have seen this same kind of behavior for many years in the software industry and few seem to have learned the lesson that this just does not work. It does not create workable, stable systems that can be maintained and that bring value to the business over the long term.
The Agile Manifesto itself is very short and sweet. Many other words have been written to expand on those ideas and to create a full-blown methodology. My hope is that we will one day see a methodology that balances both sides of the value equation. There is no doubt that software development processes must change and Agile will be an important part of that. We will probably see a gradual swing to the center where values are more balanced. I certainly hope that is the case.
Of the for values, only the last (“Responding to change over following a plan”) would have any serious argument from most Project Management Professionals. At the base of everything a PMP does is the creation of a plan and then following that plan. The plan is constantly reviewed, of course, but it is always there and it is followed. If circumstances demand that the existing plan is no longer valid, then the plan is changed and the new plan followed. But the plan is always followed.
No doubt followers of the Agile methodology would say that they do not reject all planning, just that responding to change is more valuable. My observation, though, is that those seeking to apply Agile methods to projects tend to throw out planning altogether (they often throw out processes, documentation and contracts as well).
In some descriptions of Agile development you will find that the Project Manager has been relegated to an administrative role - making sure that there are enough white boards and scheduling meetings with senior management . They are actually project expeditors and not managers at all.
The fact is that the planning function in any project is so important that it is always being done in any successful project. It is done usually by someone by default who has the leadership potential and the experience to do it. He or she may do a lot of the planning behind the scenes and informally, but the planning does exist and is followed. A plan is pushed ahead through force of will and cajolery, or it is not followed and the project fails.
I have seen some embrace Agile mainly because they cannot plan, document, negotiate or use processes or tools effectively. They see it as their license to jump in and start coding. We have seen this same kind of behavior for many years in the software industry and few seem to have learned the lesson that this just does not work. It does not create workable, stable systems that can be maintained and that bring value to the business over the long term.
The Agile Manifesto itself is very short and sweet. Many other words have been written to expand on those ideas and to create a full-blown methodology. My hope is that we will one day see a methodology that balances both sides of the value equation. There is no doubt that software development processes must change and Agile will be an important part of that. We will probably see a gradual swing to the center where values are more balanced. I certainly hope that is the case.
Thursday, July 30, 2009
Creating Business Value
Back in May I wrote about failed projects and the myths surrounding the supposed high percentage of project failures in the IT industry. I tried to make the point that the only true measure of project success is the value the project brings to the business and that success is not just bringing in a project on time and within budget. I recommended that Project Managers measure their projects by business value generated.
I don’t think I took that idea far enough. I believe that PMs should actively seek to achieve business value in their projects from the very beginning of the project and to push that idea all the way through the project. One way to do this is to think of risk in a new light – the risk that the project is not generating business value.
We should be constantly looking at risks to our projects, determining the potential impact of those risks and taking appropriate action or at leas planning for what to do if a risk becomes reality. We usually look at those risks in terms of cost or time lost. What we need to do is look at the impact on business value.
For example, a risk could be late delivery of the production server hardware from a vendor. The impact is that production cut-over is delayed and the schedule is extended by one week.
But what is the impact to the business? If this production server is to support an e-commerce site intended to go live in late October to handle the Christmas sale rush, a delay of one week could be devastating to the sales for that season. On the other hand, if the server is for a data warehouse to support analysis of the Christmas season campaign after the fact, the impact on the business of a week’s delay might be minimal.
It could be relatively easy to include such measures when doing qualitative and even quantitative risk analysis. This can help you prioritize risk responses and manage your risks in a more realistic fashion.
Business value can also be factored into the monitoring of project progress. The metrics offered by earned-value analysis do not allow for such factors to be taken into account. Earned value is a narrow measure of the value the project has earned toward the goal of completing on time and within budget. It gives only a passing nod to business value.
How could a project manager measure business value while executing, monitoring and controlling a project? This would require a new set of metrics that go beyond earned value. It might be possible to work out something very complex. Even better would be to apply Occam’s razor (or if you like, the KISS principle) and find the simplest solution first. Here’s a suggestion:
1. Predict the value the project will bring to the business over the period following the completion of the project (could be 1-3 years).
2. The total value over that period, if the project completes on time, is the baseline value.
3. If the project is expected to be late, determine how much business value will be “eaten”.
4. If the project can come in early, calculate the added business value that can be earned.
5. Factor in additional or saved project costs.
6. This gives a new business value figure. Is it better or worse than the baseline? Make decisions based on that.
I’m sure someone out there can come up with some better ideas on how to do such a measurement and it might even vary by organization or project. The point is – make sure you use business value as your prime factor in determining project success or failure!
I don’t think I took that idea far enough. I believe that PMs should actively seek to achieve business value in their projects from the very beginning of the project and to push that idea all the way through the project. One way to do this is to think of risk in a new light – the risk that the project is not generating business value.
We should be constantly looking at risks to our projects, determining the potential impact of those risks and taking appropriate action or at leas planning for what to do if a risk becomes reality. We usually look at those risks in terms of cost or time lost. What we need to do is look at the impact on business value.
For example, a risk could be late delivery of the production server hardware from a vendor. The impact is that production cut-over is delayed and the schedule is extended by one week.
But what is the impact to the business? If this production server is to support an e-commerce site intended to go live in late October to handle the Christmas sale rush, a delay of one week could be devastating to the sales for that season. On the other hand, if the server is for a data warehouse to support analysis of the Christmas season campaign after the fact, the impact on the business of a week’s delay might be minimal.
It could be relatively easy to include such measures when doing qualitative and even quantitative risk analysis. This can help you prioritize risk responses and manage your risks in a more realistic fashion.
Business value can also be factored into the monitoring of project progress. The metrics offered by earned-value analysis do not allow for such factors to be taken into account. Earned value is a narrow measure of the value the project has earned toward the goal of completing on time and within budget. It gives only a passing nod to business value.
How could a project manager measure business value while executing, monitoring and controlling a project? This would require a new set of metrics that go beyond earned value. It might be possible to work out something very complex. Even better would be to apply Occam’s razor (or if you like, the KISS principle) and find the simplest solution first. Here’s a suggestion:
1. Predict the value the project will bring to the business over the period following the completion of the project (could be 1-3 years).
2. The total value over that period, if the project completes on time, is the baseline value.
3. If the project is expected to be late, determine how much business value will be “eaten”.
4. If the project can come in early, calculate the added business value that can be earned.
5. Factor in additional or saved project costs.
6. This gives a new business value figure. Is it better or worse than the baseline? Make decisions based on that.
I’m sure someone out there can come up with some better ideas on how to do such a measurement and it might even vary by organization or project. The point is – make sure you use business value as your prime factor in determining project success or failure!
Sunday, June 14, 2009
Forecast: Clouds, Fog - Followed by Partial Clearing
Cloud computing has become one of the more interesting trends in the technical world in the last year or so. But it is not easy to see through the fog surrounding this latest buzzword. It’s worthwhile for a project manager to understand this trend and to think about where it might take us.
The term cloud computing came from the world of networking, where a diagram of a wide-area network would often show a large cloud in the middle that was meant to represent some mixture of the Internet and private links. The idea was that the communications from various servers and workstations went into the cloud and the cloud took care of routing the communications to the correct point. The cloud was generally conceived to be managed by the ISP or telecom company.
Recently, virtualization has allowed any server to be easily split into many small servers that could be resized and brought up and down, independent of the underlying hardware. A hosting provider could allow a customer to manage their server resources in a more flexible manner. A virtual server could be made available somewhere on the Internet and so could be thought of as a “cloud computer”.
Curiously, the organizations that have begun to make a serious impact on cloud computing have not been ISPs, telecoms or hosting providers. Instead, it has been a small group of large companies that already had very large infrastructures set up to manage their own businesses. We are talking here about Amazon, Google and Microsoft. Of the three, the Amazon offering is the most mature and I’ll focus on it as an example of how this all works.
Amazon’s offering is called simply Amazon Web Services – AWS. Its most basic components are Elastic Compute Cloud (EC2) and Simple Storage Service (S3). The EC2 service allows a user to set up virtual servers quickly and easily, paying only for the resources actually used. The S3 service allows users to store data – any kind of data – and access it from an EC2 server or anywhere within their own infrastructure.
This way of working can be very cost-effective for testing. A tech can bring up a virtual server, load software and data and be ready to test in a short period of time. When he is done testing, he can save the data to S3 (or on a server back in his own office) and drop the virtual server. He can do several days testing for just a few dollars. If he had to get a real server it could take weeks and cost hundreds of dollars or more.
Beyond testing, this kind of set-up can be a great help for a company who has a lot of peaks and valleys in their computing needs, such as retailers who get most of their sales in November-December. They can have a small virtual server most of the year and easily double or triple their capacity during the holiday sales season.
It probably makes less sense for a company with a steady, even usage pattern and little (or very predictable) growth to use this kind of service for production. This kind of company can plan, purchase, install and maintain servers and storage far enough in advance to meet demand and probably do it less expensively. But in today’s environment, there are fewer and fewer organizations who are in this predictable category.
From everything I have seen, Amazon is far in advance of anyone else in terms of their services, management, reliability and availability.
I started using Amazon S3 nearly a year ago almost by accident. I wanted an easy, cheap and secure way to store important files online for backup purposes.. There are several commercial offerings that charge upwards of $15 per month. With S3 and an inexpensive software component (Jungledisk - $10), I was up and running very quickly. The cost? About $1 per month!
As a project manager, if you have any flexibility in how your infrastructure is deployed, it would be worth your while to investigate cloud computing as an alternative. It could be a way for you to shave costs and time. It is not appropriate for every task (security policies may make it impossible). But if you have ever had to wait weeks for procurement to get you that test server, it can be a huge victory to get it done in a couple of hours for one-tenth the cost.
Keep an eye on this technology. The fog will clear and I predict sunny weather ahead.
Links:
http://aws.amazon.com
http://www.jungledisk.com
The term cloud computing came from the world of networking, where a diagram of a wide-area network would often show a large cloud in the middle that was meant to represent some mixture of the Internet and private links. The idea was that the communications from various servers and workstations went into the cloud and the cloud took care of routing the communications to the correct point. The cloud was generally conceived to be managed by the ISP or telecom company.
Recently, virtualization has allowed any server to be easily split into many small servers that could be resized and brought up and down, independent of the underlying hardware. A hosting provider could allow a customer to manage their server resources in a more flexible manner. A virtual server could be made available somewhere on the Internet and so could be thought of as a “cloud computer”.
Curiously, the organizations that have begun to make a serious impact on cloud computing have not been ISPs, telecoms or hosting providers. Instead, it has been a small group of large companies that already had very large infrastructures set up to manage their own businesses. We are talking here about Amazon, Google and Microsoft. Of the three, the Amazon offering is the most mature and I’ll focus on it as an example of how this all works.
Amazon’s offering is called simply Amazon Web Services – AWS. Its most basic components are Elastic Compute Cloud (EC2) and Simple Storage Service (S3). The EC2 service allows a user to set up virtual servers quickly and easily, paying only for the resources actually used. The S3 service allows users to store data – any kind of data – and access it from an EC2 server or anywhere within their own infrastructure.
This way of working can be very cost-effective for testing. A tech can bring up a virtual server, load software and data and be ready to test in a short period of time. When he is done testing, he can save the data to S3 (or on a server back in his own office) and drop the virtual server. He can do several days testing for just a few dollars. If he had to get a real server it could take weeks and cost hundreds of dollars or more.
Beyond testing, this kind of set-up can be a great help for a company who has a lot of peaks and valleys in their computing needs, such as retailers who get most of their sales in November-December. They can have a small virtual server most of the year and easily double or triple their capacity during the holiday sales season.
It probably makes less sense for a company with a steady, even usage pattern and little (or very predictable) growth to use this kind of service for production. This kind of company can plan, purchase, install and maintain servers and storage far enough in advance to meet demand and probably do it less expensively. But in today’s environment, there are fewer and fewer organizations who are in this predictable category.
From everything I have seen, Amazon is far in advance of anyone else in terms of their services, management, reliability and availability.
I started using Amazon S3 nearly a year ago almost by accident. I wanted an easy, cheap and secure way to store important files online for backup purposes.. There are several commercial offerings that charge upwards of $15 per month. With S3 and an inexpensive software component (Jungledisk - $10), I was up and running very quickly. The cost? About $1 per month!
As a project manager, if you have any flexibility in how your infrastructure is deployed, it would be worth your while to investigate cloud computing as an alternative. It could be a way for you to shave costs and time. It is not appropriate for every task (security policies may make it impossible). But if you have ever had to wait weeks for procurement to get you that test server, it can be a huge victory to get it done in a couple of hours for one-tenth the cost.
Keep an eye on this technology. The fog will clear and I predict sunny weather ahead.
Links:
http://aws.amazon.com
http://www.jungledisk.com
Wednesday, May 20, 2009
A New Venture
I have spent many years now working for various organizations as an employee. There is nothing wrong with that – a well-managed group can accomplish a great deal and working as part of a large team can be very rewarding. But I, like many in America and elsewhere, have always had the dream of starting something on my own, my own company.
I have recently decided that now is the time for me to take on such a new challenge. I want to be able to use the things I have learned about systems, organizations, projects and people and put these together in a package that I can offer to others to help them achieve success.
To that end, I have formed Pinnacle Project Group (www.PinnacleProjectGroup.com). Our mission and goal will be to help create a better world through the application of superior IT project management. We will achieve this by ensuring that our client’s projects deliver real business value to their organizations.
I know that “a better world” is a lofty goal for a consultancy that currently consists of one person. But I believe strongly that we all should be striving to create a better world in whatever big or small way we can. If we are not doing so, we must perforce be allowing the world to get worse, if only by neglect. We can all make an impact – even if it is only in one small corner of the world.
I would invite you to think about your projects and the impact they have on the world around you. Will the project lead to something that improves conditions in the world? More than it harms? If not, consider whether this is a project that you want to be associated with.
In tough economic times it can be difficult to think beyond the welfare of yourself and your immediate family. But if you look over recent history, you can probably see that considering only self-interest is what got us into this mess.
I think you will not find it hard to consider the greater good in your actions. For some excellent guidance, have a look at the booklet The Way to Happiness”, which can be found at this link:
www.thewaytohappiness.org/about/resources-and-downloads/e-books.
I have spent many years now working for various organizations as an employee. There is nothing wrong with that – a well-managed group can accomplish a great deal and working as part of a large team can be very rewarding. But I, like many in America and elsewhere, have always had the dream of starting something on my own, my own company.
I have recently decided that now is the time for me to take on such a new challenge. I want to be able to use the things I have learned about systems, organizations, projects and people and put these together in a package that I can offer to others to help them achieve success.
To that end, I have formed Pinnacle Project Group (www.PinnacleProjectGroup.com). Our mission and goal will be to help create a better world through the application of superior IT project management. We will achieve this by ensuring that our client’s projects deliver real business value to their organizations.
I know that “a better world” is a lofty goal for a consultancy that currently consists of one person. But I believe strongly that we all should be striving to create a better world in whatever big or small way we can. If we are not doing so, we must perforce be allowing the world to get worse, if only by neglect. We can all make an impact – even if it is only in one small corner of the world.
I would invite you to think about your projects and the impact they have on the world around you. Will the project lead to something that improves conditions in the world? More than it harms? If not, consider whether this is a project that you want to be associated with.
In tough economic times it can be difficult to think beyond the welfare of yourself and your immediate family. But if you look over recent history, you can probably see that considering only self-interest is what got us into this mess.
I think you will not find it hard to consider the greater good in your actions. For some excellent guidance, have a look at the booklet The Way to Happiness”, which can be found at this link:
www.thewaytohappiness.org/about/resources-and-downloads/e-books.
Friday, May 8, 2009
Zap Some Life Into Your Service Oriented Architecture Project
If you are in any stage of a Service Oriented Architecture (SOA) project or if you just want to find out what SOA is really about, you would do very well to check out the information on the subject provided by www.zapthink.com.
It is not entirely clear to me at this point that SOA is the ultimate answer to everything wrong with the way we build computerized systems, but I do believe that it is an important step toward what should be our ultimate goal: highly reliable, integrated, efficient systems that can perform real work and provide real value to the Enterprise.
Zapthink is a consultancy that has been in the forefront of the SOA evolution. They are an independent, vendor-neutral voice, pointing out that SOA is an architectural concept, not a technology.
The large software vendors promote their packages and methodologies as a way to “buy SOA”. It is not surprising that most of these kinds of projects have not been able to show much in the way of business value. Installing a package and calling it SOA is akin to buying a refrigerator and calling it dinner – you might be able to make dinner with the help of a fridge, but you can also do it without the fridge and it just might be a better dinner if you just bring home the fresh ingredients and start cooking.
The dinner analogy is perhaps not the best, but the point is that SOA needs to be thought through carefully before laying down the money for any technology. You need to think about the kinds of services that will make sense for your business and how best to implement these services, given the mix of technology currently available or planned for the near future.
Have a look at Zapthink and decide for yourself. Their newsletter is free and definitely worth a read.
It is not entirely clear to me at this point that SOA is the ultimate answer to everything wrong with the way we build computerized systems, but I do believe that it is an important step toward what should be our ultimate goal: highly reliable, integrated, efficient systems that can perform real work and provide real value to the Enterprise.
Zapthink is a consultancy that has been in the forefront of the SOA evolution. They are an independent, vendor-neutral voice, pointing out that SOA is an architectural concept, not a technology.
The large software vendors promote their packages and methodologies as a way to “buy SOA”. It is not surprising that most of these kinds of projects have not been able to show much in the way of business value. Installing a package and calling it SOA is akin to buying a refrigerator and calling it dinner – you might be able to make dinner with the help of a fridge, but you can also do it without the fridge and it just might be a better dinner if you just bring home the fresh ingredients and start cooking.
The dinner analogy is perhaps not the best, but the point is that SOA needs to be thought through carefully before laying down the money for any technology. You need to think about the kinds of services that will make sense for your business and how best to implement these services, given the mix of technology currently available or planned for the near future.
Have a look at Zapthink and decide for yourself. Their newsletter is free and definitely worth a read.
Monday, May 4, 2009
Myths of Failed Projects
How many times have you heard frightening statistics on the number of IT projects that “fail”? It is common to hear numbers well above 50%. Does this match your experience in the real world or those projects you have heard about? In my experience, the percent of truly failed projects is much less then that.
The key to determining the real percentage is, of course, to define what is meant by “failure”. I do not know what criteria the various surveys or analysis use and I’m not going to attempt to refute any published studies. But at the start, I will define a successful project as follows:
A successful project is any that provide positive business value over the life of the product of the project.
By this measure, a project could be well over budget and behind schedule at the end of the project, but so long as a viable product is created that delivers positive business value in excess of the cost of the project, it could be deemed successful.
Should we toss out completely measures such as Earned value and Cost performance Index? No, these are valuable in tracking how well a project is proceeding according to plan. These measures, however, only address how well the project team did their planning, not necessarily the value the product of the project brings to the organization. The measurement of “on time and within budget” are subservient to the real statistics that should be tracked, which must be a measure of business value.
If you are a Project Manager, you could argue that it may take years to determine project success based on this definition. You would be right in some cases. But in many cases, it can be rather easy to determine success by the time of project close. For example, a project that replaces an aging, expensive system with a new system based on commodity hardware and software components can be shown to have a payback period within a few months or a year after the project is closed.
It is true that things can go wrong after a project is done and the team is long gone. Only the passage of time will ensure that you know exactly what the payback is and how rapidly it occurred. I know of few organizations that track projects over the necessary spans of time that would be required. That is unfortunate, but a reality, since managers tend not to care about how old projects performed, only how they will get the next one done on time.
Is it worthwhile tracking project performance in this manner? I would suggest that any project manager would be well advised to do this to the greatest extent possible. Track your projects for at least a year a after completion and see how they are performing.
A PM might argue that this metric is outside of his control. He could argue “it’s not my fault if the organization dropped the ball after the project closed”. That might well be true, but it is also important for you to understand why the product did not succeed, it that was the case. Update your lessons learned on the project with information that could be helpful for the next project.
If Project Managers can take a long view of project success, they have a much better chance of being perceived as skilled managers. If we can show that our projects did in fact deliver business value we can all get beyond these myths of so many failed projects.
The key to determining the real percentage is, of course, to define what is meant by “failure”. I do not know what criteria the various surveys or analysis use and I’m not going to attempt to refute any published studies. But at the start, I will define a successful project as follows:
A successful project is any that provide positive business value over the life of the product of the project.
By this measure, a project could be well over budget and behind schedule at the end of the project, but so long as a viable product is created that delivers positive business value in excess of the cost of the project, it could be deemed successful.
Should we toss out completely measures such as Earned value and Cost performance Index? No, these are valuable in tracking how well a project is proceeding according to plan. These measures, however, only address how well the project team did their planning, not necessarily the value the product of the project brings to the organization. The measurement of “on time and within budget” are subservient to the real statistics that should be tracked, which must be a measure of business value.
If you are a Project Manager, you could argue that it may take years to determine project success based on this definition. You would be right in some cases. But in many cases, it can be rather easy to determine success by the time of project close. For example, a project that replaces an aging, expensive system with a new system based on commodity hardware and software components can be shown to have a payback period within a few months or a year after the project is closed.
It is true that things can go wrong after a project is done and the team is long gone. Only the passage of time will ensure that you know exactly what the payback is and how rapidly it occurred. I know of few organizations that track projects over the necessary spans of time that would be required. That is unfortunate, but a reality, since managers tend not to care about how old projects performed, only how they will get the next one done on time.
Is it worthwhile tracking project performance in this manner? I would suggest that any project manager would be well advised to do this to the greatest extent possible. Track your projects for at least a year a after completion and see how they are performing.
A PM might argue that this metric is outside of his control. He could argue “it’s not my fault if the organization dropped the ball after the project closed”. That might well be true, but it is also important for you to understand why the product did not succeed, it that was the case. Update your lessons learned on the project with information that could be helpful for the next project.
If Project Managers can take a long view of project success, they have a much better chance of being perceived as skilled managers. If we can show that our projects did in fact deliver business value we can all get beyond these myths of so many failed projects.
Subscribe to:
Posts (Atom)