Success Factors

The Chaos report version 1995 listed the project success factors based on respondents experiences, those 365 respondents gave user involvement the highest percentage while executive management second while hard-working and focused staff were given the least percentage. Based on my experience I would give executive management support the highest percentage and pick it as the most critical success factor for my ERP development project.

The project I am working on is an in-house ERP development project; the objective of this project is to produce an ERP application that can be used by my organization and later on customize it based on potential clients needs to make it ready for the market. Development of ERP system requires collaboration and commitment from all business divisions, without such commitment the project would fail. Usually commitment from business users is not easy to get, that because they have other priorities, unless business division management is fully committed to the project. Such commitment will be reflected to business users and add more stability to project schedule. In general, project success heavily depends on strong leadership, and commitment from top management. For example my current employer have implemented a system which at the beginning was fully supported by the management, by time management lost interest in this system due to high maintenance cost. Because of that, management has forced a direction to decommission this system and replace it another system that has less maintenance cost, although it might seem that the cost is the main driving factor for such decision, but even costly systems can survive with management support.

Organizational changes caused by projects is another important reason makes me believe that executive management support is the most important success factor, sometimes certain projects require major structural and organizational changes to insure project success, or because the project itself explores a new technology that might lead to staff replacement, and such project would see the sun unless it is supported and blessed by executive management (O’Brochta, 2008). In addition that lots of processes and procedures require management support, especially if they are new to the organization, “follow a documented project plan and ensure that projects are based on documented requirements” (O’Brochta, 2008).

Executive management support will ease project manager job, it will help in getting more resources when needed, put more pressure on certain departments to insure project schedule met, and adds more control over the project by the project manager.

Reference:

Elisabeth J Umble, Ronald R Haft, M.Michael Umble, Enterprise resource planning: Implementation procedures and critical success factors, European Journal of Operational Research, Volume 146, Issue 2, 16 April 2003, Pages 241-257, ISSN 0377-2217, 10.1016/S0377-2217(02)00547-7. http://www.sciencedirect.com/science/article/pii/S0377221702005477

(Accessed 21 January 2012)

O’Brochta, M., (2008), ‘Executive Actions For Project Success’, Published in PM World Today – December 2008 (Vol X, Issue XII), [Online], Available from:

http://www.pmforum.org/library/papers/2008/PDFs/OBrochta-12-08.pdf

(Accessed 21 January 2012)

Evaluation Metric

Project evaluation is crucial for any project to measure project status in terms of meeting budget, schedule, resource performance and a lot more. It helps in identifying issues with software development projects, methodologies followed and a lot more. The main purpose from project evaluation is to help “decision-makers in evaluating funding priorities” (). Project evaluation takes place through project evaluation metrics, which require time and effort, and used to help in as identified by Lever:

To offer sharp and real project status information with regards to schedule and cost.

To detect areas for project process enhancement.

To substantiate the results of process improvement efforts.

“To collect a database of project metrics to analyze trend information or provide historic comparators and perhaps used for parametric estimates” (lever, 2009).

Because evaluation metrics consume lots of time and effort to gather and analyze, its not practical to collect all project metrics for a project, instead project manager should identify relevant metrics to evaluate based on project need and stakeholders requirements. Developing metrics that help in project process improvement and enhancement add more value, as well metrics that offer accurate and real data about project status and budget will provide a better understanding of project specific needs, and provides project manager with signs that help in identifying problems and issues before they occur.

In-house ERP development project matrix attached, details discussed below:

First metric to evaluate will be the cost, most importantly comparison between budget approved at the beginning of the project and the actual project budget, this value will be analyzed to derive areas which consumed more budget and reason for such budget drift.

Second metric to evaluate will be schedule, we will be looking at project plan and evaluating current project progress, this will help in identifying root cause of the delay and find ways to put the project back in track.

Third evaluated metric is scope, number of requested changes, approved changes and impact on project time and budget. Scope is evaluated to insure that project won’t lose its original objective and fall into scope creep.

Quality will be he forth metric to evaluate, by quality we mean following processes, procedure and software development methodologies, insuring project phases; changes and code are properly documented. This will help in tracking project, and aligning project to universal quality standards.

Code complexity and lines of code will be measured to evaluate code quality, and identify other ways code could have been developed with, for example sometimes the way a code is written affect performance and major software functionality. For that software metric is very important to measure in an in-house development project.

The last metric to evaluate is defects, this is important because it will help in evaluating application-integrated functions, application fit to use. Number of defects and bugs and their impact should be evaluated during testing phase.

Project evaluation help in increasing number of successful projects for the IT industry in general and for an organization in specific, such evaluation will add value during a project and as well for future projects.

Reference:

Anonymous, (2006), Project Evaluation Framework, [Online], Available from:

http://dnr.wi.gov/org/water/watersheds/planning/documents/project_evaluation.pdf

(Accessed 21 January 2012)

Lever, R., (2009), ‘Project Evaluation and Selecting Project Metrics’ Project Management Metrics a Tool for Project Process Improvement, [Online], Available form: http://roger-lever.suite101.com/project-evaluation-and-selecting-project-metrics-a92421

(Accessed 21 January 2012)

Scope Management

“Project Scope Management is defined as the processes required to ensure that the project includes all the work required, and only the work required, to complete the project successfully” (Mathur, 2007). From the definition we conclude that project scope could exceed identified requirements, which could result in project failure, that because project successful completion requires defined and agreed upon scope, else project could fail.

There are many problems in the scope that make it one of the most critical and hard to control within the project lifecycle, scope could be ambiguous and this ambiguity could lead to misperception and needless work. As well project scope could be incomplete, and this leads to schedule slips as mentioned by Mathur. Other scope problems are collaborative, which leads to misunderstandings of requirements and confusion. In addition to those problems, scope creep could result due to the scope being transient; this leads to never ending projects and late deliveries. All those problems could lead to project failures, cost over run and late deliveries, Mathur said that more than 70% of projects fail, and in those 70% its rarely technical reason behind failure (Mathur, 2007). Concrete and solid scope management doesn’t mean that all changes are not accepted during project lifecycle, sometimes there are necessary changes, if not performed project could fail. But the process of controlling those changes should take place to insure proper change and scope control.

Changes during project lifecycle should be controlled, from the beginning to the end; else it will increase the workload on all team members and without any proper outcome. Changes should go through the proper evaluation, justification and approval channels, to insure that all those changes fit for project purpose, and allocate budget and time frame for those changes. As well, any nice to have or not mandatory change should be kept in a wish list. Not doing so will lead to improper scope management and hence project failure or delayed. If the scope is not managed in a correct way, it will definitely lead to unsuccessful projects. On the other hand, proper scope management will increase percentage and possibility of having successful projects.

