Project Planning

Requirements Analysis using Event/Response and 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.

Requirements Analysis using Event/Response and Use Cases – Overview

Professor of Project Management Project Planning, Requirements Analysis , , ,

Initiation

This is the start of a multi-part series on my favorite requirements elicitation technique: the Business Event/Response Analysis. Early versions of this methodology were developed in the late 1980’s by some of the great system development minds of that era. Since then it has evolved and I have adapted it to meet the needs of whatever organization in which I am working.

There are some that think you can gather requirements by just asking the sponsors and users “what do you want?”. Needless to say, this method will generate incomplete requirements and tends to start and end with functional requirements. In the latter half of the project when large requirements gaps are discovered, the sponsors/users blame the analyst and vice versa.

When I teach on this topic, I tell the analysts it is their responsibility to gather complete requirements. Given this, we need a method that will (1) generate the appropriate questions to ask, (2) ensure that we have the complete set of requirements, and (3) allow us to derive the functional requirements from the model.

The Business Event/Response method meets these desired outcomes. The advantages are:

  • It helps the Business Analyst create the questions needed to draw the requirements from the Business Owner, even if the Analyst has no knowledge of the business area.
  • It organizes the requirements in the context of Business Processes and Usage to promote better understanding.
  • The output serves as a starting point for defining the testing scope and scenarios.

In the upcoming posts I will describe this method in detail.

Risk Management Deeper Dive Part 3: Risk Triggers

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

Executing Monitoring and Controlling

In this series Part 1, I addressed Risk Identification. In Part 2, I addressed Risk Probability, Impact and Exposure. In this entry I will discuss the concept of the “Risk Trigger”.

An important aspect of Risk Management is knowing and detecting that the risk has occurred. This is know as a “Risk Trigger”. In some cases it may be obvious. An example of this would be a risk such as “If the project team loses key resource “A”, then the task estimates assigned to “A” will need to be extended which may impact key milestone commitments”. In most cases the PM will know when they have lost a key resource. However, in the case of very large project teams, the key resource may be embedded deep in the project hierarchy, hiding the loss unless there is a communication plan to notify the PM

Your risk triggers must define the method you will use to monitor the risk. For example, if there is a possible change to a government regulation that will impact your project, you can engage your Legal team to monitor the status of this regulation on a regular basis and report any changes directly to the PM.

Here is another example: if there is a risk your server capacity is insufficient to meet peak demand, you might direct your technical team to establish monitors for CPU and disk usage and raise a flag if they are approaching the safe limits.

The lesson here is don’t assume you will just know when a risk has occurred. Define Risk Triggers (even the obvious ones) for all of your risks.

Now that you know your risks, exposures, and when they occur, the next step is to manage them with mitigation and contingency plans. I will tackle these topics in the upcoming posts.

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 this order, with the ones rated “High” given the most attention. This will help you allocate your risk management resources appropriately.

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 a Project Manager earns 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.

The Project Schedule Part 6: The Critical Path

Professor of Project Management Project Planning , ,

Planning

With tasks, resource assignments, durations/effort and dependencies defined, your project scheduling software will create a schedule. The path of dependent tasks that in aggregate take the longest amount of time is called “The Critical Path”. This is because if any one of these tasks is completed later than originally scheduled, your project end date will move.

When you are in the “Execution and Monitoring” Phase of your project, regular examination of the state of your critical path tasks is a top priority. It is important to routinely check in with the assigned resources to determine if the “days to completion” is still valid. If you wait until the task is late, it will be too late to do anything about it. Your only choice would be to examine the other tasks on the critical path to see if any task times can be reigned in to make up for the lost time. We will examine techniques you can use for this in the next post.

A technique you can use to make your critical path less volatile is to estimate your individual tasks more aggressively and aggregate the extra time you would have assigned to individual tasks into one “critical path buffer”. If critical path tasks come in early, you can add the time saved to the buffer. If critical path tasks come in late, you subtract time from the buffer. Using this technique, your schedule will not move with any one late task and it will encourage team members to work faster and ignore distractions. Also, the health of the buffer would be the key metric instead of the health of each individual task.

You can measure the health of the critical path buffer with two metrics:

  1. % or original buffer remaining
  2. Divide the “% of elapsed project time” into “% of buffer used”. If this is a number less than one you are tracking well. If it is greater than one it is an early warning sign to take action

For example: Your project has used 30% of it’s original buffer but you are only 10 weeks into a 50 week project (only 20% of the project schedule has elapsed), You divide 30%/20% and this equals 1.5 (greater than one) meaning you need to take remedial action.

If your project only used 15% of your original buffer, 15%/20% = 0.75, which is less than one indicating a healthy schedule.

When using this technique, it is very important to regularly update the “days to complete” for each critical path task so you can have confidence in the status of your buffer.

Whatever technique you use, constant monitoring of the health of the critical path is one of the most important tasks for the Project Manager.

The Project Schedule Part 5: Dependencies

Professor of Project Management Project Planning ,

Planning

Now that you have your lowest level scheduled tasks defined and have assigned resources, it is time to define the dependencies between tasks. This is where MS Project really comes in handy as it will create the schedule for you based on task dependencies and resource availabilities.

