IT PROJECT REQUREMENT MANAGEMENT AND RISKSBy 12030241073Ishan MishraSystems Batch (12-14)Symbiosis Centre for Information Technology(A constituent member of SIU Established under section 3 of the UGC Act 1956 vide notification no. F.9-12/2001-U.3 of the Government of India)

ACKNOWLEGEMENT

I would like to express my sincere gratitude towards my project guide Prof. Pradnya Purandare for providing me with an opportunity to work on this project and for sharing her experience and knowledge with me. It was a great learning experience and will help me go long way in my career. I appreciate the efforts, the keen interest and the initiative taken by my mentor .With her guidance I have completed the project successfully with a knowledge enriching experience.I am also indebted to my alma mater Symbiosis Centre For Information Technology andthe esteem faculty members. It is only because of the education imparted to me during the management course that I was able to appreciate the work imparted to me.

I am also thankful to my Project coordinator and all faculties from SCIT, for co-operating and motivating me throughout this project.

Ishan Mishra

CONTENTS

Table of ContentsACKNOWLEGEMENT2CONTENTS3LIST OF TABLES4LIST OF GRAPHS5CHAPTER 161 .Introduction61.1Summary of Abstract61.2 Objective71.3 Methodology7CHAPTER 282.1 Review of literature8Risks in IT Projects:12CHAPTER 3143.1 Analysis of the work done143.2. Alternative Solutions and their advantages & disadvantages173.3. Proposed Solution193.4 Technical justification of the solution223.5 Technical environment and technical details243.6 Possible application in the industry25CHAPTER 4264.1 Findings264.2 Recommendations274.3 Conclusion28REFRENCES AND BIBLIOGRAPHY:30

LIST OF TABLES

Sr. No.TableDescriptionPage No.

1Table 1Risks table 15

2Table 2Suggested measures table16

3Table 3Survey table 18

LIST OF GRAPHS

Sr. No.TableDescriptionPage No.

1Figure 1Major causes of project failure 12

2Figure 2Survey graph 118

3Figure 3Survey graph 2 20

CHAPTER 1

1 .Introduction

Today 57 % of the projects fail due to bad communication between the parties involved and 39% of project fail due to lack of planning of resources, scheduling and activities hence this is worth investigating the importance of requirements management that it plays in project success . Here , the nature of the work done is research based wherein some primary data analysis and data collection methods like survey would be used to achieve a conclusion on the importance on requirements gathering and project risks involved in the span of project lifecycle1.1 Summary of Abstract

We all are familiar with the importance of requirements management in any IT project and also the risks involved while the project proceeds so to further enlighten this we are here doing a dissertation for the same.Evaluating, monitoring, and improving the effectiveness of project management can contribute to successful business generation for an enterpriseIn this dissertation, we introduce a formal method for gauging the effectiveness of managing a project for a specific industry viz. software industry with an aim to analyse the importance of requirements management and the risks involved throughout the project lifecycle.

The methodology followed would be primary research (surveys), questionnaires and secondary data analysis available. The survey results may be used to evaluate and monitor project management effectiveness in software projects by project managers, technical managers, executive managers, project team leaders and various experts in the project organization and also for educational purposesWell be also focussing onto the various risks involved in the project viz. cost, schedule and quality risk that are critical to be resolved for any project success and getting the insights industry people have on it.

1.2 Objective

Objectives describe how you are going to achieve the aims we have set in the dissertation.The aim of the dissertation is to analyse the importance of clear requirements management and the risks involved in the projects and preparing conclusions based on the inputs given by industry and further draw conclusions on the same. To conduct a primary data analysis and further data collectionfrom industry To gather data about the project risks in SDLC To draw conclusions regarding the industry responses and the best practices To prepare a AS-IS analysis of the results and further refine the conclusion reached1.3 Methodology

For the purpose of data gathering we are using surveys and getting their responses from industry people,the following statements are intended to give a flavour of the approach:Literature surveySecondary data will be reviewed initially through the libraryanduseof a range of information sources such as the OPAC system, academic and commercial abstracts and Internet search engines, the literature review is attached here in the next sectionsData collection and samplingTo test current practice against the historical record an on-line survey will be conducted to gather primary source data from companies currently engaged in the export of goods related to heavy engineering projects