Scope management is one of the most important knowledge areas in project management; this is due to the importance of the project scope and its impact on project status being a success or a failure.

Reference:

Atkinson, R., Crawford, L., & Ward, S., (2006), Fundamental uncertainties in projects and the scope of project management, International Journal of Project Management, Volume 24, Issue 8, November 2006, Pages 687-698, ISSN 0263-7863, 10.1016/j.ijproman.2006.09.011. (http://www.sciencedirect.com/science/article/pii/S0263786306001438)

(Accessed 14 January 2012)

Mathur, A., (2007), ‘Improve Project Success with Better Scope Management’, PM World Today - August 2007 (Vol. IX, Issue VIII), [Online], Available from:

http://www.pmforum.org/library/tips/2007/PDFs/Mathur-8-07.pdf (Accessed 14 January 2012)

Project Termination

Project closure process includes wining stakeholders and client’s acceptance of the final project deliverables, and transports the project into and well-ordered end. Output of this process could be operational documents to help in running this project after the project is completed; as well lessons learned based on what went right and what went wrong to act as a reference for future projects. In addition to that, all contract are closed with external suppliers.

Project closure is different that project termination process, the former process is held in case of a successful project and normal project end of life. On the other hand, project termination process takes place when the project is successful or when there is a need to terminate a project’s life, this could be caused by various reasons such as unrealistic requirements, technology used became obsolete, and human resources couldn’t be replaced and many other reasons. Project termination doesn’t mean project failure, and terminating a project doesn’t mean that the project manager, and stakeholders failed because it could be resulted by factors beyond their control. However, it is very important to know when to terminate a project, and how to terminate it to minimize the losses and help in turning a certain project’s termination into another’s project success.

There are four project termination modes and those are, extinction, addition, integration and starvation. Project extinction mean end of project life, and this could be reached when the project is successful, executive management no longer support this project, external factors like financial crisis occurred and forced the organization to terminate the project due to insufficient funds, or the project did not achieve its goals and objectives. Termination by addition is when the project turns out into a major achievement for an organization, and transformed into an organizational unit for an organization (Baikunth, n.d.). Termination by integration is cited as the most common mode, and it takes place when the project is successful and operations are handed over to the organization (Baikunth, n.d.). Termination by starvation mode is decreasing project budget until it dies.

Regardless of the main reason behind project termination, it is really important to document termination process, and that by preparing all necessary documents, lessons learned, and follow project closure process to ensure proper documentation to avoid mistakes if any in future projects. “The success of future projects may depend on not only the success of past ones, but also on how unsuccessful projects were treated by the organization and its stakeholders” (Hormozi, McMinn, & Nzeogwu, 2000).

Reference:

Boehm, B.; , "Project termination doesn't equal project failure," Computer , vol.33, no.9, pp.94-96, Sep 2000
doi: 10.1109/2.868706
URL: http://ieeexplore.ieee.org/stamp/stamp.jsp?tp=&arnumber=868706&isnumber=18807

Jiancheng, G, Quan, L, & Hui, P 2002, 'MAKING BETTER PROJECT TERMINATION DECISIONS', Research Technology Management, 45, 1, p. 13, Business Source Premier, EBSCOhost, viewed 13 January 2012

Hormozi, A, McMinn, R, & Nzeogwu, O 2000, 'The Project Life Cycle: The Termination Phase', SAM Advanced Management Journal (07497075), 65, 1, p. 45, Business Source Premier, EBSCOhost, viewed 13 January 2012

Baikunth, N., (n.d.), ‘Project Closure/Termination’, IT Project Management, [Online], Available from: http://www.webster.edu/ftleonardwood/COMP5940/Student_Files/Project_Termination/Project_Termination_Lec.pdf

viewed 13 January 2012

Improving Information Technology Project Quality

The International Organization for standardization (ISO) defines quality as “the totality of characteristics of an entity that bare on its ability to satisfy stated or implied need” (ISO, cited in Schwalbe, 2010, p.294). Project quality management aim is to guarantee that the project undertaken will fulfill the needs for which project was initiated. As an impact for globalization, consumer became more demanding for higher quality products, this made quality management a key are to address and budget for in all industries and projects. Project quality management include three main processes those are planning quality, performing quality and quality control. Quality is one of the area which require continuous improvement, this to insure that quality is always at its maximum levels to satisfy customers and project stakeholders.

To improve information technology project there are multiple suggestions that could be addressed, first could be managing quality expectations and cultural differences, second is using maturity models, and third is through promoting quality awareness and reinforcement through project and organizations leadership and top management. Because not all quality aspects could be clearly defined, and because different team members could have different expectations about project quality, it is important to understand various team member’s expectations, try to satisfy them and resolve any conflict caused by difference in expectations (Schwalbe, 2010, p.322). Another important factor that should be taken into consideration while defining project quality within project scope is cultural differences and perception of quality in different countries or between team members from different backgrounds. For example quality standards in EU differ a lot than quality standards in Middle East countries.

Second important factor to improve IT project quality is the use of maturity models, those are frameworks to help organizations improve their processes and systems (Schwalbe, 2010, p.323). Most of them consist of five levels, and there are three popular ones, one of them is Capability Maturity Model Integration, “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 et al., 1997). It helps in enhancing processes for a project, organization or a division within an organization, and provides guidance for quality processes (Schwalbe, 2010, 323).

The third suggestion to improve IT quality is by promoting quality to top management, or project owners. “Although initially this theory holds some truth, in the long run, leadership within the organization plays a more important role in achieving and maintaining quality” (Shiramizu  & Singh, 2007). As long, as project stakeholders are quality sensitive, and promote quality among project team, this will improve project quality, as management will force team members to become quality sensitive and insure good quality projects. Many argue that main cause of quality problems is lack for leadership (Scwalbe, 2010, p.319).

Project quality management is important for project success, and continuous improvement for quality is essential to have successful projects, this improvement could be through managing expectations and cultural differences, leadership or the use of maturity models to enhance quality processes.

Reference:

Herbsleb, J. et al. (1997), Software Quality and the Capability Maturity Model, Communications of the ACM, Volume 40 Issue 6, DOI: 10.1145/255656.255692. (Accessed 7 January 2012)

Schwalbe, K., (2010), Information Technology Project Management (with Microsoft Project 2007 CD-ROM), 6th ed., Course Technology, 2010, ISBN 978-0-324-78692-7

Shiramizu, S. & Singh, A. (2007), ‘Leadership to Improve Quality within an Organization’, Leadership Manage. Eng. 7, 129 (2007); doi:10.1061/(ASCE)1532-6748(2007)7:4(129) (12 pages), [Online]. (Accessed 7 January 2012)

Project Performance Distribution

