Information System s Project Planning & Management

Transcription

1 Information System s Project Planning & Management Prof. Zainal A. Hasibuan Panca Hadi Putra Farisya Setiadi Mata Kuliah Program MTI, Fasilkom, Universitas Indonesia Analisis Kebutuhan dan Perancangan Sistem Informasi, Semester Genap, September 2018

2 Learning Outcomes Understand the importance of linking the information systems to business needs. Be able to create a system request. Understand how to assess technical, economic, and organizational feasibility. Be able to perform a feasibility analysis. Understand how projects are selected in some organizations. Become familiar with estimation. Be able to create a project workplan (WBS, Gantt Chart, Pert chart). Understand why project teams use timeboxing. Become familiar with how to staff a project. Understand how computer-aided software engineering, standards, and documentation improve the efficiency of a project.

3 Introduction A project is a set of activities with a specified beginning and end points meant to create a system that brings value to the business. Project management is the process of planning and controlling system development within a specified time at a minimum cost with the right functionality. Inception phase: generate a system request (project charter) based on business need or opportunity. Perform feasibility analysis; revise the system request. Approve or decline the project.

4 Successful Projects Cost Schedule Performance

5 Successful Projects Cost At project completion, no more money has been spent than was originally allocated Schedule The project is delivered no later than the original delivery date Performance When delivered, the project has all features and functionality that were originally required of it

6 Where is your project? Cost Schedule Your project? Performance

7 Why Should We Care? Would you buy a car that only had a 28% chance of driving off the lot with no problems? Data source: The Standish Group Chaos Report as Outlined in IEEE Software Magazine (2005)

8

9 Examples of Significant IS Project Failures Company Year Outcome Hudson Bay (Canada) 2005 Inventory system problems lead to $33.3 million loss. UK Inland Revenue 2004/5 $3.45 billion tax-credit overpayment caused by software errors. Avis Europe PLC (UK) 2004 Enterprise resource planning (ERP) system cancelled after $54.5 million spent. Ford Motor Co Purchasing system abandoned after deployment costing approximately $400 M Hewlett-Packard Co ERP system problems contribute to $160 million loss. AT&T Wireless 2004 Customer relations management system upgrade problems lead to $100M loss Source: Charette, Robert N., Why Software Fails, IEEE Spectrum Online, Sept

10 Project Identification and Initiation Projects are driven by business needs Identified by business people Identified by IT people (better yet) identified jointly by business and IT The project sponsor believes in the system and wants to see it succeed Normally this is a business person Should have the authority to move it forward

11 Business Value Tangible Value Can be quantified and measured easily Example: 2 percent reduction in operating costs Intangible Value Results from an intuitive belief that the system provides important, but hard-to-measure, benefits to the organization Example: improved customer service

12 Elements of a System Request Project sponsor Primary point of contact for the project Business need Reason prompting the project Business requirements Business capabilities the system will need to have Business value Benefits the organization can expect from the project Special issues Anything else that should be considered

13 Feasibility Analysis Guides the organization in determining whether to proceed with a project Is this project feasible? What are the risks? Identify the project s risks that must be addressed if the project is approved Can these risks be overcome? Major components: Technical feasibility (Can we build it?) Economic feasibility (Should we build it?) Organizational feasibility (Will they use it?)

14 Technical Feasibility Familiarity with technology Less familiarity generates more risk Project size Large projects have more risk Compatibility Difficult integration increases the risk Can we build it?

15 Economic Feasibility Identify the costs and the benefits Development costs Annual operating costs Annual benefits (cost savings and revenues) Intangible costs and benefits Determine the cash flow Determine the value using one or more methods: Net present value (NPV) Return on investment (ROI) Break-even point Should we build it?

16 Break-Even Point Illustration Rupiah (in thousand) Benefits Costs Years Break-even point

17 Cost-Benefit Analysis Source: Dennis, Wixom and Tegarden (2015).

18 Cost-Benefit Analysis Source: Dennis, Wixom and Tegarden (2015).

19 Organizational Feasibility Conduct stakeholder analysis Project champion(s) Senior management Users Others Is the project strategically aligned with the business? Will the users accept the system? If we build it, will they use it?

