1 2. project management
- 1. ASSISTANT PROFESSOR LPU, PUNJAB Software Project Management
- 2. Till far we have studied What’s a project? What makes software projects different Project Perspectives Software Management Basics
- 3. 1.1 What is a Project? Project is a temporary endeavor undertaken to create a unique product or service. Project is a well defined set of tasks or activities that must be completed in order to meet the project’s goal. Non routine tasks : Planning reqd. Sp. Objective to be met/ sp. Products to be created Predetermined time span Work is done for others Work is carried out in several phases Resource constraints Projects could be large and/or complex
- 4. 1.2 Project vs Programme Project is a nonrepetitive set of activities leading to singular product or service and gets over in a limited / finite time frame Great wall of China Suez Canal Taj Mahal Programme is a repetitive array of activities carried out on a longer/ indefinite time frame to accomplish many no of similar / dissimilar projects Identify : project or programme ???? putting a robot vehicle on Mars to search for sign of life Writing an operating system
- 5. 1.3 Project Success or Failure A project success is usually measured in terms of whether it is completed within specified time and under stipulated budget If it exceeds uncontrollably it is termed as a failure. However there is more to a project’s success than just its completion within time and budget Meeting customer specifications Degree of customer satisfactions Level of success in the market place Result in greater revenue and profits
- 6. 1.4 Software project vs other project Invisibility, A bridge or road can actually be seen. With software, progress is not immediately visible. Complexity, Per dollar, pound or euro spent, software products contain more complexity than other engineered artefacts. Conformity, Software developers have to conform to the requirements of human clients Flexibility, The ease with which software can be changed is usually seen as one of its strengths.
- 7. 1.5 Type of Software System Software Real time Software Business Software Engg. N scientific Software Embedded Software PC based Software Web based Software AI based Software Open source Software
- 8. 1.6 Problem with software project poor estimates and plans; lack of quality standards and measures; lack of guidance about making organizational decisions; lack of techniques to make progress visible; poor role definition – who does what? incorrect success criteria.
- 9. 1.7 Why Projects need to be Managed ? Because resources are limited Because project has to be delivered within time and budget Therefore in order to maximise output (with regard to project delivery) with the limited input resource , managerial attention is needed.
- 10. 1.8 Project Management (Defn.) PMI defines Project Management as the “Art of directing and coordinating human and material resources through out the life of a project by using modern management techniques to achieve predetermined objectives of scope, cost, time, quality and participant satisfaction
- 11. 1.9 Activities in Software Project Management There are four broad phases in any project life cycle Preplanning--- Conceptualization, Formulation and Selection (Project feasibility study, Project Scoping) Planning--- Task definition and break ups, resource estimation Scheduling and Control--- Resource allocation, task execution, feedback and review Implementation and Termination--- Project completion, closure and hand over.
- 13. 1.10 Step Wise Project planning 1. Identify project objectives 2. Identify project infrastructure 3. Analyse project characteristics 4. Identify products and activities 5. Estimate effort for activity 8. Review/ publicize plan 6. Identify activity risks 7. Allocate resources 9. Execute plan 10. Lower level planning Review Lower level detail For each activity 0.Select project
- 14. A project scenario LPU Shopping mall Project Where to setup .. Which brand Facilities Stakeholders Virtual money
- 15. Step 1 establish project scope and objectives 1.1 Identify objectives and measures of effectiveness ‘ how do we know if we have succeeded?’ 1.2 Establish a project authority ‘ who is the boss?’ 1.3 Identify all stakeholders in the project and their interests ‘ who will be affected/involved in the project?’ 1.4 Modify objectives in the light of stakeholder analysis ‘ do we need to do things to win over stakeholders?’ 1.5 Establish methods of communication with all parties ‘ how do we keep in contact?’
- 16. Step 2 Establish project infrastructure 2.1 Establish link between project and any strategic plan ‘ why did they want the project?’ 2.2 Identify installation standards and procedures ‘ what standards do we have to follow?’ Software life cycle?? 2.3. Identify project team organization ‘ where do I fit in?’
- 17. Step 3 Analysis of project characteristics 3.1 Distinguish the project as either objective or product-based. Is there more than one way of achieving success? 3.2 Analyse other project characteristics (including quality based ones) what is different about this project? Identify high level project risks ‘ what could go wrong?’ ‘ what can we do to stop it?’ Take into account user requirements concerning implementation Select development methodology and life cycle approach waterfall? Increments? Prototypes? Review overall resource estimates ‘ does all this increase the cost?’
- 18. Step 4 Identify project products and activities 4.1 Identify and describe project products - ‘what do we have to produce?’ What will be the deliverables
- 19. Products The result of an activity Could be (among other things) physical thing (‘installed pc’), a document (‘logical data structure’) a person (‘trained user’) a new version of an old product (‘updated software’) The following are NOT normally products: activities (e.g. ‘training’, design, testing ) events (e.g. ‘interviews completed’) Products CAN BE deliverable or intermediate
- 20. Product breakdown structure(PBS) Main product have sets of component products Product are grouped into those relating to the system as whole and those related to individual module. Project Products System Project Module Products Management Projects Progress Report Module Code Module Design doc Tested integrated software Overall specification
- 21. Product description (PD) Product name/identity Description - what is it? Derivation - what is it based on? Composition - what does it contain? Format: form of the product Relevant standards Quality criteria PDs can usually be re-used from one project to another.
- 22. Step 4 continued 4.2 Document Generic Product flows Need of other product to exit first before their creation Product flow diagram (PFD) Shows the order in which the products have to be completed. Defines a method of working User Requirement Overall system Specification Module design Integrated system test case Module code Integrated software
- 23. Step 4.3 Recognize product instances The project breakdown structure (PBS ) and Project flow diagram (PFD) will probably have identified generic products e.g. ‘software modules’ It might be possible to identify specific instances e.g. ‘module A’, ‘module B’ … But in many cases this will have to be left to later, more detailed, planning
- 24. 4.4. Produce ideal activity network Identify the activities needed to create each product in the PFD More than one activity might be needed to create a single product Draw up activity network
- 25. An ‘ideal’ activity Specify overall system Design Module A Design Integration Test case Design Module B Code module A Test Integration software Code module B
- 26. Step 4.5 Add check-points if needed Design module A Design module B Design system Design module C Code module A Code module B Code module C Test system Design module A Design module B Design system Design module C Code module A Code module B Code module C Test system Check-point put in a check point
- 27. Step 5:Estimate effort for each activity 5.1 Carry out bottom-up estimates Estimation of staff effort required distinguish carefully between effort and elapsed time Effort : Total number of staff-hours (or days etc) needed to complete a task Elapsed: time between the start and end of the task. 5.2. Revise plan to create controllable activities break up very long activities into a series of smaller ones as we cant judge the status in long activities bundle up very short activities (create check lists)
- 28. Step 6: Identify activity risks 6.1.Identify and quantify risks for activities damage if risk occurs (measure in time lost or money) likelihood if risk occurring Identify the assumptions : client requirement is clear 6.2. Plan risk reduction and contingency measures risk reduction: activity to stop risk occurring contingency: action if risk does occur Eg : contracting staff
- 29. 6.3 Adjust overall plans and estimates to take account of risks e.g. add new activities which reduce risks associated with other activities e.g. training, pilot trials, information gathering
- 30. Step 7: Allocate resources 7.1 Identify and allocate resources to activities Eg staff need for each activities 7.2 Revise plans and estimates to take into account resource constraints More than one task assigned to staff e.g. staff not being available until a later date non-project activities
- 31. Gantt charts Select subjects Design questionnaire Book machine Conduct tests Analyse results Week commencing 5 12 19 26 MARCH APRIL 9 16 Plan testing 2 Draft changes LT TA LT TA LT LT TA LT = lead tester TA = testing assistant
- 32. Step 8: Review/publicise plan 8.1 Review quality aspects of project plan Each task should have quality criteria Quality check has to be passed 8.2 Document plan and obtain agreement Proper documentation Agreement of all parties Step 9 and 10: Execute plan and create lower level plans
- 33. Step 9 &10: Execute plan/ low level of planning Make provisional plan for distant task Execute plan
- 34. Step Wise Project planning 1. Identify project objectives 2. Identify project infrastructure 3. Analyse project characteristics 4. Identify products and activities 5. Estimate effort for activity 8. Review/ publicize plan 6. Identify activity risks 7. Allocate resources 9. Execute plan 10. Lower level planning Review Lower level detail For each activity 0.Select project
- 35. Draw up a product breakdown structure of a computer.
- 36. a product breakdown structure of a computer.
- 37. EXAMPLE There is a garden shed in a garden. The project is to dismantle the shed and reassemble it in the garden of a close neighbour. The shed has some rotten pieces. When the shed has been dismantled, these rotten pieces must be identified and replacements ordered from the company that supplied the original shed. New fixtures and fittings (screws, nuts and bolts, glue etc.) for all pieces will be needed, so a list of the requirements is to be made as the shed is dismantled. The neighbour has said that he will prepare the site for the shed’s new location as part of his own, separate project.
- 38. product breakdown structure of the ‘old shed’
- 39. Product Flow Diagram
- 40. Develop a project planning for Course Scheduling System in LPU . Proposed Plan Course scheduling software is meant to create a schedule for courses in a department, given the preferences of professors and the information on available rooms and timeslots for courses
Editor's Notes
- #19: Here we follow the PRINCE approach of firstly identifying the products to be created. These products could be deliverables that will eventually be handed over to the customer, or intermediate products such as specifications and design documents, that are produced along the way. The PBS is a way of listing these products. In the scenario, the need for usability testing was identified, and the example of planning a usability test is used here. In order to do the testing, we need a set of selected subjects , a group of people who have similar characteristics to those who will finally use the system and who have agreed to try out the application. We need to have a booked PC that is available for testing when we need it. We are going to give each subject a questionnaire to complete when they have tried out the application ( completed questionnaire ), but we will need to have a questionnaire design first. We are also to observe the subjects using the application and collect details of things like the time taken to complete standard tasks and the errors they make ( test results ). These will then be analysed and the results put in an analysis report which will then be used to suggest changes to the application ( change requests ). All the boxes in the diagram which are not sub-divided at a lower level represent products. Boxes that are sub-divided (i.e. usability testing and testing arrangements ) are names given to the group of activities that are connected to them lower in the hierarchy.
- #22: The names of products on the PBS can be rather vague. If you were to ask someone to produce, for example, the ‘analysis report’ in the usability testing scenario, then you would need to explain exactly what you mean by that. This is done via a Product Description. PDs can usually be re-used from one project to another. Note that they are different from specifications – the explain in general terms what a product is and the description is relevant to all instances of that product. A specification describes a particular instance within the class of products.
- #23: The product flow diagram shows the order in which the products have to be completed. Effectively it defines a method of working. Note that as we drew up the PFD for the usability testing scenario, we identified an additional product called ‘testing plan’. The flow of the PFD is generally from top to bottom and left to right. We do no put in lines which loop back. This is not because iterative and back-tracking is not accepted. Rather it is that you can in theory jump back to any preceding product. For example, when producing the analysis report we might realise that there is a particular type of user that we have not included in our tests. We could go back and find some more selected subjects . However this would potentially mean that all the products that follow the one we have jumped back to would have to be reworked.
- #31: You now need to allocate resources (in particular, staff) to the activities in the plan. Where there is a resource constraint, that is there are not enough staff (or other resource) of the right type to start all the activities that run in parallel at the planned time, then the start of some activities may need to be delayed until the appropriate resources are available.
- #32: We now have the basic information needed to produce a plan. One way of presenting the plan is by means of a Gantt chart (named after Henry Gantt).
- #33: We have noted already that it is not feasible to produce a detailed plan for all stages of the project right at the beginning of the project planning process and not all the information needed for the detailed planning of the later stages is available at the outset. Initially an outline plan for the whole project would be produced, plus a detailed plan for the first stage.