Communication management is one of the most essential skills and knowledge areas for successful project management, each project should include a communication management plan where it could be part of project documentation for small projects, or a separate document. By all means it should cover stakeholder communication requirements, the type of information to be communicated, recipients, frequency and escalation procedure for problem solving (Schwalbe, 2010, p.387). Schwalbe stresses on the importance of project communication plan as it guides all stakeholders with agreed upon guidelines, it is important because not all team members have good communication skills, and this plan will help them understand communication requirements for a project.

Communication the proper information at a proper time for the proper person is the ideal goal in any project. There are plenty of ways were team member can distribute information across; technology is one of the heavily depended on mediums to distribute project information and organization communication in general. Team members could use email, instant messaging, collaboration tools, wiki’s or websites to exchange information, project manager could set internal project management information system to organize project documentation, schedule meetings, document minutes of meetings, and change requests, this is useful for large project to help share and make information available for everyone. Still relying only on technology for project communication is not enough, face-to-face meetings is crucial for project success, as sometimes words might be incorrectly interpreted or misunderstood, scholars stress on the importance of body language and tone for successful communication (Schwalbe, 2010, p.391). It is important to use informal communication to distribute project information, some team members might prefer to have coffee chat about project rather than reading status reports, as it helps them more in giving the proper feedback and understand issue clearly with verbal communication.

When it comes to project performance information, mainly there are two types to distribute it, reporting and forecasting. Reports are used to distribute work performance information and measurements (Schwalbe, 2010, p.398), there are two types for reporting those are status reports, and progress reports. They differ in the time frame for each of them, status report “describe where the project stands at a specific point in time” (Schwalbe, 2010, p.398), it describes whether the project is meeting, time, scope and budget or not at a certain time, on the other hand, progress report “describe what the project team has accomplished during a certain period” (Schwalbe, 2010, p.398). Other form of performance information reporting is project forecasts; by this project manager guess future progress and status of the project based on previous information and trends (Schwalbe, 2010, p.398), forecasts help in estimating project budget, time required to complete certain tasks and so on. Other than those two forms of reporting, status review meeting could be used to distribute project performance information, in such meeting top management get status review feedback and update on project performance, and discuss important project isses.

Communication management plan is crucial to set the guideline for project communication; it helps team members to better communicate and report progress to project manager and top management. Project communication could take multiple forms and types, such technology based communication, or face-to-face. However for performance information distribution formal communication, which takes the form of reports and forecasts, is the best way to distribute it.

Reference:

Ronald L. Thompson, H. Jeff Smith, Charalambos L. Iacovou, The linkage between reporting quality and performance in IS projects, Information & Management, Volume 44, Issue 2, March 2007, Pages 196-205, ISSN 0378-7206, 10.1016/j.im.2006.12.004., Available from: http://www.sciencedirect.com/science/article/pii/S0378720607000031. (Accessed 7 January 2012)

Schwalbe, K., (2010), Information Technology Project Management (with Microsoft Project 2007 CD-ROM), 6th ed., Course Technology, 2010, ISBN 978-0-324-78692-7

RM Planning

Risk is something that has not happened yet, and has a potential impact over the future. Schwalbe defined the project risk as “an uncertainty that can have a negative or positive effect on meeting project objectives” (Schwalbe, 2010, p.425), for that risk management can be defined as the action to be done to lessen the impact of negative future events. Cervone raises a very important issue with regards to risk management implementation, he said that although project risks could be dangerous, and that risk management is crucial, still its not given the required attention by project managers. He also explains the common practice by project managers of risk estimation, and that by examining issues related to risk and adding a margin of risk, known as WAG technique (Cervone, 2006).

Schwalbe defined planning risk management as “the process of deciding how to approach and plan for risk management activities for a project, and the main output of this process is risk management plan” (Schwalbe, 2010, p.428). The plan itself is a document that contains procedures for managing project risks. Early in the project, the team should hold planning meetings to start developing the risk management plan, as well they have to review project documents and organizations risk policies, risk categories, lessons learned from previous projects, and risk management plan templates (Schwalbe, 2010, 428). Another important aspect that should be considered by project team is project stakeholders risk tolerance, in specific decision makers such as project sponsor and senior management. Risk management plan should address various topics; those are methodology, roles and responsibilities, budget and schedule, risk categories, risk probability and impact, revised stakeholders tolerances, tracking and risk documentation (Schwalbe, 2010, p.429).

Each of those topics should be addressed in a risk management plan; valid questions to answer with regards to methodology are “how will risk management be performed on this project? What tools and data sources are available and applicable?” (Schwalbe, 2010, 429). Risk manager or project manager should gain buy-in from the management to allocate resources to manage risks, create a risk management plan and have it approved by all stakeholders. Risk management plan should include all team members who should be involved in risk management sessions, frequency of these sessions and identifies the risk manager for each risk identified. As well it should include the tools to be used to identify, manage and control risks, tools such as risk register, probability-impact matrix, and software such as Monte Carlo.

With regards to roles and responsibilities, risk management plan should address a question about “who are the individuals responsible for implementing specific tasks and providing deliverables related to risk management?” (Schwalbe, 2010, 429). There should be a risk manager if not the project manager to handle defining the risks, entering them to the risk register, perform meetings to assess risks and define new risks, prioritize risks, help create risk response plans and contingency plans. Each risk should have an owner who watches the triggers for the risk, implement the risk response plan or request the contingency plan to be performed, decide whether or not this risk is still valid and all the project team is responsible for defining risks as they arise. With regards to budgets and schedule, risk management plan address a question about the estimated costs and schedules for performing risk related activities? (Schwalbe, 2010, 429).

With regard to budget and schedule, risk management plan should answer a a question like “what are the estimated costs and schedules for performing risk related activities?” (Schwalbe, 2010, 429). As well the plan should cover risk categories as what are the main risk categories that should be addressed on the project? Risk categories could be technology, unrealistic time estimates, unrealistic cost estimates, lack of resources, hardware compatibility, delays in hardware procurement, unclear requirements and a lot more. As well the plan should address questions related to risk probabilities and impacts of risk items be assessed, in addition to scoring interpretation methods that will be used for analysis? How will the probability and impact matrix be developed? (Schwalbe, 2010, 429). The plan also should question current status of stakeholders risk tolerance, and how a change in risk tolerance could affect the project itself? In this regards, Stakeholders tolerance to risks is either risk averse or risk takers. If the management tends to be a risk averse, then the scoring to the risk from a probability and impact perspective will be higher and hence more contingency reserves will be taken into consideration. Risk takers tend to evaluate risks with lower probability and impact, which means less contingency reserves. Another factor to be addressed in the risk plan is “how will the team track risk management activities how will lessons learned be documented and shared? How will risk management processes be audited?” (Schwalbe, 2010, 429), this could be achieved by performing risk sessions periodically, updating the risk register, and review the watch list for the less important risks. Once the project is on its closing phase, the team members should perform a lessons learned sessions and document the results

