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.
Wednesday, May 20, 2009
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)