Project Sponsor

This report explores the principles and tools of project management taking the case of a manufacturing company for which a software development project has been discussed. A manufacturing organization needed a software to be developed for managing its orders, deliveries, and outstanding for which an existing package was to be modified based on the needs of the organization.

The project involved requirement gathering from the project stakeholders on their needs for development, selection of vendor for procuring standard license for the software, development of modules based on the company needs through tailing the identified software, testing of the software on key users, installation of the same in the company system, and delivery of training to the employees on the working of the software.

The project was managed using PRINCE 2 project management methodology which is a project management method that can be used with a wide variety of projects including IT and non-IT projects. The methodology defines a project in eight key processes that include starting up, initiation, directing, managing deliveries, managing boundaries, closing, and planning. Starting up is the stage where the project is evaluated to make a decision on whether to proceed with it or not (ADB, 2006). The company had realized that manual processes were slow and causing dissatisfaction in customers who were able to get faster and order processing capabilities from competition and thus, the upgrading of the system was a necessity in the company which is why the management decided to proceed with the project. A business case was prepared at this stage to justify the costs that the project was going to incur which reveal that the company would be able to recover the investment as well as build profits through cost saving and increase in revenues after its being used (Bradley, 2002).

In the next stage of initiation, the project was planned and organized for which a project management plan was developed and approved by the management. A project board was formed involving the company CEO, Operation director, and IT director who were involved in directing the project by defining its objectives and monitoring its progress though provision of support for progress. In the controlling stage, the project was executed stage wise such that after completion of one stage, the project was first reviewed to see if it needed any corrections and then the next stage was proceeded with (Treasury Board of Canada , 2010). Project deliveries were managed at the end of each stage boundaries as the deliverables were produced and communicated to the customer at the end of each stage. Once all deliveries were made, the project closure process began that had recoding of the lessons learned and delivery of documentation with project details for approval. The planning process was followed throughout beginning with the initiation stage and as required, modifications were made in the plan. In the initial plan, the schedule decided for the project was four months but in the due course of time, it was extended by 2 months and according to the same, the timelines and deliverables in the plans were changed (Clements & Gido, 2006).

Customers

In PRINCE 2 methodology, project management components are used including business case, organization, plans, controls, risk management, quality management, configuration management, and change control (Pincemaille, 2008).

The choice of the methodology was made as it had several benefits to the company and the project such as ability to have a control over the project life cycle, continues justification of project through business case analysis, automatic control of the deviations on project, effective communication between project stakeholders, and high engagement of project stakeholders from time to time (Pawar & Mahajan, 2017).

Project Sponsor: The manufacturing company was sponsoring the project and the chairman was the decision maker for releasing the funds for the project.

Customers: Customers of the company had to use the system for placing orders and tracking their project deliveries and thus, their inputs were important at the requirements gathering stage especially for the development of the web-based interfaces for them to access the order information (Beringer & Kock, 2013).

Suppliers: The suppliers of the project included the IT vendors and developers who provided the IT infrastructure and software codes for the development of the project. These also included IT consultants who guided the project during implementation and also during the training of the employees in the developed software (Welsh & Black, 2010).

End users: End users of the system were the internal employees from the order processing, delivery, and finance department who used the system for their own operations.

Community: Community included the people affected by the developments in the organization and were interested in results. These included the communities of the IT people and consumers (BIS, 2010).

Project scope includes objectives, deliverables, milestones, requirements, and exclusions. Each of these have been defined for the software development project that is being discussed here in this section (Kisongoch & Nsubug, 2013).

The objectives of the project were following:

• Develop a software that can manage order processing, deliveries, and payment outstanding for the company
• Ensure that the manual operations that are time consuming can become fast with the use of software system
• Implement the software in the company and provide integration with its legacy applications
• Provide training to the end users so that they can start using the system with ease(FME, 2014)

Deliverables of the development project included:

• Modules for order processing, delivery management and payment outstanding tracking
• User interfaces for internal and external users including order processing department users, company management, and customers
• Data migration from the legacy systems to the new software for order, deliveries and payment management.
• Installation of the new system and its integration with the legacy applications of the company(PM4DEV, 2016)
• Training to the employees of the organisation on the use of the developed software

