1

Volume

PMP AGILE COURSE DEVELOPMENT

FIRST DRAFT

Value-Driven Delivery

C O U R S E

D R A F T

1
Introduction

Chapter

gile thinking is an attempt to simplify things by reducing complexity of planning, by focusing on customer value, and by shaping a fruitful climate of participation and collaboration. There are a vast number of methods, techniques, best practices, that claim to be agile. There will be fifteen (15) objectives laid out in this section of the PMP agile course
I C O N K E Y

Valuable information
Test your knowledge

Keyboard exercise
Workbook review

What is Agile?
Umbrella term to describe a family of methodologies Engineering best practices Leadership philosophy Project management methodology

An agile approach grows and evolves over time by mixing and matching ideas contributed by practitioners. This summarizes a set of important truths: Grow and evolve: An agile project will not pick a formal process from the shelf and simply execute it. The actual process will shape out while teams develop hands-on and learn from the experiences being made. The development approach is subject to the same need for change and constant improvement as the developed code itself. When development processes mature from primitive to perfection, it can imply that we grow a notable complexity. But if a development process becomes too complex, it will die under its own weight. Therefore, a clear aim is to evolve towards simplicity
1

C O U R S E

D R A F T

instead: Simplicity with the right balance between structure and flexibility is the key to success! Mix and match: Agility is a pool of thoughts, out of which individual projects can combine their specific implementation of an agile development process. The teams way of working is a composition of practices, instead of applying a generic one-size-fits-all process. The resulting process will be tailored to a teams needs and context. Even within the same organization, different teams can adopt different practices. Practitioners: While agility will definitely need active sponsorship and support by top management, the actual implementation will be shaped bottom-up by the teams themselves. The applied methodologies are strongly influenced by practitioners, who disseminate their ideas into their daily working environment. This is quite different to classical development processes which are defined by specialists and are introduced within an organization in a top-down approach as generally binding. Driving the development approach from the bottom will help to avoid gaps between the defined processes and reflect what the teams are actually doing.

Objective 1: Features and Project Work

Define features and project work in terms of end-user and stakeholder value by focusing on maximizing value delivered and minimizing non-value-added activities in order to keep the delivery team focused on maximizing the value developed.

C O U R S E

D R A F T

Agile methods break tasks into small increments with minimal planning, and do not directly involve long-term planning. Iterations are short time frames ("timeboxes") that typically last from one to four weeks. Each iteration involves a team working through a full software development cycle including planning, requirements analysis, design, coding, unit testing, and acceptance testing when a working product is demonstrated to stakeholders. This helps minimize overall risk, and lets the project adapt to changes quickly. Stakeholders produce documentation as required. An iteration may not add enough functionality to warrant a market release, but the goal is to have an available release (with minimal bugs) at the end of each iteration. Multiple iterations may be required to release a product or new features. Team composition in an agile project is usually cross-functional and self-organizing without consideration for any existing corporate hierarchy or the corporate roles of team members. Team members normally take responsibility for tasks that deliver the functionality an iteration requires. They decide individually how to meet an iteration's requirements.

Objective 1 Exercises Separate document to be included after all courses finished for numbering

Objective 2: Feedback and Lessons Learned

Incorporate experience from each delivery by soliciting feedback and lessons learned in order to surface new information about and optimize the value of the system. Agile methods emphasize face-to-face communication over written documents when the team is all in the same location. When a team works in different locations, they maintain daily contact through videoconferencing, voice, e-mail, etc. Most agile teams work in a single open office (called bullpen), which facilitates such communication. Team size is typically small (5-9 people) to help make team communication and team collaboration easier. Larger development efforts may be
3

C O U R S E

D R A F T

delivered by multiple teams working toward a common goal or different parts of an effort. This may also require a coordination of priorities across teams. No matter what development disciplines are required, each agile team will contain a customer representative. This person is appointed by stakeholders to act on their behalf and makes a personal commitment to being available for developers to answer mid-iteration problem-domain questions. At the end of each iteration, stakeholders and the customer representative review progress and re-evaluate priorities with a view to optimizing the return on investment and ensuring alignment with customer needs and company goals. Most agile implementations use a routine and formal daily face-to-face communication among team members. This specifically includes the customer representative and any interested stakeholders as observers. In a brief session, team members report to each other what they did yesterday, what they intend to do today, and what their roadblocks are. This standing face-to-face communication prevents problems being hidden.

