1. 1 / 48 ©Jozef De Man 2008-2009 Managing a small Software Project A quick Guide ed 2 Managing a small Software Project A quick Guide Prof. Dr. ir J. De Man

2. 2 / 48 ©Jozef De Man 2008-2009 Managing a small Software Project A quick Guide ed 2 Introduction This is a quick guide to project management for small sofware projects. It is a light-weight interpretation of general project management practices tailored to the specific needs of software projects. This is an adaptation of the Capability Maturity Model Integration (CMMI) for Development edition 1.2. http://www.sei.cmu.edu/cmmi/ Software development is not only a technical activity requiring technical skills but also a business activity requiring (project) management skills

3. 3 / 48 ©Jozef De Man 2008-2009 Managing a small Software Project A quick Guide ed 2 Content  A few words about: n Process Model – CMMI n Development Model – Agile  What is a project?  Process Areas n Measurements n Requirements Management n Project Planning / Monitoring and Control n Quality Assurance n Configuration Management n Risk Management n Process Improvement

4. 4 / 48 ©Jozef De Man 2008-2009 Managing a small Software Project A quick Guide ed 2 CMMI Staged Representation 5 Maturity Levels 2 Managed Projects have Disciplined Process 3 Defined Organizational Standard Process 4 Quantitatively Managed Measured, Predictable Process 5 Optimizing Continuously Improving Process A Maturity Level is assigned to an organization and is an evolutionary plateau in process maturity Practices at a lower level must be established to enable practices at a higher level to be efficient and effective http://www.sei.cmu.edu/cmmi 1 Initial Ad hoc Chaotic

5. 5 / 48 ©Jozef De Man 2008-2009 Managing a small Software Project A quick Guide ed 2 CMMI Process Areas by Maturity Level (Staged) Requirements Management* Project Planning* Project Monitoring and Control* Supplier Agreement Management Measurement and Analysis Process and Product Quality Assurance* Configuration Management* 2 Requirements Development Technical Solution Product Integration Verification Validation Organizational Process Focus* Organizational Process Definition + IPPD Organizational Training Integrated Project Management + IPPD Risk Management* Decision Analysis and Resolution 3 Organizational Process Performance Quantitative Project Management 4 Organizational Innovation and Deployment Causal Analysis and Resolution 5 Process Areas at lower level must be addressed before Process Areas at higher levels IPPD = Integrated Product and Process Development *Process Areas addressed in this guide

6. 6 / 48 ©Jozef De Man 2008-2009 Managing a small Software Project A quick Guide ed 2 CMMI Generic Goals and Practices Generic Practices to be applied to EACH process area n GP2.1 Establish an organizational policy n GP2.2 Plan the process n GP2.3 Provide resources n GP2.4 Assign Responsibility n GP2.5 Train people n GP2.6 Manage Configurations n GP2.7 Identify and involve relevant stakeholders n GP2.8 Monitor and control the process n GP2.9 Objectively evaluate adherence n GP2.10 Review status with higher level management Stakeholder = individual or group affected by or accountable for the outcome of an activity Policy = guiding principle, typically established by higher management

7. 7 / 48 ©Jozef De Man 2008-2009 Managing a small Software Project A quick Guide ed 2 http://agilemanifesto.org/ Manifesto for Agile Software Development We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value: Individuals and interactions over processes and tools Working software over comprehensive documentation Customer collaboration over contract negotiation Responding to change over following a plan That is, while there is value in the items on the right, we value the items on the left more. Kent Beck Mike Beedle Arie van Bennekum Alistair Cockburn Ward Cunningham Martin Fowler James Grenning Jim Highsmith Andrew Hunt Ron Jeffries Jon Kern Brian Marick Robert C. Martin Steve Mellor Ken Schwaber Jeff Sutherland Dave Thomas We still value the items on the right

8. 8 / 48 ©Jozef De Man 2008-2009 Managing a small Software Project A quick Guide ed 2 What is a Project?  Delivers one or more products/services to a customer  Has a definite beginning and end  Involves interacting resources (people, tools, material)  Typically operates according to a plan, specifying n The product(s) to be delivered n The work to be done n The required resources and funds n The schedule for doing the work