Functional requirements involved technicalities of the implementation. Software development project has some functional and some non-functional requirements. Its functional requirements would include administrative functions and user interface requirements. Administrative functions include:

• The software should provide feature for receiving orders and data related to the order on the product, quantity, price, location, customer, and payment details.
• An administrator should be able to have backend access to the data of customers as well as of the company
• An information feature must be prided which admittatur could use to generate reports from the database
• Administrator must have the access to deciding rights for other users as per the company policies.

User interface requirements include:

• The administrative user interface must provide control to all the functionalities needed by the management including operations, access, and security
• A web interface must be providing to the customers for the placement of the order based on the product availability
• A backend user interface would be provided to the company employees to perform their needed functions which would include multiple logins for multiple departments such that the features needed by specific department are only accessible to the users of that department. For instance, the accounting department would have access to the invoices but would not have access to production data.
• Management interface would provide overview on the entire company data for the purpose of monitoring operations and taking decisions.

Non-functional requirements of the project would include:

Availability: The software must have 99% of the uptime during working hours and even in the case of upgrading needed, the downtime must remain limited to non-working hours at the night.

Performance: At these points when the software is working, it should be able to take the load of 1million users at any point of time allowing customers to order and back end teams to process the orders.

Suppliers

Scalability: The system should be able to accommodate for increasing users of the system in near future without any major upgrade needed and thus, it made scalable to a million-user load at any point of time which currently is only half a million.

Usability: The users should be able to use its features for performing all the desired functions involving order processing, data management, delivery tracking, and payment outstanding management.

Security: The software should have the inbuilt features that protect it from security treats and unauthorized attacks so that the data of the customers and the company do not go into the wrong hands.

Reliability: The data that gets stored into the system through various functions should create automatic backups in the database and this data should remain intact without any modification such that it can always be relied on. Any changes happening in the orders must be automatically reflected on the data for ensuring its reliability.

The project did not include the following in its deliverables –

• Training of customers as end users on the software usage
• Troubleshooting problems with legacy applications after integration has been done with the new software

The progress of the project was tracked with budget utilization and schedule adherence as per the deliverables and activities that were to be executed on the project. A work Breakdown Structure was prepared listing all the activities involved in the development project. For each activity identified in the WBS, time required would was estimated in days. Activities that were most critical to the project would were used for the calculation of the minimum duration of the project. The time that is available to each activity was be recorded in the plan and while during execution, a comparison was done between the available time planned and the actual time taken for project activities. Slack time was calculated as the difference of the two while tracking the progress of the project (SAEO, 2015).

WBS

• Initiation
  • Business Case Analysis
  • Budgeting
  • Scheduling
• Planning
  • Cost Management Plan
  • Time Management plan
  • Risk Management plan
  • Quality Management Plan
  • Change management plan
  • Scope Management Plan
• Execution
  • Requirement gathering
    • Functional Requirements
    • Non-functional requirement
  • Procurement
    • Hardware
    • Software license
  • Designing
    • Administrative interface
    • User Interface
    • Web interface
  • Development
    • Order processing module
    • Delivery tracking module
    • Outstanding payment management module
  • Testing
    • System testing
    • Unit testing
  • Implementation
    • Installation
    • Integration
    • Testing
      • Integration testing
      • User Acceptance testing
    • Closure
      • Lessons learned
      • Training
      • Closure documentation
      • Project Sign off

The purpose of project scope management is to ensure that the project is able to deliver the desired output within the limitations of the constraints of time and cost. It involves execution of planned activities while avoiding working on those excluded from the scope. A WBS is used as the base for understanding what activities are required to be performed on a project (Pennypacker, 2005). The scope was managed on the project through a five step process that included gathering of functional and non-functional requirements of the software project, defining of specific elements in the project scope, preparation of the work breakdown structure to list down activities in detail, verification of scope by involving project stakeholders through discussions, and controlling of the scope to ensure that only those activities planned are executed without wasting any time on non-productive activities (CIMA, 2005). Project charter and stakeholder register usually create the inputs to scope management plan. In the software development project, project charter was prepared at the start-up stage which formed the basis for the use of scope management tools like interviews, surveys, and observations. Output to the tools and techniques that are used to obtain information through this tool could be requirements document or requirement traceability matrix. The company used requirements document in which both functional and non-functional requirements of the project were recorded in detail (PMI, 2013).

