Risk and Issue Management With Enterprise Architect and eadocx

Transcription

1 2011 Risk and Issue Management With Enterprise Architect and eadocx This document, the first in a series on EA for Project Managers, looks at how risk and issue management can be automated, made more relevant and support effective management of successful projects, all by keeping the information in EA. Jackie Mitchell eadocx Ltd 12/16/2011

2 Risk and Issue Management with EA and eadocx Table of Contents Abstract Introduction Definitions Risks Using EA Risks Documenting EA Risks Reporting Conclusion Recommendation: Using EA Risk Elements Risk Attributes to be captured Reporting Issues Using EA Project Issues Issue Attributes to be captured Reporting Using EA Issue Elements Issue Attributes to be captured Reporting Summary Appendix A. Project Management Metamodel Appendix B. About Enterprise Architect (Sparx Systems) Appendix C. About eadocx Appendix D. About the Author P a g e

3 Risk and Issue Management with EA and eadocx Abstract Many projects use Enterprise Architect (EA) to store information about their projects: requirements, use cases, designs and other information. What is less common is to use EA as the repository for ALL project information, replacing all the spreadsheets and reports which come along with a well-managed project. This document, one in a series on EA for Project Managers, looks at how risk and issue management can be automated, made more relevant and support effective management of successful projects, all by keeping the information in EA. 1 Introduction Every project has associated risks and issues that need to be tracked and managed. Using EA for project analysis and design gives us the ability to capture risks and issues at Project level or as discrete elements. This paper compares these two approaches and proposes a way to use EA and eadocx to make project risk and issue management and all the associated reporting a fully integrated activity within the project. 2 Definitions Risks are defined here as future problems that can be avoided or mitigated. Issues are defined as current problems, i.e. risks with a probability of 100%, which must be immediately addressed. 3 Risks The Project Manager is usually the owner of the Project Risk log, taking inputs from a wide range of project stakeholders both inside and outside the project team. If project analysis and design is held in EA, it already contains a large amount of data that can support the assessment of risks. With a small amount of work this can be tailored to provide a complete set of information, and then extracted using eadocx to support Risk Management. This approach has the major benefit of ensuring that everyone on the project understands how their work impacts, or is impacted by, risks and issues, making them visible and relevant. It also moves towards EA becoming one version of the truth. 3 P a g e

4 Risk management 1 involves having reliable, up-to-date information about risks, decision making processes supported by a framework of risk analysis and evaluation, processes in place to monitor risks and the right balance of control in place to manage those risks. The stages of risk management and factors required to support them are: Risk Management Activity Comment Information required 1. Identify the risks Each risk needs to be uniquely identified, described and clearly associated with the area(s) of the project or business that it will impact a) Unique identifier b) Author c) Date identified d) Description e) Category (e.g. legal, technical, 2. Evaluate the risks Evaluation of a risk is based on how likely it is to happen and what the impact (assessed across a range of measures) will be if it does. These result in a risk priority. 3. Identify suitable responses (mitigations) A range of actions identified that will either eliminate or reduce the risk probability and/or impact 4. Select responses What amount of effort is required to carry out the mitigation actions compared with the expected result? Choose the most attractive. commercial etc.) a) Probability b) Impact: i. Time ii. Cost iii. Quality iv. Scope v. Benefit vi. People/resources a) Prevent b) Reduce c) Transfer d) Accept e) Contingency Cost benefit analysis 5. Implement Carry out actions Plan and engage resources to implement 6. Monitor Review actions & results and update EA project model with associated changes. Management Information regarding cost and effectiveness of actions. Documentation of changes to design, business processes etc., compliance to requirements and impacts on business case. Data stored in EA can easily support all these stages of activity, and by using eadocx the associated reports can be easily produced to manage and communicate the project exposure to risks. The rest of this document shows you how. 1 Managing Successful Projects with Prince p251 UK Office of Government Commerce. (Prince is the UK standard qualification for Project Management) 4 P a g e