CHAPTER 2

2.1 Review of literature

First of all, we have to define what a project is and discuss if the definition applies to software projects.A project is an organization of people dedicated to a specific purpose or objective. Projects generally involve large, expensive, unique, or high risk undertakings which have to be completed by a certain date, for a certain amount of money, within some expected level of performance. At a minimum, all projects need to have well defined objectives and sufficient resources to carry out all the required tasksRequirements engineering is concerned with identifying, modelling, communicating and documenting the requirements for a system, and the contexts in which the system will be used. Requirements describe what is to be done but not how they are implemented The RE process consists of five main activities:Elicitation, Analysis and Negotiation, Documentation, Validation, and ManagementAccording to IEEE, requirements can be defined as:1. A condition or capability needed by a user to solve a problem or achieve an objective.2.A condition or capability that must be met or possessed by a system or system component to satisfy a contract, standard, specification, or other formally imposed document.Requirements are: specifications of what should be implemented. They are descriptions of how the system should behave, or of a system property or attribute.Three Levels of requirements are: Business level: high level objectives of the organization or customer requesting the system orProduct. User requirement: describe tasks the users must be able to accomplish with the product. Functional requirements: describes the functionality the developers must build into the product to enable users to accomplish their tasks, thereby satisfying the business requirements.Non-functional requirements: Standards, regulations and contracts to which the product must conform to. Description of external interfaces Performance requirementsStakeholders:Customer, End-users,Other stakeholdersProject Success Factors: determine how success is defined and measures for this product, and describe the factors that are likely to have the greatest impact on achieving success. E.g.: market share, sales volume, revenue, customer satisfaction, accuracy, speed etc.

Sources of Requirements Marketing surveys and user questionnaires: used in our dissertation Interviews and discussions with potential users

User ClassesUsers of a product differ in many ways : the features they use, frequency of use of the system, computer expertise, the business process they perform, their geographic location and access privilege.Req. Elicitation

Elicitation is the process of identifying and understanding the needs and constraints of the different user classes for a proposed software product.

Use Case ApproachImp: A use case provide a way to represent the user requirements which must align with the systems business requirements.Use case should describe all the task users need to perform with the system.Hence, Use cases should encompass all the desired functions of the system

Use case DescriptionA unique identifier.A name that states the user taskName of the actor A short description.

Identifying and documenting Use CasesIdentify the actors and their roles first, and then identify the business processes in which each participatesIdentify the external events to which the system must respond

Classifying the Customer InputsAnalysts have to gather information from the customer and categories the requirements appropriatelyBusiness Requirements: anything related to the business benefits, financial benefits, and marketplace is included in the business requirements. E.g.: save $X per yearUse cases and scenarios: business task which needs to be performed with the system. Specific task can be classified in broader use casesFunctional requirementsWhile carrying elicitation the focus should be on what is to be done rather than how it is to be done. Identify customer specified solution, which will help you to understand the real need of the customers.Software Requirements SpecificationThe software requirement specification is known as the functional specification, requirement agreement, and specification.It precisely states the function and capabilities that a software system must provide and the constraints that it must respect.It must contain: intended external, user visible behaviours of all the systems. It should contain constraints related to design, construction, testing, project management.Audiences of SRSCustomer and marketing dept.: to know what product they will deliver.Project managers: plans and estimates of schedule, effort, and resources on the product description.Software development team: to understand what to build.Testing group: derive test cases, test plans.Software maintenance and support staff: to understand the product.Publication group: to develop user documentationTraining Personal

Non Functional Requirements:

Performance RequirementsSafety RequirementsSecurity Requirements

Software Quality AttributesBusiness RulesUser Documentation

Attributes of Requirements Complete Correct Feasible Necessary Unambiguous Verifiable.

Technical Methods for Requirement Specification:Various technical methods are: DFD ERD State transition diagrams Activity diagrams Object oriented (class diagrams)

Modelling the Requirements

Models include: Data Flow Diagram (DFD) Entity Relationship Diagrams (ERD) State Transition Diagrams (STD) Class Diagrams