Objective 2 Exercises Separate document to be included after all courses finished for numbering

Objective 3: Progress and Acceptance Criteria

Sharpen the requirements by defining acceptance criteria for the most important features on a just-in-time basis in order to articulate a shared definition of done. Agile emphasizes working software as the primary measure of progress. This, combined with the preference for face-to-face communication, produces less written documentation than other methodsthough, in an agile project, documentation and other artifacts rank equally with a working product. The agile method encourages stakeholders to prioritize wants with other iteration outcomes based exclusively on business value perceived at the beginning of the iteration. Specific tools and techniques such as continuous integration, automated or xUnit test, pair programming, test driven development, design patterns, domain-driven
4

C O U R S E

D R A F T

design, code refactoring and other techniques are often used to improve quality and enhance project agility.

Objective 3 Exercises

Separate document to be included after all courses finished for numbering

Objective 4: Project Methodology: Scope , Cost, Schedule

Select and tailor the project methodology based on project and organizational characteristics in order to maximize project success. What is Project Management? When will the project be done? How much will it cost? Do we all agree on what done looks like? What are the risks to delivering time and on schedule? How will we mitigate these risks so we can get done
5

C O U R S E

D R A F T

There is a dynamic relationship between time, cost, and scope. When one of the three variables changes, there is a change in one or more of the other two. Understanding and managing the relationship between these variables is the primary job of the Project Manager. Scope Project scope is the set of deliverables the project is approved to build. It is defined at a high level in the business case or project charter. And it is defined in greater detail in a product requirements document or a work break down structure. Cost Project cost is the sum of all capital expenditures, contractor expenses, and internal cost of labor. Project managers track project expenses in relationship to the budget. Project managers are responsible for making sure the project is spending money at the right rate and time. Schedule The project schedule defines when all the deliverables should be completed and who is going to do them. The project schedule also defines the order of the deliverables and is used to track physical percent complete. When developing the schedule, scope for the project is defined and the sizes of the deliverables are estimated. Deliverables are sequenced and resource needs are calculated. Then based on the size, available budget, dependencies, and constraints; the project timeline can be calculated.

Objective 4 Exercises

Separate document to be included after all courses finished for numbering

C O U R S E

D R A F T

Objective 5: Manageable pieces

Compose small releasable system increments by organizing requirements into minimally marketable features in order to achieve a rapid return on investment (ROI) and to allow for the incorporation of feedback. Agile methods generally promote a disciplined project management process that encourages frequent inspection and adaptation, a leadership philosophy that encourages teamwork, self-organization and accountability, a set of engineering best practices intended to allow for rapid delivery of high-quality software, and a business approach that aligns development with customer needs and company goals. Conceptual foundations of this framework are found in modern approaches to operations management and analysis, such as lean manufacturing, soft systems methodology, speech act theory (network of conversations approach), and Six Sigma.

C O U R S E

D R A F T

There are many specific agile development methods. Most promote development iterations, teamwork, collaboration, and process adaptability throughout the lifecycle of the project. Agile methods break tasks into small increments with minimal planning, and do not directly involve long-term planning. Iterations are short time frames ("timeboxes") that typically last from one to four weeks. Each iteration involves a team working through a full software development cycle including planning, requirements analysis, design, coding, unit testing, and acceptance testing when a working product is demonstrated to stakeholders. This helps minimize overall risk, and lets the project adapt to changes quickly. Stakeholders produce documentation as required. An iteration may not add enough functionality to warrant a market release, but the goal is to have an available release (with minimal bugs) at the end of each iteration.[1] Multiple iterations may be required to release a product or new features. Team composition in an agile project is usually cross-functional and selforganizing without consideration for any existing corporate hierarchy or the corporate roles of team members. Team members normally take responsibility for tasks that deliver the functionality an iteration requires. They decide individually how to meet an iteration's requirements. Agile methods emphasize face-to-face communication over written documents when the team is all in the same location. When a team works in different locations, they maintain daily contact through videoconferencing, voice, e-mail, etc. Most agile teams work in a single open office (called bullpen), which facilitates such communication. Team size is typically small (5-9 people) to help make team communication and team collaboration easier. Larger development efforts may be delivered by multiple teams working toward a common goal or different parts of an effort. This may also require a coordination of priorities across teams.

Objective 5 Exercises Separate document to be included after all courses finished for numbering

C O U R S E

D R A F T

