ICPM

This email address is being protected from spambots. You need JavaScript enabled to view it. This email address is being protected from spambots. You need JavaScript enabled to view it. The International Community for Project Managers
Brought to you by TenStep, Inc.
2363 St. David's Square
Kennesaw, GA 30152
877-536-8434 or 770-795-9097

This email address is being protected from spambots. You need JavaScript enabled to view it.
You are here: Home Blogs Creating Clear Project Requirements (1 of 5)
Thursday, 22 January 2009 14:17

Creating Clear Project Requirements (1 of 5)

Written by 
Rate this item
(0 votes)
Differentiating “What” from “How” Requirements Definition: Through our experience working with project teams, in many industries, on hundreds of projects, we recognize that although Project Managers may understand the theory for developing project requirements they don’t have viable tools, techniques or processes for enabling project stakeholders to clearly define their needs and the expected outcomes for the project. On many projects, the requirements definition effort can take months or, in extreme cases, years to complete before any tangible benefits are realized by the project effort.  In this case, it is not uncommon for the environment the project was originally established under to have changed.
All too often, project teams dive into the solutions they want to implement before ever gaining alignment on and fully understanding the underlying needs they should be solving for.  Many times project team members believe they can save the team time by starting with a solution, rather than starting at the beginning of the project and defining the needs.  These “silver bullet” solutions rarely pan out.  In fact, this often results in project teams implementing what appears, on the surface, to be a great solution, but in reality is a solution that fails to address the true needs of the organization.

Project requirement definition requires a progressive elaboration approach.  This approach starts with high level definition of the project scope, which sets the boundaries for areas within the organization that are anticipated to change.  Then, the team expands on the scope statement by collaboratively uncovering the need statements to be solved for (business requirements). Finally, the team can drill down to a technical approach and appropriate solutions for satisfying the project needs.  This concept may seem simple, but unfortunately 71% of projects either fail outright, or are “challenged” – projects deliver fewer features and  functions than the customer expects, are completed over budget,  or are completed behind scheduled. (Standish Group, 2004)

The top four factors associated with project failure are:
  • Poor end user / customer involvement (stakeholders)
  • Poor executive management support
  • Improper planning
  • Unclear statement of requirements
This paper focuses on poor end user / customer involvement and unclear statement of requirements.  It will present tools and techniques that can be used to collaboratively build comprehensive and clear project requirement statements that differentiate between what is needed and how the need will be met. 

Project Requirement Definition Facilitated Meetings

Project teams struggle with developing clear requirement statements when they lack the tools and techniques to ensure there is appropriate stakeholder involvement throughout the requirements definition activity.  In far too many project environments, Project Managers do not possess skills enabling them to effectively engage all necessary project stakeholders, in collaborative meetings, to describe their needs for the project. As a result, on these projects, the Project Manager, or a small subset of project team members, write the requirements for the stakeholders.  These requirements are then routed throughout the organization in an attempt to gain alignment and buy in.  Often, the requirements are not uniformly understood and do not represent the full breadth of the project needs.  This can lead to costly rework later during the project lifecycle, or after the project implementation, when these missing or misunderstood needs are identified.

JAD (Joint Application Design) facilitated meetings effectively improve the requirements definition activity by incorporating collaborative meeting and group management techniques led by a neutral facilitator (i.e. someone without a stake in the project outcome).  These facilitated meetings engage all the appropriate stakeholders as participants who collaboratively meet, make decisions and interactively build their project requirements.

To increase the success of any JAD meeting, it must be fully planned prior to starting the meeting. Planning enables the project management team and the Facilitator to set expectations and agree on the deliverables, activities to be created, and techniques that will be used to produce project requirement deliverables, during the meeting. The Facilitator conducts the meeting, using collaborative techniques to collect information, validate this information, and continually adjust it to ensure it is clear, complete and addresses the needs of the project. The results of facilitated JAD meetings are consensus among participants, ownership and buy-in on all decisions and deliverables produced during the meeting.




Creating Clear Project Requirements – Differentiating “What” from “How” Requirements Development (2 of 5)

Foundation for Successful Requirement Development

Project Stakeholders
Project stakeholders must understand and be aligned on the boundaries of the project effort before the first requirement statement is ever written. This is accomplished when the project stakeholders work together to define the scope of their project. 

Project teams choosing to bypass the creation of a Project Scope Statement are often operating under false assumptions, such as:
  • We talked about the scope when we kicked off the project, so people already understand the scope
  • We have a small project team, so everyone is already aligned on what we are doing and why
  • We have to implement a solution quickly, we don’t have time to document scope.

