.
Sunday, September 29, 2019
Project Plan- Risk and Quality Requirements Essay
IT Project Plan IT projects are complex in nature. A proper plan gives not only maps the elements of the project but also ensures that the progress of project is going in the desired direction. In other terms, a project plan reduces the risk of project failure or over runs and improves the quality of the project. Project plan is the initial step in executing the project management. Project management strives to meet the expectations of the project stakeholders in terms of cost, quality, delivery and operations. Project management is a crucial process that involves, people, process, price, infrastructure and cost. Project management should balance the interests of different stakeholders of the project like Project team members, management of the working group, client parameters, industry practices and the budget restrictions. In IT industry, it becomes the responsibility of project manager to look after the co-ordination of the above aspects. Project plan becomes an essential helping tool to the project management in directing the project requirements to the people and system. The project plan aligns the activities with the project life cycle and gives visibility to different phases of the project. IT will be like indicating the stakeholders of the project like client and project team to act upon the different activities of the project like, development, testing, rollout, training and implementation. The project plan is developed in connection with Organizational plan, Risk plan, Cost plan, Test plan, Roll out plan, Quality plan, Maintenance plan etc., So it is evident that Risk identification and Quality parameters act as forecasters for the project phase activities and does have a great significance in the successful implementation. However project plan includes the The Project Plan provides complete overview on how and when a project’s objectives are to be achieved, by expressing different activities to resources to achieve targets at different milestones The major elements of the project plan are as following: Description of the project or an over view of the project plan. Project specifications and requirements of the client Project Initiation plan and requirements in terms of technology, budget and people Project dependencies- external, internal Project milestones like Analysis, design, development, testing, implementation and training Identification and specification of project assumptions like availability of resources, technical inputs, skills and competency requirements. Project plan with work break down structure through Gantt chart or bar chart and control points at different levels. Project level activity specifications for different stakeholders like client team,, analysis team, design team etc., Project level resource specifications Project budget and cost plan Project tolerance, through put and capacity in terms of users and boundaries Technology to be implemented with constrains and rationale for the usage. Network contingency plans and infrastructure layout plans to be required for the project work out Risk identification and risk tolerance specifications of he system Quality framework under which the project is expected to execute Risk Risk can be termed as the possible loss or damage to a process. Risk identification is the estimation of possible potential dangers that can occur or hinder the progress of the project. Risk in IT project management is a major component to consider even before the project execution, as the unidentified risks not only obstruct the progress but also may turn the entire project into loss. A risk will have a probability something above 0%. And there is an identified chance to happen, which other wise is not a risk. So a deliberate approach to identify and mitigate the risks is highly appreciable from the project learning from decades. According to Dr. Barry W. Boehm, (as cited in kjordan) the top 10 identified software risks are as follows: Personal Shortfalls in perception of risk and resources Unrealistic schedules and budgets Developing the wrong functions and properties Developing the wrong user interface Gold-plating Continuing stream of requirements changes Shortfalls in externally furnished components Shortfalls in externally performed tasks Real-time performance shortfalls Straining computer-science capabilities So, IT projects do have a risk management process that is expressed through the risk management plan. The risk management plan contains the four major areas to observe in the plan: Risk Identification: The project manager or risk management personnel will identify the possible potential threats to the project management before well in advance. Eg; Shortage of workforce due to the withdrawal of people from the team; this can be from different reasons like, maternity leave, transfers to other projects or contract termination etc., Risk Quantification: The risk identified should be quantifiable, other wise which it is will not be of much useful. Eg; What percentage of people are going to be placed on another major project or percentage of testers that may not be available on project A. Risk Response: The consequences of risk should be specified, in the sense, sometimes the system may be less altered with certain types of risks. With this, the low response of system indicates and attributes the risk as a less priority risk. And the risks that may cause major alterations to the process will be given high priority by the project plan to address them and mitigate them. Risk Monitoring and Control: Risk monitoring and controlling involves the risk mitigation tools and practices for the easy execution of the project. Eg: Training the new people to fill the gaps on attrition by the time they leave or to be transferred from the current project process. The common risk scenarios in IT projects are as follows: Schedule Risk This is the highly possible risks in IT projects, when projects over run with scheduled times or slip the release schedules or the client priorities and queries are not answered Schedule risks alters the project phases and disturbs many dependencies. Other project dependencies like testing schedules, release schedules and infrastructure costing etc., can be altered and result in excessive costing and losses. Schedule risk can happened due to the following reasons: Inappropriate or wrong project time estimation Poor tracking and monitoring of work break down plan with the resources. Over estimation of system functionality and through put. Eg: When the existing system support only 50 resources to work, scheduling of 60 or 65 may result in non availability of proper infrastructure. Wrong estimation of effort or skills. Eg: the project with low skilled work force or low effort estimation may take much time compared with the scenario of experienced people on task. Failure to specify or identify complex functionalities or requirements that emerge and become stumbling blocks for the progress execution, takes longer time to resolve and them to continue with the projected phases. Unexpected project scope expansions: These can happen due to the poor business analysis and feasibility guidelines. Budget Risk All the above schedule risks can ultimately result in increase in resource cost. In addition to this, the following at the initial project plan phase also result in budget risks Wrong budget estimation: When the cost of resources is going to be increased in future, adaptation of old compensation rates will ask for more funds to meet the project execution after some time. Cost overruns: These will arise when the project activities are not aligning with the planned activities Project scope expansion: Wrong specification of requirement may lead to extra budgets.      Eg: Some IT projects fail to define the project scope very specifically in terms of design,      development, training (on site), installation, maintenance, and support. A project that fails        to differentiate between on site training support and training support through    documentation like user guide and admin guide has to face a situation in which the      company has to bear the traveling and expenses of training resource when on-site training      is demanded in the last moment. Operational Risks Operational risks arises due to non specification of appropriate project methodology and non implementation of project processes like daily meetings (scrums), communication reports, Change requirement reports. Such risks will again result in over runs in operational schedules and results in high costs. Some causes of Operational risks are as follows: Failure to address priority conflicts: when tasks and conflicts are not nor prioritized, people sit on unnecessary or low priority tasks resulting the operational delays. Failure to resolve the responsibilities: The non-defined roles and responsibilities work on the similar operations or raise conflicts at some point of time in the operations. Insufficient resources : A project with in sufficient resources may execute poor operational performance and may result in operational delay.  No proper subject training : When the project stakeholders are not given project training at consecutive levels, there will be no direction and clarity in the project operations.  No resource planning : If the resource allocation is not properly planned, conflict arises between the different activities of the system  No communication in team: poor communication is the major hindrance for smooth project execution. Excessive communication and less communication will also alter the project schedules. Non -defining the desired level and form of communication hampers the information flow . eg: Non-maintenance of Change request forms from the client may result in wastage of work on the old configuration of modules by the developers and may result in project over runs. Technical risks Technical risks are the most unidentified risks with great damage and result in failure of functionality and performance. The causes of technical risks are: Continuous changing requirements: The initial technical specifications may require different technology platform to the technology that is appropriate for the recently added requirements Poor suggestion of technology: Lack of technical expertise of resources may result in compatibility problems. Some advanced features that may not be ready by the time of release, or that may not be compatible with the already developed functionalities will hamper the project execution. Product is complex to implement: When the product development is too complex and there is a dearth of skill and expertise in the market, the project needs to suffer delay or failure. Difficult project modules integration: When different modules are products are to be integrated, incompatibility problem arises between them that result in re work or failure. External Risks  These are the external risks beyond the boundaries of project management. These are all uncertain and may result of the following: Shortage of fund. Market Changes: Transferred demand Changing customer product strategy and priority Government rule changes. Quality Requirements of Project Quality refers to the delivery of projects and products that meet the expectations of all the stakeholders. A project that may meet all the specification of the client, but may over run the project schedule is not termed as a quality project, as it has resulted in extra cost to the management. So in order to bring down the risk, IT projects adopt different Quality models. For example Software design and development projects adopt quality models like CMMI, ISO, BSI, etc., he quality model frames a risk management plan and ensures the system to adhere to the planned project activities until the successful implementation. Usually the quality models identify some risk areas and constantly work on controlling the risk areas. The parameters that are commonly observed by different Quality models for IT systems are as follows: Correctness, Reliability, Integrity, Usability, Efficiency, Maintainability, Testability, Interoperability, Flexibility, Reusability, Portability, Clarity, Modifiability, Documentation, Schedule, Validity, Functionality, Generality and Economy. The quality management department or manager will ensure the project that it is being executed properly as per the plan. All the stakeholders monitor the project activities according to the quality parameters and control the error or risk as per the risk mitigation guidelines. Project Quality Plan defines the expectation of the stakeholders in terms of project specifications, schedule time, technology inputs, dependencies etc., and also maps the process to ensure the system to balance. A Project Quality management supports the following through quality plans and system guidelines: Defining organizational and project level quality objectives and parameters Customer requirements and expectations in terms of functionality, delivery Acceptance criteria of the IT product, which is a prioritized list of criteria for the customer to accept the final product. Roles and responsibilities of Quality management team. Functionality boundaries of the project quality system Reference to Industry practices or standards to be met The quality-control and audit processes to be applied to project management Quality-control and audit process parameters and requirements Change management procedures in case of scope change in project Configuration management plan Validation and verification controls Quality control and Assurance plan and procedures By adopting quality monitoring procedures Defining test lab procedures like- test documentation, testing resources, Test cases, scenarios, error logs and other testing documentation Metrics for quality analysis System guidelines for quality management procedures Maintenance of configuration management and change control requirements Conclusion For the Successful IT Project implementation, the project plan must address the risk issues and Quality requirements to mitigate the risk issues. Effective project planning, quality control, and monitoring will ensure the quality assurance of the project mitigating the identified risks. References Elizabeth and Richard Larson, How to Create a Clear Project Plan, Retrieved February 2,          2008 from www.projectmanagement.ittoolbox.com/documents/industry-articles/how-to–           create-a-clear-project-plan-844 – 26k – EPA Requirements for Quality Assurance Project Plans (EPA QA/R-5), Retrieved February     2, 2008 from http://www.epa.gov/QUALITY/qs-docs/r5-final.pdf kjordan, Introduction to Software Risk & Risk Management, Retrieved February 2,2008           from            http://baz.com/kjordan/swse625/intro.html Hyatt & L. Rosenberg, A Software Quality Model and Metrics for Identifying Project Risks and Assessing Software Quality, http://satc.gsfc.nasa.gov/support/STC_APR96/qualtiy/stc_qual.html Project Management Planning, Retrieved February 2, 2008 from            http://www.cio.ca.gov/itpolicy/pdf/PM3.2_Planning_Process_and_Plan.pdf Project Quality Plan , Retrieved February 2, 2008 from            http://www.ogc.gov.uk/documentation_and_templates_project_quality_plan.asp Project plan, Retrieved February 2, 2008 from      http://www.ogc.gov.uk/documentation_and_templates_project_plan_.asp QUALITY ASSURANCE PROJECT PLAN REQUIREMENTS, Retrieved February 2,            2008   from            http://www.wipp.energy.gov/library/CRA/BaselineTool/Documents/Appendices/            WAP%           2010.PDF Quality Assurance Planning, Retrieved February 2, 2008 from            http://www.chesapeakebay.net/info/qa_planning.cfm Risk management strategy, Retrieved February 2, 2008 from            http://www.ogc.gov.uk/documentation_and_templates_risk_management_strateg           y_.asp Risk management framework, Retrieved February 2, 2008 from            http://www.ogc.gov.uk/documentation_and_templates_risk_management_framew         ork_.as p Risk management strategy, Retrieved February 2, 2008 from      http://www.ogc.gov.uk/documentation_and_templates_risk_management_strateg           y_.asp Risk log (risk register) Retrieved February 2, 2008 from      http://www.ogc.gov.uk/documentation_and_templates_risk_log_risk_register.asp Types of Risks in Software Projects, Retrieved February 2, 2008 from      http://www.softwaretestinghelp.com/types-of-risks-in-software-projects/ Â
Subscribe to:
Post Comments (Atom)
No comments:
Post a Comment