Objective 6: Individual inspection

Define product increments for both internal evaluation and external release in order to expose integration, performance, requirements, compatibility, usability and other problems early and at minimal cost. No matter what development disciplines are required, each agile team will contain a customer representative. This person is appointed by stakeholders to act on their behalf and makes a personal commitment to being available for developers to answer mid-iteration problem-domain questions. At the end of each iteration, stakeholders and the customer representative review progress and re-evaluate priorities with a view to optimizing the return on investment and ensuring alignment with customer needs and company goals.

C O U R S E

D R A F T

Most agile implementations use a routine and formal daily face-to-face communication among team members. This specifically includes the customer representative and any interested stakeholders as observers. In a brief session, team members report to each other what they did yesterday, what they intend to do today, and what their roadblocks are. This standing face-to-face communication prevents problems being hidden. Agile emphasizes working software as the primary measure of progress. This, combined with the preference for face-to-face communication, produces less written documentation than other methodsthough, in an agile project, documentation and other artifacts rank equally with a working product. The agile method encourages stakeholders to prioritize wants with other iteration outcomes based exclusively on business value perceived at the beginning of the iteration. Specific tools and techniques such as continuous integration, automated or xUnit test, pair programming, test driven development, design patterns, domain-driven design, code refactoring and other techniques are often used to improve quality and enhance project agility.

Objective 6 Exercises

Separate document to be included after all courses finished for numbering

10

C O U R S E

D R A F T

Objective 7: Additional feedback

Frequently release high-quality project deliverables to stakeholders so that they can evaluate and provide feedback on the value delivered. Plan and design of the project is outlined only at a high level, while the current iteration is detailed further. Teams are decentralized as self organizing fractals and cover end-to-end functionality including test. They are equipped with the necessary authority to pursue their goals, rather than being micromanaged, thoroughly tracked or permanently inspected. In an agile environment, working and tested code is the preferred way to measure progress. For now, here are a few well-known examples of agile thoughts to start with: Lean Software Development is a concept which evolved from the ideas of lean manufacturing in automotive industry. It includes thoughts on eliminating waste, adding customer value, and empowering workers. Scrum is an extremely efficient and streamlined process of managing and tracking teams.
11

C O U R S E

D R A F T

The Agile Unified Process combines a process with tools and is a derivate of Rationals Unified Process. Test Driven Development emphasizes the definition of test cases even prior to the actual implementation of the code. Extreme Programming is a toolbox of engineering practices like pair programming, or continuous integration.

Agile methods are a family of development processes, not a single approach to software development. The Agile Manifesto states: 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. Some of the principles behind the Agile Manifesto are:

Customer satisfaction by rapid, continuous delivery of useful software Working software is delivered frequently (weeks rather than months) Working software is the principal measure of progress Even late changes in requirements are welcomed Close, daily cooperation between business people and developers Face-to-face conversation is the best form of communication (co-location) Projects are built around motivated individuals, who should be trusted Continuous attention to technical excellence and good design Simplicity Self-organizing teams Regular adaptation to changing circumstances

The manifesto spawned a movement in the software industry known as agile software development. In 2005, Alistair Cockburn and Jim Highsmith gathered another group of peoplemanagement experts, this timeand wrote an addendum, known as the PM Declaration of Interdependence. The functioning principles of Agile can be found in lean manufacturing and six sigma. These concepts include error proofing, eliminating waste, creating flow, adding customer value, and empowering workers. The concepts were first formally espoused in the 14 principles of the Toyota Way, the two pillars of the Toyota
12

C O U R S E

D R A F T

Production System (Just-in-time and smart automation), the 5S methodology, and Demings 14 points. These have been summarized in the seven points of lean software development.

Objective 7 Exercises

Separate document to be included after all courses finished for numbering

Objective 8: Additional feedback

Investigate and communicate termination opportunities in order to assist the business to optimize benefit-to-cost of the system developed.

Business Value The agile development has a business value associated with it. It is able to do the following: Reduce time to market Increase quality Increase flexibility Increase product utility Increase visibility Reduce cost Increase product lifetime

13

C O U R S E

D R A F T