Project stakeholders include anyone with a vested interest in or anyone who is impacted by the project.  Key representatives from each of the project stakeholder areas, internal and external to the organization, should be engaged in the project scoping requirements definition activities. For purposes of this discussion, project stakeholders are grouped into two different categories: Business / End Users and Technical / Solution Providers.

Project Scope Statement

Without a clear project scope definition, the project stakeholders lack critical information needed to determine if any requirements are missing, if the solution proposed can be implemented, if the requirements effort has expanded beyond the expected areas of change (i.e. scope creep), or whether requirements discovered as the project progresses should be included or excluded from the project effort.  The requirements definition activities can result in random collection of business need and solution statements that may fall into an unconstrained project effort. Think of this as a funnel where only some of the business needs and some of the solutions work their way down through the funnel to the implemented product or project solution. Business needs and solutions are not necessarily linked together. (Exhibit 1) Critical needs and solutions may remain outside the project effort, only to be discovered after the project implementation, or too late in the project lifecycle to include them without major rework and impacts to the project schedule and budget.

exhibit_1_project_requirements_developed_without_a_defined_scope_statement.png

Exhibit 1: Project Requirements Developed Without A Defined Scope Statement
 
The starting point for differentiating project “What’s” from project “How’s” is the creation of the Project Scope Statement.  The Project Scope Statement defines the project boundaries by describing what impacts the project will have on the organization, what parts of the current processes will be impacted, what interfaces are included in the project effort, what limitations will constrain the project effort, what factors will the project success be measured on, and what assumptions exist that the project team is operating under. Understanding all of these high level “What’s”  provides the foundation for the project team to make decisions regarding which requirements to include in the project and which solutions best support the direction of the organization. The most accurate Project Scope Statement, offering the highest value to the project team, is one developed by all the project stakeholders, not just the Project Manager. 

The Project Scope Statement generally includes five specific deliverables. Once these deliverables are defined, they will guide the project team as they drill down into lower levels of requirement definition activities. (Exhibit 2) The Project Scope Statement includes:  
  • Objectives (Business and Project)
  • Context Diagram – differentiating Business Processes and External Entities
  • Project Constraints
  • Critical Success Factors
  • Project Assumptions

 
exhibit_2_project_requirements_developed_with_a_defined_project_scope_statement.png

Exhibit 2: Project Requirements Developed With a Defined Project Scope Statement

When asked to facilitate requirements definition activities for customers who will not invest the time to create the entire Project Scope Statement, we require the project team to define, at a minimum, the Objectives, Context Diagram, and Project Assumptions.  Business and Project Objectives enable the team to understand changes the organization is attempting to achieve (increase, reduce, or improve results of the organization) and the specific project efforts that will be funded to help the organization achieve these results.  The Context Diagram will identify the organization’s Business Processes expected to be changed by the project and the interfaces, or hand-offs, that need to be provided to external entities as part of the project solution.  The Project Assumptions will identify decisions outside the control of the project team which are believed to be valid, but may be invalid.  These decisions directly influence project requirements, including what is in or out of scope for the project.




Creating Clear Project Requirements – Differentiating “What” from “How” Documenting the “What’s” (3 of 5)

Requirements Definition – Documenting the “What’s” for a Project

Types of Requirements
At the highest level, every project has two types of requirements – Business Requirements (What’s) and Technical Requirements (How’s). Business Requirements define what the organization wants or needs to be able to do once the project is completed. They describe the changes in capabilities that will result from the project.  Technical Requirements, on the other hand, define solutions for how each project need will be satisfied. These solutions are directly linked to one or more business requirements. Many times, teams that implement a project that is missing expected functionality, started by defining solutions first because they assumed the needs were obvious and everyone was already aligned on the needs. Having everyone naturally aligned on the needs at the beginning of a project is rarely the case. Solutions implemented without a direct tie to a specific business need expose the project team to gold plating and possible project failure.  When faced with this situation working with our clients, we tell project teams that if everyone is already aligned on the business needs, it won’t take much time to formally write them down.  Ultimately, project teams realize, during the course of the activity to define the business needs, that they were not aligned at all! As project stakeholders define the business needs for their project, it is necessary to look beyond the obvious functional requirements covering the core business capabilities associated with the Business Processes on the Context Diagram. Stakeholders should also consider interface requirements, which are capabilities driven by the External Entities represented on the Context Diagram. Additionally, non-functional, or supporting requirements, can be uncovered by ensuring the meetings include participation beyond the core business stakeholders. Non-functional requirements vary by type of project and industry, but typically include:
  • Audit requirements
  • Security requirements
  • Information movement requirements
  • Reporting requirements
  • Information integrity (validation / edit) requirements.