End users

Stakeholders are the people or entities that are either affected by the project or affect the project. They can have from low to high level of interest in the project and can carry from low to high influence. The communication needs of stakeholders are identified by their interest and influence levels. Stakeholders with low influence by high interests are kept informed. Stakeholders with high influence but low interest could be communicated just to keep them satisfied. Those with high influence as well as interest are managed closely through formal and continuous communication. The modes of communication, frequency of communication and the communication items would vary with stakeholders. On the software development project, stakeholder communication was managed in the following ways (LIM, et al., 2005):

Project Sponsor: The sponsor of the company was interested in ensuring that the project brought business benefits to the organization and every investment made on it was justified making project viable. He has high level of influence on the project and also high level of interest. The project sponsor needs to be communicated formally by the project manager through the submission of a project charter to get the approval on budget. Once the project sponsor has approved it, he is only kept informed about how the project is going and affecting the budget at every major milestone. A face to face meeting would be the mode of communication during initiation for charter approval while email based communication can be followed for updating on milestones (PMI, 2011). If the project faces a risk of cost over run and extra funds are needed then a formal meeting may be needed between project manager and the sponsor to decide on provision of additional funds.  The project sponsor of the software development project was met first for approval and then the project manager sent him the project progress report with actual budget versus planned budget highlights (Clement, 2005).

Customers: Customers of the company were the people who were going to use the web-based interface for placing orders and thus, their satisfaction was important as they would be needed to accept the project outcome for it to be successful. However, when considering project, they carried moderate level of influence but low interest. Thus, they were just kept informed about the project progress with formal emails sent to them informing them about the potential changes in the system and how they were going to affect the order management process of the company. They were also involved during the requirement gathering stage through a face to face interview conducted with a few trusted customers (USP, 2000).

Community

Suppliers: The suppliers of the project included the IT vendors and developers who had moderate level of influence and high interest in the project as their output would determine the success of the project and the project would earn them profits if successful. Thus, suppliers were managed closely and involved throughout the progress of the project right from the starting of the bidding and vendor selection process. These suppliers were interested in getting desired payments and clarity on the project requirements. Thus, they were formally involved through contracts that mentioned the details legally and identified terms, conditions, and responsibilities that they had to follow on the project (Júnior, et al., 2015).

End users: End users of the system were the internal employees from the order processing, delivery, and finance department. These users would use the actual developed software and thus, had moderate interest in the project with high influence. They were closely involved in the project starting from the requirement gathering stage where their inputs were taken and further, they were involved in review meetings to understand how software outcome was coming and if it was aligned with the requirements. They were also involved in the testing stages for project acceptance (MARCONI, 2013).

Community: Community included the people from the IT communities, researchers and government that were having low interest and low influence on the project and thus, were just kept informed about when the project started and when it was finished with not much involvement in the operational details (Jainendrakumar, 2016).

A number of collaborative tools were used while executing the project that included Google Docs for creating, editing and sharing documents between the team members online. Kanban boards were used for visual display of the tasks that were completed at each stage or were in progress for the team to see each day so that they would know how they are progressing against the plan. Tasks to be done, tasks in progress, and tasks that were done were plotted on the board which acted as a guide for all the team members to keep progressing in the right direction as well as have an insight on how the whole project is progressing (Berbec, 2014).

Meetings are the major part of the communication that would happen between the project team members daily, weekly, monthly and as and when milestones are completed. In order for the project to run smoothly, it is essential that the communication happening in these meetings is controlled effectively. To ensure that the meetings involved on the project are productive, an agenda was developed with clear identification of participants needs and information needs.   A project manager was designated to track the discussions happening in the meeting as well as following up with the participants post meeting to ensure that they act as per the action plan decided during the meeting. Different people in a project can have different communication styles which can cause conflicts that also had to be avoided for the project to grow smooth (William Dow & Taylor, 2010). Thus, the project manager identified the participating personnel and their communication styles from introvert, extroverts, intuitive, and rationales (Futrell, 2002). Based on these communication styles, their decision styles also vary. Introverts who are intuitive ask others opinion while taking a major decision while introverts with rational opinion rely on logic. Intuitive extroverts are more of tellers and they acknowledge feelings of others. Rational extroverts or introverts are more logical people and extroverts of this category tell things to others. The people working on the project were categorised according to this classification and while communication plans were decided, the project manager took care of their specific needs so that conflicts could be avoided (Gardiner, 2005).