20 Project Selection Projects are approved, declined or delayed based on value added vs. risks Project portfolio management Goals: Maximize cost/benefit ratio Maintain an optimal mix of projects based on: Risk Size, cost & length of time to complete Purpose, scope & business value Limited resources require trade-offs Selected projects enter the project management process

21 Project Selection/Portfolio Matrix High Technical Feasibility How easy is it to build? Bread and Butter White Elephant Pearl Oyster Low Low Adapted from Gray and Larson (2010) Economic Feasibility (ROI Commercial Return) High

22 How Not to Select a Project First in, first out Political clout of project inventor Squeaky wheel getting the grease Any other method that does not involve a deliberate course of action analysis A recent analysis found that between 2% and 15% of projects taken on by IT departments are not strategic to the business.

23 IS Development: Effort Allocation Sarjana Sistem Informasi: dua kelas Anaperancis dan Propensi Master Teknologi Informasi: satu kelas AKPSI AKPSI Waktu ANAPERANCIS PROPENSI Plan Analysis Design Implementation Tahapan

24 IS Development: Effort Allocation Time / Cost Problem Identification Project Initiation Analysis Design Implementation & Evaluation Project Plan Project Presentation Project Execution

25 Methods, Techniques and Instruments in Project Identification Methods Techniques Instruments Observation Direct location visit Check list Interview Questionnaires Face-to-face, telephone, , etc. Personal administration, , etc. List of questions Questionnaire Document search Direct location visit List of documents Sampling Random, purposive, etc. Randomization

26 For technical issues, please consider: Pastikan tempat studi kasus accessible, dan friendly enough untuk menerima tim analyst/developer. Ada letter of acceptance Identifikasi contact person, yang cukup representative untuk studi kasus. Ada no HP, contact person. Diskusikan the dos and the don'ts (apa yang boleh dan apa yang tidak boleh) di studi kasus tersebut. dll.

27 Regarding substance, please consider: Gali strong reasons why the organization needs to develop information systems. Tidak cukup mengatakan, organisasi tersebut masih manual, organisasi tersebut perlu website, dst. Sumber informasi: dari pimpinan, manajer, dan karyawan. Kita membuat sistem informasi, BUKAN membuat software (misalnya, cara menghitung zakat, pajak, premi, dll), BUKAN membuat Website. Usahakan mendapatkan dokumen strategic plan atau organization vision, mission, and objectives, seawal mungkin. Kita ingin memastikan ada tujuan organisasi yang hendak dicapai. In case you cannot find it, anda bisa mendiskusikan dengan santun kepada klien(pimpinan). Kembalikan ke definisi sistem informasi: interaksi berbagai elemen utk mencapai tujuan organisasi. Pastikan anda mendapatkan informasi seoptimal mungkin mengenai elemen-elemen tersebut (teknik, metode, proses, prosedur, tools, orang, dll). Identifikasi, tertulis maupun tidak tertulis, business processes, data, values, dll yang mungkin ada di organisasi tersebut (observasi, interview, kuesioner, dll).

28 Questions/issues in problem identification Top Management Masalah dream, vision, business plan Masalah competitor, new entrance, supplier, customer, substitute product Masalah innovasi produk, layanan, dll. Middle Management Masalah manajerial Masalah line of businesses dan internal value chain Masalah business processes Masalah data, dll. Employee Kemudahan bekerja Produktivitas, dll

29 Why Projects Fail Image Credit: University of London Computer Center Newsletter

30 Project Management Tools Aids in creating workplans Identify all tasks, their sequence and estimate the time to complete each one Work breakdown structures (WBS): a hierarchy of tasks to identify: Duration of each task Current status of each task Task dependencies (shows which tasks must be completed before others can begin) Gantt charts: horizontal bar chart that shows the WBS graphically Network diagrams: PERT and CPM

31 Project Effort Estimation Estimation involves trade-offs between functionality, time and cost It is the process of assigning projected values for time and effort Most accurate estimates come from experience Use-case point method; based on: Technical complexity factors (13) Environmental factors (8) Function point approach: Function points à person-months à months

32 Use Case Point Estimation: Actors and Use Cases Note: Use case point estimation method is based on Karner (1993). See the original paper on SCELE.

33 Use Case Point Estimation: Technical Complexity