“Risk management can make an important contribution to effective project management” (Rangopal, 2003). For that risk or uncertainty management as Rangopal prefers to name it should be given more focus by project managers, and not identify major risks and add a risk margin as described earlier.

Reference:

H. Frank Cervone, (2006) "Project risk management", OCLC Systems & Services, Vol. 22 Iss: 4, pp.256 - 262

DOI 10.1108/10650750610706970 (Permanent URL)

Rangopal, M 2003, 'Project Uncertainty Management', Cost Engineering, 45, 12, pp. 21-24, Business Source Premier, EBSCOhost, viewed 31 December 2011

Schwalbe, K., (2010), Information Technology Project Management (with Microsoft Project 2007 CD-ROM), 6th ed., Course Technology, 2010, ISBN 978-0-324-78692-7

RM Software

Controlling risks in projects is considered a major contributor to projects success, surveys suggested that only quarter of software projects succeed and completed as scheduled, on time and on budget, and this means billions of wasted dollars due to project failures (Charette, 2005, cited in Bannerman, 2008). It is argued that risk management for software projects could improve project outcomes, and I believe the same however, this is not limited to software projects, it covers all projects in varies industries. Good and effective risk management will improve project outcome, and help in increase project success ratio. Although risk management is so important and so effective, its outcome might not be that obvious as long as projects are running smoothly. To assess risk management processes and systems, predefined measurements should exist to better evaluate its outcome. “It is quite difficult to measure the benefits of risk management: successful risk management may prevent some problems from occurring and very few organizations have good enough measurement systems or data points to show the impact of risk management” (Kontio, 2001).

Risk management software can be divided into two main categories, being integrated and standalone. Those categories are with relation to project management software used by organizations, an example of an integrated tool is Monte Carlo add-on tool for Microsoft Project. Although Microsoft project has a PERT module that implements quantitative risk analysis, but Monte Carlo add-on overcomes some of its limitations being accuracy of results is limited to single dominant path through a precedence network, and accurate estimation of optimistic, most likely and pessimistic times (intaver, n.d.). There are other integrated tools such as @RISK and Risk+. On the other hand, standalone risk management software such as “Acertus Securac’s ERM software solution enables organizations to identify, measure, manage and mitigate risk and compliance in all aspects of the organization” (RiskWorld, n.d.). All those tools help in answering to risk related questions, and those are as identified by intaver:

· What is the chance of completing project on schedule and within budget?

· What is the chance that a certain task is on the critical path?

· Which tasks affect project duration?

· What is the project success rate?

The introduction of risk management brings lots of advantages and benefits for organizations, they “enhance various risk management processes” (Schwalbe, 2010). Organizations could use risk management software to create or update risk registers, as well track project risks and quantify them, those software aid in preparing charts and perform sensitivity analysis. “Software can be used to create decision trees and estimate expected monetary value” (Schwalbe, 2010). Advantages of risk management software vary and exceed basic benefits mentioned earlier, depending on complexity of features offered by the tool, for instance Monte Carlo simulation software “could develop models and use simulations to analyze and respond to various risks” (Schwalbe, 2010). As well some tools offer features like probabilistic and conditional branching, “An example of probabilistic branching is when the user defines that there is 40% chance that task A will be successor of task B and 60% chance that task C will be successor of task B. An example of conditional branching is when the user defines that task A task will be followed by task B if task A duration is greater or less then a certain value“ (Intaver, n.d.)

Although those tools ease project manager risk management related task, and increase project success rate, they have some disadvantages and limitations. A major limitation in risk management tools is that they rely on user input, for that if a risk was not presented to the tool because it was not originally identified, or user forgot to present it to the system it cannot be managed. For that project management should not over-rely on those tool, and still they need to identify the risks themselves, and based on their experience. “It takes hard work to develop and implement good risk response strategies” (Schwalbe, 2010, p. 450).

Other disadvantages could be software cost, as risk management software are expensive, and could add to the project budget f not already purchased and installed. Another problem could be conducting user trainings to employees and motivate them to use risk management tools instead of word editing and spreadsheets to maintain and log risks.

Risk management software could be very helpful and a major contributor to project success, as they offer lots of features that ease project manager job. Still those tools should be used with cautious, as they are bug free and require valid and complete input to provide us with expected results.

Reference:

Downes, D 2006, 'Risk management software solutions it's a fragmented marketplace', Accountancy Ireland, 38, 4, pp. 22-24, Business Source Premier, EBSCOhost, viewed 31 December 2011

Intaver, (n.d.), ‘Quantitative Risk Analysis with Microsoft Project’, [Online], Available from: http://www.intaver.com/Articles/Article_MSProjectRiskAnalysis.pdf

(Accessed 31 December 2011)

J Kontio, 2001 “Software Engineering Risk Management: A Method, Improvement Framework, and Empirical Evaluation” available online from: http://lib.tkk.fi/Diss/2001/isbn951225655X/isbn951225655X.pdf