Objectives of the project

The first step to risk management is risk identification which is done by talking to stakeholders through the use of different tools such as brainstorming, interviewing and SWOT analysis. Once project risks are identified, they are analysed to explore their impact on the project. This analysis would include both qualitative and quantitative exploration. Based on this analysis, an appropriate response plan is created for management of risks. Risks can be managed using either of the common strategies that include avoiding, transferring, mitigating impacts or assuming the risks. Based the level of severity which is determined by understand the probability of their occurrence and the impact on the project, the ideal response can be determined (Caltrans, 2007).

Risks can be identified by involving project team and key stakeholders of the project who can help identify different types of risks. A number of different tools were used at different stages of the project for identification of risks and these included SWOT analyses of the project that revealed broad categories of risks that project can face, interview that helped in identifying risks in each category, and brainstorming that was used to refine the risks identified and produce a description for them.

SWOT analysis

This involved identification of strengths, weaknesses, opportunities and threats of the project in which weaknesses and threats are the most important areas to discuss when risks have to be identified on a project.  The weaknesses of the software development project included:

• Lack of experience in users of working on the automated systems like the one being built
• Limited human resource that was involved in the project execution
• The project has been provided with a limited budget which cannot be exceeded beyond the utilization of the contingency amount

The threats to the project included:

• The software could have the bugs that would affect its functionalities or fall prey to security threats and thus, lead to the project failure
• It could be found later that project could not be completed within the allotted budget but would need more money which may make the project not feasible
• Stakeholders may not be satisfied with the project output and then then would not accept the final output after its completion

Selected end users were involved in the process of requirement gathering through interviews in which the project managers asked the potential users about the needs and expectations related to the software. These users helped the project manager formulate the functional and non-functional requirements of the project. During these interviews conducted with the potential internal users, they were also asked about the potential risks that the project could face and the same were recorded in the risk register.

This process was used between the project team members once they had collected the requirements through the interview with the users to build the requirements document. They discussed on what was essential and what could be skipped and derived a plan for requirements based on which they were formally documented. Brainstorming was first done at the requirements analysis stage and later after completion of every project stage when project team brainstormed on how the project was progressing and if they needed any improvement in their strategies or needed to take some corrective actions for managing project scope, timelines or cost. For each of these areas and other risk categories identified during interviewing, specific risks were identified by the project team and were formally recorded in the risk management plan with details of probability of occurrence, impact on the project and potential response plan recorded.

Deliverables of the development project

Risk analysis is about assessing how often is the risk likely to occur and what level of impact it can have on a project. In the qualitative analysis of risks, the project manager used the historical data on previously similar projects to understand these for the identified risks and had brainstorming done with the team to come up with the proper assessment of probability of their occurrence, impact on the project and potential measures that can be taken in response from acceptance, avoiding, transfer, and mitigation. Based on these assessments, each risk is given a ranking to reflect upon the severity of specific risk. Risk rating can be calculated as risk probability * risk impact. The values of risk probability and risk impact could be from 2 for low, 3 for medium to 4 for high. The project involved creation of a risk matrix based on these values for ranking as follows (Galway, 2004):

Risk Matrix	Probability
Impact	4	6	8	Low
6	9	12	Medium
8	12	16	High
Low	Medium	High	(Scheinin & Hefner., 2005)

Risk category	Risk	Impact	Probability	Severity/ risk ranking
Financial	Project cost overrun	Moderate	Low	6
Technology	Wrong functionality produced Incorrect interfaces developed	High High	Low Low	8 8
People	Dissatisfaction in stakeholders Conflicts between team members Lack of resources	Moderate High Moderate	Moderate Moderate Moderate (Kendrick, 2003)	9 12 9