9. 9 / 48 ©Jozef De Man 2008-2009 Managing a small Software Project A quick Guide ed 2 Project Basic Decision Gates Start Gate  Commit Gate  End Gate  PlanningExecution Develop Business Case Vision Statement Define Requirements Manage Risks Develop initial plan Commit Adequate Resources Is there a business case with acceptable risk to continue with the project? Is the product ready for delivery to the customer? InitiationClosure

10. 10 / 48 ©Jozef De Man 2008-2009 Managing a small Software Project A quick Guide ed 2 Four essential Dimensions Scope Cost Schedule Quality Functional Requirements Non-Functional Requirements What is the order of priority? What are the targets? Which dimensions are fixed? Which dimensions can be renegotiated during the project?

11. 11 / 48 ©Jozef De Man 2008-2009 Managing a small Software Project A quick Guide ed 2 Measurement and Analysis Global Performance  Priorities along schedule, cost, scope and quality are based on business objectives defined by higher management  Metrics must be defined to quantitatively express performance along these four dimensions (key performance indicators), e.g. n Schedule overrun = actual duration – planned duration  Margins must be defined within which the project must be managed, e.g. n Schedule adherence < 1 week  Estimates of the key performance indicators (KPIs) are maintained during the project and higher management must be asked to intervene if the project is estimated to go beyond one of the margins

12. 12 / 48 ©Jozef De Man 2008-2009 Managing a small Software Project A quick Guide ed 2 Measurements Quality  Also non-functional requirements of the product must be documented and expressed quantitatively  Examples: n Coverage of test cases in terms of features and code n Number of test case executed and passed n Number of known, unresolved defects in the product  Performance against quality targets is an aspects determining readiness for delivery of the product to the customer

13. 13 / 48 ©Jozef De Man 2008-2009 Managing a small Software Project A quick Guide ed 2 Measurements KPI Examples  Schedule Overrun n Actual duration – Planned duration  Budget Overrun n Actual effort spent – Original budgeted effort  Feature Churn n # features added/deleted during execution  Quality n # test cases passed successfully / # test cases planned

14. 14 / 48 ©Jozef De Man 2008-2009 Managing a small Software Project A quick Guide ed 2 Measurement Practical Guide  Derive metrics from goals n Identify goals of the project n Identify simple metrics to quantify the goals n Define mechanisms to collect/report measurements n Do it  Remember n Metrics must be useful n Keep it simple

15. 15 / 48 ©Jozef De Man 2008-2009 Managing a small Software Project A quick Guide ed 2 Requirements Types  Functional requirements n Describe the functionality of the system n Typically expressed in terms of nouns and verbs  Non-functional requirements n Describe properties of the system and its actions n Typically expressed in terms of adjectives n Include the “-ilities” of the system  Constraints n Are externally imposed and cannot be negotiated, e.g. legal obligations

16. 16 / 48 ©Jozef De Man 2008-2009 Managing a small Software Project A quick Guide ed 2 Requirements Activities Elicitation - identify sources of requirements and obtain requirements Documentation - write down the requirements in a way that is understandable for all stakeholders Negotiation - reconcile conflicting interests of stakeholders Classification - identify (hierarchical) relationships, taxonomy, traceability, priority,… Analysis - understand the requirements, identify possible conflicts, overlaps, ambiguities Allocation - to components of the product/solution Modeling - abstract representation supporting formal analysis

17. 17 / 48 ©Jozef De Man 2008-2009 Managing a small Software Project A quick Guide ed 2 Requirements Documentation Hierarchy/Granularity  Vision - One page general description of the objectives and scope to provide a common direction to the entire team  Feature/Requirements List - Index with one sentence for each requirement to serve as a basis for classification  Requirements Specification - detailed specification of each requirement (e.g. detailed specification of protocols)

18. 18 / 48 ©Jozef De Man 2008-2009 Managing a small Software Project A quick Guide ed 2 Requirements Documentation Features  The definition of the product must be broken down in “features”  Features are more or less independent characteristics of the product  It must be possible to implement features incrementally n To develop value as quickly as possible n To enable tracking of progress n To enable renegotiation of scope during project