There are four types of dependencies:

  • Finish to Start – This is the most common and the default in MS Project. The predecessor must finish before the successor can start. For example, “Applying Primer” must finish before “Painting” can start.
  • Start to Start – Predecessor must start before the successor can start. For example “Mortgage Application” must start before “Credit Check”.
  • Finish to Finish – Predecessor must finish before the successor can finish. This can be true of tasks that run in parallel but both are needed for the subsequent task.
  • Start to Finish – Predecessor must start before the Successor can finish. This one is rarely used and frankly should be avoided.

When you initially define the dependencies, take care to only define “true” dependencies. If you have one person assigned to all the tasks you may be tempted to make all of the tasks dependent since the resource must complete one before starting another. Don’t do this. Let MS Project do this via resource leveling. The reason for not doing this is you may get additional resources later so some tasks can run in parallel. If you made them all dependent, the schedule will not show this possibility.

MS Project can now take your tasks, resource assignments, estimates and dependencies and create an initial schedule. I say initial because you often will find with your first cut that the finish date does not occur within the Sponsor’s expected time frame. In the next topic I will discuss the concept of the “Critical Path” and what the Project Manager can do to rein in the target date.

The Project Schedule Part 4: Resource Assignments and Estimates

Professor of Project Management Project Planning ,

Planning

Once you have defined your Work Breakdown Structure (WBS) the next step in creating a schedule is to assign resources and estimates to each task (the lowest level items in your WBS). A starting point in assigning resources is to consult the “Roles & Responsibilities” matrix you created as part of the Project Charter. You are looking for the stakeholders that are in the category of “helping you execute your project”.

You may find that some WBS tasks need resources that have not yet been specifically identified as assigned to the project. In this case you will meet with the managers of the areas that have the resource expertise and agree on the assignment. In other cases you may need to contract for professional services. This should have been included in your Project Budget and the Procurement Plan. If not, you will have to use the formal Project Change Management process to alter the budget to include these services.

Microsoft Project allows you to assign resources to a task. You can also assign the percentage of the resource’s time that will be dedicated to the task. In addition, you can assign more than one resource to a given task.

Once you have resources assigned to a task you can attach estimates. You can estimate using “Duration” (the length of time the task will take independent of the resources assigned) or “Effort” (the amount of hours or days a task will take given undivided attention of the resources). Which one you use will depend on the type of project, type of task and organization culture. As a general rule I like to use “Effort” and let MS Project calculate the duration given the resource percent allocation and other tasks assigned to that resource.

When defining estimates, take into account the expertise of the resource(s) assigned to that task. An expert resource may complete a task much faster than a novice. Sometimes estimates are placed on a task prior to the resource assignment to get an idea of how the schedule will look. If you do this, remember to re-estimate once the specific resource is assigned.

There are many techniques to creating estimates. I will not address them all here. The most common are:

  • We’ve done this task before so we know how long it takes
  • The assigned resource supplies the estimate
  • A small group of people with expertise in that task are asked to independently estimate the task, then the group discusses the discrepancies and comes to a consensus
  • Management may dictate the duration of the task in which case the PM may have to assign resources with more expertise or add resources (if feasible) to meet the deadline.

You can also use a 3-point estimate (optimistic, pessimistic and most likely) and calculate your estimate using PERT (I recommend you Google this term for the details). For a more advanced scheduling technique, you can investigate “Critical Chain and Buffer Management”. This is an advanced technique that will need organizational buy-in from the top down.

The Project Schedule Part 3: Work Breakdown Structure (WBS)

Professor of Project Management Project Planning ,

Planning

A Work Breakdown Structure (aka WBS) takes high level deliverables and breaks them down into lower-level activities suitable for assigning, managing and scheduling work. Creating a WBS is the first step in creating a schedule.

To build a project schedule, you must first define all of the activities that are part of the schedule. If you have created a Project Charter and a Project Plan, you have rich sources of information with which to define the deliverables and the activities needed to produce them.

The Project Charter contains the Project Objectives, which are products, services or results that the project will produce and will survive after the project is over. These are the ultimate deliverables of the project. The Business Objectives contain “Measures of Success” which may require the project to build measurement tools and processes. The Scope section contains high-level activities which can be broken down to smaller pieces for scheduling.

The Project Plan contains the “hows” of the project and most or all of the key project activities were defined there. As the Project Manager, you will need to decide at what level you will define the activities for scheduling purposes. As I mentioned in an earlier post, I am not a fan of Project Schedule’s that contain a large amount of activities as you will wind up putting more effort into schedule maintenance than the benefits you derive.

One common way to define the activities (create a WBS) is to start with the project deliverables and work backwards from there, asking the questions “What inputs are needed for this activity?” and “What activity creates each input?”. For example, for the Requirements Document deliverable, you need final approval. To get final approval, you need to conduct a review meeting. To conduct a review meeting, you need to schedule it. To schedule it, you need a draft document. To get a draft document, you need to write it. To write it, you need to schedule and conduct requirements gathering meetings. And so on until you reach the very first activity which either needs no inputs or the inputs have already been created.

If the deliverable is simple enough you can start from first activity and drill forward. Either method should work. For activities that are not yet well understood or defined, you can define high-level placeholders in the schedule and add the activities needed to obtain the understanding.

Once you have all of the activities, you will work on assigning the resources to the activities and defining the dependencies between activities. I will cover these topics in the upcoming posts.