Quantitative risk analysis involves the assessment of the impact of a risk on the project with defined monetary value which is calculated as a multiplication of the present monetary value of impact and the percentage of probability of occurrence (Schuyler, 2001). For the risks identified in the qualitative analysis, the expected monetary value of each risk was calculated using this formula as illustrated in the table below. The calculations are made considering the total project cost of $200,000 and contingency amount of $20,000

Risk	Impact	Probability	Expected Monetary Value of Risk
Project cost overrun	$30,000	5%	$1,500
Wrong functionality produced Incorrect interfaces developed	$60,000 $60,000	5% 5%	$3,000 $3,000
Dissatisfaction in stakeholders Conflicts between team members Lack of resources (Salichos, 2015)	$30,000 $60,000 $30,000	15% 15% 15%	$4,500 $9,000 $4,500

Risk category	Risk	Severity	Responsibility	Response plan
Financial	Project cost overrun	6	Project Manager	Avoid: Have a pessimistic approach to estimation and keep extra funds as contingencies to take care of emergencies. Take inputs from the experts who have experience of handling similar project in past to ensure that estimates are more accurate (Rodrigues-da-Silva & L.H., 2014).
Technology	Wrong functionality produced Incorrect interfaces developed	8 8	Developers	Avoid: Involve all stakeholders and potential users in requirement gathering stage to ensure all project requirements are well formulated and also take users inputs through proper testing to identify any bugs or discrepancies so that they can be corrected before that actual launch of the software (Sanderson, 2012)
People	Dissatisfaction in stakeholders Conflicts between team members Lack of resources (Virine, 2013)	9 12 9	Project Manager	Mitigate: If the stakeholders are not satisfied with certain requirements, have a discussion with them to bring consensus on selected requirements and include them in the project scope. In the case of conflicts arising between them, the project manager should take steps to resolve issues through discussion. If lack of resources is faced due to a person quitting project in between, the work may be distributed to remains for which they can be made prepared in advance through proper training. AN immediate new hiring is recommended through the use of contingency funds to bring the project back on the track and compensate for any delays to ensure that the project meets the final deadline (Raz, 2001).

Project leadership is about creation of a productive environment for working and management of change. Leadership management on a project is done with the proper employment of a project leader or project manager. It then becomes the responsibility of the project manager as its leader to ensure that the project progresses smoothly and resources are well managed. For this, it is needed that the project manager possesses leadership qualities. On the project of software development, the qualities that a project manager would need can include technical knowledge of development aspects, working knowledge of project management principles, communication skills, negotiation skills, conflict management skills, critical thinking and team management skills (Kurzyd?owska, 2016). A project manager with these skills would be able to make a team which has the right set of skills and competencies as well as keep the team targeted toward project goals and keep them motivated enough to facilitate productivity in them. A project manager should also have a good understanding of how project stakeholders can be managed including the major decision makers of the project such as the company CEO and project sponsor as the project manager would need to act as a communicator or bridge between the actual working project team and these stakeholders and thus, it would be his or her duty to ensure proper transfer of information and flow of support for the team to progress (Krahn & Hartment, 2006).

Functional requirements

Project is controlled so that project outcomes can be achieved in given time and within budget that is allotted. Monitoring over project gives project manager an opportunity to explore if the project is going as per the plan or there are any deviations in schedule, cost, resource utilization, or scope. While monitoring gives the picture of variations, control procedures are needed to establish control over the project to prevent these deviations or control their impacts. Control can be establish using a number of different methods such as project reviews, resource allocations, and personnel assessments and assignments (IFRC, 2011). Control can be established on a project by the project manager but not alone as it is augmented by a number of components that form the control structure. These include sensor, standard, comparator, decision maker, and effector. Sensor would be the person using a procedure to identify deviations on a project which can be done using different tools like schedule comparison and Gantt charts. Standards are used for projects for performance assessment that are compared with the actual project outcomes by a comparator based on which a decision maker takes a decision which is acted upon by a project team and is facilitated by the effector (DOBRE, 2006).

A number of different types of control systems can be used on project depending on the project stage. A go-no go control is established when decisions have to be made whether to perform an activity or include it in the scope. In the software development project, go-no go control was used at the end of each stage such that once a stage was completed and reviewed, management had to take a decision on whether to proceed on to the next stage or not. This decision was taken on the basis of viability of the project and task completion as well as on the impact of the project activities completed till review on the project constraints (Karamitsos, et al., 2010).