Data Flow Diagram (DFD) DFD identifies the transformations processed of a system, the collection (stores) of data or material the system manipulates, and the flows of data or material between the processes, stores and the outside world.

ER Diagram ER Diagrams depict the systems data relationships. In order to represent software requirements, the ERD should represent the logical groups Expressing NFR as User StoriesThe URPS part is a placeholder for organizing the NFRs.Besides NFR we also have design constraints.Functional requirements: Express how the system interacts with its users-its input, its output, and the functions and features it provides. E.g.: display a pop-up on the TV when the utility sends a brownout warning.Non-functional requirements: Criteria used to judge the operations or qualities of a system. E.g.: the system must be available to its users 99.99% of the time.

Risks in IT Projects:

Insufficient user involvement Creeping requirements leading to overrun and degrading productsAmbiguous requirementGold platingMinimal specification leading to missing key requirements.Overlooking the needs of certain user classes causing dissatisfied customersIncompletely defined requirements make accurate project planning and tracking impossible.

As Large number of failed / challenged projects is due to:Poor quality, Over budgeted, Late in schedules, Unmaintainable, Unsatisfied customer

So, we can clearly see the risks and the impact they have on project success

CHAPTER 3

3.1 Analysis of the work done

What is Project Management?Project management is the application of knowledge, skills, tools, and techniques to project activities to meet the Project Requirements. Project management is accomplished through the appropriate application and integration of the 47 logically grouped project management processes, which are categorized into five Process Groups. These fiveProcess Groups are: Initiating, Planning, Executing, Monitoring and Controlling, and ClosingWhat is Project Risk?A risk is any factor that may potentially interfere with successful completion of the project. A risk is not a problem; a risk is the recognition that a problem might occur. By recognizing the potential problems, the project manager can attempt to avoid a problem through proper actions.Risk Management ProcessThe procedure that the team will use to manage the project risks is defined in the planning stage, documented in the project plan, and then executed throughout the life of the project. Risk management deals with the following risk phases: Risk identification Risk analysis and quantification Risk mitigation planning Risk responseThe risk management plan documents the procedures used to manage risk throughout the project. Project risks are identified and carefully managed throughout the life of the project. There are various areas that can affect a project, including: The technology used on the project The environment in which the project is executed Relationships between team members How well the project fits the culture of the enterprise How great a change will result from the projectRisk identification consists of determining risks that are likely to affect the project and documenting the characteristics of those risks. Any potential risks likely to occur must be included in the analysisProjectRiskManagementElementsProjectrisk management includes thefollowing program elements. Each element is important to developing effective project risk management A scalable project risk management process three levels of effort based on the size and complexity of the project Clear communication and accountability checkpoints so that project delivery is seen as one process across multiple functions Incorporation of project risk management into the existing Functional Units guidance Project Delivery Directive and policies for implementationTraining and subject matter experts from Headquarters and Districts

The table below summarises some of questions you can ask in considering potential risks associated with your project and the action you can take to minimise them:Type of riskQuestions to askActions you can take

Financial riskWill the project deliver the savings predicted during scoping? Will the funds requested for the project be sufficient to deliver the project?

Ensure any quotes come from reputable sources. Review a similar project if available and use any monitoring and verification of their projects to inform your own calculations. Conduct sensitivity analysis to account for variability in the assumptions you make about the costs and benefits of your project.

Strategic riskWill the funds be used inappropriately, and hinder the organisations ability to deliver other corporate goals?

Demonstrate how your project links to existing policies and strategies and make sure you follow any processes that are outlined in your organisation.

Operational-technical risk

Does the project involve potential interruptions to normal plant operations?

Consult with the relevant managers and specialist expertise as required.

Operational-safety risk

Will the project involve safety issues?

Most organisations will have an established safety risk assessment protocol that will need to be followed.

3.2. Alternative Solutions and their advantages & disadvantages

For the same I have concluded a table and the justification for the same is given:S.NO.Suggested measures related to ProjectsRelevanceJustification

1Provide appropriate trainingMust For avoid skill lag

2Hire trained specialistsVery importantTo save training costs

