“While project performance is generally evaluated in terms of the “iron triangle” of schedule, cost and quality performance, guidelines for project quality management are lacking.”(Steyn, 2008) For this purpose, several institutions and research papers addressed this issue and provided recommendations for improving information technology projects’ quality. After researching and reading many of these recommendations, I choose to discuss below three suggestions for improving the quality of IT projects.
My first preferred suggestion is to understand the level of quality expected by the project owners or stakeholders. “Customer quality expectations and acceptance criteria specify that quality is determined by the customer, not by the project manager.” (Cusolito, n.d.) Defining this understanding early on in the project helps both the project manager and team evaluate the processes and phases better and comprehend accordingly the level of commitment and effort required. Delivering a project that satisfies the customers expected quality can be interpreted as nothing but success.
My second suggestion is to follow maturity models prepared by renowned institutions like the Software Engineering Institute (SEI). SEI developed a Capability Maturity Model (CMM) for Software: “The Capability Maturity Model for Software (CMM or SW-CMM) is a reference model for appraising software process maturity and a normative model for helping software organizations progress along an evolutionary path from ad hoc, chaotic processes to mature, disciplined software processes.” (Herbsleb/Zubrow/Goldenson/Hayes/Paulk, 1997) Following such models enhances not only the quality of the final product but furthermore affects other major aspects: “sophisticated statistical analysis of data from a large software development laboratory in a Fortune 100 company showed that process maturity significantly increased quality…. Higher product quality, however, significantly reduced both development and support cost,…”.(Herbsleb/Zubrow/Goldenson/Hayes/Paulk, 1997)
CMM, being a five-level model, allowed immediate quality related categorization of the different IT companies according to the level of commitment to the defined standards.
Many other similar models are still being developed like the Organizational Project Management Maturity Model (OPM3) created by the PMI’s Standards Development Program and the Documentation Maturity Model suggested by Huang and Tiley in 2003 (Huang&Tiley, 2003).
My third suggestion is to promote quality amongst top management or project owners. “Quality is the result of a carefully constructed cultural environment. It has to be the fabric of the organization, not part of the fabric.”(Crosby, n.d.) If the project stakeholders are accustomed to quality, then they will settle for nothing less. Highlighting the advantages of having quality products increases the management’s crave for quality. Accentuating the return on investment related to quality of the produced project will further improve the chances of even obtaining a bigger budget for the project at hand!
Quality of projects is what differentiates one company from another. It divides them into different levels similar to the maturity levels described above. Understanding the stakeholders expected quality enhances the chances of delivering a sign-off material project. And finally, familiarizing top management with quality products ameliorates the quality likelihood of the project. With this thought, I would like to end this by a related quote for a leader in the IT industry, Steve Jobs, when he said: “Be a yardstick of quality. Some people aren't used to an environment where excellence is expected.”(Jobs, n.d.)
References:
1. Steyn, Herman (July 27-31, 2008) A Framework for Managing Quality on System Development Projects [Research Paper] available from: IEEE Digital Library – IEEE Xplore under: PICMET 2008 Proceedings, 27-31 July, Cape Town, South Africa
2. Cusolito, Rick (n.d.) The High Cost of Low Quality [online] available from: http://www.butrain.com/Project-management-training-courses/highcost.asp?source=20669
3. James Herbsleb, David Zubrow, Dennis Goldenson, Will Hayes, and Mark Paulk (June 1997) Software Quality and the Capability Maturity Model [Research Paper] available from: ACM Digital Library - ACM 0002-0782/97/0600
4. Shihong Huang & Scott Tiley (October 12-15, 2003) Towards a Documentation Maturity Model [Research Paper] available from: ACM Digital Library - ACM 1-58113-696-X/03/0010
5. Crosby, Philip (n.d.) Quality Quotes[online] available from: http://thinkexist.com/quotations/quality/2.html
6. Jobs, Steve (n.d.) Quality Quotes[online] available from: http://thinkexist.com/quotations/quality/2.html
Saturday, October 18, 2008
Risk Management Software: Advantages & Disadvantages
“Australian companies are gambling the future of millions of dollars of software development projects by not implementing simple risk management schemes, an industry study has found.”(AFR, 1996) Risk management is an essential aspect of project management. Defining, controlling, managing, and eliminating risks helps project managers succeed in their relative projects.
Risk management involves many different techniques related mostly to risk analysis. Such techniques are sometimes complex and time-consuming as is the case with the Monte-Carlo simulation risk analysis technique. Due to such complexities, many software were developed to solve this problem.
Risk management software can be divided into two main categories: integration software and standalone ones.
By integration software we mean tools that were built in order to integrate with existing project management software. For example in case you want to use the Monte Carlo simulation technique “with Microsoft Project you need to have add-on tool.
There are a number of such tools available on market including @RISK for Project from Palisade Corporation (www.palisade.com), RiskyProject from Intaver Institute (www.intaver.com), Pertmaster software from Pertmaster Limited (www.pertmaster.com), Risk+ from S/C Solutions Inc. (www.cs-solutions.com).”(INTAVER, n.d.)
As for the standalone software, Riskworld.com (Tec-com Inc., 2008) lists more than fifty different risk-related ones that range from desktop applications to web-based applications. One example is “The Risk Manager” from RMSS: “The Risk Manager© is a user friendly application, based on the principles and workflow of the Australian and New Zealand Standard for Risk Management, known as AS/NZS 4360. The core process of Identification, Assessment, Control and Monitoring has been embedded in the application.” (RMSS, 2008)
Using risk management software, however, be it a tool or standalone software, has both advantages and disadvantages.
Other than the obvious advantage of saving time and eliminating the complexities of some of the risk analysis and management techniques, risk management software allow project managers through a user-friendly interface to access the latest tools to assess the project risks. For instance they provide answers to questions such as:
“
- What is the chance of your project being completed on schedule and within budget?
- What is the chance that the particular task will be on the critical path?
- What tasks affect the project duration at most?
- What is the project success rate?”(INTAVER, n.d.)
In some cases, such software allow him/her to, furthermore, get alerts regarding any risk that may have trespassed a preset threshold.
Having an online risk management application can also allow charts, tables, and different reports to be prepared in the easiest and most time-efficient manner.
Moreover, having the ability to integrate some application tools with the general project management software, enable the project manager to have a single management dashboard for the different processes involved.
As for the disadvantages of using such software, we could start by mentioning the additional cost involved which is on average around US$ 2000 excluding maintenance and support.
User-friendliness is not a common characteristic among such rigid scientific tools. Some risk management software require training while others have minimal or no proper documentation (especially the free tools). In similar cases, the risk management software will be time-consuming and even sometimes inaccurate in case misused.
Finally, relying on automated results in the form of charts and other types of reports to manage project risks could actually add unforeseen risks in case wrong or imprecise input was entered due to inexperience or simply by mistake, or in other cases where the software itself was defected or contained bugs. Some web risk management applications, for instance, might fail to provide instant critical information due to connection or server failure causing instant severe damage to the project’s timeline and/or budget.
To conclude, risk management software although built to help projects succeed with minimum or controlled risks, usage of such tools requires full consciousness of the consequences that might result from any related misuse.
References:
1. Australian Financial Review AFR (Thursday, 13 June 1996) “Cut risk or face costly software consequences, warns IT expert” [online] available from: http://www.zenkara.com/aust_fin_rev.pdf
2. INTAVER Institute Inc. (n.d.) Quantitative Risk Analysis with Microsoft Project [Online Article] available from: www.intaver.com/Articles/Article_MSProjectRiskAnalysis.pdf
3. Tec-com Inc. (July 21, 2008) Risk-Related Software [online] available from: http://www.riskworld.com/SOFTWARE/sw5sw001.htm
4. Risk Management & Safety Systems - RMSS (2008) The Risk Manager [online] Available from: http://www.rmss.com.au/Products/RiskManager.aspx
Risk management involves many different techniques related mostly to risk analysis. Such techniques are sometimes complex and time-consuming as is the case with the Monte-Carlo simulation risk analysis technique. Due to such complexities, many software were developed to solve this problem.
Risk management software can be divided into two main categories: integration software and standalone ones.
By integration software we mean tools that were built in order to integrate with existing project management software. For example in case you want to use the Monte Carlo simulation technique “with Microsoft Project you need to have add-on tool.
There are a number of such tools available on market including @RISK for Project from Palisade Corporation (www.palisade.com), RiskyProject from Intaver Institute (www.intaver.com), Pertmaster software from Pertmaster Limited (www.pertmaster.com), Risk+ from S/C Solutions Inc. (www.cs-solutions.com).”(INTAVER, n.d.)
As for the standalone software, Riskworld.com (Tec-com Inc., 2008) lists more than fifty different risk-related ones that range from desktop applications to web-based applications. One example is “The Risk Manager” from RMSS: “The Risk Manager© is a user friendly application, based on the principles and workflow of the Australian and New Zealand Standard for Risk Management, known as AS/NZS 4360. The core process of Identification, Assessment, Control and Monitoring has been embedded in the application.” (RMSS, 2008)
Using risk management software, however, be it a tool or standalone software, has both advantages and disadvantages.
Other than the obvious advantage of saving time and eliminating the complexities of some of the risk analysis and management techniques, risk management software allow project managers through a user-friendly interface to access the latest tools to assess the project risks. For instance they provide answers to questions such as:
“
- What is the chance of your project being completed on schedule and within budget?
- What is the chance that the particular task will be on the critical path?
- What tasks affect the project duration at most?
- What is the project success rate?”(INTAVER, n.d.)
In some cases, such software allow him/her to, furthermore, get alerts regarding any risk that may have trespassed a preset threshold.
Having an online risk management application can also allow charts, tables, and different reports to be prepared in the easiest and most time-efficient manner.
Moreover, having the ability to integrate some application tools with the general project management software, enable the project manager to have a single management dashboard for the different processes involved.
As for the disadvantages of using such software, we could start by mentioning the additional cost involved which is on average around US$ 2000 excluding maintenance and support.
User-friendliness is not a common characteristic among such rigid scientific tools. Some risk management software require training while others have minimal or no proper documentation (especially the free tools). In similar cases, the risk management software will be time-consuming and even sometimes inaccurate in case misused.
Finally, relying on automated results in the form of charts and other types of reports to manage project risks could actually add unforeseen risks in case wrong or imprecise input was entered due to inexperience or simply by mistake, or in other cases where the software itself was defected or contained bugs. Some web risk management applications, for instance, might fail to provide instant critical information due to connection or server failure causing instant severe damage to the project’s timeline and/or budget.
To conclude, risk management software although built to help projects succeed with minimum or controlled risks, usage of such tools requires full consciousness of the consequences that might result from any related misuse.
References:
1. Australian Financial Review AFR (Thursday, 13 June 1996) “Cut risk or face costly software consequences, warns IT expert” [online] available from: http://www.zenkara.com/aust_fin_rev.pdf
2. INTAVER Institute Inc. (n.d.) Quantitative Risk Analysis with Microsoft Project [Online Article] available from: www.intaver.com/Articles/Article_MSProjectRiskAnalysis.pdf
3. Tec-com Inc. (July 21, 2008) Risk-Related Software [online] available from: http://www.riskworld.com/SOFTWARE/sw5sw001.htm
4. Risk Management & Safety Systems - RMSS (2008) The Risk Manager [online] Available from: http://www.rmss.com.au/Products/RiskManager.aspx
Managing Project Teams: Tools & Techniques
“Managing software project teams is a complex task further complicated by a continued increase in the size and complexity of software-intensive systems and the distribution of project teams.”(Smith, Bohner, & McCrickard, 2005) Many tools and techniques were devised/proposed for this purpose, and became available assisting project managers in managing their project teams.
In the following excerpt, we will summarize these tools and techniques and further discuss the challenges that project managers face when dealing with virtual teams.
Managing teams, be it in the field of IT or other fields, requires many skills and knowledge of the several available management techniques. Some techniques are related to human communication and interaction while others are related to technical skills, planning, scheduling and team organization, and finally others are related to psychological status of team members.
Effective planning and scheduling techniques aid both project manager and team to develop better understanding of the scope, time, budget, and requirements of the project. Some techniques used in this regard include: Gantt and Pert charts, critical paths and general project plans that incorporate scope charters and budget estimation amongst others. These techniques, by organizing the team and assigning tasks, help each of the members to organize their own tasks and prioritize accordingly.
An increasing number of software is being used as tools that assist project managers in using such techniques. These include: SOPPTS, TeamSpace, TeamSCOPE, SoftRisk, LINK-UP (Smith, Bohner, & McCrickard, 2005), MS Project, MS Visio, and Open Workbench.
Project managers, moreover, need to use different approaches in order to achieve better communication and interaction between the team members. Listening to their team’s opinions highlights the cooperation and team spirit that should be emphasized by the project manager. Encouraging active collaboration and sharing of expertise will further enhance the team building efforts and surely reflect positively on the project success. Many collaboration software and tools are being used such as wikis.
Moreover, team management involves resolving conflicts whenever they arise. Conflicts can be beneficial to the project if well-directed and kept professional allowing each to defend his/her ideas resulting in better judgment of the situation.
“In organizing and managing the project, you can emphasize the organization (structural) or you can emphasize the people. You cannot afford to ignore either.” (Culp & Smith, 1992)
Investing in people is one of the most important techniques that a project manager can use. For instance, enhanced training and investment in productivity tools and methods surely intrigues employees to perform better by meeting, and in some cases exceeding, their expectations.
Further investments in people techniques include providing professional development and career progression opportunities, recognizing achievements using rewarding incentives. These techniques will also help provide psychological relief and stability for the team.
Managing the work environment elevates team morale. Adopting egoless programming techniques, constant motivation, and team balancing are all techniques that will increase the level of productivity of the team.
However, most of these techniques, practices, and tools are not applicable when a virtual team is working on the project (or part of it). “Multi-national projects face many challenges, such as finding and coordinating resources, managing logistics in different countries, defining research methodology, controlling project cost, and dealing with cross-cultural issues.”(Gorlenko & Krause, 2006) Indeed, “globally distributed teams require special skills in system design and project management.” (Cusumano, 2008)
For this purpose, many researches have suggested different approaches. While different software tried to overcome such difficulties.
Donker and Blumberg tackled virtual team management tools issues: “In general, we see an essential necessity in creating a symbiosis between project management tools and collaborative tools, as these two areas are both crucial for virtual project management.” (Donker & Blumberg, 2008)
While Cusumano was interested in the development style when faced with a virtual team experience: “One of the biggest challenges is to apply an iterative (or more popularly called “agile”) style of development when teams are large and not co-located.” (Cusumano, 2008)
Gorlenko and Krause elaborated most on the techniques and tools that could assist in managing virtual teams. They discussed in-depth their experience from different viewpoints including strategies, choice of participating countries, methodology for multi-national data analysis, challenges, and lessons learned of which I choose to mention a particular one: “The number of problems in a multi-national project is proportional to the number of participating segments. Always plan for it.” (Gorlenko & Krause, 2006)
What all the above researches yielded, however, was to stress on the collaborative end of virtual project management. In other words, project managers should work harder on creating a fully collaborative system in order to control and manage virtual teams efficiently. Collaboration techniques and tools became widely available nowadays with the internet revolution that added video-conferencing, instant chatting, cheap voice-calls and many other tools to allow better communication and involvement of team members even if they were working virtually.
Finally, different techniques and tools were devised for project managers allowing them better control and management over their teams whether local or virtual the trick is to know how and when to use them.
Reference:
1. Jamie L. Smith, Shawn A. Bohner, D. Scott McCrickard (March 18, 2005) Center for Human-Computer Interaction and Department of Computer Science Virginia Polytechnic Institute and State University, Blacksburg, VA 24061-0106 USA: Project Management for the 21st Century: Supporting Collaborative Design through Risk Analysis [Research Paper] Available from: ACM digital library.
2. Gordon Culp, Anne Smith (1992) Managing People (including Yourself) for Project Success - Published by John Wiley and Sons, ISBN 0471290181, 9780471290186 [online] available from: Google Scholars: http://books.google.com/books?hl=en&lr=&id=NO5sGrYZTisC&oi=fnd&pg=PR11&dq=project+management+managing+people&ots=zaH0K38gOh&sig=qks4xXsCf5ldsmWuDVVMNJ0upHQ#PPP1,M1
3. Lada Gorlenko, Sven Krause (April 22-27, 2006) Managing International Usability Projects: Cooperative Strategy [Research Paper] Available from: ACM digital library.
4. Michael A. Cusumano (February 2008) Technology Strategy and Management: Managing Software Development in Globally Distributed Teams: Surveying the basic elements needed for globally distributed teams to function smoothly and efficiently. – [article] Communications of The ACM February 2008/Vol. 51, No. 2. Available from: ACM digital library.
5. Hilko Donker, Malte Blumberg (May 13, 2008) Dresden University of Technology, Faculty of Computer Science: Collaborative Process Management and Virtual Teams - CHASE’08 [Research Paper]. Available from: ACM digital library.
In the following excerpt, we will summarize these tools and techniques and further discuss the challenges that project managers face when dealing with virtual teams.
Managing teams, be it in the field of IT or other fields, requires many skills and knowledge of the several available management techniques. Some techniques are related to human communication and interaction while others are related to technical skills, planning, scheduling and team organization, and finally others are related to psychological status of team members.
Effective planning and scheduling techniques aid both project manager and team to develop better understanding of the scope, time, budget, and requirements of the project. Some techniques used in this regard include: Gantt and Pert charts, critical paths and general project plans that incorporate scope charters and budget estimation amongst others. These techniques, by organizing the team and assigning tasks, help each of the members to organize their own tasks and prioritize accordingly.
An increasing number of software is being used as tools that assist project managers in using such techniques. These include: SOPPTS, TeamSpace, TeamSCOPE, SoftRisk, LINK-UP (Smith, Bohner, & McCrickard, 2005), MS Project, MS Visio, and Open Workbench.
Project managers, moreover, need to use different approaches in order to achieve better communication and interaction between the team members. Listening to their team’s opinions highlights the cooperation and team spirit that should be emphasized by the project manager. Encouraging active collaboration and sharing of expertise will further enhance the team building efforts and surely reflect positively on the project success. Many collaboration software and tools are being used such as wikis.
Moreover, team management involves resolving conflicts whenever they arise. Conflicts can be beneficial to the project if well-directed and kept professional allowing each to defend his/her ideas resulting in better judgment of the situation.
“In organizing and managing the project, you can emphasize the organization (structural) or you can emphasize the people. You cannot afford to ignore either.” (Culp & Smith, 1992)
Investing in people is one of the most important techniques that a project manager can use. For instance, enhanced training and investment in productivity tools and methods surely intrigues employees to perform better by meeting, and in some cases exceeding, their expectations.
Further investments in people techniques include providing professional development and career progression opportunities, recognizing achievements using rewarding incentives. These techniques will also help provide psychological relief and stability for the team.
Managing the work environment elevates team morale. Adopting egoless programming techniques, constant motivation, and team balancing are all techniques that will increase the level of productivity of the team.
However, most of these techniques, practices, and tools are not applicable when a virtual team is working on the project (or part of it). “Multi-national projects face many challenges, such as finding and coordinating resources, managing logistics in different countries, defining research methodology, controlling project cost, and dealing with cross-cultural issues.”(Gorlenko & Krause, 2006) Indeed, “globally distributed teams require special skills in system design and project management.” (Cusumano, 2008)
For this purpose, many researches have suggested different approaches. While different software tried to overcome such difficulties.
Donker and Blumberg tackled virtual team management tools issues: “In general, we see an essential necessity in creating a symbiosis between project management tools and collaborative tools, as these two areas are both crucial for virtual project management.” (Donker & Blumberg, 2008)
While Cusumano was interested in the development style when faced with a virtual team experience: “One of the biggest challenges is to apply an iterative (or more popularly called “agile”) style of development when teams are large and not co-located.” (Cusumano, 2008)
Gorlenko and Krause elaborated most on the techniques and tools that could assist in managing virtual teams. They discussed in-depth their experience from different viewpoints including strategies, choice of participating countries, methodology for multi-national data analysis, challenges, and lessons learned of which I choose to mention a particular one: “The number of problems in a multi-national project is proportional to the number of participating segments. Always plan for it.” (Gorlenko & Krause, 2006)
What all the above researches yielded, however, was to stress on the collaborative end of virtual project management. In other words, project managers should work harder on creating a fully collaborative system in order to control and manage virtual teams efficiently. Collaboration techniques and tools became widely available nowadays with the internet revolution that added video-conferencing, instant chatting, cheap voice-calls and many other tools to allow better communication and involvement of team members even if they were working virtually.
Finally, different techniques and tools were devised for project managers allowing them better control and management over their teams whether local or virtual the trick is to know how and when to use them.
Reference:
1. Jamie L. Smith, Shawn A. Bohner, D. Scott McCrickard (March 18, 2005) Center for Human-Computer Interaction and Department of Computer Science Virginia Polytechnic Institute and State University, Blacksburg, VA 24061-0106 USA: Project Management for the 21st Century: Supporting Collaborative Design through Risk Analysis [Research Paper] Available from: ACM digital library.
2. Gordon Culp, Anne Smith (1992) Managing People (including Yourself) for Project Success - Published by John Wiley and Sons, ISBN 0471290181, 9780471290186 [online] available from: Google Scholars: http://books.google.com/books?hl=en&lr=&id=NO5sGrYZTisC&oi=fnd&pg=PR11&dq=project+management+managing+people&ots=zaH0K38gOh&sig=qks4xXsCf5ldsmWuDVVMNJ0upHQ#PPP1,M1
3. Lada Gorlenko, Sven Krause (April 22-27, 2006) Managing International Usability Projects: Cooperative Strategy [Research Paper] Available from: ACM digital library.
4. Michael A. Cusumano (February 2008) Technology Strategy and Management: Managing Software Development in Globally Distributed Teams: Surveying the basic elements needed for globally distributed teams to function smoothly and efficiently. – [article] Communications of The ACM February 2008/Vol. 51, No. 2. Available from: ACM digital library.
5. Hilko Donker, Malte Blumberg (May 13, 2008) Dresden University of Technology, Faculty of Computer Science: Collaborative Process Management and Virtual Teams - CHASE’08 [Research Paper]. Available from: ACM digital library.
Project Schedule Conflicts
Often conflicts arise in projects between the different parties involved. Most of the conflicts, however, seem to be related in some way or another to the project schedule.
In the following paragraphs, we will try to identify the link between schedule issues and conflicts within projects.
Schedules are related to both time management and tasks distribution. These two aspects fall under the responsibility of the project manager. Project managers are responsible not only for managing conflicts, but also controlling and resolving any that might arise in this regards.
Conflicts related to project schedule are of many types and can arise on several different levels within the project team: stakeholders/management vs. project manager, project manager vs. team member(s), and finally team member(s) vs. another team member(s).
Stakeholders are usually concerned with projects meeting deadlines that are sometimes very stressful. “Every time you increase schedule pressure, you increase the likelihood of not meeting your deadlines.” (Richard, 2005) Any delay with the project schedule can cause a conflict between the shareholders and the project manager.
On the other hand, since project managers bear the responsibility of meeting deadlines, they might request more staff members or hiring a third party contractor for a specific job when they feel that the schedule might slip or in order to accommodate to some project change. Such requests might implicate budgetary increases and as a consequence create conflict again with the management.
Conflicts related to schedule between the stakeholders/management and project managers usually reflect on the project team’s schedule. Tighter deadlines, additional tasks, changes to be accommodated within the same deadline will surely add pressure on the project team and create further conflicts.
“Developers tend to think that managers don't respect them, or simply don't care about them. “I have to work yet another weekend because my Project Mangler, who clearly doesn't understand the first thing about software development, thinks that this feature can be done in 3 weeks even though I clearly stated that I would need 5”, is the type of comment often overheard from developers.” (Richard, 2005) This creates yet another type of conflict between the project manager and his team.
Furthermore, team member(s) unsatisfied with task distribution within the schedule provided might complain to the project manager. Conflict in this case might be due to the unjust distribution by the project manager, or the fact that some tasks are more important for future career advancement than others. For instance, discrimination against women is common in this sense. Some consider women less competent in completing certain tasks related to IT due to many gender related reasons. One paper written by four University of Arkansas graduates, highlights this fact with a full study entitled: “Barriers Facing
Women in the IT Work Force.” (Riemenschneider, Armstrong, Allen, and Reid, 2006)
Other types of conflicts can exist when project managers are discontented with the performance of their team. If the team effort is not enough, deadlines might slip. Project managers, in this case, need to find solutions in order to keep the project on-schedule and avoid further conflicts that might arise in case of failure in doing such.
“You might get lucky on a few features, but sooner or later, one of them will slip. And instead of working with you to catch up, the developer will start pointing the finger at you. Then you'll point the finger at him.” (Richard, 2005)
In case a failure happens in delivering any or all parts of a project, more serious problems arise. Blame-game is common in this sense between project owners, project managers, and project team. “Ultimately, people will start caring more about who gets blamed for what than saving the project.” (Richard, 2005)
This type of conflict might reflect into conflicts within the team itself. “Slippages in schedule are not the only source of conflict among developers, and concerns over the allocation of component tasks are especially prevalent among student teams, in which no line management accountability has been established.”(Hogan & Thomas, 2005) Each member starts blaming the incompetency or poor effort of other members in order to take the blame off his/her shoulders.
As a conclusion, project schedules and project conflicts’ are closely linked due to the stress and consequences often related with deadlines and tight schedules. Conflicts can arise between the different involved parties in a project. It is, however, the project managers’ responsibility in all cases to resolve such by using different approaches and skills including: leadership, communication, team motivation, incentives, clear job definitions, team balance, trust, commitment, accountability, discipline, and negotiation.
Reference:
1. Richard, Luc K. (November 7, 2005). Excessive Schedule Pressure [online] available from: http://www.projectmangler.com/content/regular/art20051107.htm
2. Cynthia K. Riemenschneider, Deborah J. Armstrong, Myria W. Allen, Margaret F. Reid (Fall 2006) The DATA BASE for Advances in Information Systems - Fall 2006 (Vol. 37, No. 4): “Barriers Facing Women in the IT Work Force” [Research Paper] Available from: ACM digital library.
3. James M. Hogan and Richard Thomas (2005) Centre for Information Technology Innovation - Queensland University of Technology. ACM International Conference Proceeding Series; Vol. 106 & Proceedings of the 7th Australasian conference on Computing education - Volume 42; ISBN ~ ISSN:1445-1336 , 1-920682-24-4; “Developing the Software Engineering Team” [Paper] Available from: ACM digital library.
In the following paragraphs, we will try to identify the link between schedule issues and conflicts within projects.
Schedules are related to both time management and tasks distribution. These two aspects fall under the responsibility of the project manager. Project managers are responsible not only for managing conflicts, but also controlling and resolving any that might arise in this regards.
Conflicts related to project schedule are of many types and can arise on several different levels within the project team: stakeholders/management vs. project manager, project manager vs. team member(s), and finally team member(s) vs. another team member(s).
Stakeholders are usually concerned with projects meeting deadlines that are sometimes very stressful. “Every time you increase schedule pressure, you increase the likelihood of not meeting your deadlines.” (Richard, 2005) Any delay with the project schedule can cause a conflict between the shareholders and the project manager.
On the other hand, since project managers bear the responsibility of meeting deadlines, they might request more staff members or hiring a third party contractor for a specific job when they feel that the schedule might slip or in order to accommodate to some project change. Such requests might implicate budgetary increases and as a consequence create conflict again with the management.
Conflicts related to schedule between the stakeholders/management and project managers usually reflect on the project team’s schedule. Tighter deadlines, additional tasks, changes to be accommodated within the same deadline will surely add pressure on the project team and create further conflicts.
“Developers tend to think that managers don't respect them, or simply don't care about them. “I have to work yet another weekend because my Project Mangler, who clearly doesn't understand the first thing about software development, thinks that this feature can be done in 3 weeks even though I clearly stated that I would need 5”, is the type of comment often overheard from developers.” (Richard, 2005) This creates yet another type of conflict between the project manager and his team.
Furthermore, team member(s) unsatisfied with task distribution within the schedule provided might complain to the project manager. Conflict in this case might be due to the unjust distribution by the project manager, or the fact that some tasks are more important for future career advancement than others. For instance, discrimination against women is common in this sense. Some consider women less competent in completing certain tasks related to IT due to many gender related reasons. One paper written by four University of Arkansas graduates, highlights this fact with a full study entitled: “Barriers Facing
Women in the IT Work Force.” (Riemenschneider, Armstrong, Allen, and Reid, 2006)
Other types of conflicts can exist when project managers are discontented with the performance of their team. If the team effort is not enough, deadlines might slip. Project managers, in this case, need to find solutions in order to keep the project on-schedule and avoid further conflicts that might arise in case of failure in doing such.
“You might get lucky on a few features, but sooner or later, one of them will slip. And instead of working with you to catch up, the developer will start pointing the finger at you. Then you'll point the finger at him.” (Richard, 2005)
In case a failure happens in delivering any or all parts of a project, more serious problems arise. Blame-game is common in this sense between project owners, project managers, and project team. “Ultimately, people will start caring more about who gets blamed for what than saving the project.” (Richard, 2005)
This type of conflict might reflect into conflicts within the team itself. “Slippages in schedule are not the only source of conflict among developers, and concerns over the allocation of component tasks are especially prevalent among student teams, in which no line management accountability has been established.”(Hogan & Thomas, 2005) Each member starts blaming the incompetency or poor effort of other members in order to take the blame off his/her shoulders.
As a conclusion, project schedules and project conflicts’ are closely linked due to the stress and consequences often related with deadlines and tight schedules. Conflicts can arise between the different involved parties in a project. It is, however, the project managers’ responsibility in all cases to resolve such by using different approaches and skills including: leadership, communication, team motivation, incentives, clear job definitions, team balance, trust, commitment, accountability, discipline, and negotiation.
Reference:
1. Richard, Luc K. (November 7, 2005). Excessive Schedule Pressure [online] available from: http://www.projectmangler.com/content/regular/art20051107.htm
2. Cynthia K. Riemenschneider, Deborah J. Armstrong, Myria W. Allen, Margaret F. Reid (Fall 2006) The DATA BASE for Advances in Information Systems - Fall 2006 (Vol. 37, No. 4): “Barriers Facing Women in the IT Work Force” [Research Paper] Available from: ACM digital library.
3. James M. Hogan and Richard Thomas (2005) Centre for Information Technology Innovation - Queensland University of Technology. ACM International Conference Proceeding Series; Vol. 106 & Proceedings of the 7th Australasian conference on Computing education - Volume 42; ISBN ~ ISSN:1445-1336 , 1-920682-24-4; “Developing the Software Engineering Team” [Paper] Available from: ACM digital library.
Friday, October 17, 2008
Project Cost Management
Why many information technology professionals have a poor attitude toward project cost management and how this attitude might affect the poor track record for completing projects within budget.
By simply searching Google or Yahoo with strings like “IT Project failed” or “IT Project goes over-budget” one will immediately understand how often IT Projects fail due to failed cost management. One survey reported that “Projects that are considered 'challenged' – usually due to cost or schedule overruns – account for 51% of all projects.”(PM Today, n.d.) Cost management is one of the most critical aspects that fall under the responsibilities of the project manager. Cost estimation, budgeting, and cost control are usually the reasons for most of the project managers’ nightmares. IT project managers in particular, tend to have a poorer attitude toward project cost management. But why is that?
IT project managers have a poor track record for completing projects within budget due to the fact that they are more interested in closing the project on-time then within budget.
“According to KPMG, only 9% of organizations feel that delivering projects within budget is their most important measurement for success. Also, only 21% said that being on-time was their top driver.” (OUT-LAW News, Nov. 2002) Due to the fast evolution of technology, project managers tend to be more concerned about the timeliness of their projects.
Cutting short the time required to estimate costs is a common practice amongst IT project managers. Quick decisions, while evaluating the required costs for a project, opens the door for speculations and unsound decisions. In general, human beings are biased toward underestimation; specially programmers. The ego, overconfidence, and unawareness in tracking time, drive programmers to give lower estimates concerning the time needed to complete any particular task. Less time estimates implies lower estimated costs.
The real nightmare of the project manager in fact is due not during the estimation phase, but at a later stage during management and control of such. In fact most project managers have the hardest time completing this task: “For many project managers managing budgets along the critical path becomes both a challenge and a source of frustration.” (BCS, n.d.) Frustration, in this sense, is due to the poor estimations previously done. But what is done is done.
Finding solutions in order to cut down further costs adds to the frustration. In order to request more funds for a project from upper management, project managers need proper supporting reasons which most of the time don’t exist.
Since project initiation, stakeholders, and especially the financially related ones, require accurate and precise cost estimates in order to assess the feasibility of any project. However, this is not the case with IT PM. Knowing the amount of work and the huge number of different responsibilities that fall under an IT project manager’s job description, finishing within budget becomes of lower priority. In fact, he/she might even purposely underestimate a project’s budget in order to get approval the fastest possible and initiate a project.
Time is the main concern for IT project managers. Initiating projects faster, estimating cost faster, and pushing their teams to finish on-time is a priority. Producing output and visual proof of project progress are the only things that relieve both the project manager and the stakeholders.
However, coming back to cost control, IT project managers face their toughest challenges. Early budgetary estimations usually are accurate when it comes to tangible requirements like software and hardware requirements. The remaining costs are related to man-hours which are the hardest to minimize. Man-hours, eventhough related to the team’s morale which affects directly productivity, has however limitations. Some things are simply impossible to be done unless given a minimum timeframe.
Cutting down on costs, therefore leads project managers to think about ways to cut down on time required which in turn leads project managers to sometimes jeopardize the quality of the resulting project. Skipping on documentation, code comments, and frequent testing of modules are some of the strategies that are used in this context.
As a summary, IT project managers face a very challenging problem when it comes to cost management and therefore tend to have a rather poor attitude towards it. The problem comes as a tradeoff between cost, time, and quality; and IT professionals choose time.
Nowadays, however, in order to avoid having these problems, “Most other Fortune 1000 companies are in the process of setting up PMOs.” (Hertzberg, May 2007) Saving them money on experienced and skilled human resources required, management headaches, and getting better results makes PMOs most appropriate. “Effective project management can save organizations millions, if not billions of dollars in lost revenue, says J. LeRoy Ward, PMP, PgMP, executive vice president at ESI International”.(PM Today, n.d.)
References:
PM Today (n.d.) Troubled projects costing billions worldwide.[online] Available from: Project Manager Today: http://www.pmtoday.co.uk/content/en/news_details.aspx?guid=94ACA134-74CA-43C6-9AC3-F9C6A6318552
BCS (British Computer Society) (n.d.) Keeping projects under cost control [online] Available from: http://www.bcs.org/server.php?show=ConWebDoc.5912
OUT-LAW News (Nov. 2002) Failed IT projects cost businesses millions, says survey [Online] Available from: http://www.out-law.com/page-3149
Hertzberg, Robert (May 07, 2007) I.T. Cost Containment: 5 Best Practices. [online] available from: http://www.baselinemag.com/c/a/Projects-Management/IT-Cost-Containment-5-Best-Practices/
By simply searching Google or Yahoo with strings like “IT Project failed” or “IT Project goes over-budget” one will immediately understand how often IT Projects fail due to failed cost management. One survey reported that “Projects that are considered 'challenged' – usually due to cost or schedule overruns – account for 51% of all projects.”(PM Today, n.d.) Cost management is one of the most critical aspects that fall under the responsibilities of the project manager. Cost estimation, budgeting, and cost control are usually the reasons for most of the project managers’ nightmares. IT project managers in particular, tend to have a poorer attitude toward project cost management. But why is that?
IT project managers have a poor track record for completing projects within budget due to the fact that they are more interested in closing the project on-time then within budget.
“According to KPMG, only 9% of organizations feel that delivering projects within budget is their most important measurement for success. Also, only 21% said that being on-time was their top driver.” (OUT-LAW News, Nov. 2002) Due to the fast evolution of technology, project managers tend to be more concerned about the timeliness of their projects.
Cutting short the time required to estimate costs is a common practice amongst IT project managers. Quick decisions, while evaluating the required costs for a project, opens the door for speculations and unsound decisions. In general, human beings are biased toward underestimation; specially programmers. The ego, overconfidence, and unawareness in tracking time, drive programmers to give lower estimates concerning the time needed to complete any particular task. Less time estimates implies lower estimated costs.
The real nightmare of the project manager in fact is due not during the estimation phase, but at a later stage during management and control of such. In fact most project managers have the hardest time completing this task: “For many project managers managing budgets along the critical path becomes both a challenge and a source of frustration.” (BCS, n.d.) Frustration, in this sense, is due to the poor estimations previously done. But what is done is done.
Finding solutions in order to cut down further costs adds to the frustration. In order to request more funds for a project from upper management, project managers need proper supporting reasons which most of the time don’t exist.
Since project initiation, stakeholders, and especially the financially related ones, require accurate and precise cost estimates in order to assess the feasibility of any project. However, this is not the case with IT PM. Knowing the amount of work and the huge number of different responsibilities that fall under an IT project manager’s job description, finishing within budget becomes of lower priority. In fact, he/she might even purposely underestimate a project’s budget in order to get approval the fastest possible and initiate a project.
Time is the main concern for IT project managers. Initiating projects faster, estimating cost faster, and pushing their teams to finish on-time is a priority. Producing output and visual proof of project progress are the only things that relieve both the project manager and the stakeholders.
However, coming back to cost control, IT project managers face their toughest challenges. Early budgetary estimations usually are accurate when it comes to tangible requirements like software and hardware requirements. The remaining costs are related to man-hours which are the hardest to minimize. Man-hours, eventhough related to the team’s morale which affects directly productivity, has however limitations. Some things are simply impossible to be done unless given a minimum timeframe.
Cutting down on costs, therefore leads project managers to think about ways to cut down on time required which in turn leads project managers to sometimes jeopardize the quality of the resulting project. Skipping on documentation, code comments, and frequent testing of modules are some of the strategies that are used in this context.
As a summary, IT project managers face a very challenging problem when it comes to cost management and therefore tend to have a rather poor attitude towards it. The problem comes as a tradeoff between cost, time, and quality; and IT professionals choose time.
Nowadays, however, in order to avoid having these problems, “Most other Fortune 1000 companies are in the process of setting up PMOs.” (Hertzberg, May 2007) Saving them money on experienced and skilled human resources required, management headaches, and getting better results makes PMOs most appropriate. “Effective project management can save organizations millions, if not billions of dollars in lost revenue, says J. LeRoy Ward, PMP, PgMP, executive vice president at ESI International”.(PM Today, n.d.)
References:
PM Today (n.d.) Troubled projects costing billions worldwide.[online] Available from: Project Manager Today: http://www.pmtoday.co.uk/content/en/news_details.aspx?guid=94ACA134-74CA-43C6-9AC3-F9C6A6318552
BCS (British Computer Society) (n.d.) Keeping projects under cost control [online] Available from: http://www.bcs.org/server.php?show=ConWebDoc.5912
OUT-LAW News (Nov. 2002) Failed IT projects cost businesses millions, says survey [Online] Available from: http://www.out-law.com/page-3149
Hertzberg, Robert (May 07, 2007) I.T. Cost Containment: 5 Best Practices. [online] available from: http://www.baselinemag.com/c/a/Projects-Management/IT-Cost-Containment-5-Best-Practices/
Friday, October 3, 2008
Define & Refine
Importance of Project Scope Management
Are you a project manager facing a failing streak? Are you having trouble in understanding the objectives and requirements of your project? You might want to consider focusing more on your Projects’ Scope Management aspect. Project Scope Management is the process of planning, defining, verifying, and controlling the requirements in any project. Making sure you have the complete requirements is the utmost consideration before starting any other process in a project. “The 1995 Chaos survey of IT executive managers listed the Top 10 causes for project termination to be:
1. Incomplete requirements (13.1 percent)…
2. Lack of user involvement (12.4 percent)…
3. Lack of resources (10.6 percent)…
4. Unrealistic expectations (9.9 percent)…
5. Lack of executive support (9.3 percent)…
6. Changing requirements (8.7 percent)…
7. Lack of planning (8.1 percent)…
8. Absence of need (7.5 percent)…
9. Lack of IT management (6.2 percent)…
10. Technology illiteracy (4.3 percent)” (Boehm, 2000)
The above statistics not only emphasize the importance of having complete requirements (13.1%), but, furthermore, highlight the necessity for scope management. Scope Management represents 31.7% of the causes for project termination (failure in this case) as portrayed above: incomplete requirements (13.1%) + unrealistic expectations (9.9 %) + changing requirements (8.7 %).
Stakeholders or project owners sometimes have unrealistic expectations. These expectations cannot surface unless scope definition is refined. Having unclear or misunderstood scope/objectives was listed as the number one risk in another survey performed by Addison and Vallabh: “All respondents indicated that the risk of unclear or misunderstood scope/objectives was very important… Aggregating the responses resulted in the following ranking of the listed risks: (in order of importance): — Unclear or misunderstood scope/objectives (Risk 1)” (Addison & Vallabh, 2002). Below is a chart showing the full results.
Fig. 1: IT Projects’ Risk Factors’ Importance Percentage as per the survey performed by Addison & Vallabh [2002]
While changing requirements is managed by the Control Management Plan, Scope Management allows the project manager to identify and report the effects of such a possible scope change avoiding by which any scope creep.
Marwan Abi Antoun in a recent research paper; while detailing his experience in an IT project which he referred to as “project BLUE”; mentioned what he considered as a “serious process mistake” referring to project scope creep which “introduced delays at various points” of the project. (Abi-Antoun, 2007)
Avoiding such scope creeps was cited in Addison and Vallabh’s paper quoting Keil et al. [1998]: “to avoid the problem of scope creep, project managers should inform users of the impact of scope changes in terms of project cost and schedule.” (Addison & Vallabh, 2002) In this sense, Scope Management has direct effect on the cost and schedule of a project which are considered two of three (third being quality) defining elements for project success.
Moreover, focusing on Project Scope Management permits the project manager to have a better understanding of what to expect through initial estimations he/she should make related to an original Work Breakdown Structure (WBS) devised as part of this management plan. “The risk of ‘unclear or misunderstood scope/objectives’ also occurs less frequently when the project is broken down into controllable portions.” (Addison & Vallabh, 2002) Breaking down the project along with their initial estimations, help further in identifying risks associated with any of the project aspects. These estimations are considered vital for scope verification. Stakeholders need to provide the project manager with enough input allowing him/her to verify the accuracy level of both his/her estimations and scope definition (along with many other aspects).
Project Scope Management’s real effect on project success or failure is mainly related to the question of understanding what problem or need is this project solving/fulfilling in addition to managing and controlling any possible changes that might be faced throughout the project processes. Appreciating the value of Project Scope Management will always pay-off favoring project success.
References:
Abi-Antoun, Marwan (October 21–25, 2007) Making Frameworks Work: a Project Retrospective [Research Paper] Available from: ACM Digital Library - ACM 978-1-59593-865-7/07/0010
Boehm, Barry (2001) Software Management: Project Termination Doesn’t Equal Project Failure [Article] Available from: IEEE Xplore and www.cs.unc.edu/~welch/class/comp145/media/docs/Boehm_Term_NE_Fail.pdf
Tom Addison and Seema Vallabh (2002) Controlling Software Project Risks – an Empirical Study of Methods used by Experienced Project Managers [Paper] Available from: ACM Digital Library.
Are you a project manager facing a failing streak? Are you having trouble in understanding the objectives and requirements of your project? You might want to consider focusing more on your Projects’ Scope Management aspect. Project Scope Management is the process of planning, defining, verifying, and controlling the requirements in any project. Making sure you have the complete requirements is the utmost consideration before starting any other process in a project. “The 1995 Chaos survey of IT executive managers listed the Top 10 causes for project termination to be:
1. Incomplete requirements (13.1 percent)…
2. Lack of user involvement (12.4 percent)…
3. Lack of resources (10.6 percent)…
4. Unrealistic expectations (9.9 percent)…
5. Lack of executive support (9.3 percent)…
6. Changing requirements (8.7 percent)…
7. Lack of planning (8.1 percent)…
8. Absence of need (7.5 percent)…
9. Lack of IT management (6.2 percent)…
10. Technology illiteracy (4.3 percent)” (Boehm, 2000)
The above statistics not only emphasize the importance of having complete requirements (13.1%), but, furthermore, highlight the necessity for scope management. Scope Management represents 31.7% of the causes for project termination (failure in this case) as portrayed above: incomplete requirements (13.1%) + unrealistic expectations (9.9 %) + changing requirements (8.7 %).
Stakeholders or project owners sometimes have unrealistic expectations. These expectations cannot surface unless scope definition is refined. Having unclear or misunderstood scope/objectives was listed as the number one risk in another survey performed by Addison and Vallabh: “All respondents indicated that the risk of unclear or misunderstood scope/objectives was very important… Aggregating the responses resulted in the following ranking of the listed risks: (in order of importance): — Unclear or misunderstood scope/objectives (Risk 1)” (Addison & Vallabh, 2002). Below is a chart showing the full results.
Fig. 1: IT Projects’ Risk Factors’ Importance Percentage as per the survey performed by Addison & Vallabh [2002]
While changing requirements is managed by the Control Management Plan, Scope Management allows the project manager to identify and report the effects of such a possible scope change avoiding by which any scope creep.
Marwan Abi Antoun in a recent research paper; while detailing his experience in an IT project which he referred to as “project BLUE”; mentioned what he considered as a “serious process mistake” referring to project scope creep which “introduced delays at various points” of the project. (Abi-Antoun, 2007)
Avoiding such scope creeps was cited in Addison and Vallabh’s paper quoting Keil et al. [1998]: “to avoid the problem of scope creep, project managers should inform users of the impact of scope changes in terms of project cost and schedule.” (Addison & Vallabh, 2002) In this sense, Scope Management has direct effect on the cost and schedule of a project which are considered two of three (third being quality) defining elements for project success.
Moreover, focusing on Project Scope Management permits the project manager to have a better understanding of what to expect through initial estimations he/she should make related to an original Work Breakdown Structure (WBS) devised as part of this management plan. “The risk of ‘unclear or misunderstood scope/objectives’ also occurs less frequently when the project is broken down into controllable portions.” (Addison & Vallabh, 2002) Breaking down the project along with their initial estimations, help further in identifying risks associated with any of the project aspects. These estimations are considered vital for scope verification. Stakeholders need to provide the project manager with enough input allowing him/her to verify the accuracy level of both his/her estimations and scope definition (along with many other aspects).
Project Scope Management’s real effect on project success or failure is mainly related to the question of understanding what problem or need is this project solving/fulfilling in addition to managing and controlling any possible changes that might be faced throughout the project processes. Appreciating the value of Project Scope Management will always pay-off favoring project success.
References:
Abi-Antoun, Marwan (October 21–25, 2007) Making Frameworks Work: a Project Retrospective [Research Paper] Available from: ACM Digital Library - ACM 978-1-59593-865-7/07/0010
Boehm, Barry (2001) Software Management: Project Termination Doesn’t Equal Project Failure [Article] Available from: IEEE Xplore and www.cs.unc.edu/~welch/class/comp145/media/docs/Boehm_Term_NE_Fail.pdf
Tom Addison and Seema Vallabh (2002) Controlling Software Project Risks – an Empirical Study of Methods used by Experienced Project Managers [Paper] Available from: ACM Digital Library.
Thursday, October 2, 2008
LAST BUT NOT LEAST
Importance of Project Termination Planning
It is said that “you never get a second chance to make a first impression” (unknown, n.d.); however, you always have the chance to leave the floor with the best finale.
Project Termination Plan (PTP) is the roadmap for closing projects in the most successful manner. Project failure or success is irrelevant to the fact that a proper handover of the final product should be made. PTP is actually one of the criteria that differentiate successful project managers from struggling ones.
Why is it so important?
Early planning minimizes risks of failure. When a project approaches termination or closure its environment changes: resources start thinking or worrying about their next project; final testing adds to the stress; documentation becomes a present issue; installation, production, training, and change control guides need to be in place; necessity of financial closeout; management final reports; equipment handover; and finally a call for a lessons learned brainstorming session.
Without planning, all the above mentioned aspects will be hard to control and achieve. “As projects near completion, there is a natural tendency to minimize costs by transferring people as soon as possible and by closing out work orders.”(Visitask, n.d.) When your project team has already left, or is no longer focused, your termination process is at risk. “Project Termination is usually an emotional time for the project team” (Taylor, n.d.) For this purpose, project managers use the PTP as their guide to avoid such risks in the final stage of the project. “The Project Manager must plan for the termination phase well in advance of the scheduled project end – ideally in the development phase of the project’s life cycle” (Taylor, n.d.)
Managing the last minutes of the project life cycle highlights not only the leadership skills of the PM to control the siphoning of his resources, but, furthermore, proves the validity of his original plans. For instance initiating the documentation process only after the entire project is done will cause a schedule increase. Documentation should be preplanned to cover the different stages of the project allowing swifter project termination.
Documentation and training guides may be the most important deliverable of the project termination process from a client’s perspective; however, the lessons learned brainstorming session report is the vital element of project termination for project managers. This report helps both the development company and project manager learn from previous experiences thus allowing improvements to, and setting guidelines for, any similar future project management plans.
Having a project termination plan increases further the reliability factor of the management towards the project manager. “Although the primary emphasis in any project is to provide the end product to the customer on time and on schedule, the project manager must not forget that there are ancillary support items required in each project.” (Taylor, n.d.) Stakeholders care to know that the final product is not going to be an alien handed over in a rushed manner. Planned periodic audits, continuous support, and a well-documented product with an established change control mechanism constitute what is considered as a successfully delivered project. Moreover, the project manager’s management would surely recognize clients’ satisfaction towards project termination that will reflect positively on the development company’s reputation.
As for projects that are terminated because of some failure, PTP is equally important. “Project Termination can not even be disregarded for an unsuccessful project. Even in such a case, there are key learnings, team evaluations and other wrap-up activities to make the most of what has been done in the project.” (Visitask, n.d.)When projects fail people start blaming each other, getting rid of evidence, and leave the soonest possible in fear of relating their names with an unsuccessful project. “It can take some adjustment to realize that terminating projects can be natural and even healthy.” (Boehm, 2001) This fact makes the termination process even harder to achieve. PTP in this sense, especially if included in the signed-off project charter, offers the project manager the instructions and authority he/she needs in order to close this chapter in the most professional way.
Convincing a project manager to include PTP as part of their project plan should be made easier with the above advantages discussed. I believe the way to remember to do Project Termination Planning is to always associate it with the phrase “Last but not least”; although it tackles the Last or final part of the project, but it is surely not the Least aspect to consider when devising their project plans.
References:
Unknown (n.d.) First Impressions quotes [online] Available from: http://thinkexist.com/quotes/with/keyword/first_impressions/
Taylor, James (n.d.) A Survival Guide For Project Managers: Chapter 14: The Termination Phase - Second Edition – Page 275-287 [book] available from: http://books.google.com/books?id=QRoGPcBfTOkC&pg=PA276&dq=project+termination+planning+books&as_brr=3&sig=ACfU3U0qnI6W1jumP6aOQk_hvBxmQKoMDA#PPP1,M1
Visitask (n.d.) The Importance of Formal Project Termination Procedures [online]
Available from: http://www.visitask.com/Project-Termination.asp
Boehm, Barry (2001) Software Management: Project Termination Doesn’t Equal Project Failure [Article] Available from: IEEE Xplore and www.cs.unc.edu/~welch/class/comp145/media/docs/Boehm_Term_NE_Fail.pdf
It is said that “you never get a second chance to make a first impression” (unknown, n.d.); however, you always have the chance to leave the floor with the best finale.
Project Termination Plan (PTP) is the roadmap for closing projects in the most successful manner. Project failure or success is irrelevant to the fact that a proper handover of the final product should be made. PTP is actually one of the criteria that differentiate successful project managers from struggling ones.
Why is it so important?
Early planning minimizes risks of failure. When a project approaches termination or closure its environment changes: resources start thinking or worrying about their next project; final testing adds to the stress; documentation becomes a present issue; installation, production, training, and change control guides need to be in place; necessity of financial closeout; management final reports; equipment handover; and finally a call for a lessons learned brainstorming session.
Without planning, all the above mentioned aspects will be hard to control and achieve. “As projects near completion, there is a natural tendency to minimize costs by transferring people as soon as possible and by closing out work orders.”(Visitask, n.d.) When your project team has already left, or is no longer focused, your termination process is at risk. “Project Termination is usually an emotional time for the project team” (Taylor, n.d.) For this purpose, project managers use the PTP as their guide to avoid such risks in the final stage of the project. “The Project Manager must plan for the termination phase well in advance of the scheduled project end – ideally in the development phase of the project’s life cycle” (Taylor, n.d.)
Managing the last minutes of the project life cycle highlights not only the leadership skills of the PM to control the siphoning of his resources, but, furthermore, proves the validity of his original plans. For instance initiating the documentation process only after the entire project is done will cause a schedule increase. Documentation should be preplanned to cover the different stages of the project allowing swifter project termination.
Documentation and training guides may be the most important deliverable of the project termination process from a client’s perspective; however, the lessons learned brainstorming session report is the vital element of project termination for project managers. This report helps both the development company and project manager learn from previous experiences thus allowing improvements to, and setting guidelines for, any similar future project management plans.
Having a project termination plan increases further the reliability factor of the management towards the project manager. “Although the primary emphasis in any project is to provide the end product to the customer on time and on schedule, the project manager must not forget that there are ancillary support items required in each project.” (Taylor, n.d.) Stakeholders care to know that the final product is not going to be an alien handed over in a rushed manner. Planned periodic audits, continuous support, and a well-documented product with an established change control mechanism constitute what is considered as a successfully delivered project. Moreover, the project manager’s management would surely recognize clients’ satisfaction towards project termination that will reflect positively on the development company’s reputation.
As for projects that are terminated because of some failure, PTP is equally important. “Project Termination can not even be disregarded for an unsuccessful project. Even in such a case, there are key learnings, team evaluations and other wrap-up activities to make the most of what has been done in the project.” (Visitask, n.d.)When projects fail people start blaming each other, getting rid of evidence, and leave the soonest possible in fear of relating their names with an unsuccessful project. “It can take some adjustment to realize that terminating projects can be natural and even healthy.” (Boehm, 2001) This fact makes the termination process even harder to achieve. PTP in this sense, especially if included in the signed-off project charter, offers the project manager the instructions and authority he/she needs in order to close this chapter in the most professional way.
Convincing a project manager to include PTP as part of their project plan should be made easier with the above advantages discussed. I believe the way to remember to do Project Termination Planning is to always associate it with the phrase “Last but not least”; although it tackles the Last or final part of the project, but it is surely not the Least aspect to consider when devising their project plans.
References:
Unknown (n.d.) First Impressions quotes [online] Available from: http://thinkexist.com/quotes/with/keyword/first_impressions/
Taylor, James (n.d.) A Survival Guide For Project Managers: Chapter 14: The Termination Phase - Second Edition – Page 275-287 [book] available from: http://books.google.com/books?id=QRoGPcBfTOkC&pg=PA276&dq=project+termination+planning+books&as_brr=3&sig=ACfU3U0qnI6W1jumP6aOQk_hvBxmQKoMDA#PPP1,M1
Visitask (n.d.) The Importance of Formal Project Termination Procedures [online]
Available from: http://www.visitask.com/Project-Termination.asp
Boehm, Barry (2001) Software Management: Project Termination Doesn’t Equal Project Failure [Article] Available from: IEEE Xplore and www.cs.unc.edu/~welch/class/comp145/media/docs/Boehm_Term_NE_Fail.pdf
Subscribe to:
Posts (Atom)
Posts
