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.
Wednesday, September 2, 2009
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.
Friday, February 27, 2009
The Completion of a Project and the Start of a New Chapter
Just recently I completed a major project – the third phase of a project that had extended over nearly four years all-told. The project involved implementing a data warehouse with a global scope, involving over 30 different countries and in excess of 50 million customer records.
I think it is fair to say the project was a major success. It consolidated several systems the company had been using, dramatically lowered costs, increased the business intelligence capabilities of the organization and was extremely well-received by the users. In all my years of doing project work, I have rarely seen a project achieve such positive results. This may sound like personal horn-blowing, but if you spoke to the key stakeholders, I think you would find that they would generally agree.
It is not that the project went completely smoothly and with no hiccups. The last phase in particular (converting an old mainframe-based system) was a tough one and it went several months longer than the original plan. There are many reasons for this, the primary one being underestimating the effort involved in converting some of the very technical and complex functions. But in the end the project delivered very positive business value. And delivering business value is what a project should be all about.
There were many lessons learned on this project. I’d like to focus on one aspect here that could be of help to other PMs. This is how to effectively close a project without leaving many loose ends.
In my experience, projects do not often close in a clean manner, with everything wrapped up and delivered and nothing left to tidy up. Often the projects seem to just go on forever in a sort of maintenance mode, with new issues arising week after week. On the other hand, sometimes the project is closed abruptly with software full of bugs and the users feeling that the product is incomplete.
There may be many ways to manage this. The closing process in the PMBOK is straightforward – you complete all the work assignments, release the resources, close any contracts, write up Lessons Learned and have a party. It seldom works out so cleanly.
There are two primary ways to ensure that all loose ends are tied up. They can also be used to compliment each other.
First, at the end of the project all outstanding issues are either closed or they are converted into open requests or tickets in the normal maintenance system.
The other way to manage this is to build a warranty period into the project, where some project resources are kept at least part-time to resolve any issues or bugs that arise. The project is formally close before the start of the warranty period and the warranty work is done under the auspices of the organizations normal maintenance process.
The warranty makes most sense when the product of the project is delivered to an outside organization, but it also can be used within an enterprise, especially when the product is delivered to another department or group.
But the key thing is – don’t leave loose ends! They will come back to haunt you.
I have made my best efforts to apply these principles to my recent projects. The effect has not been perfect, but it has had a positive impact.
============================================
As the title of this post implies, the end of my most recent project has also meant the opening of a new chapter in my career and life. I have left the organization where I had spent over 20 years. There were many reasons for my departure, but in essence the company and I both felt that it was time to part. They were and continue to be very gracious and generous.. I greatly appreciate their good will.
I am taking some time now to assess my future and to look over my options. I will be working to establish myself as an independent consultant, one who can assist in the management of any IT project and make those projects work better.
To see more about me and my background and competencies, see my Linkedin profile: http://www.linkedin.com/pub/8/648/258.
I think it is fair to say the project was a major success. It consolidated several systems the company had been using, dramatically lowered costs, increased the business intelligence capabilities of the organization and was extremely well-received by the users. In all my years of doing project work, I have rarely seen a project achieve such positive results. This may sound like personal horn-blowing, but if you spoke to the key stakeholders, I think you would find that they would generally agree.
It is not that the project went completely smoothly and with no hiccups. The last phase in particular (converting an old mainframe-based system) was a tough one and it went several months longer than the original plan. There are many reasons for this, the primary one being underestimating the effort involved in converting some of the very technical and complex functions. But in the end the project delivered very positive business value. And delivering business value is what a project should be all about.
There were many lessons learned on this project. I’d like to focus on one aspect here that could be of help to other PMs. This is how to effectively close a project without leaving many loose ends.
In my experience, projects do not often close in a clean manner, with everything wrapped up and delivered and nothing left to tidy up. Often the projects seem to just go on forever in a sort of maintenance mode, with new issues arising week after week. On the other hand, sometimes the project is closed abruptly with software full of bugs and the users feeling that the product is incomplete.
There may be many ways to manage this. The closing process in the PMBOK is straightforward – you complete all the work assignments, release the resources, close any contracts, write up Lessons Learned and have a party. It seldom works out so cleanly.
There are two primary ways to ensure that all loose ends are tied up. They can also be used to compliment each other.
First, at the end of the project all outstanding issues are either closed or they are converted into open requests or tickets in the normal maintenance system.
The other way to manage this is to build a warranty period into the project, where some project resources are kept at least part-time to resolve any issues or bugs that arise. The project is formally close before the start of the warranty period and the warranty work is done under the auspices of the organizations normal maintenance process.
The warranty makes most sense when the product of the project is delivered to an outside organization, but it also can be used within an enterprise, especially when the product is delivered to another department or group.
But the key thing is – don’t leave loose ends! They will come back to haunt you.
I have made my best efforts to apply these principles to my recent projects. The effect has not been perfect, but it has had a positive impact.
============================================
As the title of this post implies, the end of my most recent project has also meant the opening of a new chapter in my career and life. I have left the organization where I had spent over 20 years. There were many reasons for my departure, but in essence the company and I both felt that it was time to part. They were and continue to be very gracious and generous.. I greatly appreciate their good will.
I am taking some time now to assess my future and to look over my options. I will be working to establish myself as an independent consultant, one who can assist in the management of any IT project and make those projects work better.
To see more about me and my background and competencies, see my Linkedin profile: http://www.linkedin.com/pub/8/648/258.
Subscribe to:
Posts (Atom)