Paul L. Bannerman, Risk and risk management in software projects: A reassessment, Journal of Systems and Software, Volume 81, Issue 12, December 2008, Pages 2118-2133, ISSN 0164-1212, 10.1016/j.jss.2008.03.059. (http://www.sciencedirect.com/science/article/pii/S0164121208000897)

RiskWorld, (n.d.), ‘Risk Related Software’, [Online, Available from: http://www.riskworld.com/software/sw5sw001.htm

(Accessed 31 December 2011)

Schwalbe, K., (2010), Information Technology Project Management (with Microsoft Project 2007 CD-ROM), 6th ed., Course Technology, 2010, ISBN 978-0-324-78692-7

Schedule Issues

The nature of projects that include team members from different backgrounds and different cultures, were those have to interact and work together to complete certain project. Conflict arise due to differences in way team member perceive things, personalities, misunderstanding and needs, because of that project managers need to address those issue and know how to deal with them. One of the main causes of conflict and considered a big challenge is delivering projects on time (Schwalbe, 2010: 212).

Many reasons could lead to schedule conflict; I believe lack of collaboration and team synergy are the main drivers behind schedule conflict. Due to project team nature, they differ in attitudes, perception and the level of control over them, some people have a great level of respect to deadlines, while others prefer and produce more if no pressure is set on them. In addition to that, team members differ in the level of detailed schedule they need to accomplish a task, some require detailed schedules to help them complete their part, while others prefer more flexible schedules (Schwalbe, 2010, 212). Other than team member’s perception and attitude, the community they belong to or cultural background has a great impact on project schedule, religious holidays are a good example of ethnic or cultural differences that affect project schedule.

Another important factor that could cause schedule conflict is as described by Schwalbe “time is easily and simply measured” (Schwalbe, 2010, 212). In other words, when a project schedule is defined, with clear milestones, task level start and end dates and deadline, anyone even without project management knowledge can judge project performance based on delays against set time. Although it might seem like a correct way to measure project performance, approved changes should be taken into account because usually those will delay project deadlines and affect other tasks within the project.

Aggressive deadlines set by managers could as well lead to schedule conflict; the amount of pressure on team members due to unrealistic schedules will lead to conflict. To avoid schedule conflict or at least minimize some of its effects, project managers should insure s.m.a.r.t. Milestones that are specific, measurable, assignable, realistic and time-framed are defined. Activities should be defined along with their expected output; as well activities should be defined in the proper order, with realistic time frames based on resource capabilities, availability, and tools available.

It’s important for project managers to control schedules through progress reports, schedule change controls, variance analysis, and performance measurement. Those will help project manager to know the status of the project schedule and manage known and unknown changes.

Reference:

Terje I Vaaland, Håkan Håkansson, Exploring interorganizational conflict in complex projects, Industrial Marketing Management, Volume 32, Issue 2, February 2003, Pages 127-138, ISSN 0019-8501, 10.1016/S0019-8501(02)00227-4. (http://www.sciencedirect.com/science/article/pii/S0019850102002274) (Accessed 24 December 2011)

Schwalbe, K., (2010), Information Technology Project Management (with Microsoft Project 2007 CD-ROM), 6th ed., Course Technology, 2010, ISBN 978-0-324-78692-7

Verma, V., (1998), ‘Conflict Management’, The Project Management Institute Project Management Handbook, Ed: Jeffrey Pinto. 1998 isbn 0-7879-4013-5, [Online], Available from:

http://www.iei.liu.se/pie/teio04/allmanna_filer/1.171778/conflManagementVerma.pdf

(Accessed 24 December 2011)

Manage Project Teams

There are plenty of factors that affect project success or failure, such as qualified project managers, proper change control process, time and scope management, and team management. Human resources are the most important assets for any organization, without them projects won’t be executed. Project manager should have the organizational skill that helps him or her to manage and lead project team. Some projects have limited number of human resources, and others could exceed thousands, and some projects might have resources spread in different geographical regions.

People management and leadership theories helped us understand people needs, behaviors, and personal traits. Project manager should understand motivational factors for team members, depending on team member personality; they could be motivated through more challenging tasks, and this called intrinsic motivation. While others could be motivated if being rewarded and appreciated for their work, or through punishment, this is called extrinsic motivation. As well project managers should understand Maslow’s hierarchy of needs, and that team members won’t be innovative and creative if their deficiency needs are not satisfied (Schwalbe, 2010, p.354). It’s crucial to understand differences between team members to be able to manage them and reach synergy.

There are techniques and tools that help project managers understand their team differences, motivational factors and help in managing them effectively, Schwalbe highlighted those tools as:

· Observation and conversation: project managers should reach team members either on a personal and friendly manner, or through professional project related conversations. This will help in understating team members issues and help resolving them, a key factor to achieve this could be in enhanced communication tools, or management by walking around (Schwalbe, 2010, p.368)

· Project performance appraisals: it’s a common practice in organizations to evaluate employees performance, this usually helps managers to better understand employees strengths, weaknesses and insure departmental and organizational objectives are fulfilled. Same applies to projects, its important to evaluate team members performance, such appraisal will help project manger to track tasks, and identify any factors that might delay it.

· Conflict management: conflict between colleagues and team members is expected at any work place or project, its critical and could result in project delays or failures if not handled properly. Project manager should know how to handle conflicts, understand cultural differences between team members, and help them understand each other to reduce conflict impact on the project.

· Issue logs: its good practice to keep log of team potential conflict issues such as differences, concerns that might affect team performance to work on resolving it before it affect the project.

· Interpersonal skills: project manager should have influencing skills, ability to lead team members and great decision making skills.

Virtual team whose members are spread across different geographical locations are more difficult to manage that teams whose members are physically at the same location, studies have shown that non virtual teams have more sense of belonging to the company or a team, as well they tend to socialize after working hours which enhance team synergy (Johnston & Rosin, 2011). Due to virtual team nature, management of such teams requires more concentration on communication, either by email, video conferencing or the use of collaboration tools to get the team to know each other and reduce potential conflicts. More serious conflicts could rise due to cultural differences, time zone difference and personal traits within team members. “Research has shown that it is extremely important that the use of collaborative software is correctly managed in order to facilitate team cohesion, if not managed correctly this can have adverse effects on the communication of the team” (Johnston & Rosin, 2011).

To effectively manager project teams, project manager should enhance and define communication tools such as email, video conferencing, and collaboration software. Team members should be coached to resolve conflicts and be open to different cultures and different team members. Project manager should have the interpersonal skills that help him in leading and managing project teams.

Reference:

'Manage a Virtual Team' 2005, Journal Of Accountancy, 199, 6, p. 34, Business Source Premier, EBSCOhost, viewed 24 December 2011.

Johnston, K.A.; Rosin, K.; , "Global Virtual Teams: How to Manage Them," Computer and Management (CAMAN), 2011 International Conference on , vol., no., pp.1-4, 19-21 May 2011, doi: 10.1109/CAMAN.2011.5778849
[Online]. Available from: http://ieeexplore.ieee.org/stamp/stamp.jsp?tp=&arnumber=5778849&isnumber=5778726

(Accessed 24 December 2011)

Schwalbe, K., (2010), Information Technology Project Management (with Microsoft Project 2007 CD-ROM), 6th ed., Course Technology, 2010, ISBN 978-0-324-78692-7

Weiss, WH 2002, 'building and managing teams', Supervision, 63, 11, p. 19, Business Source Premier, EBSCOhost, viewed 24 December 2011

Cost Estimate Problems

Each project should have an approved budget, and the project manager’s job is to ensure that the project is completed without exceeding this budget. Project cost management as defined by Schwalbe “includes the processes required to ensure that a project team completes a project within an approved budget” (Schwalbe, 2010, p.256). Project cost management is subdivided into three processes that are cost estimation, budget determination and cost control.

Cost estimation process involves estimating costs needed to complete the project, those costs include everything that would make a project successful, such as human and non-human resources, engagement of external contractors, hardware and software requirements and so on, it even include travel expenses if necessary. Budget determination on the other hand is about allocating project cost estimate defined in the previous process to work packages, it is based on activities in work breakdown structure of the project. This process has a main goal, which is constructing a project cost baseline to measure performance and understand funding requirements (Schwalbe, 2010, p.256). The third process in project cost management is cost control; this process includes monitoring cost performance (Schwalbe, 2010, p.256), this ensures that only required changes are added to the revised cost baseline, as well update all engaged stakeholders about the changes that impact cost.

Project sponsor is more interested in financial terms rather than technological terms, this is the main reason why project managers should understand financial terms and know how to present the project for approval based on financial values. Project manager should understand the difference between profit and revenue, direct and indirect costs, cash flow and suck cost, and terms like earned value, which is “the estimate of the value of the physical work actually completed” (Schwalbe, 2010, p.273). There are three basic types of cost estimates, each of them has a certain use within the project lifecycle and differs in the level of accuracy it provides, and those are:

1) ROM estimate, this is done at early stages and not accurate, however it is used to estimate a project total cost.

2) Budgetary estimate, this is more accurate than ROM and used to allocate budget for this project.

3) Definitive estimates, this is the most accurate and is used to issue actual purchasing decisions.