Adaptive methods focus on adapting quickly to changing realities. When the needs of a project change, an adaptive team changes as well. An adaptive team will have difficulty describing exactly what will happen in the future. The further away a date is, the more vague an adaptive method will be about what will happen on that date. An adaptive team can report exactly what tasks are being done next week, but only which features are planned for next month. When asked about a release six months from now, an adaptive team may only be able to report the mission statement for the release, or a statement of expected value vs. cost. Predictive methods, in contrast, focus on planning the future in detail. A predictive team can report exactly what features and tasks are planned for the entire length of the development process. Predictive teams have difficulty changing direction. The plan is typically optimized for the original destination and changing direction can cause completed work to be thrown away and done over differently. Predictive teams will often institute a change control board to ensure that only the most valuable changes are considered.

14

C O U R S E

D R A F T

15

C O U R S E

D R A F T

Objective 8 Exercises Separate document to be included after all courses finished for numbering

16

C O U R S E

D R A F T

Objective 9: Improved Quality

Maintain system design quality by timely updating the internal design in order to reduce the overall cost of incremental development. Contrasted with other iterative development methods Most agile methods share other iterative and incremental development methods' emphasis on building releasable software in short time periods. Agile development differs from other development models: in this model time periods are measured in weeks rather than months and work is performed in a highly collaborative manner. Most agile methods also differ by treating their time period as a timebox. Contrasted with the waterfall model Agile development has little in common with the waterfall model. As of 2009, the waterfall model is still in common use. The waterfall model is the most structured of the methods, stepping through requirements-capture, analysis, design, coding, and testing in a strict, pre-planned sequence. Progress is generally measured in terms of deliverable artifacts: requirement specifications, design documents, test plans, code reviews and the like. A common criticism of the waterfall model is its inflexible division of a project into separate stages, where commitments are made early on, making it difficult to react to changes in requirements as the project executes. Iterations are expensive. This means that the waterfall model is likely to be unsuitable if requirements are not well understood or are likely to change in the course of the project. Agile methods, in contrast, produce completely developed and tested features (but a very small subset of the whole) every few weeks. The emphasis is on obtaining the smallest workable piece of functionality to deliver business value early, and continually improving it and adding further functionality throughout the life of the project. If a project being delivered under the waterfall method is cancelled at any point up to the end, there is nothing to show for it beyond a huge resources bill. With the agile method, being cancelled at any point will still leave the customer with some worthwhile code that has likely already been put into live operation. Adaptations of Scrum show how agile methods are augmented to produce and continuously improve a strategic plan.

17

C O U R S E

D R A F T

Some agile teams use the waterfall model on a small scale, repeating the entire waterfall cycle in every iteration. Other teams, most notably Extreme Programming teams, work on activities simultaneously. Contrasted with "cowboy coding" Cowboy coding is the absence of a defined method; i.e., team members do whatever they feel is right. The Agile approach is often confused with cowboy coding, due to Agile's frequent re-evaluation of plans, emphasis on face-to-face communication, and relatively sparse use of documentation. However, Agile teams follow definedand often very disciplined and rigorousprocesses. As with all development methods, the skill and experience of users determine the degree of success and/or abuse of such activity. Rigid controls, which are systematically embedded within an Agile process, offer stronger levels of accountability. The degradation of well-intended procedures can lead to activities that are often categorized as cowboy coding. Suitability of agile methods There is little if any consensus on what types of software projects are best suited for the agile approach. Many large organizations have difficulty bridging the gap between the traditional waterfall method and an agile one. Large scale agile software development remains an active research area. Agile development has been widely documented as working well for small (<10 developers) co-located teams. Some things that can negatively impact the success of an agile project are:

Large scale development efforts (>20 developers), though scaling strategies and evidence to the contrary[17] have been described. Distributed development efforts (non-co-located teams). Strategies have been described in Bridging the Distance and Using an Agile Software Process with Offshore Development[19] Command-and-control company cultures Forcing an agile process on a development team Mission critical systems where failure is not an option at any cost (Software for surgical procedures).

Several successful large scale agile projects have been documented. BT has had several hundred developers situated in the UK, Ireland and India working collaboratively on projects and using Agile methods. While questions undoubtedly still arise about the suitability of some Agile methods to certain project types, it

18

C O U R S E

D R A F T

would appear that scale or geography, by themselves, are not necessarily barriers to success. Barry Boehm and Richard Turner suggest that risk analysis be used to choose between adaptive ("agile") and predictive ("plan-driven") methods. The authors suggest that each side of the continuum has its own home ground as follows: Agile home ground:

Low criticality Senior developers Requirements change often Small number of developers Culture that thrives on chaos