34 Use Case Point Estimation: Environmental Factors

35 Use Case Point Estimation: Final estimate Note: We have made the above UCP calculator available for public use. You may download it on SCELE.

36 Creating & Managing the Workplan Workplan: a dynamic and sequential list of all tasks needed to complete a project Created after a project manager has a general idea of the project s size and rough schedule The work plan is usually the main item in a project management software application Approaches: Modify existing or completed projects Derive the tasks from the methodology being used

37 Sample Task Task name: Perform economic feasibility Start date: Jan 5, 2010 Completion date: Jan 19, 2010 Person assigned to the task: Mary Smith Deliverable(s): Cost-benefit analysis Completion status: Complete Priority: High Resources needed: Spreadsheet software Estimated time: 16 hours Actual time: 14.5 hours

38 Work Breakdown Structure Source: Dennis, Wixom and Tegarden (2015).

39 Gantt Chart Source: Dennis, Wixom and Tegarden (2015).

40 Pert Chart Used to communicate task dependencies Allows easier visualization of tasks on a critical path Source: Dennis, Wixom and Tegarden (2015).

41 Scope Management Scope creep Occurs after the project is underway Results from adding new requirements to the project Can have a deleterious effect on the schedule Techniques to manage the project scope: Identify all requirements at the outset Allow only those changes deemed absolutely necessary Carefully examine the impact of suggested changes Delay some changes for future enhancements Time boxing

42 Timeboxing Steps 1. Set the date for system delivery 2. Prioritize the functionality that needs to be included in the system 3. Build the core of the system (the functionality ranked as most important) 4. Postpone functionality that cannot be provided within the time frame 5. Deliver the system with core functionality 6. Repeat steps 3 through 5 to add refinements and enhancements

43 Staffing the Project Goals: Determine how many people are required Match skill sets to required activities Motivate the team to meet the objectives Minimize conflicts Deliverable The staffing plan, which includes: Number & kind of people assigned Overall reporting structure

44 The Staffing Plan Calculate the number of people needed: Lines of communication increase exponentially as people are added to a project Create a reporting structure for projects with large numbers of people assigned Form sub-teams as necessary Assign the Project Manager, Functional lead & Technical lead Pay attention to technical and interpersonal skills

45 Reporting Structures Project Manager Functional Lead Technical Lead Analyst Analyst Programmer Programmer

46 Avoid the this classic mistake: Brook s Law: Adding manpower to a late software project makes it later

47 Motivating People Motivation is the greatest influence on performance Monetary rewards usually do not motivate Suggested motivating techniques: 20% time rule Peer-to-peer recognition awards Team ownership (refer to the team as we ) Allow members to focus on what interests them Utilize equitable compensation Encourage group ownership Provide for autonomy, but trust the team to deliver

48 Handling Conflict Preventing or mitigating conflict: Cohesiveness has the greatest effect Clearly defining roles and holding team members accountable Establish work & communications rules in the project charter Additional techniques: Clearly define plans for the project Make sure the team understands the importance of the project Develop detailed operating procedures Develop a project charter Develop a schedule of commitments in advance Forecast other priorities and their impact on the project

49 Environment & Infrastructure Management Environment Choose the right set of tools Use appropriate CASE tools to: Increase productivity and centralize information (repository) Utilize diagrams more easily understood Establish standards to reduce complexity Infrastructure Document the project appropriately Store deliverables & communications in a project binder Use Unified Process standard documents Don t put off documentation to the last minute

50 Choice of CASE Tools that Support UML See:

51 Standards Types of Standards Documentation standards Coding standards Procedural standards Specification requirement standards User interface design standards Example The date and project name should appear as a header on all documentation. All modules of code should include a header that lists the programmer, last date of update, and a short description of the purpose of the code. Report to project update meeting on Fridays at 3:30 PM. All changes to a requirements document must be approved by the project manager. Name of program to be created Description of the program s purpose The tab order of the screen will move from top left to bottom right. Accelerator keys will be provided for all updatable fields.

52 Documentation Good documentation happens up front Documentation that occurs only at the tail end of a project/ phase is not very useful Project binder(s) are best practices containing All internal communications (e.g. minutes from status meetings) Written standards Letters to and from the business users Deliverables from each task

53 Any questions?