There are varies numbers of estimation tools and techniques that project managers can use to estimate project cost, those tools differ based on their estimation accuracy, cost, and time required to derive the cost estimates. Analogous estimate, also known as top-down estimate, this technique is known as the least accurate and less costly, this technique builds cost estimate for current project based on previous similar projects, and due to this reason previous project should be as much similar as current project, as well it requires expert judgment (Schwalbe, 2010, p.263). Another cost estimate technique is the bottom-up estimate; also known as activity-based, if the WBS is constructed, each resource will be responsible for a work package and he or she will develop the cost estimate for that work package. This technique is costly but and time consuming, but very accurate.

With the existence of previously mentioned tools and techniques to aid project managers better estimate cost for their projects, it is still inaccurate. Its not easy to relate cost estimation problem to a single cause, as lots of external and internal factor affect cost estimation results, McDonald for example identifies lack of experience, as one of the main reasons behind generating inaccurate cost estimates (McDonald, 2005), this could be either because inexperienced team would require longer time to complete their tasks and by that it will cost more, or because as McDonald mentioned inexperienced resources produce lower cost estimates. DeMarco listed four main drivers that cause in accuracies in project cost estimations, and those are:

1) Estimates done too quickly: usually estimating cost for IT projects, being software development or customization, require lots of efforts, in terms of time, money and resources. To properly estimate cost, requirements should be set, analyzed and evaluated. WBS should present to help in understanding actual project requirements, against task list. If cost is estimated without proper analysis and knowledge of task list, it will result in inaccurate results.

2) Lack of experience: resources who perform cost estimates usually lack proper cost management experience, as well organizations lack project estimation history to help in top-down cost estimation. Keeping historical data within the organization provide more solid data for project managers; as well training IT personnel on cost estimation matter would help in providing more accurate and solid estimates.

3) People are biased toward underestimation: usually people involved in project estimation are not the same who execute actual tasks, they do estimations based on personal judgments. As well estimators might forget to allocate extra cost for unknowns.

4) Management seek accuracy: although tope management requests estimates, but their actual aim would be accurate cost, or as much accurate as possible. The reason behind this is to help them prepare and allocate budgets, insure proper cash flow present in the organization.

Top management, as Schwalbe mentioned would never forget initial estimates, for that approved change to cost estimates should be documented and communicated with stakeholders along with amendments to original approved budget.

Reference:

McDonald, J., (2005), ‘The Impact of Project Planning Team Experience on Software Project Cost Estimates’, Empirical Software Engineering, Springer Netherlands, ISSN: 1382-3256, V10, Issue 2, pp. 219-234, DOI: 10.1007/s10664-004-6192-9, [Online]. Available from: http://dx.doi.org/10.1007/s10664-004-6192-9 (Accessed 17 December 2011)

Rick McCarthy, (2004) "Understanding project costs and building costs", Bottom Line: Managing Library Finances, The, Vol. 17 Iss: 1, pp.6 – 9, DOI: 10.1108/08880450410519638, [Online]. (Accessed 17 December 2011)

Schwalbe, K., (2010), Information Technology Project Management (with Microsoft Project 2007 CD-ROM), 6th ed., Course Technology, 2010, ISBN 978-0-324-78692-7

Project Scope Management

Project scope is defined as “all the work involved in creating the products of the project and the processes used to create the,” (Schwalbe, 2010, p. 178). It is one of the most difficult to aspects to define in the project, and most important at the same time. Scope management is he set of processes that helps defining and controlling project deliverables, as well what is included or not in the project scope. Those processes help all stakeholders have a common view for project requirements, deliverables, and tools used to achieve project success.

Project scope management has five main processes. Schwalbe identified them as, collecting requirements, defining scope, creating the WBS, verifying scope and controlling scope (Schwalbe, 2010, p.178,179), Khan has a different naming and order for the same processes however both serve the same purpose of managing project scope. Khan identified those processes as project initiating, scope planning, definition verification and scope change control (khan, 2006). Collecting requirements also known as project initiation involves defining and documenting functions of produced products, services or deliverables generated from the project. Its important to note that any project is initiated usually from the business in order to request a new feature, product or enhancements for existing systems, in such cases stakeholders requirements should be collected and documented, in addition to that requirements management plan along with traceability matrix are generated in this phase. Collecting requirements is the most critical and difficult step in scope management, if requirements are not collected, misunderstood or not properly documented this could lead to rework of the project and hence project failure. It’s very important in this phase to conduct project feasibility studies, such as technical, economical and financial feasibility (Khan, 2006). The following process is defining scope, in this phase or process project charter and requirements collected in previous phase are reviewed, the defined scope can be revised in later stages as in most of the IT projects, scope is not clear at the beginning of the project. Defined scope should be agreed on and signed by key stakeholders, and communicated with project team to have a better understanding for project objectives. Project scope should include description, user acceptance criteria, and detailed deliverable information (Schwalbe, 2010, p.185). Scope planning comes after the scope is defined and clear, which is also known as creating the WBS, its dictionary and scope baseline. The main objective of this phase is to create list of tasks and subtasks to be conducted by project team, this will help in ease project management. There are plenty of approaches that aid in developing the WBS, such as mind mapping, using organization’s guidelines, top-down, bottom-up and the analogy approach. Developing WBS dictionary and scope baseline are very important outputs of this phase, the dictionary include detailed task information.

Scope verification is an important phase in project scope management, khan state that this phase starts as early as its predecessors, means it’s a continuous process. It involves formally accepting project scope by stakeholders; this is done after customer review and followed by a sign-off on deliverables, and his process in important to avoid scope creep. “Earned value management is a technique frequently used for measuring progress of a project. Earned value management evaluates several indices to measure the cost and schedule progress of the project” (khan, 2006). By this technique a comparison between actual delivered work against schedules work, based on time and cost. The final process of project scope management is scope controlling, “An effective scope change control mechanism must be put in place as early as the start of the scope planning phase. It is important to classify types of scope change requests and the reason for the change” (khan, 2006). Scope should be controlled, all changes should go through predefined change control process to evaluate requested change, review, approve and then implement, impact on project cost and time should be evaluated.