19. 19 / 48 ©Jozef De Man 2008-2009 Managing a small Software Project A quick Guide ed 2 Requirements Documentation Feature List  Features are documented in a Feature List which is maintained during the course of the project  The initial Feature List documents the “target” for scope  A Feature List involves for each feature n Name n Description n Cost Estimate (rough estimate - high,medium,low) n Customer Value Estimate (need-to-have, nice-to-have) n Risk level (level of uncertainty of feasibility/cost) n Dependencies on other features n Project increment/iteration

20. 20 / 48 ©Jozef De Man 2008-2009 Managing a small Software Project A quick Guide ed 2 Requirements Management Traceability  Establish a simple mechanism to maintain traceability from requirement to implementation  Examples n Features > Code Modules n Features > Test Cases n Bug reports > affected items  The goal is to answer questions like n What is the test coverage of a feature? n Is a feature completely implemented? n Have all corrections associated with a bug report been implemented?

21. 21 / 48 ©Jozef De Man 2008-2009 Managing a small Software Project A quick Guide ed 2 Project Planning Assign Responsibility  Project Manager  But also n Requirements/Feature Manager n Development Manager, Test Manager n Build / Configuration Manager n Quality Manager n Process Improvement Manager n Risk Manager n Measurements Manager Notes Several roles can be performed by one person Roles must be assigned early in the planning phase

22. 22 / 48 ©Jozef De Man 2008-2009 Managing a small Software Project A quick Guide ed 2 Project Planning Iterations  The execution of a project happens in iterations/increments  Essential characteristics of each iteration n Period (duration) n Available Resources n Features to be implemented Start Gate  Commit Gate  End Gate  PlanningExecution Iteration 1  Iteration 3  Iteration 2  ……….

23. 23 / 48 ©Jozef De Man 2008-2009 Managing a small Software Project A quick Guide ed 2 Project Planning Identify Activities / Work Products  Consider mainstream n Requirements, feature lists, design artefacts, code modules, test cases, …  But also supporting functions n Build / Configuration Management of code and documents n Risk Management n Planning and Monitoring n Requirements Management n Measurement and Analysis n Quality Assurance of Product and Process n Process Improvement / Definition n Training

24. 24 / 48 ©Jozef De Man 2008-2009 Managing a small Software Project A quick Guide ed 2 Project Planning Identify attributes of activities / work products A few examples:  Reviews n Duration n Number of participants n Frequency n “Size” – number of slides in presentation  SW Build n Effort n Duration n Frequency n Required resources

25. 25 / 48 ©Jozef De Man 2008-2009 Managing a small Software Project A quick Guide ed 2 Project Planning Estimate attribute values and cost  For example for reviews n Duration1 hour n Number of participants5 n Frequencymonthly n Number of slides in presentation 20  Derive estimated of required effort n Effort spent in meeting + preparation  Notes: n Estimates tend to be more accurate if “objective” attributes are identified first and required effort is derived based on attribute values n Accuracy of initial estimates may be low

26. 26 / 48 ©Jozef De Man 2008-2009 Managing a small Software Project A quick Guide ed 2 Project Planning Scheduling  Consider for the first increment n Available effort budget n Estimated period n Effort for supporting functions  And determine the features to be implemented in the first iteration based on n Customer value, estimated cost, risk  Negotiate and obtain commitment on resources based on n Project Requirements n Available skills n Personal interest

27. 27 / 48 ©Jozef De Man 2008-2009 Managing a small Software Project A quick Guide ed 2 Project Monitoring and Control Monitoring  Monitoring the project involves n Keeping people aware of their commitments n Verifying actual performance against plan n Adapting the plan as required n Improving the way of working based on experience gained in the project (and previous projects)  To enable this, it is essential that mechanism are established to monitor actual performance versus the original plan

28. 28 / 48 ©Jozef De Man 2008-2009 Managing a small Software Project A quick Guide ed 2 Project Monitoring and Control Corrective Actions  Monitor performance at the level of the attribute values  E.g. for project reviews n Actual duration, frequency, number of participants, size  If actual performance deviates from the plan it is now possible to take corrective action at the process level and adjust either the plan or actual performance at the attribute level  You can propose changes in the attribute values and get accurate estimates for the impact on performance assuming the other values will not change, e.g. n Change frequency, content, duration, # of participants