5 3.1 Using EA Risks In EA, selecting View More Element Tools Project Management opens a window where Risks can be entered. The standard information comprises 4 fields only: Risk, Type, Weight and Notes. Valid Types within this structure (i.e. to populate the drop down Type list within the Risks entry field) can be edited in Settings Project Types Project Indicators. However there is no way to add extra fields to the Risk item to let it hold the full range of data described above Documenting EA Risks EA advice on documenting such risks is as follows: (Sparx comments are in blue; my further annotations are in black.) In the Risk Type field type the name of the risk type This could equate to Risk category (1e in the table above) or one or more characteristics of Impact (2b), depending on how you define the risk type. In the Description field type a short description of the risk type I believe this is referring to the Field called Risk. Therefore this could be used for a Unique identifier (Reference/Title) In the Weight field type the default weighting to apply to the risk type (is this the same as probability? Or some sort of priority based on a mix of probability and impact?) In the Note field, type any additional information on the risk type I would suggest this is used for Risk Description or Everything Else The entry screens are either: a) View including Show Properties: Or: b) View including Hide Properties: 5 P a g e

6 (NB EA Settings Project Types Project Indicators also provides access to enter and edit Project Risks.) All Risks captured in this way must be associated with an element of the EA model (in fact an element in the EA model must be selected in order to enter any data into these forms). However it is not possible to associate a risk with more than one element, and it is not possible to associate a Project Risk with a Package. This means that for a Risk which does impact multiple packages or elements it is necessary to create multiple duplicate instances of that Risk and associate each one with a different element. This is obviously against the good practices of EA modelling and would rapidly lead to the project risks becoming unmanageable. Owing to the limitations imposed by this interface, project risks captured here cannot be easily sorted or analysed. This means that the Project Risk Management activity must use other tools for analysis and maintenance of risks Reporting There is a problem with reporting these Risks; EA cannot even produce RTF reports so recommends creating your own custom reports using other tools. In this case the lack of any EA reporting interface means that there is no means of extracting the data into an eadocx document either Conclusion Viewing Risks in EA with the Project Management browser gives a clear single view of all risks. The two views to review and add information are clear, and in the Hide Properties view it is possible to re-order the columns and to sort on any of the columns. However in the context of the requirements for Risk management set out earlier, using Project Risks has several limitations: Risks can only be associated with 1 element (so multiple impacts cannot be captured) Risks must be associated with 1 element (so global project risks are linked to individual elements this can be misleading) Very few fields to enter information (so information is potentially incomplete, it is difficult to compare risk A to risk B and it is time consuming (or impossible) to search, sort or filter on anything but the highest level attributes) There is no simple way to produce Risk reports. As a result this approach is Not Recommended as the basis for risk management activity. However, there is another option 3.2 Recommendation: Using EA Risk Elements The alternative way to capture risks is using risk elements within the EA model. By using the attributes included within the standard Element definition, adding tagged values and tailoring the other fields (e.g. drop down menus for Type) then the whole range of information to support project risk management can be stored in your model. 6 P a g e

7 This approach also has the benefit that risks can be linked (we use a simple dependency) with any or all elements of the model e.g. requirements, use cases, classes, components, interfaces, domains etc. that would be impacted if the risk became an issue. Potential mitigation actions can also be inked to the risks, indicating other elements that may have to change Risk Attributes to be captured A typical list of attributes in a Risk register would include: Reference, Impact level, Category, Originator, Owner, Title, Description, Mitigation, Open date, Review date, Impact, Probability, Priority (impact*probability), Impact date, Type of risk, Status, Escalations required, closure date, last updated. These can be implemented in a Risk Element as follows: Risk Attribute Description Default EA attribute/representation Reference Unique if possible with Risk attribute: Alias project reference Impact level e.g. Work Package, Project, Programme, Cross Programme, How to implement It should be possible to make the reference project/risk specific using EA Settings Auto Names and counters, but unfortunately Risk is missing from the element list in the Type drop-down Sparx have been asked Add New Tagged Value if required with permitted values 7 P a g e

8 Executive Category e.g. legal, commercial, technical, security Add New Tagged Value with permitted values Risk Attribute Description Default EA How to implement attribute/representation Originator Who raised it Risk attribute: Author Done Owner Stakeholder responsible for accepting risk management approach Add New Tagged value link to element of type Actor (possibly of stereotype Business Function ) Title Risk attribute: Short description Done Description Notes Done Mitigation Actions Open date Review date Impact Probability Priority Impact date Type of risk Status Escalations required Associated actions needed in order to fulfil the above management approach When Risk was first captured When risk is due for next review How significant is the result if this risk happens? How likely is this risk to happen? Priority, calculated from combination of Impact and Probability When would this become an issue? Time/Cost/Quality or combinations of these e.g. Open, Closed, Escalated, Monitor e.g. to Programme manager, Project board, Programme board Risk attribute: Created Risk attribute: Priority (Type is set to Requirement stereotypes only) Risk attribute: Status but needs to be changed Create action stereotypes Mitigation Actions and link to Risk. Could include Change requests Done Add New Tagged Value of type Date Add New Tagged value with permitted values 1-5 Add New Tagged value with permitted values 20/40/60/80% Manually selected to match product of impact and probability i.e. 1-8 = low 9-16 = medium = high Add New Tagged Value of type Date Add New Tagged value with permitted values Settings Project Types General types status drop down can be modified to define Risk specific permitted values Add New Tagged value with permitted values Closure date When Risk is closed Add New Tagged Value of type Date Last updated When Risk element data was last amended Risk attribute : Last updated Done NB Green boxes require no change to standard EA Risk element attributes. Other standard attributes of a Risk Element are applicable as follows: 8 P a g e