The importance of scope management in IT project is clear based on the nature of those projects, usually vast number of ambiguity exist in IT projects, either due to lack of understanding of the technology and what it delivers, or due to big hopes set by business users. For that technology project scope should be managed to collect business requirements and translate them into technology tasks and subtasks, where all stakeholders have a clear understanding of project requirements and technology capabilities, to properly set expectations. Hartman & Ashrafi defined main reasons behind IT project failures or problems as lack of understanding for success criteria based on project scope, as well lack of understanding of project deliverables and evaluation process (Hartman & Ashrafi). During software development projects, changes cannot be ignored, some changes might come due to code bug, in such cases, and changes requested should be handled properly to insure project success.

Technology projects are complex, scope change during project lifecycle is inevitable, for that its important to collect requirements, communicate it with all stakeholders and form a scope baseline. Any changes after that should be controlled and managed not to lead to scope creep and project failures.

Reference:

Hartman, F, & Ashrafi, R 2002, 'Project Management in the Information Systems and Information Technologies Industries', Project Management Journal, 33, 3, p. 5, Business Source Premier, EBSCOhost, viewed 10 December 2011.

Khan, A 2006, 'Project Scope Management', Cost Engineering, 48, 6, pp. 12-16, Business Source Premier, EBSCOhost, viewed 10 December 2011.

Schwalbe, K., (2010), Information Technology Project Management (with Microsoft Project 2007 CD-ROM), 6th ed., Course Technology, 2010, ISBN 978-0-324-78692-7

Project Change Management

It impossible to avoid changes through out the software development projects, and same applies to almost all IT projects, scope usually change throughout the project lifecycle due to uncertainties, ambiguities and / or unclear requirements. Hu & Liu stated, “changes in the project has become the most prominent source of risk in the development of the project” (Hu & Liu, 2008), that because changes in the scope has a direct impact on time, quality and cost of the project. Another catastrophic impact of requirement and scope change is that it is one of the main reasons for project failures, based on a survey conducted in 2004 that analyzed 13,522 completed projects, results showed only 29% success, 18 % failed projects and 53% questioned projects. The projects were identified as questioned due to increase in project cost or time to be able to complete the project, the main reason behind additional cost and exceed in project time, was requirement changes through out software development lifecycle (Hu & Liu, 2008).

Due to the nature of IT projects, almost all of them require acquiring services and products from outside source (Schwalbe, 2010, p.462). In such cases, project procurement management that includes processes to control and manage products and services acquired from external companies becomes a must; those are planning, conducting, administering and closing procurements (Schwalbe, 2010, p. 465,467). There are tools and techniques that help in procurement planning, those should be conducted prior to getting external source help; it should start with proper analysis such as make-or-buy, and external judgment either by staff or external organizations. Make-or-buy analysis is important because it helps decision makers to justify their decision based on organization’s financial interests. Contracts should be planned to the best interest of the organization, contract types vary and their risk to the buyer vary as well, those should be taken into consideration to avoid never ending projects and project failures. As well and part of procurement planning, project scope of work, request for proposal and request for quotation should be properly documented with experts help, and its important to have a clear source selection criteria that is balanced, specific and objective.

Conducting procurement starts with getting sellers responses, selecting them and contract awarding. It is important to note that technical criteria shouldn’t be given a higher weight than cost or management criteria (Schwalbe, 2010, p. 478). Administering procurement involves ”managing relationships with sellers, monitoring contract performance, and making changes as needed” (Schwalbe, 2010, p. 484). Effective change control systems should exist to identify review and approve changes; the following suggestions could help ensure adequate change control on projects that involve outside contracts (Schwalbe, 2010):

1) Any change to part of the project and regardless of its size, should be reviewed, approved and documented in the same way and by the same people who conducted those actions. Another important control is to perform impact analysis for any change.

2) Documentation in writing for all changes, especially with outside contractors those documents could be referred to incase of disputes. In such cases even verbal or telephone conversation could become useful.

In closing procurement, its important to perform procurement audits, to identify lessons learned (Schwalbe, 2010, p.481).

“The challenge to the project manager, then, is how to partner with procurement in a way that positively impacts the project life cycle” (Rinkavage, , Bennis, ,& Gault, 2006). Bridging the gap between project management and procurement is important for project success; every role has its own importance in the project lifecycle, project manager should increase his knowledge in this area to be able to manage external contract effectively.

Reference:

Hu & Liu, (2008), ‘IT project change management’, Computer Science and Computational Technology, 2008. ISCSCT '08. International Symposium, ISBN: 978-1-4244-3746-7, pp. 417-420, [Online]. Available form: 10.1109/ISCSCT.2008.224

Rinkavage, E, Bennis, P, & Gault, C 2006, 'Project Management: Partnering With Procurement. (cover story)', Government Procurement, 14, 2, pp. 6-8, Business Source Premier, EBSCOhost, viewed 10 December 2011.

Schwalbe, K., (2010), Information Technology Project Management (with Microsoft Project 2007 CD-ROM), 6th ed., Course Technology, 2010, ISBN 978-0-324-78692-7

Required PM Skills

Project managers can have different job description in different organizations and industries, however there are some shared and common goals every project manager aim to perform (Schwalbe, 2010, p.22). Project managers aim to plan, schedule, communicate, and allocate resources, and a lot more. For them to be able to perform their job there are key competencies every project manger need to develop, as well key skills that help them achieve their objectives.

Project manager need to develop his/her knowledge in nine main areas to be able to perform his/her task efficiently, those are scope, time, cost and quality project management. Those four are considered core knowledge areas, without them a project manager will fail in his/her tasks. Other four areas that smooth his/her job are HR, communication, risk and procurement project management. The ninth is integration management that is affected and affects the previously listed knowledge areas (Schwalbe, 2010, p.22). Each of these knowledge areas has special tools and techniques that assist project managers and project stakeholders developing knowledge in those areas, and effectively run projects.

One of the main factors that affect project success rates and failures is having a good project manager, his/her role is crucial as he/she communicates with all stakeholders, should take critical decisions, properly allocate resources and budget, team motivator, and a lot more. A project manager has in addition to developing his/her knowledge, develop soft skills that will help him/her, lead, manage, communicate, motivate and take decisions to make a project successful. A good project manager is the one who has the ability to get things done, manage project stakeholders expectations and motivate people. This requires the project manager to have good communication and leadership skills. Many projects fail due to the lack of communication and not sharing the right information with the right project stakeholders at the right time, which creates huge gaps between the planned and actual progress and may cause scope changes that lead to extra costs. Managing project communication requires a great deal of commitment, and may take more than 80% of the project manager's time for a certain project.

