4squareviews

1.  INTRODUCTION

This webinar is part of the Advanced Project Management series of webinars sponsored by Project Insight, which produces Project & Portfolio Management Software.  The webinar today is about validating requirements, a technical but vital subject for project managers, especially those in the IT field.  It is presented by Janelle Abaoag, who is the Marketing, and Public Relations coordinator, as well as Diane Altweis, the CEO of Core Performance Concepts. 

The Advanced Project Management series is to designed to

• Expand knowledge of more complex tools & techniques
• Build leadership skills to manage people more effective
• Identify practical methods to begin using advanced techniques
• Explore other methodologies and/or techniques that enhance PM competency

Here are the objectives of the webinar:  by the end of this webinar, you should be able to

• Define what validation means as it relates to project delivery
• Define team roles and responsibilities as it relates to requirements
• Identify the types of validation necessary for your project
• Develop action plans to validate key components of the project

2.  REQUIREMENTS GATHERING

Collecting the requirements is a matter of defining the business need for the project.  You need to ask yourself some basic questions.  What is the project we are working on, why are we doing it?  What is the need we are trying to fulfill?

To fully understand the problem, you need to know not just what you are doing, but WHY you are doing it.  The project should be something that is needed in the organization to respond to a problem that needs to be resolved.

Understand what your expected outcome is.  Let’s say you are manufacturing facility and you take 10 days to produce product, and the competition can do it in 7 days.  Is the problem really that you need to reduce your cycle time to 7 days or less?  Let’s say the problem is that the competitor has a larger capacity.  To reduce cycle time you need to understand what the problem is, and how you solve it.  You can’t ASSUME that solving the problem requires reducing cycle time; maybe it’s because you have a higher quality product than competitors.  If you reduce the cycle time, are you willing to trade product quality in order to do so?

 

Requirements gathering need someone who has excellent interviewing skills, has persistence, and can chip away at getting to the requirements.  Sometimes we plan for one session to take care of requirements gathering, but in reality, most people can’t disseminate or regurgitate all the information in one session.  One week later you may think of new ways to look at problem.

3.  PRODUCT DOCUMENTATION

These are the elements of product documentation that are needed on the front end of the project:

• Project charter
• WBS
• Business requirements
• Functional requirements
• Non-functional requirements—performance of a new system.  does it have to perform 24/7.
• Requirements traceability matrix
• Design requirements

These elements of product documentation should come AFTER requirements are spelled out clearly.

• Technical Specifications
• Use Case with Diagrams and Descriptions
• Test Plans
• Training Documents

4.  VALIDATING REQUIREMENTS

The definition of validation is “a technique of evaluating a component or product during or at the end of a phase or project to ensure it complies with the specified requirements.”

To do that we need to understand the following:

• the needs of the business,
• the problem that is being solved,
• the expected outcome.

All of the above is what we are trying to validate.

Let’s use an example of a website.  There is a screen with fields.  You may validate that the fields are there in the right place, and that all the data put in the field has the right attributes.  But you need to check to see that the screen ITSELF solves the problem, the underlying business need.  Does it meet the needs of the users?  You need to look at requirements with a microscope and a telescope, from details to big-picture issues.

This requires excellent analytical skills, an ability to visualize the solutions, and the proactive identification of requirements gaps.

Who writes the requirements on the project?  The project manager or a business analyst?  Or even the client (as a first pass)?  Who typically writes test plans?  If the person who writes the requirements and the person who writes the test plans are two different people, are those two parties talking to each other to see what is being tested and whether the tests validate the requirements?

You can’t put a test plan together in a vacuum.  The people writing the test plan need to be aware of the details of the business plan so they can validate whether the problem is actually being solved, and not just testing the details of the solution.  Does the screen capture all the information?  Is it easy to use?  Both the business analyst and quality assurance people need to work side by side.

5.  ROLES & RESPONSIBILITY FOR VALIDATION

Role	Responsibility
Project Manager (PM)	Ensure that the project ultimately delivers on the goals and objectives, and that the product of the project solves the business need.
Business Analyst (BA)	Identify business requirements and analyze the solution to determine how requirements can be validated either prior to or after project delivery
Quality Assurance (QA)	Perform validation tests (can be technical personnel OR business personnel)

 

6.  TECHNIQUES FOR VALIDATION

• Use a requirements traceability information as a starting point.
• Develop methods for validating business requirements and project objectives
• Budget as part of project the efforts associated with validating
• Identify who is responsible for measuring the solving of the business problem.

Less than 40% of all projects succeed.  As a profession, we still don’t have high success rate for projects in general.  We aren’t focused on solving the business problem.  The product of the project doesn’t always meet the expectations.

7.  VALIDATING YOUR PROJECT OBJECTIVES AND REQUIREMENTS

Share your goals, objectives, and business problem with your BA and QA team.  You want to make sure that your project achieves your goals and objectives.