9 Difficulty This attribute doesn t have a direct application in Risk management unless it is a summary field associated with the cost/time/complexity of managing the mitigation Recommendation = ignore. Priority Choose from H/M/L on the basis of Probability & Impact assessments. Ideally this would be automatically generated based on the tagged value inputs for impact and probability, but if not then manually allocate level. Type the default drop down list in this case is the list of requirement stereotypes. This cannot be edited and is not applicable to risk types Recommendation = ignore Phase and Version these can be populated as applicable to your project. Key Words - these can be populated as applicable to your project. By creating a Risk Stereotype with these characteristics or amending the Risk Element to make this the default then EA can be used to store all the required attributes to make Risk Management completely integrated with the EA project model. Ways to do this are: Either add a new stereotype via MDG, or Create the Stereotype with all the new Tagged values then create new elements by copying & renaming (cheat?!) Reporting With Risks documented in this way, eadocx provides flexibility to support reporting for various project audiences and purposes. Risk Elements can be documented within the packages to which they relate. By adding Package Sections to an eadocx document, the diagrams and text produced (whether formatted as tables or in-line) can clearly identify all package elements including package risks. The Risks can be printed out in situ with the package as either tables or in-line, depending on the quantity and format of information included, then sorted and formatted to support your purposes. Risks can also be included as related elements within the table or in-line formatting of all other elements. Alternatively, to create a specific report for Risk Management, set the eadocx document profile to not print 'Risk' elements, and then create an Element Report which just collects all the Risks together. Using the eadocx sorting and conditional formatting options, such a report can give focus to risks that satisfy particular criteria (e.g. due date, priority, owner etc ). In the following example, Risk elements have been modified to include the fields as described above, some representative data has been populated and the Risk element table format defined in the eadocx profile. The resulting output shows the standard of report that can be produced. 9 P a g e

10 In the above example a subset of available fields has been defined to print, and the table has been sorted on Priority, which has had conditional formatting applied to give greater emphasis. It also illustrates the way eadocx handles incomplete data Risk owner names are shown, including hyperlinks where they are documented elsewhere in the report but just as text if there is no link, and with the default text (none) if there is no data to print. In this way a Risk report can be easily generated as a separate document or incorporated easily into the body of other analysis and design documents. This means that the communication and management of risk becomes integrated into every part of the project, and allows for more people to have more opportunities to identify mitigations that should make for a better quality project overall. 4 Issues Tracking and reporting of Project Issues is always a high priority for Project Managers when Project Board or Programme reviews are held. The typical summary presentation can often lead to a detailed review of how we got here where and when the risk was first identified, what mitigations were tried (giving an idea of the most or least appropriate course of action to be taken next) and what the business case impacts are. Joined-up data capture and management of Risks and Issues is therefore essential for Project Managers. As with Risks, EA offers two approaches to managing Issues; Project Issues or Issue Elements 10 P a g e

11 4.1 Using EA Project Issues There are two ways to access the EA Project Issues: Either select View More Project Tools Project Information and select the Issues tab or navigate via Project Documentation Issues. Following either of these approaches leads to the Project issues screen. This allows entry of the data fields: Priority, Issue, Date, Status, Owner, Description, Resolved, Resolved By and Comments. (Additional fields to the standard set shown can be accessed by a right click in the Project Information screen and selection of Field Chooser). This set of data fields cannot be edited or added to although it is possible to change the order of columns and sort on any of the fields. It is also substantially different to the Project Risks data set and is accessed via a different part of the model so a smooth transition from Project Risk to Project Issue is not possible Issue Attributes to be captured EA advice on documenting and maintaining Project Issues is: The issue name Auto counters - if you have configured these, click on the Auto button The issue priority The date the issue was raised The issue status The issue owner A description of the issue The name of the person who resolved the issue The date on which the issue was resolved (select the check box to activate the date) Any comments on the resolution This set of functions is much closer to the required data that is needed for a Risk and Issue Management approach than the Project Risk equivalent. However it is still missing some key fields, in particular the ability to associate an Issue with any related elements. Also there is no way to transfer Risks into Issues without completely re-entering all the relevant field data. 11 P a g e