A number of different tools were used for establishing control over the project including variance analysis and trends projection. In the variance analysis the budget and schedule were compared with those planned and deviations from the original plans were calculated. Trend project was used to make a projection on the timelines and costs that would be incurred in the remining activities of the project after completion so specific strategy that would change based on the outcome of the previous stage that was being reviewed. If any major variations were found or the predictions would suggest major variations in future, the project manager would work to take corrective actions to avoid problems like scope creep and cost overrun though the use of change control procedures (Kovachev & Ross, 2009).

Non-functional requirements

A feedback was taken by the learner on how the project was managed from the fellow team members and the seniors on the ability to plan and implement projects. Based on the feedback received, certain strengths and weaknesses could be identified. Strengths include the ability to foresee the results of present actions and develop forecasts and ability to communicate effectively. Weaknesses includes lack of formal knowledge of project management models to the needed level and inability to control the project scope (Mishkind, 2014).

Based this evaluation, a development plan can be created for the researcher that would involve the following actions and strategies:

• Project management certification study and appearance would help the professional gain understanding of the standards and methodologies of project management
• Project manager will learn some professional tools like MS Project and would use the same for managing project scope through monitoring and control
• The researcher would expose himself to different types of projects and would apply the learning to gain a practical experience that would add to the knowledge and skills through practice.
• The researcher would explore the skills needed by an effective project manager and would do activities to inculcate them in himself such as participating in team building activities to gain team building skills and learning of facilitation skills to gain an understanding of how people can be motivated and managed on projects.

Conclusions

This report explored the concept of project management, its principles, and tools to understand how they can be used on a real project. To have a practical understanding of them, a case of software development for manufacturing company that was to build a system for managing operations of the company like order fulfilment, outstanding managed, and delivery management was considered. The project was executed using PRINCE 2 methodology which had a number of different processes to follow along the project while the predict was divided into stages with each stage having a definite boundary. At the end of each stage, a review would be taken for monitoring project progress and deviations from plan would be measured and worked upon to establish control. The report also explored the risk management strategies, stakeholder management plan, and communication managed plan. A number of risks were identified including cost overrun, lack of resources, and delays that were analysed using qualitative and quantitative methods and a response plan was developed. It was found that professional practice of project management has a variety of different tools that can be used for the tangent of each component and stage of a project which would increase the probability of success of a project.

References

ADB, 2006. Guidelines for Preparing Performance Evaluation Reports for Public Sector Operations , s.l.: Asian Development Bank .

Berbec, I. S., 2014. Aligning Project Scope And Deliverables With Business Strategy, s.l.: KTH Royal Institute of Technology .

Beringer, C. J. & Kock, A. D., 2013. Behavior of internal stakeholders in project portfolio management and its impact on success. International Journal of Project Management, 31(6), pp. 840-846.

BIS, 2010. Guidelines for managing projects: How to organise, plan and control projects, s.l.: BIS.

Bradley, K., 2002. Understanding PRINCE2, s.l.: SPOC.

Caltrans, 2007. PROJECT RISK MANAGEMENT HANDBOOK: Threats and Opportunities , s.l.: Caltrans.

Project progress tracking

CIMA, 2005. Standard Costing and Variance Analysis, s.l.: CIMA.

Clement, R. W., 2005. The Lessons from Stakeholder Theory for U.S. Busines Leaders. Business Horizons, 48(1), pp. 255-264.

Clements, J. P. & Gido, J. .., 2006. Effective Project Management, s.l.: Thompson.

DOBRE, E., 2006. Control of projects – a cybernetic control , s.l.: Journal of Applied Quantative Methods.

FME, 2014. Project Scope Management: Project Skills, s.l.: FME.

Futrell, R. T., 2002. Quality Software Project Management, s.l.: Pearson Education India.

Galway, L., 2004. Quantitative Risk Analysis for Project Management, s.l.: RAND.

Gardiner, P. D., 2005. Project Management: A Strategic Planning Approach, s.l.: Macmillan International Higher Education.