A project manager can create a full communication plan that states what type of communication should be carried out, the frequency of this communication, and who is responsible for this communication, who it should be distributed to and in what format, but still he has to be able to enforce applying this communication plan and adjust it according to the situation. On another note, a project manager has to be able to motivate the project team, the customer and the project sponsor. Motivation can be achieved in many ways; one of the most important ways is to involve the project stakeholders in the planning phase and defining the requirements, this way he can gain their buy-in and make them feel that they own this project and keen to make the project successful.

Flannes and Levin listed four main roles project manager should play in able to be successful and effective, those main four skills roles are “Leader, Manager, Facilitator, and mentor” (Flannes & Levin, n.d. cited in Indelicato, 2005). Each of those roles require special skills, such as stakeholders motivations, being a good listener, strong at building trust (Book, 2010, 25), conflict management skills, problem solver, critical thinker, and gas good verbal communication skills. A skill is learned by definition; Knapp defined the skill as ”learned ability to bring pre-determined results with maximum certainty, often with minimum outlay of time and energy or both” (Knapp, 1964, cited in Pinkowska, Lent, & Keretho, 2011). For that all soft skills or interpersonal skill required and important for project managers to effectively mange projects are learned. In addition to that, Carbone & Gholston based on their survey concluded that graduate programs and project management training develop soft skills along with project management skills (Carbone & Gholston, 2004)

But if soft skills are learned, and key knowledge areas that project mangers need to develop knowledge in are learned, then what differentiate project managers, and how come there are some project managers better than the others? I personally believe that a project manger can develop his/her knowledge and soft skills to a certain level, but some people by nature have tendency to lead better than others, and developing skills of such a perform will give him/her and edge over others. It applies to all skills, all can be learned, by mastering those skills is dependent on each person, surrounding environment, projects, industry and a lot more.

Reference:

Carbone, T, & Gholston, S 2004, 'Project Manager Skill Development: A Survey of Programs and Practitioners', Engineering Management Journal, 16, 3, pp. 10-16, Academic Search Complete, EBSCOhost, Accessed on 3 December 2011

Indelicato, G 2005, 'ESSENTIAL PEOPLE SKILLS FOR PROJECT MANAGERS', Project Management Journal, 36, 4, p. 81, Business Source Premier, EBSCOhost, Accessed on 3 December 2011

Pinkowska, Lent, & Keretho, 2011, ‘Process Based Identification of Software Project Manager Soft Skills’, Computer Science and Software Engineering (JCSSE), pp. 343 – 348, [Online], IEEE, Accessed on 3 December 2011

Schwalbe, K., (2010), Information Technology Project Management (with Microsoft Project 2007 CD-ROM), 6th ed., Course Technology, 2010, ISBN 978-0-324-78692-7

What is EPM

A project is a temporary work or effort started to create a unique product, service, or result (Schwalbe, 2010, p.4). It has attributes and characteristics that help identifying it from operational tasks, those attributes are defined objective, has a definite beginning and end, progress with time, has a sponsor, resources with different technical and non-technical abilities, and includes uncertainties (Schwalbe, 2010, p.7-8). Each project has three or four constraints, those are scope, time, cost and quality/customer satisfaction, one of the project manager’s tasks is to complete the project within those constrains, or trade-off one of them to have a successful project. Usually its not easy especially in technology projects, as they hold vast number of uncertainties, due to technological factors and the need for talented resources.

Aggressive competition, cost pressures, new technology, and globalization are some of the factors Parr & Williams identified as creating the need for organizations to assume initiatives that are more complex with unique speed (Parr & Williams, 2003). Organizations are investing more in new projects; still the percentage of failure is considerably high, failure in terms of delivering the project objective in time, and within budget. One of the drivers of such failure is lack for enterprise wide project management strategy, a strategy than meets business needs, and considers new challenges to help making successful projects. When companies rely on conventional or traditional project management techniques, basically they ignore other functions within the organization, and run multiple projects in isolation. Such isolation might result in increased project cost, and bad resource utilization. Parr & Williams believe that organizations due to there increased complexity and interdependency, as well the need of collaboration between multiple functions to deliver real business benefit are main drivers to emergence of new project management methodologies that over come those complexities and provide organizations with holistic view over its budget, resources and objectives (Parr & Williams, 2003, p).

Schwalbe, identified a system’s view of project management as “carrying out projects within the context of the organization” (Schwalbe, 2010, p.45). To handle complex projects, project managers need a holistic view of a project to be able to relate it to the organization’s strategy (Schwalbe, 2010, p.45). technology project affect the surrounding functions, customers and society, for that it should not run in isolation, rather surrounding factors and implications should be considered to be able to deliver the best out of technology. Organizations have different cultures; structures and behaviors, each of those affect the ability to manage projects. An Enterprise Project Management (EPM) is a wider term than the conventional project management. EPM is more specific to managing a set of projects in an organization that contribute to the success and development of that company while conventional project management is about managing one project at a time regardless of any other dependent or related projects. EPM helps prioritize the current and/or future set of projects an organization plans to implement on an organizational level and may be grounds for discarding less important projects and focusing on the important ones. There are many tools and software applications that are developed for implementing EPM such as Microsoft Project Server which is designed to help many projects an organization is implementing on the same database which can utilize the use of shared resources, manage dependencies between projects, and set priorities for the projects. Implementing EPM in an organization calls for the need of starting an enterprise project management office that defines what methodologies to be used in managing projects, defines what project to implement first and what projects to discard, and follow up on the projects being implemented. EPM is not specific to a certain project management methodology, some use PMI methodologies, some use Prince2, and some even create their own project management methodology. 

EPM includes portfolio management where organization’s group and manage multiple projects as a portfolio of investments that contribute to the organization’s success (Schwalbe, 2010, p.18). Portfolio management is different than project management, project managers concentrate on projects in hand and their management way, while portfolio managers question projects in hand effectiveness. Englund & Muller lists steps to convert to EPM from traditional project management; they explain the benefits from such transformation as increased project success (Englund & Muller, 2004). It is with no doubt that EMP has been a point of turnover for many organizations, which lead to their success and improvement. This is due to the power that EPM provides in prioritizing projects and managing the dependencies and link between projects.

Reference:

Englund, R. & Müller, R., (2004), ‘Leading Change Towards Enterprise Project Management’, Projects & Profits November, [Online]. DOI: 10.1.1.88.2131, Accessed on 3 December 2011

Schwalbe, K., (2010), Information Technology Project Management (with Microsoft Project 2007 CD-ROM), 6th ed., Course Technology, 2010, ISBN 978-0-324-78692-7

Williams, D., & Parr, T., (2003), ‘Enterprise Programme Management, Delivering Value’, [Online]. Available from: Palgrave Connect, DOI: 10.1057/9780230514706, ISBN: 9780230514706, Accessed on 3 December 2011