Project Planning

Requirements Analysis Using Event / Response and Use Cases: Final Summary

Professor of Project Management Project Planning, Requirements Analysis , ,

Planning

In the preceding posts, I gave you some guidance on how to execute the Event/Response methodology for scope and requirements analysis. In this last of the series of posts on this topic, I will take the 5,000 foot view and put it all together in a summary of steps.

  • Step 1 – Define the Business Objectives (the measurable benefits realized after implementation). These will be used to verify the scope and requirements.
  • Step 2 – Define the Project Objectives (the products, services and/or results delivered at project implementation). These will also be used to verify scope and requirements.
  • Step 3 – The Context Diagram. Look at the area under study as an outsourced business, with Suppliers (of data) and Customers (recipients of data/information/results).
  • Step 4 – The Event List. This represents your “business model”. You define all of the events that “wake up” your business and require a planned response. In the prior posts, I presented a variety of techniques for fleshing out these events. Included in the Event List are your business processes and stakeholders.
  • Step 5 – Validate the Event Model. Compare your event scope with the Business and Project Objectives and verify with the Project Sponsor that all objectives are covered by this scope.
  • Step 6 – Construct Use Cases. Use the defined business processes in the Event Model as the starting point for creating Use Cases.
  • Step 7 – Test Planning and Execution. The Event Model is a wonderful framework in which to define your test scenarios and cases. Take advantage of all the work you did in the requirements phase to make your test planning and execution easier.

That’s it for this topic. I hope you found it informative and useful. I have used this technique successfully in many real-world projects.

Requirements Analysis Using Event/Response and Use Cases: Test Planning & Execution

Professor of Project Management Project Planning , , ,

Planning

In addition to being a great way to elicit the complete scope of a project, the Event/Response methodology delivers a comprehensive framework for test planning and execution. When using this methodology, what many call “User Acceptance Testing” can be replaced by the term “Event Testing”.

In my prior posts on this topic, I identified the primary deliverables of the Event/Response methodology as:

  1. The Event List (containing the event that triggers the response, the origin and data content of the information flow into your “business”, the named processes, the outputs of the processes and the destinations of the outputs), and
  2. The Use Cases. You can plan to test by simulating the actual Events, creating the data flows, executing the processes and examining the outputs. The Use Cases give you a good start on creating the data and usage variations for each Event. Doing this yields a direct mapping of the scope and requirements to the test cases and execution.

Note that since the Event List also contains the roles of the actors initiating the events and processes, as well as the roles receiving the outputs, security testing can also be built into this framework.

Another major plus of planning and executing the tests this way is that you are testing the system as it will actually be used in context, as opposed to functional testing which tests bits of functionality in isolation.

A recent project of mine used this methodology and yielded 180 Events and over 1,600 test cases. Because of this comprehensive approach, the system was very well tested and only experienced minor problems after implementation.

Requirements Analysis Using Event-Response / Use Cases: The Context Diagram

Professor of Project Management Project Planning, Requirements Analysis ,

Planning

The Context Diagram is the place to start when doing your analysis. It should be done in conjunction with the stakeholders that are most knowledgeable about the business processes for the domain under study. The initial list of Business Events will be derived from the Context Diagram.

Start with a circle in the middle of the diagram. This represents the area of the business in the scope of the project. All of the processes within this circle are in scope and are able to be modified or added to as part of the project scope. Think of it as if this business function were outsourced to a service provider and the Executive Sponsor of the project is the CEO of this service provider. What would they need to know to create a business model?

First, you would want to define “who are my Customers?”. Your Customers are recipients of your business’s outputs (in most projects, these are flows of information and data). Ask the key stakeholders “who are the current recipients of information your business function?”. Draw the Customers as rectangles on the right hand side of the diagram. It is not important at this time that you have the complete list of Customers, only that you have some. We will complete the list of Customers in an iterative process in conjunction with the Event/Response Model.

Next, define the types of information that flow to each Customer. Draw these as arrows from the center circle and connecting to the Customer rectangle. Have a short, high level description of the flow on each arrow.