Plan-driven home ground:

High criticality Junior developers Requirements do not change often Large number of developers Culture that demands order

Agile methods and method tailoring In the literature, different terms refer to the notion of method adaptation, including method tailoring, method fragment adaptation and situational method engineering. Method tailoring is defined as: A process or capability in which human agents through responsive changes in, and dynamic interplays between contexts, intentions, and method fragments determine a system development approach for a specific project situation. Potentially, almost all agile methods are suitable for method tailoring. Even the DSDM method is being used for this purpose and has been successfully tailored in a CMM context. Situation-appropriateness can be considered as a distinguishing characteristic between agile methods and traditional software development methods, with the latter being relatively much more rigid and prescriptive. The practical implication is that agile methods allow project teams to adapt working practices according to the needs of individual projects. Practices are concrete activities and products that are part of a method framework. At a more extreme level, the philosophy behind the method, consisting of a number of principles, could be adapted (Aydin, 2004). Extreme Programming (XP) makes the need for method adaptation explicit. One of the fundamental ideas of XP is that no one process fits every project, but rather
19

C O U R S E

D R A F T

that practices should be tailored to the needs of individual projects. Partial adoption of XP practices, as suggested by Beck, has been reported on several occasions.[22] A tailoring practice is proposed by Mehdi Mirakhorli which provides sufficient roadmap and guideline for adapting all the practices. RDP Practice is designed for customizing XP. This practice first time proposed as a long research paper in APSO workshop at ICSE 2008 conference and yet it is the only proposed and applicable method for customizing XP. Although it is specifically a solution for XP, this practice has the capability of extending to other methodologies. At first glance, this practice seems to be in the category of static method adaptation but experiences with RDP Practice says that it can be treated like dynamic method adaptation. The distinction between static method adaptation and dynamic method adaptation is subtle.[23] The key assumption behind static method adaptation is that the project context is given at the start of a project and remains fixed during project execution. The result is a static definition of the project context. Given such a definition, route maps can be used in order to determine which structured method fragments should be used for that particular project, based on predefined sets of criteria. Dynamic method adaptation, in contrast, assumes that projects are situated in an emergent context. An emergent context implies that a project has to deal with emergent factors that affect relevant conditions but are not predictable. This also means that a project context is not fixed, but changing during project execution. In such a case prescriptive route maps are not appropriate. The practical implication of dynamic method adaptation is that project managers often have to modify structured fragments or even innovate new fragments, during the execution of a project (Aydin et al., 2005).

Objective 9 Exercises

Separate document to be included after all courses finished for numbering

20

C O U R S E

D R A F T

Objective 10 and 11: Improved Risks with Reviews

10. Plan early and proactively mitigate project risks by identifying them and/or utilizing spikes or proof of concepts in order to manage their unknown affects on project 11. Use operational reviews or periodic checkpoints to identify and mitigate dependency risks in order to ensure expectations are managed and stakeholders are aware and informed

The incremental development approach takes the milestone approach further by not only breaking the implementation phase into smaller pieces, but by also taking the whole development process and repeating it several times on subsets of the overall project. By doing so the whole project becomes more flexible to react to change and changing requirements. As the design for the complete solution is now done in steps and not overall at the beginning, there may be a higher risk that in a later round the designs and the code that were done before need to be changed again to support requirements that are just addressed in this round. This approach also addresses the issue of the waterfall approach that it takes until the test phase to see the first integrated and working code. The project is split into several increments, with each of the increments being a small waterfall project. This way you do not have a big bang towards the end of the project, but have the project broken into smaller parts that can be managed more easily. Now it is possible to show working code much earlier to the stakeholders and customers as well as receive feedback early to have enough time to react and incorporate the feedback into the solution or product. A full development approach from requirements to test is executed in each round. Automating all the test cases is a key factor to success with improved productivity in a software development project. Rerunning manual test cases several times to ensure that nothing broke (for example at the end of each iteration) is simply too labor-intensive and therefore too costly. Agile development is a development method to ensure that the developer also focuses on the development of the test cases. The developer starts with the design of the additional functionality to be

21

C O U R S E

D R A F T