12 4.1.2 Reporting From the EA Issues Dialogue it is possible to produce a basic rtf report of the Project Issues. A fuller report can be generated using eadocx; simply add a Section into your Issues document using Insert Other Project data Project Issues. The data produced can then be formatted to meet your reporting requirements, either in table or in-line format, with sorting, selected data fields and manual hyperlinks if necessary. 4.2 Using EA Issue Elements The best way to ensure consistency between Risks and Issues is to add Project Issues as Elements in the EA model. This also ensures that Risks can be easily reclassified as Issues if necessary and makes sure we keep full traceability through the Risk/Issue lifecycle Issue Attributes to be captured Issue Attribute Reference Impact level Category Description Unique if possible with project reference e.g. Work Package, Project, Programme, Cross Programme, Executive e.g. legal, commercial, technical, security Default EA attribute/representation Issue attribute: Alias Originator Who raised it Issue attribute: Author Done Owner Stakeholder responsible for accepting issue management approach Title Issue attribute: Short Done description Description Notes Done Mitigation Actions Open date Review date Priority Associated actions needed in order to fulfil the above management approach When Issue was first captured When Issue is due for next review How significant is the impact on Business case*? (* Business case impacted Issue attribute: Created Issue attribute: Priority How to implement Use EA Settings Auto Names and counters to make the reference project/issue specific. Add New Tagged Value with permitted values Add New Tagged Value with permitted values Add New Tagged value link to element of type Actor of stereotype Business Function Create action stereotypes Mitigation Actions and link to Issue. Could include Change requests Done Add New Tagged Value of type Date Done: select from Low, Medium, High 12 P a g e

13 Type of issue Status Escalations required by costs, User experience, regulatory concerns etc.) Time/Cost/Quality or combinations of these e.g. Open, Closed, Escalated, Monitor e.g. to Programme manager, Project board, Programme board (Type is set to Requirement stereotypes only) Issue attribute: Status but needs to be changed Add New Tagged value with permitted values Settings Project Types General types status drop down can be modified to define Issue specific permitted values Add New Tagged value with permitted values Closure date When Issue is closed Add New Tagged Value of type Date Last updated When Issue element data was last amended Issue attribute: Last updated Done NB Green boxes require no change Other standard attributes of issue elements (Difficulty, Priority, Type, Phase and Version, Key Words) are applicable in the same way as they are for risks. Comparing this set of fields, it becomes clear that the only changes in data from Risks to Issues are the removal of the probability and impact date fields, or that these just become N/A. Using this schema therefore provides us with the simple task, when a Risk becomes an Issue, of changing its type using the EA menu Element Advanced Change Type (Note this is NOT valid if the above changes to Issue Elements are saved as a Stereotype. Stereotypes cannot be selected in the Change Type dialogue the bespoke Tagged Value data would then be lost and so have to be reentered.) Reporting eadocx can document Issue elements as part of the main body of the document, in-situ with the package(s) to which they relate. Alternatively, to create a specific report for Issue Management, set the document profile to not print 'Issue' elements, and then create an Element Report which just collects all the Issues together, in the same way as shown in the Risk printing example. In both cases, eadocx can be configured to print hyperlink(s) with each Issue, which will take readers to the appropriate EA element(s) to which the Issue relates. 13 P a g e

14 5 Summary Using Enterprise Architect and eadocx, a sophisticated Risk and Issue Management process can be supported. By modifying Risk and Issue Elements, detailed information can be captured within the EA model, with rich contextual links. Generating eadocx reports can present the information to the Project Manager s exact requirements. In this way Project Managers can see the Big picture of the impacts of Risk and Issues, as well as having detailed information about the scope (including impacted requirements, use cases, deliverables etc. ) of mitigations or corrective actions. With these pieces of information readily available, Enterprise Architect and eadocx can lead to high quality decision making. And with that, better, more successful projects. 14 P a g e