After that you need to define “who are your Suppliers?”. The Suppliers are providers of the business’s information and data. Ask the key stakeholders “who are the current providers of information for your business function?”. Draw the Suppliers as rectangles on the left hand side of the diagram. It is not important at this time that you have the complete list of Suppliers, only that you have some. We will complete the list of Suppliers in an iterative process in conjunction with the Event/Response Model.

Next, define the types of information that flows from each Supplier. Draw these as arrows from the Supplier rectangles and connecting to the center circle. Have a short, high level description of the flow on each arrow.

Rules for Suppliers and Customers:

  • They can be individuals, roles, departments, organizations, systems, vendors, etc. Anything that is a net originator or receiver of data or information from your “business”.
  • Some entities can be both Suppliers and Customers. so they will have arrows going in both directions.
  • If you are struggling with whether a Supplier or Customer is inside or outside the circle, the general rule is for entities outside the circle, the project has no control over their processes. The project can only change the nature and content of the information flows to and from these entities.
  • There are no flows represented that go from entity to entity. They may exist but they are of no concern to the project.

Here is an example of a Context Diagram:

Context_Diagram

Requirements Analysis Using Event Response / Use Cases: The Event Model

Professor of Project Management Project Planning, Requirements Analysis , ,

Planning

The Event Model looks at the scope of your project as if this business function is being outsourced to a third party business and your Executive Sponsor is the CEO of that business. This is the new way of thinking about requirements that I referred to in the Overview post.

The Event Model consists of the following elements:

  • The Context Diagram – shows your business boundary as a circle in the center of the diagram with your suppliers, customers and information flows surrounding the center circle. I will present this in detail in the next post.
  • The Event/Response Model – this contains the detail of the events that “wake up your business” and requires the business to have a planned response. It is progressively elaborated in conjunction with the Context Diagram. More on this in a future post.
  • Use Cases – are derived from the Event/Response Model and show the specific steps required for each business response. At the end of the requirements analysis, this becomes (or is the basis for) your “Business Standard Operating Procedures Manual”. Functional Requirements are derived from the Use Cases.

An important thing to remember when creating the Event Model is to keep it independent of technology. It needs to address “what we do” and not “how we do it”. Doing this will help you envision more design alternatives than you would if you locked in a solution at the requirements level.

In the next post I will give you a closer look at how to create a Context Diagram and utilize it to get the requirements discovery rolling.

Requirements Analysis Using Event Response / Use Cases: Business/Project Objectives

Professor of Project Management Project Planning, Requirements Analysis , ,

Planning

If you search this site using the keyword “objectives”, you will see my prior posts on the importance of documenting your Business and Project Objectives, as well as how to properly define them. Those posts framed objectives in the context of the Project Management process. Having the objectives defined is also critical in the requirements analysis process.

Here are some of the key reasons for knowing your Business and Project objectives in advance of your requirements analysis:

  1. Ensure that everyone on the project team understands the project vision. There is a saying in the military that “no plan survives contact with the enemy”. That is also true for projects (where the “enemy” is usually time and resources). However, if everyone understands the commander’s intent (the “objectives”), then it is easier to change and adapt the plan. Conditions may make you unable to execute the original plan, but you are always responsible for achieving the commander’s intent.
  2. The Objectives guide everyone’s decision making. There are many decisions made each day on a project. They are made by everyone on the team, not just the management. Along with empowering people to make decisions, you must give them the tools to make the right decisions. Chief among those tools is making sure they know and understand the Business and Project Objectives.
  3. The Objectives are used to validate the Requirements Model. At the end of the first round of analysis, you will compare the results to the documented Project and Business Objectives. Do your requirements address all the deliverables in the Project Objectives? If not, another round of analysis is needed. Will the requirements achieve the Business Objectives? If not, understand why. Has your analysis revealed additional Project Objectives? If so, these must be addressed in your Change Management process in order to change your Project Charter.

In the next post I will define the Event Model, with subsequent posts addressing each element in detail.

Requirements Analysis Using Event/Response and Use Cases: Analysis Sequence

Professor of Project Management Project Planning, Requirements Analysis , ,

Planning

Getting requirements right is a process. Your business stakeholders will rarely (if ever) be able to give you all of their requirements without some method of generating relevant questions to draw the requirements from them. What I am going to present in this and the following posts on this topic is NOT a new way to document your old thinking. It is a new way to think about requirements.