Business Requirement Facilitated Meetings

The Project Manager should arrange to hold several  2 – 3 day collaborative meetings focused on defining the business requirements. Initially, the first business requirement meeting focuses on the higher level or “parent” requirements. Parent level requirements include conceptual needs across all of the Business Processes, interfaces and support requirement categories. The subsequent business requirement meetings drill down these “parent” requirements into detailed business requirements or “child” requirements.

To ensure the business requirement statements focus on project needs and not solutions, the meeting facilitator prompts the project stakeholders to begin each statement with the words “Ability to …” or “Ability for…” (Exhibit 3). Some project teams start their business requirements with the phrase – “The system shall provide the ability to”. We prefer not to start business requirements using the words “capability for the system to … or the system shall …”, as these words tend to steer the activity into solutions and technical capability discussions, rather than business needs and functional capabilities.

exhibit_3_parent_and_child_level_business_requirements.png

Exhibit 3: Parent and Child Level Business Requirements

Initially, business requirements are brainstormed without regard to which Business Process they fall under. After the brainstorm, the requirements are clarified and categorized under one Business Processes. If the stakeholders find they are unable to categorize the business requirement under just one Business Process they have a gap that needs to be resolved. This gap is a result of:
  • The business requirement is not specific enough and may need to be broken into multiple statements where each statement describes a need specific to the functionality associated with a Business Process
  • The business requirement is out of scope which is why it doesn’t have a Business Process it fits under
  • The business requirement is valid, but the team discovers there is a missing Business Process that should have been included as part of the Project Scope.  After securing approval to add the Business Process, additional brainstorming is needed to identify other missing requirements that belong to the new Business Process.

During the Business Requirement meetings the mix of business and technical project stakeholders consists of 90% business stakeholders and 10% technical stakeholders. We work with many customers who try to completely separate these two groups of stakeholders during the requirements effort.  They often believe business requirements need to be defined without the influence of technical solutions / limitations, or that the technical stakeholders simply do not need to be involved in the project until after the needs are clearly defined and “thrown over the wall” to the technical team to solve for.

While it is true that the business requirement definition activities should not be constrained, too early, with perceived technical limitations, value is added to the definition effort by including a representative group of technical stakeholders in the facilitated meetings. These stakeholders provide insight as to whether a business requirement is clear enough for the technical team to use when considering solution options later in the project.  They can also help identify when a requirement is too vague or appears to contain a solution.

The focus of the business requirement meetings is to ensure stakeholders agree on business requirements which state the needed business capabilities, without describing how to solve for the need. Statements that include information about files, feeds, tables, flags, indicators, architecture, etc. are solution oriented statements. Technical stakeholders should understand what the business wants to be able to do as a result of the project. When they hear the business stakeholders describe solutions as needs, they should ask what the solution will enable the business to do, what is the need.  This helps to lead the discussion back to the true business needs (What’s).




Creating Clear Project Requirements – Differentiating “What” from “How” Documenting the “How’s” (4 of 5)

Requirements Definition – Documenting the “How’s” for a Project

Once the project team is aligned on the business requirements, which clearly state the needs for the project, they are ready to expand the requirement statements to include solutions. By using the business requirement statements as the driver for documenting the project “How’s” and tying each solution directly to the business need, the team ensures the project includes only solutions that are in scope for the project. This minimizes the risk of using the project as a mechanism to justify a solution rather than address a defined business need.  By using this technique, solutions can be traced all the way back to the Business Processes that were expected to change and Objectives the organization expected to meet.


Developing the Technical Approach


Project Teams should begin defining project solutions by starting with the documentation of a Technical Approach consisting of broad concepts relating to the architecture and foundation of the solution. The Technical Approach is usually formulated outside of the facilitated meeting and contains information used to understand the context the technical requirements should fit within. The high level Technical Approach could include categories, such as:
  • Security
  • Information Management
  • Software platform
  • Storage.

When project stakeholders attempt to define solutions without alignment on the Technical Approach, the technical requirement effort can stall due to confusion over multiple potentially viable ways to address the solution and solve for the needs of the project.

Technical Requirement Facilitated Meetings