implemented. As soon as the design is done, the test case is written before the functionality itself is implemented. While implementing the test case the developer also validates the design with respect to what the function needs to provide, and how it needs to behave. A test case should only be a relatively small increment that can be developed and tested in a matter of hours. After the code has successfully passed the test case, the cycle starts again with an additional or enhanced test case, followed by the implementation of the function, until the test case passes. The developer starts to implement the code as soon as the test case for a use case or scenario is finished. He now has the benefit that he can directly run the automated test case against the new code to ensure that it passes the test or identifies areas that still need to improve. This should also ensure that there is good test coverage for all the code areas developed and that only the code is written that is needed to pass these test cases (all additional code would be considered waste in lean software development terms). If the functionality is implemented first and the test cases are done later, there is always the risk that automated test cases are only provided for a subset of the functionality, and that at a certain point in time, the developer has no more time left or just decides that the test cases are done. With the agile approach it is especially important that the test suite can be executed within a few minutes to provide instant feedback. If the test suite for the complete project becomes too large, it may need to be broken down into subsets that each developer can execute within minutes, and the complete test suite should then be executed in a separate environment several times a day to ensure that no other part of the product broke because of a change somewhere else.

Objective 10 and 11 Exercises

Separate document to be included after all courses finished for numbering

22

C O U R S E

D R A F T

Objective 12: Customer Feedback

Solicit customer feedback by developing and demonstrating working, integrated stages of the system in order to ensure that the functionality meets customer needs. The project team must obtain information from people who will be using the system, either by interviewing them or by watching them work. They obtain additional information by reviewing planning documents and policy statements. They also study existing systems, including their documentation. They also frequently obtain additional information by looking at what other companies (particularly vendors) have done when faced with a similar business need. DEFINE REQUIREMENTS System requirements include the functions the system must perform (functional requirements) and such related issues as user interface formats and requirements for reliability, performance, and security (nonfunctional requirements). As the project team gathers information, they will use that information to create models that express the user's needs in terms of precise processing requirements. Building and refining requirements models occupies much of the teams time. PRIORITIZE REQUIREME NTS Once the system requirements are well understood, it is important to establish which requirements are most crucial for the system. It is important to prioritize requirements because resources are always limited, and the team must always be prepared to justify the scope of the system. Therefore, it is important to know what is absolutely required. Unless the project manager carefully evaluates priorities, system requirements tend to expand as users make more suggestions (a phenomenon called scope creep). Requirements priorities also help to determine the number, composition, and ordering of project iterations. DEVELOP USER-INTERFACE METHODS Such requirements models as use cases, activity diagrams, and interaction diagrams can be developed based on user input, but it is often difficult for users to interpret and validate such abstract models. In contrast, user validation of an interface is much simpler and more reliable because the user can see and feel the system. To most users, the user interface is all that matters. Thus, developing user-interface dialogs is a powerful method of eliciting and documenting requirements. EVALUATE REQUIREMENTS WITH USERS Whether it is building models or creating user-interface dialogs, the requirements must be validated by the user to insure that the new system does, in fact, meet the business need. Project managers usually use an iterative process in which they elicit user input,

23

C O U R S E

D R A F T

work alone to model requirements or create dialogs, return to the user for additional input or validation, and then work alone to incorporate the new input and refine the models.

Objective 12: Exercises Separate document to be included after all courses finished for numbering

Objective 13: Prioritize

Prioritize both features and related project work to balance stakeholder value, business value, and residual risk by incorporating both value- and risk elements

24

C O U R S E

D R A F T

into the requested work set in order to maximize total value proposition over time. Project Risk Analysis is a process which enables the analysis and management of the risks associated with a project. Properly undertaken it will increase the likelihood of successful completion of a project to cost, time and performance objectives. Risks for which there is ample data can be assessed statistically. However, no two projects are the same. Often things go wrong for reasons unique to a particular project, industry or working environment. Dealing with risks in projects is therefore different from situations where there is sufficient data to adopt an actuarial approach. Risk Analysis This stage of the process is generally split into two 'sub-stages'; a qualitative analysis 'substage' that focuses on identification and subjective assessment of risks and a quantitative analysis 'sub-stage' that focuses on an objective assessment of the risks. Qualitative Analysis A Qualitative Analysis allows the main risk sources or factors to be identified. This can be done, for example, with the aid of check lists, interviews or brainstorming sessions. This is usually associated with some form of assessment , which could be the description of each risk and its impacts or a subjective labeling of each risk. A sound aim is to identify the key risks, perhaps between five and ten, for each project (or part-project on large projects) which are then analyzed and managed in more detail. Quantitative Analysis A Quantitative Analysis often involves more sophisticated techniques, usually requiring computer software. To some people this is the most formal aspect of the whole process requiring: Measurement of uncertainty in cost and time estimates Probabilistic combination of individual uncertainties. An initial qualitative analysis is essential. It brings considerable benefit in terms of understanding the project and its problems irrespective of whether or not a quantitative analysis is carried out. It may also serve to highlight possibilities for risk 'closure' i.e. the development of a specific plan to deal with a specific risk issue.