3Implement product functionality in a phased mannerImportantUseful for agile dev.

4Negotiate better environmentImportantHelps you earn more

5Suggest/Sell functional specifications before developmentVery importantAvoid scope creep

6Unilaterally develop functional specificationsImportantFor tracing it easily

7Adjust deadline and get buy-offNeutralNot important in every kindof projects

8Do not commit to third party performanceVery important To avoid lock in

9Get customer commitment to participate in the projectVery importantCMMI approves it

10Increase estimates for the related tasksImportantProper estimation leads toBetter development

11Do not commit to response time unless absolutely necessary and only if a study is done by knowledgeable personsVery importantCommitment has to be delivered

12Establish access to product support personnelVery importantWithout support your serviceCan be as good as null

13Divide staff into teams and assign team leadersMustTogether everyone achieves More

14Establish final authority of project managerVery importantSOX mention that Accountability has to be There

15Design an alternate solution strategyMust Strategy should adjust as per Market Trends

3.3. Proposed Solution

The proposed solution is based on the results obtained from the secondary research done by us , I have identified some trends that I will be depicting via some diagrams and figures Note: The survey is filled mostly by industry people and in particular services industryAs we can see the functionality and security is defined the most important factor for any software / service

Also, one of the major causes of a project risk is improper change request approval and as evident in the results of survey also industry people believe that change request have to be approved properly and with proper authentication and authorization, also we have come up with a conclusion that technical, operational, schedule and cost associated risks cannot be taken for granted as they are existing for any kind of projectAnd for the same I have attached a screen shot of the results post that inadequate skills, poor design and changing requirements are the main causes of the many identified causes that affect a project success

So, till now we have analyzed the main factors out of many on which the success or failure of a IT project depends

So, summarizing the results we have the following trends :The clarity of requirements is although a major factor on which the success of a project may depend on but it cannot be considered as the only factor responsibleUse case point should be used as the artifact for turning the user requirements into technical ones but when the requirements are not clear from strating going for analogy based estimaitons can reduce the risksThe process of change request approval should follow the proper segregation of who can approve what and principle of least privilegeSince poor design and inadequate skills are identified as main factors that contribute to the failure of a project hence the employees should be provided appropriate training and assesments to avoid such factorsThe organizations should focus more on the security and functionality aspect of the solution they are developing as its more emphasized than usability and scalability, if we talk about the project associated risks and their impact then cost and technology associated risks in my opinion should be minimized and other risks like external risks and operational risks should be incorporated in the agenda of minimizing risks as they cant be left out and have to be taken into accountAlso, team cohesion or say how well the teams share the responsibility assigned to them has been derived as a proposed solution because if we see the more the teams share the responsibility for a project assigned the more the need of knowledge transfer becomes less and lesser the chances of the project failure

So, the proposed solution here is based on various factors that we have seen and the overall justification lies in the fact that organization need to focuses more on the basic elements discussed above to be more dynamic and have a business model in place that can cater to the changing market and at the same time establish themselves as the strategic player in the market 3.4 Technical justification of the solution

Estimating the effort, time, and resources needed to complete project activities is one of the most challenging tasks that project managers must face. Thus in this paper we give the detail analysis and justification of various estimation techniques.Projects are unique. That is one of the differences between projects and processes. This uniqueness often creates uncertainty. Uncertainty because the activity is unique to the project, or the activity is being accomplished by a resource that is not a practiced expert, or the interaction of this activity with other project activities is unique in this project. All of these can create problems when estimating effort, time or resources. Following are the estimation techniques gien with their advantages and disadvantages.Analogous EstimatingAnalogous Estimating is one of the most common forms of estimating project activities. This technique uses the experience from previous projects and extrapolates that onto the current project. This technique is appropriate for those cases where the type of work is similar and the resources doing the work are the same between projects. Its advantage is that it is quick and, when the conditions are appropriate, it is usually fairly accurate. The disadvantage is that the organization must have similar projects for comparison.