29. 29 / 48 ©Jozef De Man 2008-2009 Managing a small Software Project A quick Guide ed 2 Project Monitoring and Control Project Review/Meetings Types  Decision Reviews at Decision Gates to decide n Go / No Go for project at Commit Gate n Delivery of product at End Gate  Iteration Reviews between iterations to accept end of previous iteration and decide to start the next iteration  Kick-off meetings with the entire team at the beginning of the project or an iteration  Periodic Meetings n Team meetings n Progress reviews at project level n Reviews with higher Management / External Stakeholders

30. 30 / 48 ©Jozef De Man 2008-2009 Managing a small Software Project A quick Guide ed 2 Project Monitoring and Control – Decision Gates Commit Gate Checklist - sample n Feature List available? n Risk repository available, risks analyzed and risk handling actions planned? n Targets established for features, quality, schedule and budget? n Are the “boundary conditions” for the project team established? n Initial Plan available Responsibilities Activities / Work Products, their attributes and estimates Schedule Allocation of resources to activities / work products committed n Are the risks acceptable to proceed?

31. 31 / 48 ©Jozef De Man 2008-2009 Managing a small Software Project A quick Guide ed 2 Project Monitoring and Control - Decision Gates End Gate Checklist - sample n Are all committed features implemented? n Does the product meet its quality targets? n Is the business case still valid? n Are all legal and regulatory issues resolved? n Are plans and resources in place to support the product? n Are the risks acceptable to deliver the product to the customer?

32. 32 / 48 ©Jozef De Man 2008-2009 Managing a small Software Project A quick Guide ed 2 Project Monitoring and Control Iteration Reviews  Goals n Verification committed targets have been met n Risk (re-)assessment n Lessons-learned: what did we do well? What can be improved? n Keep focus  At iteration reviews n Process changes can be introduced n The Feature List can be updated n The project plan is revised

33. 33 / 48 ©Jozef De Man 2008-2009 Managing a small Software Project A quick Guide ed 2 Project Monitoring and Control Project/Iteration Kick-Off  Goals n Re-enforce a common vision n Higher management to demonstrate its commitment to the project  Entire project team and higher management are invited  Project Management presents n Vision n Features n Quality targets n Schedule n The process to be followed

34. 34 / 48 ©Jozef De Man 2008-2009 Managing a small Software Project A quick Guide ed 2 Project Monitoring and Control Project/Team Meetings  Goals n Review progress n Identify issues and take action to resolve them n Decide on escalation of issues if required  Format n Weekly meetings with project team to review overall progress n Daily Team meetings (Scrum meetings) for fast direct communication and avoid delays associated with email

35. 35 / 48 ©Jozef De Man 2008-2009 Managing a small Software Project A quick Guide ed 2 Project Monitoring and Control Management Reviews  Goal n Provide higher management visibility on project progress n Obtain commitment for actions that are beyond the responsibility of the project team  Typical content n Key features n Latest estimate of project in terms of schedule, cost, scope and quality n Main achievements n Issues that require higher management attention n Next steps

36. 36 / 48 ©Jozef De Man 2008-2009 Managing a small Software Project A quick Guide ed 2 Project Monitoring and Control Data Management - Establish a Project Portal  It is important that all members of the project have instant access to the latest edition of data relevant to the project n Feature List n Risk List n Action Points n Planning / tracking n Meeting minutes n …  A “Project Portal” must therefore be established to manage project data and support efficient communication  The portal must also refer to the Process Assets Library of the project

37. 37 / 48 ©Jozef De Man 2008-2009 Managing a small Software Project A quick Guide ed 2 Quality Assurance Product and Process  Product Quality Assurance n Actions to ensure and verify that the quality requirements of the product are satisfied n These actions are typically performed as part of the “mainstream” project: document reviews, testing activities at various levels.  Process Quality Assurance n Actions to ensure and verify objectively that actions for product quality assurance are executed as planned and effective n These actions are typically performed by a separate Quality function to ensure objectivity

38. 38 / 48 ©Jozef De Man 2008-2009 Managing a small Software Project A quick Guide ed 2 Quality Assurance Quality Manager Role  Ensure that the Project Manager not only considers schedule and content but also quality  Monitors whether the process (agreements made in the project) is followed and analyzes deviations  Coaches project members in the process  Considers adjustments of the process if required  Report quality issues to senior management