Risk Management

25

C O U R S E

D R A F T

This stage of the process involves the formulation of management responses to the main risks. Risk Management may start during the qualitative analysis phase as the need to respond to risks may be urgent and the solution fairly obvious. Iteration between the Risk Analysis and Risk Management stages is likely. Risk Management can involve: identifying preventive measures to avoid a risk or to reduce its effect establishing contingency plans to deal with risks if they should occur initiating further investigations to reduce uncertainty through better information considering risk transfer to insurers considering risk allocation in contracts setting contingencies in cost estimates, float in projects and tolerances or 'space' in performance specifications. Techniques and Methods Analysis and Management can be split into its two constituents or stages - Risk Analysis (Qualitative and Quantitative) and Risk Management. There is no one technique or method for carrying out either stage of the process. Some of the techniques and methods that can be employed are detailed below. Qualitative Risk Analysis The first phase of the qualitative analysis is identification. This is considered by some as the most important element of the process since once a risk has been identified it is possible to do something about it. Identification can be achieved by: interviewing key members of the project team organizing brainstorming meetings with all interested parties by using the personal experience of the risk analyst reviewing past corporate experience if appraisal records are kept. All of the above methods are greatly enhanced by the use of check lists which can either be generic in nature i.e. applicable to any project or specific to the type of project being analyzed. Quantitative Risk Analysis Once all risks have been identified, during the qualitative analysis, it may be appropriate to enter into a detailed quantitative analysis. This will enable the impacts of the risks to be quantified against the three basic project success criteria: cost, time and performance. Several techniques have been developed for analyzing the effect of risks on the final cost and time-scale of projects. However, such techniques do not always readily apply themselves to the analysis of performance objectives. The main techniques currently in use are: Sensitivity Analysis, often considered being the simplest form of risk analysis. Essentially, it simply determines the effect on the whole project of changing one of its risk variables such as delays in design or the cost of materials. Its importance is that it often highlights how the effect of a

26

C O U R S E

D R A F T

single change in one risk variable can produce a marked difference in the project outcome. The number of companies practicing Project Risk Analysis and Management is continuing to increase due to the realization that the methods, techniques and processes involved form an integral part of project and business management. The increase in its use has led not only to expertise being gained by individuals within companies but the arrival of specialist consultancies that can train, advise and carry out Project Risk Analysis and Management for their clients. Project Risk Analysis and Management has also established itself as an important element in the syllabuses of many universities and higher educational establishments.

Objective 13 Exercises

Separate document to be included after all courses finished for numbering

Objective 14: Changes

Reprioritize requirements periodically in order to reflect changes in the environment and stakeholder understanding.

27

C O U R S E

D R A F T

Scope is the way to describe the boundaries of the project. It defines what the project will deliver and what it will not deliver. This process ensures that the project has identified the goals and objectives and those have been documented and that each objective has a well defined set of indicators to monitor their progress. During this process a scope management plan is created to help manage any changes to the projects. This is a critical process and one that will help project managers deal with scope creep, which is when a project includes additional work after a project has started without considering the impact on the resources or schedule of the project. Request for additional work may come from many of the stakeholders the problem arises when the project manager decides to the additional work without a corresponding increase in the time or budget, this is one of the leading causes for project failures. To manage scope creep the project needs to establish a scope change control plan that will facilitate how, when and why any changes to the scope are made. The steps include an assessment, impact to the budget and/or schedule the corresponding authorization, incorporation of changes to the project plans and implementation of the approved change of scope. It is a good practice for the project to define what is not included in the project, by defining what is out of scope the project stakeholders can have a better understanding of the project boundaries. During the scope management process the project manager develops a Work Breakdown Structure (WBS) which is a management technique of breaking the project down into a hierarchy of work tasks which represent the work to be done. This schedule then is used as an input to define the time and budget of the project. Schedule Management This process includes the actions required to ensure the timely completion of the project. Schedule management is the development of a project schedule that contains all project activities, the project schedule is a communication tool that informs project stakeholders the status of the project and gives project team members information, in the form of graphs and charts, as to when each activity must begin and end. The first step in schedule management is estimating the time each one of the activities identified in the WBS would take to be completed, the relationships among the activities and the sequence they should start. A network diagram is a tool used to graphically display the activity sequence and dependencies. The project schedule is also used to assign project staff with their