Project stakeholders should use collaborative facilitated meetings, scheduled over 2 – 3 day periods, to define the Technical Requirements. During the Technical Requirement facilitated meetings, the mix of project stakeholders flips to 90% technical stakeholders and 10% business stakeholders. Again, it is highly recommended to include both types of stakeholders in these meetings. Although technical stakeholders may be resistant, the intent is not to encourage business stakeholders to dictate how technical team should solve for the project solution. Business stakeholders provide value by confirming that the business need has not been missed or misconstrued in an attempt to drive to a solution. They also confirm, early on in the project, that if the proposed solution in developed it will in fact address the real business need and not create a negative impact on the business processes.

The solutions documented during the meetings are considered High Level Design (HLD) in most methodologies. The statements describe how the technical team will address each project need listing out each change they will make in the current environment.  The documentation in these meetings is not intended to delve into Low Level Design (LLD) where the team will describe detailed characteristics and attributes associated with their solution (e.g. file / report / screen / layouts, field sizes and attributes, etc.). Documentation of the technical requirements may also include technical assumptions.  Technical assumptions provide alignment on any scope limitations of the solution.

The vocabulary for writing technical requirement changes from the vocabulary for business requirements.  These statements should start with more specific verb phrases, such as:
  • Build a table to…
  • Add logic for…
  • Modify the procedure to…
  • Update a screen / report / file to include…

The change in verb phrases shifts the focus of the requirements from describing what capabilities or abilities are needed to how the capabilities will be met. Technical Requirements are defined for every business requirement included in the project scope. (Exhibit 4) With the individual business requirements serving as the driver for technical requirements, the project team ensures that every solution to be designed and implemented directly supports an agreed need for the project effort.

exhibit_4_technical_requirements_mapped_to_business_requirement_statements.png
Exhibit 4: Technical Requirements Mapped to Business Requirement Statements

Sometimes, multiple viable Technical Approaches exist for the project solution. When this situation exists, it is best for the project stakeholders to assess each approach individually, comparing them side by side and identifying Pro’s and Con’s, in an attempt to select one approach for defining the technical requirements.  If one Technical Approach cannot be determined as the most viable approach, the meeting facilitator will need to ensure that the stakeholders are aligned on the multiple approaches being considered.  The meeting discussion will need to document detail technical requirement statements for each Technical Approach being considered. As the details of each solution are clarified, it generally becomes easier for the project team to make a clear decision on one approach over another, or possibly discover a new or blended approach to meet the project needs.




Creating Clear Project Requirements – Differentiating “What” from “How” Summary (5 of 5)

Summary – Ensuring Requirement Traceability throughout the Project Lifecycle

By defining the boundaries of the project effort at the beginning of the project using the Project Scope Statement, the project stakeholders will have established the framework for making all future project decisions and tracing the evolution of the project requirement statements from high level business needs (“What’s”) to lower level solutions (“How’s”).  Project Managers need to ensure they engage representatives from all affected stakeholder areas to minimize the risk of overlooking critical project needs. As business requirements are defined across the breadth of the Business Processes, consideration for functional requirements, interface requirements and supporting non-functional capabilities need to be included.


To ensure business requirements are both clear and  in scope for the project, they must be mapped back to one Business Process defined during the project scoping activity. Creating a cross reference column for the Business Process on each requirement statement allows the stakeholders to quickly see and review related business requirements together. Project stakeholders will have the ability to cross reference business requirements to Project Assumptions and the Business Objectives, as well, by adding cross references to each uniquely defined statement.

When project teams drill down to the project “How’s” with technical requirements, they are literally expanding the business requirement statements by adding additional rows of detail under each business requirement.  Using this technique continues to ensure that solutions tie back to business requirement needs, which in turn map to Business Process, and ultimately Business Objectives.

When project teams clearly differentiate between project “What’s” and project “How’s”, they increase the quality of the requirements defined for a project, reduce the incidence of missed requirements and help prevent the implementation of unsubstantiated solutions that fall short of delivering expected functionality at the conclusion of a project.


References

Project Management Institute. (2004) A guide to the project management body of knowledge (PMBOK) (2004 ed.).  Newtown Square, PA: Project Management Institute.

Standish Group. (2004) Chaos Report 2004.  Retrieved on March 10, 2006, from http://standishgroup.com/sample_research/pdfpages/q3-spotlight-pdf

For more information on methods to close the gap on your projects between project management theory and practical tools and techniques to apply this theory, contact Solutions Cube Group at http://SolutionsCubeGroup.com 

Read 21305 times Last modified on Monday, 07 December 2009 04:31
Login to post comments

News and Promotions

Keep up to date with the latest happenings by signing up for our newsletter. Subscribe below.

Twitter Update

Who's Online

We have 399 guests and no members online

Got something to say?