39. 39 / 48 ©Jozef De Man 2008-2009 Managing a small Software Project A quick Guide ed 2 Configuration Management Overview  Configuration Management involves n Identification of items to be placed under CM n Establishing a repository for items (code, test cases, requirements, technical and project documents,..) n Ensuring the most current version of each item is available n Managing changes to items in an efficient and controlled fashion n Audit integrity of the configurations, e.g. have all approved changes been implemented?

40. 40 / 48 ©Jozef De Man 2008-2009 Managing a small Software Project A quick Guide ed 2 Risk Management Uncertainty  A project faces many uncertainties n Feasibility of implementation n Volatility of the requirements n Accuracy of effort estimates n Availability of resources n Dependencies on external partners n ….  A risk is a potential problem that has not yet turned into an actual problem  Risk Management deals with risks and not with problems

41. 41 / 48 ©Jozef De Man 2008-2009 Managing a small Software Project A quick Guide ed 2 Risk Management Purpose  Before Commit Gate n Identify risks n Plan risk handling actions n Plan for risk reduction during the execution of the project E.g. implement high-risk features first n Establish adequate visibility on risk as input for decision  During Execution n Monitor risks and re-assess periodically n Monitor and replan mitigation actions as required n Take corrective actions if risks materialize as problems

42. 42 / 48 ©Jozef De Man 2008-2009 Managing a small Software Project A quick Guide ed 2 Risk Management Risk Register  Risks and related attributes are maintained in a risk register  Risk Attributes n Likelihood of occurrence n Number of occurrences (optional) n Impact/cost of occurrence n Cost/Impact of actions  Risk ranking is used to select type of action

43. 43 / 48 ©Jozef De Man 2008-2009 Managing a small Software Project A quick Guide ed 2 Risk Management Risk Statement  A well-written risk statement facilitates risk management  It typically contains two components: n A condition n An undesirable effect cause by that condition  To be a risk, the condition must not yet be satisfied, otherwise it is a problem

44. 44 / 48 ©Jozef De Man 2008-2009 Managing a small Software Project A quick Guide ed 2 Risk Management Actions  Avoidance n Take action to reduce the likelihood that the risk materializes  Mitigation n Take action to reduce the negative impact of a risk in case it materializes  Nothing n Accept the risk

45. 45 / 48 ©Jozef De Man 2008-2009 Managing a small Software Project A quick Guide ed 2 Process Definition Establish a “Process Assets Library”  A “Process Assets Library” is the all information that enable project members to perform their tasks more efficiently and effectively  In includes n Templates for documents (e.g. the risk list) n Templates for meeting presentations, reports n Standards (e.g. rules for configuration management, naming conventions, coding rules,…) n Procedures (e.g. how build the product) n User guides for tools n Recommended attributes of activities (frequency of reviews, duration of reviews,…) n …

46. 46 / 48 ©Jozef De Man 2008-2009 Managing a small Software Project A quick Guide ed 2 Process Improvement  You must continuously improve your way of working  This must happen in a controlled fashion n Project members must follow agreed rules n Everybody can submit proposals for improvements n Proposals are evaluated, approved and implemented quickly n New rules must only be followed after agreement  Recommendations n Take time to discuss and agree improvements at project meetings n Communicate changes (e.g. via kick-off meetings) n Document changes in the Process Assets Library n Share improvements with fellow project

47. 47 / 48 ©Jozef De Man 2008-2009 Managing a small Software Project A quick Guide ed 2 Process Improvement Two Levels  Organization n Lessons-learned in projects, appraisals of the process and other inputs are used to document improvements for use by later projects (organizational learning)  Project n If a project is executed in iterations, lessons learned in an iteration can be used for improvements in the next iteration n Iteration Reviews must be used to evaluate possible improvements and decide whether they can be applied immediately n Process Improvements must be clearly communicated to all members

48. 48 / 48 ©Jozef De Man 2008-2009 Managing a small Software Project A quick Guide ed 2 Summary Key Points  Perform Software development as a PROJECT  Deliver a functioning product early and frequently  Keep focus on the customer  Ensure efficient and effective communication between all stakeholders  Stick to a common way of working and continuously improve it