28

C O U R S E

D R A F T

tasks. Monitoring the schedule is an ongoing task, as each activity is performed the project manager must review the progress made against the schedule baseline and determine what schedule variance have occurred, the schedule management plan should include instructions on how to proceed when schedule variances occur. Another element of schedule management is the procedure to control schedule changes and define who can authorize changes to the schedule. It is not uncommon that at the moment of planning the project some oversight occurred that did not plan for situations when the beneficiaries are involved in other events, such as festivities or social events; this can also include unpredictable events such as the weather or political events that can disrupt any project schedule. Schedule reporting includes techniques to compare the project baseline with the actual dates and uses variance analysis to determine project progress, if the project is behind schedule then the project must determine the best options to bring the project back to schedule using methods such as making trade-offs to compress the schedule or fast tracking which involves doing more activities in parallel. In agile planning you are counting on what you know you definitely have. Depending on the type of project, you are either given a number of resources by your management to do the project, or, as in a services contract, there is a certain amount assigned for resources that you better not overspend. The time constraints will be fixed as well. On the other hand, requirements will be a moving target. Therefore the plan is fluid and includes only a rough estimate of those requirements that might be achievable in a prioritized order. Content is the parameter to adjust when adapting to change. The actual deliverable will be the best that can be accomplished within the given timeframe and with the given resources. Each team will figure out how to accomplish as much work as possible. In contrast to this, traditional waterfall project management teaches just the opposite approach: You start with gathering the list of fixed requirements, then estimate the cost and time needed to implement them. This approach ignores that in most cases, resources and dates are non-negotiable given constraints. The content delivered by the team will always be confined by the team size and available time, regardless which requirements you commit to address in your specification. If the requirements are fixed by management as well as the dates and resources, this is neither waterfall nor agile, but simply unprofessional and a setup for failure.

29

C O U R S E

D R A F T

The team will be doomed to fall into a never-ending emergency mode, which is not sustainable and will offer quality decrease as the only way out.

Objective 14 Exercises

Separate document to be included after all courses finished for numbering

30

C O U R S E

D R A F T

Objective 15: Non-Functional Requirements

Elicit non-functional requirements to ensure that the solution satisfies operational and maintenance parameters in order to minimize the impacts of failure. Non-functional requirements define the overall qualities or attributes of the resulting system. Non-functional requirements place restrictions on the product being developed, the development process, and specify external constraints that the product must meet. Examples of NFR include safety, security, usability, reliability and performance requirements. Project management issues (costs, time, and schedule) are often considered as non-functional requirements as well. There is no a clear distinction between functional and nonfunctional requirements. Non-functional requirements may result in new functional requirements statements. Whether or not a requirement is expressed as a functional or a nonfunctional requirement may depend: on the level of detail to be included in the requirements document the comprehension of application domain and the desired system experience of developers

Some properties of a system may be expressed either as a functional or nonfunctional property. Example: The system shall ensure that data is protected from unauthorized access. Conventionally a non-functional requirement (security) because it does not specify specific system functionality. Expressed as functional requirement:, the system shall include a user authorization procedure where users must identify themselves using a login name and password. Only users who are authorized in this way may access the system data.

31

C O U R S E

D R A F T

The IEEE-Std 830 - 1993 lists 13 non-functional requirements to be included in a Software Requirements Document. 1. Performance requirements 2. Interface requirements 3. Operational requirements 4. Resource requirements 5. Verification requirements 6. Acceptance requirements 7. Documentation requirements 8. Security requirements 9. Portability requirements 10. Quality requirements 11. Reliability requirements 12. Maintainability requirements 13. Safety requirements Non-functional (product) requirements play an important role for critical systems. Systems whose failure causes significant economic, physical or human damage to organizations or people need to be looked at. There are three principal types of critical system: 1. Business critical systems Failure leads to significant economic damage 2. Mission critical systems Failure leads to the abortion of a mission 3. Safety critical systems Failure endangers human life

Objective 15 Exercises

Separate document to be included after all courses finished for numbering

32