Parametric Model EstimatingParametric Model Estimating is a very accurate and easy estimating technique. A formula is developed for estimating the time or resources needed to perform a project activity. The formula is usually based upon a great deal of historical experience. A PMO will often develop the parametric model based upon having done lessons learned on many projects. A classic example from construction projects is the parametric model for estimating resources and time based upon the number of square feet of new construction. The advantage of parametric model estimating it is quick and accurate. The disadvantage is that models don't exist for activities until there is a large experience base for the activity.

3 Point EstimatingThe 3 Point Estimating technique is used to understand the level of uncertainty embedded within an estimate. In this technique three estimates are generated for the project activity using three different sets of assumptions. The first estimate is a best case or optimistic estimate. The second estimate is a worst case or pessimistic estimate. The third estimate is between the other two and is the most likely estimate. The way those estimates are developed is by using one of the other techniques such as Analogous or Parametric Model. However, because of the high degree of uncertainty due to the risk assumptions, the three estimates are used to create a boundary on expectations for the activity. A variation on this technique, the PERT analysis, uses a weighted average of these estimates to create a PERT estimate. When using this approach, the most likely estimate is normally what is put in the project plan but the optimistic and pessimistic estimates are used during the reserve analysis. Also, an activity that has a great deal of difference between the optimistic and pessimistic estimates is an uncertain activity and should be tracked in the Risk Register. The advantage of this technique is that it provides boundaries on expectations. The disadvantages are that it takes more work - since three estimates must be created not one - and the most likely is still very much a guess - the actual could be significantly better or worse.

Expert Judgment EstimatingExpert Judgment estimating is easy to do - provided you have an expert on the project. This technique looks to the expert to create an estimate based upon their understanding of the project requirements. Many, if not most, project estimates are created in this fashion. The advantage of this is that it is quick and if the expert is knowledgeable, it is often the most accurate estimate for uncertain activities. The disadvantages are that you may not have an expert available and even if you do, the expert often can provide no solid rationale for their estimate beyond, "That's what I think it will take to do this."3.5 Technical environment and technical details

Assessing risk at the project, portfolio, and business levels helps you understand risk, make better decisions, negotiate fair contracts, create risk mitigation scenarios, and improve teamwork. This white paper shows how risk assessments lead to accurate plans that are less likely to lead to budget overruns or delays.

Risk assessment fully discloses the sensitivity of the project to its participants to ensure that all threats are fully understood. As a result, targets and contingencies can be set at correct levels, contracts can be negotiated with an accurate understanding of potential challenges, and risk mitigation strategies can also be created in advance. Risk assessment also improves teamwork by increasing openness, honesty, and understanding within the project team. The benefits of risk assessmentextend beyond a single project.Projects within a portfolio can be understood in terms of their interdependencies, shared resources, and ultimate goals. Projects can also be prioritized according to their risk level so risk can be balanced and managed across the portfolio

3.6 Possible application in the industry

By understanding risk to both individual projects and portfolios, management will be able to make better strategic decisions. Cost commitments, revenue pipelines, and profit forecasts will be accurately stated for each level of risk. The sensitivity of the forecasts will be better understood. When informed by the risk assessment, the entire business will be more profitable

IT project Risk assessment increases profitability. Contracts can be selected and priced at the right level ofRisk and the business can be managed with risk fully understood. Specific risks can be negotiated

In itself, the process of performing a risk assessment can give your project a greater chance ofSuccess.

Assessments lead to the expression of outcomes as ranges, the development of riskMitigation plans, and the ability to set contingency

CHAPTER 4

4.1 Findings

Following are the main findings: Function points estimation techniques is more useful for estimation and hence reducing risks when the project related risks are concerned Use case point although lead to different size estimation but they can be used to convert the user requirements to technical ones and show the interaction of user with the system and show which all functions the user can perform The cost and technical risks and the external risks have the highest impact on a project success or failure Whereas the operational risks have less impact on the projects success The IT software project teams share the responsibility fairly well which leads to lesser risks which may arise due to inappropriate knowledge transfer Resource lag and poor designing skills also play an important role in the project successSo the organizations should have a proper risk assessment plan in place which analyses the potential risks and eliminates them before they can cause any damage to the success of the projectSince the cost of rework is the highest cost that the industry suffers and also we know that more than 50 per cent of the projects fail hence from the above findings its important to connect the dots before its too late for the project to be profitable