IFRC, 2011. Project/programme monitoring and evaluation (M&E) guide, s.l.: IFRC.

Jainendrakumar, T. D., 2016. Project Stakeholder Management. PM World Journal, 5(5), pp. 1-9.

Júnior, A. C. P., Porto, G. S., Pacífico, O. & Júnior, A. P. S., 2015. Project Stakeholder Management: A Case Study of a Brazilian Science Park. Journal of Technology Management & Innovation , 10(2), pp. 39-42.

Karamitsos, I., Apostolopoulos, C. & Bugami, M. A., 2010. Benefits Management Process Complements Other Project Management Methodologies. J. Software Engineering & Applications, Volume 3, pp. 839-844.

Kendrick, T., 2003. Identifying and Managing Project Risk: Essential Tools for FailureProofing your Project, s.l.: AMACOM.

Kisongoch, G. & Nsubug, A., 2013. IT Project Management Methodology : Project Scope Management Support Guide, s.l.: NITA.

Kovachev, I. & Ross, L., 2009. Management accounting tools for today and tomorrow, s.l.: CIMA.

Krahn, J. & Hartment, F., 2006. Effective project leadership: a combination of project manager skills and competencies in context, s.l.: PMI.

Kurzyd?owska, A., 2016. Leadership in Project Management. Humanities and Social Sciences, XXI(23), pp. 103-112.

LIM, G., Ahn, H. & Lee, H., 2005. Formulating strategies for stakeholder management: a case based reasoning approach.. Expert Systems with Applications, 28(2), pp. 831-840.

MARCONI, F., 2013. Stakeholder Relationship Management for Software Projects, s.l.: Politecnico di Milano.

Mishkind, A., 2014. Evidence-Based Professional Learning, s.l.: State of California.

Pawar, R. P. & Mahajan, K. N., 2017. Benefits and Issues in Managing Project by PRINCE2 Methodology. International Journal of Advanced Research in Computer Science and Software Engineering, 7(3), pp. 170-195.

Pennypacker, J. S., 2005. Measures of Project Management Performance and Value , s.l.: CBP.

Pincemaille, C., 2008. Prince 2: a methodology of project management, s.l.: Cork Institute of Technology.

PM4DEV, 2016. Project Scope Management for Developing Organizations, s.l.: PM4DEV.

PMI, 2011. Executive Engagement: The Role of the Sponsor, s.l.: PMI.

PMI, 2013. A guide to the project management body of knowledge, Newton Square: Pennsylvania.: PMI.

Raz, T. M. E., 2001. Use and benefits of tools for project risk management. International Journal of Project Management, Volume 19, pp. 9-17.

Rodrigues-da-Silva & L.H., C. J., 2014. The project risk management process, a preliminary study. Procedia Technology, Volume 16, pp. 943-949.

SAEO, 2015. Cost Estimating Manual for Projects , s.l.: SAEO.

Salichos, A., 2015. Title: “Qualitative and Quantitative Risk Management approaches for Turnaround Projects in the Process Industry”. s.l.:University of Piraeus .

Sanderson, J., 2012. Risk, uncertainty and governance in mega projects – A critical discussion of alternative explanations. International Journal of Project Management, Volume 30, pp. 432-443.

Scheinin, W. & Hefner., R., 2005. A Comprehensive Survey of Risk Sources and Categories. Los Angeles, CA, Proceedings of Space Systems Engineering and Risk Management Symposiums.

Schuyler, J., 2001. Risk and Decision Analysis in Projects, Newton Square, PA: Project Management Institute.

Treasury Board of Canada , 2010. A Guide to Project Gating for IT-Enabled Projects , s.l.: Treasury Board of Canada.

USP, 2000. Improving Customer Service through Effective Performance Management, s.l.: United States of Personnel Management.

Virine, L., 2013. Integrated Qualitative and Quantitative Risk Analysis of Project Portfolios, s.l.: Casualty Actuarial Society.

Welsh, W. D. & Black, D., 2010. Engaging stakeholders for a software development project: River Manager model, s.l.: Brigham Young University.

William Dow & Taylor, B., 2010. Project Management Communications Bible, s.l.: John Wiley & Sons.