15 Appendices Appendix A. Project Management Metamodel Implicit in the above discussion is the meta-model which is being used for the project. This may sound like an exotic, technical idea, but the project meta-model is just a simple model of what the project knows about itself: what kinds of information exist, and how those pieces of information relate to each other. Only by knowing and sticking-to the project meta-model can we hope to keep EA as the single version of the truth for a project. It must be precise and well-defined, whilst allowing for users to create variations where they really need to. For the more expected parts of the project the Use Cases, classes & components, there s no need to invent a meta-model: UML has already done this, but it only covers the core of the analysis & design. Even the role of the humble Requirement has many possible implementations in a project meta-model. So, the model presented below is one we suggest. It s based on a large number of projects, some of which used EA, some which didn t, but which all shared similar problems: how to wrap the traditional EA information with project management ideas. 15 P a g e

16 class Risk & Issue Classes Risk Issue Change Legend EA Built-in classes New Project stereotypes «project» Project Risk «project» Project Issue Project Change «trace» «trace» «trace» EAElement individual OWNS issue individual OWNS risk Indiv idual Actor Requirement Diagram VERY incomplete 16 P a g e

17 Appendix B. About Enterprise Architect (Sparx Systems) Enterprise Architect is a visual platform for designing and constructing software systems, for business process modelling, and for more generalized modelling purposes. Enterprise Architect is based on the latest UML 2.3 specification (see UML defines a visual language that is used to model a particular domain or system (either proposed or existing). Enterprise Architect is a progressive tool that covers all aspects of the development cycle, providing full traceability from the initial design phase through to deployment, maintenance, testing and change control. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Sparx Systems is an Australia-based company with a solid history of innovation and development within the modelling tools market. Sparx Systems is a Contributing Member of the Object Management Group (OMG), the standards body responsible for defining and maintaining the UML and related specifications. Sparx Systems believes that a complete modelling and design tool should be used throughout the full software life-cycle. Our subscription plan reflects this, as does our belief that life-cycle software should be as dynamic and modern as the systems you design and maintain. Sparx software is intended for use by analysts, designers, architects, developers, testers, project managers and maintenance staff; that is, almost everyone involved in a software development project and in business analysis. It is Sparx Systems' belief that highly priced CASE tools severely limit their usefulness to a team, and ultimately to an organization, by narrowing the effective user base and restricting easy access to the model and the development tool. To this end, Sparx Systems is committed to maintaining an accessible pricing model and to distributing a free 'Read Only' (Enterprise Architect Lite) version of Enterprise Architect for use by those who only need to view model information. Contact Sparx Systems at the following addresses: Sales and Purchase Enquiries: sales@sparxsystems.com Product Support Enquiries: support@sparxsystems.com 17 P a g e

18 Appendix C. About eadocx eadocx is the new high-quality Microsoft Word document generator for the popular Enterprise Architect (Sparx Systems) tool. It combines an intuitive user interface with tight integration with Word, so you can produce ready-to-publish documents with a couple of clicks. You'll save hours by creating documents using the built-in formatting options, then customise the document to look exactly the way you want it using the wide range of options. Then when your EA model changes, a couple more clicks will pull in the latest from your EA model, directly into your Word document. Simple to create great-looking documents Use formatting from your favourite Word documents Automatically create hyperlinks within your documents Access to all Enterprise Architect content One-click re-generation This represents a significant breakthrough for Enterprise Architect users. Now a whole project team can use EA as their knowledge repository: analysts, architects, designers, developers and project managers, because each can define their own documents, customised to their exact requirements. eadocx started out as a solution to a very specific problem. How to produce pages of complicated technical design documentation - Use Cases, Domain models, sequence & state diagrams and architecture descriptions - written by 6 people, for a very smart but critical audience. And produce it in 6 different but overlapping documents, with a new version of each document every other week. Enterprise Architect was the obvious choice for the tool in which the design would be produced, but how to produce the documents? The only solution was to generate the documents directly from EA. Six years, and many projects later, and after a port from VBA to VB.NET and new user front end, the result is eadocx. As we are experienced EA users - for both Business Analysis and Architecture/Design - we know what it takes for a generator to be really useful. Fast, simple and comprehensive. So that's what we've built. We hope you enjoy using it. Website: enquiries@eadocx.com 18 P a g e

19 Appendix D. About the Author Jackie Mitchell has worked in the Aerospace, Health and IT industries for more than 25 years, as a project and programme manager, consultant and trainer. She has worked on multi-national technology projects of all shapes & sizes, most recently in Telecoms, using Waterfall and Agile methods. She has a particular interest in making sure that teams are using the right tool for each job and in optimising the use of information to help the technical team do the right things right and minimise the administrative and management burden - delivering quality, on time and to cost, and keeping all project stakeholders happy. 19 P a g e