4.2 Recommendations

For any project the teams involved should share the responsibilities among them and deliver the artifacts on timeUse case point although lead to different size estimation but they can be used to convert the user requirements to technical ones and show the interaction of user with the system and show which all functions the user can performFor any application or software the security should be kept in first place and then the functionalities and scalability should be thought of For any project the various risks like cost associated risks, technology risks , external risks and operational risks should be considered So we recommend that organizations should:

1. Identify the Risk2. Assess the Risk What would cause this risk? How will this risk impact the project?3. Develop Responses to the Risk What can be done to reduce the likelihood of this risk? What can be done to manage the risk, should it occur? 4. Develop a Contingency Plan or Preventative Measures for the Risk The project team will convert into tasks, those ideas that were identified to reduce or eliminate risk likelihood. Those tasks identified to manage the risk, should it occur, are developed into short contingency plans that can be put aside. Should the risk occur, they can be brought forward and quickly put into action, thereby reducing the need to manage the risk by crisis.

4.3 Conclusion

After discussing all the pros and cons of the factors that affect a projects success we conclude that the solution proposed is feasible and the justification for the same can be given as the project risks arise due to either of the factors discussed above and if appropriate emphasis be given on the vulnerabilities then the risks and associated consequences can be minimizedFor any application or software the functionality and security are most important and which is evident in the survey alsoResource lag and inadequate skills along with poor design and unclear requirements are industry accepted and justified for the current industryFor IT projects the cost and technical risks play a important role as well the external and cost associated risks are importantIt is noticeable thatProject risks can make or break a project. , usethe ranges on the task estimates to understand what contingency should be set for the project asa whole. Setting contingency at the project level reflects the reality that some tasks may bedelayed whereas others may be completed on time or be finished early. The amount ofmanagement reserve can be set by the same principleallowing drawdown against risks thatwere identified at the start of the project.In addition to setting the right, risk assessment also benefits the project teamby giving it a forum for expressing concerns and for challenging or defending assumptions.Removing the restriction of having to work with deterministic (single-point) estimates allowsteam members to give open and honest opinions of what is likely to happen. A risk assessmentworkshop is an importantbut often ignoredoccasion for the project team to come together.It can lead to discussion and clarification of the scope of project tasks, and missing work is oftenidentified. As a result of the workshop, the project team reaches an improved awareness andunderstanding of the status of the whole project.Although the cost and schedule disciplines for aproject are often separate, it is important for these groups to confer with each other. A riskassessment workshop can bring these disciplines togetherCost/benefit analysis can be used to compare IT project risk mitigation strategies and understand how effectively the money would be spent. When the cost of implementing the response is included in the comparison, it can show the net effectof the response on the project cost.The response can then be judged in terms of whether its net effect is to increase cost and whether that increase can be justified by the time it saves. Assessing risk mitigation strategies makes it possible to fully understand their effects.

REFRENCES AND BIBLIOGRAPHY:

http://www.vbhconsulting.com http://www.cioarchives.ca.gov/ITpolicy/pdf/PM3.10_Planning_Risk_Management.pdf http://www.dot.ca.gov/hq/projmgmt/documents/prmhb/PRM_Handbook.pdf http://info.farragut.com/Services-Blog/bid/118703/Top-5-Risks-for-IT-Projects http://www.fanstep.ru/docs/PMBOKGuideFifthEd.pdf http://en.wikipedia.org/wiki/Identifying_and_Managing_Project_Risk http://www.softwaretestinghelp.com/types-of-risks-in-software-projects/ http://eex.gov.au/energy-management/the-business-case-and-beyond/developing-your-business-case-six-strategies/identify-project-risks-and-develop-strategies-to-manage-them/ http://www-public.it-sudparis.eu/~gibson http://www.euroi.ktu.lt http://calleam.com/WTPF/?page_id=1445 http://www.slideshare.net http://www.gartner.com www.google.com www.hbr.com http://webarchive.nationalarchives.gov.uk http://www.pmi.org http://www.pmworldtoday.net www.projectmanagementbooks.com & BABOKV2.0(business analysis body of knowledge)