It’s more than just meeting requirements.  We have to assess the probability of achieving the goals and objectives of the project. Let’s take the earlier example of cycle time.  Assumption:  the 10 days that we are currently taking to deliver products is the problem.  We want to get it down to 7 days.  Do we validate during the course of the project that we are actually reducing cycle time.  We want to, say, streamline this process, so that it should reduce it to 7 days.  You have to PROVE that it is reduced to 7 days.

Many people are in IT.  When you are under the gun to deliver on time, you jump to reducing scope.  When we do that, we increase the probability of us not achieving our goal because you are taking some level of scope that was needed to actually deliver on objectives.  By reducing scope, we are ADDING RISK of achieving our ultimate goals.  This is why 60% of project continue to fail.

Let’s take an example of building a website for a wine bar.

The project is to create a website to increase product revenue for a wine bar within one year of website launch.

Are objectives are:

• to increase revenues by at least 10% within one year.
• to increase customer base by at least 5%
• maintain or increase EXISTING customer purchases by 5%

What happens if you don’t have a separate person doing the PM, BA, and QA roles?  Sometimes it is more important that you know what SHOULD be happening in the real world than it is to get that extra person on the team.  It could be that the BA can do the work on the QA portion as well.  You need to recognize the role that you are playing.  Separating out the roles is important in getting more resources, but you may have to wear more than one hat.

Out of three primary measures of success–time, cost and quality–time might be the most important issue with most products, but with medical devices, it might be quality.  Define it in project charter which of these measures of success are most important.  .

In the case of the wine bar, when it launches is not important.  But when it does launch, revenue should increase within one year.

Here’s an example of the requirements for this project.

OBJECTIVE	REQUIREMENT	VALIDATION APPROACH
Increase revenues by 10%	Websites will offer food products in addition to wines that are complementary.	Calculate monthly revenue 1 year prior to website launch to be able to track monthly increase in revenues.  The sum of the 1st year after implementation should be 10% higher than the sum of the prior year.
Increase customer base by at least 5%	Website will have a quick referral program that allows existing customers to refer friends by only entering in an email address	Determine quantity of current customers purchasing products either on website or elsewhere at the time of website launch.  Compare the prior customer list with a customer list one year after website launch.
Maintain or increase existing customer purchases by 5%	Website gives existing customers quick access to prior purchases and allow re-purchase within 5 clicks.	Determine the revenue per client for a calendar year prior to website launch.  One year after launch recalculate average revenue by client.

 

The BA and QA have to come up with tests that show that the purpose is fulfilled.  If information or a data baseline do not exist, you need to create it as part of the project so that the results can it can be measured against the baseline through the course of the project.

The question is, how can you prove that the website is the cause of increased revenue as opposed to some other cause.  If only thing you are changing is offering food products, the increase in food products should give you an indication that website is effective.  It’s hard to prove causality if you change too many things at once.

How do you validate requirements for new products?  You need to do market research:  what is the company expecting for that new product?  If it is a new product, you have a marketing team that is tracking revenues of that new product.  As PMs ,you normally aren’t following the lifetime of product after launch; however, you SHOULD maintain relationship with marketing to let the project team know that the product is doing well, to let team know that it made a difference.

8.  VALIDATING THE SOLUTION OF THE BUSINESS PROBLEM

The ultimate objective of the project needs to be achieved, so you need to think of measuring things beyond the end of the project, so that you know that the product was a success for the organization.

What we do as PMs is critical to the strategic growth of organizations.  Projects need to be delivered on time, on budget, with specified quality levels.  That is a contribution to the organization.  If we don’t deliver it on time, the company cannot achieve those goals.  So you have to be conscious of the business need.  You need to PROVE that project was delivered at the level it should be.

For example, if revenue growth year after year is the business problem, then the validation can include the following elements:

• Goal:  10% revenue growth annually baseline:  $1,000,000
• Responsibility:   Accounting department to report to CEO
• Timeline:  within one year

So the validations developed for goals and objectives can be used as tools for the overall business problem.  You need to make sure that the company can measure success, however, with the current reports and tools available.  If not, you need to develop them.

In summary,

• An objective should be defined to solve the business problem.
• Every requirements should point back to address an objective.
• Every requirement should be able to be validated.
• Every requirement in the requirement traceability matrix should have an owner.

You should be able to PROVE at the end of the project that all requirements have been met.  You may not be able to prove it perhaps when the product is launched, but you need to get everything in place so that you CAN prove it, say, one year from now.   It usually does take time beyond the project delivery to determine success.

Use requirements traceability information as a starting point.  What about requirements that were met but in a way that didn’t meet the project owner needs?  Having iterations and involvement throughout the project life is very important.  Many times it is difficult to get through requirements meetings, anything like prototypes, design layouts, will help get the project owners on board.

9.  INTEGRATING REQUIREMENTS VALIDATION WITH AGILE METHODOLOGY

You will always have a problem with not being able to measure things until after the project.  For example, if there is an ease of use or usability requirements, with agile, you can get feedback from user groups to make sure your requirements actually solve the problems.  People like to throw extra requirements in there that don’t meet the project objectives.  Your role as PM is to make sure that EVERY requirement that is being proposed is tied to one of the objectives.

 

Filed under: Uncategorized |