The deliverables created from this approach are:

  • Identification of all processes in scope
  • Documentation of the specific Use Cases for each process
  • Identification of all of the stakeholders that interact with the business processes
  • Creation of a framework with which you can generate and execute your test cases

Many analysts start and end their requirements elicitation with “functional requirements” (e.g. “I need to search by Last Name” or “Requests for time off need to be approved by the manager”). In the Event/Response/Use Case approach, functional requirements are derived from the Use Cases at the end of the analysis process.

The analysis sequence is as follows:

  • Business Objectives
  • Project Objectives (1st cut)
  • Event Model
  • Project Objectives (verified)
  • Use Cases
  • Functional Requirements

In the next post, I will discuss how the Business and Project Objectives are defined and used in the Event/Response methodology.

Risk Management Deeper Dive Part 2: Risk Prioritization

Professor of Project Management Project Execution and Monitoring, Project Planning ,

Executing Monitoring and Controlling

After you have identified your risks, the next step is to prioritize them. We do that by assigning a probability rating and an impact rating, then combining the two to determine your exposure (i.e. priority).

The Risk Probability is a measure of the likelihood of the risk occurring. In most cases it is difficult to assign an exact probability. It usually will be sufficient to define probabilities as “High”, “Medium”, and “Low” and define these probabilities as ranges. Here is an example of the ranges I typically use:

  • High = 70% or greater probability
  • Medium = between 40 – 69 % probability
  • Low = less than 40% probability

You can use whatever definition you choose as long as all of the parties helping you assign probability are aware of the defined ranges.

The Risk Impact is a measure of the effect of the Risk occurrence on the schedule, scope, budget and quality of the project. Again, since in most cases this may be difficult to quantify, using ranges represented by “High”, “Medium” and “Low” will suffice. Here is an example of range definitions for Risk Impact:

  • High = greater than 10% impact on one or more of schedule, scope, budget and quality
  • Medium = 5-10% impact on one or more of schedule, scope, budget and quality
  • Low = less than 5% impact on one or more of schedule, scope, budget and quality

The Risk Exposure is a product of both the Risk Probability and the Risk Impact. It is also measured as “High”, “Medium” and “Low” if that is the way you defined the probability and impact. Here is how the Risk Exposure can be determined:

  •  Probability (High) + Impact (High) = Exposure (High)
  •  Probability (High) + Impact (Medium) = Exposure (High)
  •  Probability (High) + Impact (Low) = Exposure (Low)
  •  Probability (Medium) + Impact (High) = Exposure (High)
  •  Probability (Medium) + Impact (Medium) = Exposure (Medium)
  •  Probability (Medium) + Impact (Low) = Exposure (Low)
  •  Probability (Low) + Impact (High) = Exposure (Medium – but watch closely due to impact)
  •  Probability (Low) + Impact (Medium) = Exposure (Medium)
  •  Probability (Low) + Impact (Low) = Exposure (Low)

Now that you have your Risk Exposure determined you should monitor and act on them in order of exposure, with the ones rated “High” given the most attention. This will help you allocate your risk management resources appropriately.

Risk Management: Deeper Dive Part 1 – Risk Identification

Professor of Project Management Project Execution and Monitoring, Project Planning , ,

Executing Monitoring and Controlling

The first step in managing risk is to identify the risks you need to manage. This is the most important step in risk management and something new project managers tend to struggle with. I will present some techniques that have over the years have worked well for me.

  1. What worries you? – You can ask this question to your project team members and stakeholders. Do this first individually, then in groups. Many do not understand the term “risk” as it applies to projects and may come up with a blank if you ask them about risks. Everyone can relate to the term “worry” and I have found this helpful. You may get answers such as “I don’t have enough resources” or “the timeline is too tight” or “I don’t have enough expertise on my team in this area”. These types of answers are a great start in risk identification.
  2. The “Pre-Mortem” – we are familiar with doing “lessons learned” and “post-mortems” on projects. Doing a “Pre-Mortem” can help identify risks. You ask the project team and stakeholders  “It’s 9 months from now, the project is over and it was a disaster. What are the reasons?”. Your mind works better at identifying risk when looking backwards so this technique can be very effective. You may get responses like “The Sponsor wasn’t involved in decision making” or “We didn’t train the staff on the new tools”. These types of answers are risks that need to be managed. You can also ask the opposite question: “It’s 9 months from now, the project is over and it was wildly successful. Why?”. Responses like “John Jones was assigned as the technical lead” or “The Steering Committee made prompt decisions” will help you identify risks and mitigate them.
  3. Risk Breakdown Structure(RBS) – if you Google this term you will find many examples. An RBS is simply a hierarchy of areas in which risks can occur. You would present each of these areas to the team and brainstorm potential risks for each area. Here is a sample RBS:

Technical

Technology

Complexity of Interfaces

Performance and Reliability

Quality

External

Vendors

Regulatory

Market

Customer

Weather

Environmental

Government

Internal

Dependencies on other projects

Resources

Funding

Requirements

Resistance to change

Inexperience

Schedule

Equipment

Quality

Customer satsifaction

Project Management

Estimates

Plans

Controls

Communications

Scope

——————————-

You should state your risks in a consistent manner. A common way to phrase your identified risks are: “If (risk event occurs), then (impact to project in terms of scope, schedule, cost, quality)”

Here is an example: “If the vendor is late delivering Component X, then we may not be able to meet the project milestone for the first build”. Note that I stated “may” not “won’t”. Remember, risks are probabilities, not certainties. If it is a certainty, it is an issue, not a risk.

Risk Management Deeper Dive – Introduction

Professor of Project Management Project Execution and Monitoring, Project Planning ,

Executing Monitoring and Controlling

When I teach project management principles to non-professional PM’s, I emphasize that the two things you must do to greatly increase your chance of success are (1) create a complete Project Charter, and (2) manage risk. Those two practices, when done well, contribute to the bulk of project success.

In previous topics I discussed Risk Management in two places:

  1. The Project Charter
  2. The Project Management Plan

In the Project Charter, only the initially identified high exposure risks are typically listed and you may not yet have fully developed mitigation and contingency plans. In the Project Management Plan, the Risk Management Plan describes the process of risk management but it does not address the specific risks.

In the “Risk Management – Deeper Dive” series, I will present the following topics in detail:

Part 1: Risk Identification

Part 2: Risk Prioritization (probability/impact/exposure)

Part 3: Risk Triggers

Part 4: Risk Mitigation Strategies

Part 5 : Risk Contingency Plans

Part 6: Risk Ownership

Part 7: Risk Monitoring

Managing risk is a key project management best practice. I strongly suggest you make this one of the first areas of mastering project management.

The Project Schedule Part 7: Schedule Adjustments

Professor of Project Management Project Planning ,

Planning

After you have created your initial cut of the schedule, you will often find that this schedule will not meet the target date. Adjusting the schedule and adapting to changing circumstance is where Project Managers earn their money.

Here are some of the actions you can take:

  • Focus on the tasks that are on the Critical Path
  • Revisit the estimates – do some of the estimates have more safety time built in than is needed? Where can you reduce estimates and not take on more risk?
  • Fast-Tracking – look at activities that you have scheduled in sequence due to assumed dependencies. Can you do some of these in parallel or at least have some overlap? For example, you might have “Solution Construction” following “Design” but in reality you can start building some of the solution after some (but not all) of the design is completed. Fast-tracking is a very common practice and you will use this on most large projects.
  • Crashing the schedule – this is where you throw additional resources at critical path tasks without regard to efficiency or budget. If meeting the target date is imperative, this is a useful tactic. It is best to plan for this contingency when you are doing your Risk Management Plan in order to have contingency funds in the budget that you can draw on in case the schedule risk is triggered.
  • Obtain stronger resources – you can examine the critical path task assignments and look for opportunities where more experienced and knowledgeable resources would allow you to substantially reduce the task estimates.
  • Reduce Scope – review the ranked requirements and obtain Sponsor approval to remove or delay requirements that are not essential for the initial go-live date.
  • Sacrifice Quality – you can ask the Sponsor for approval to reduce test time for functions that are used rarely or are not business critical.

You are likely to use some or all of the tactics listed above in any project of significant size. It is a critical skill for Project Managers.