Chapter2-1:Receiving a Project Request
Initiation is the formal authorization of a project and is the only process in the Initiation process group.
Before you can initiate a project, you need to have a request. A number of events can drive a new project request. These requests fall into one of the following categories:
-
New product development to meet a market demand
-
Internal business need, such as a new invoice system
-
External customer request
-
New technology
-
Legal requirement
-
Social need, such as infrastructure in a developing country
The manner in which a project request is received can vary widely in different organizations. Requests may come from inside your corporation or from external customers. Your IT organization may have business analysts who are assigned to work with various departments and proactively document departmental requests. The company may have regular interdepartmental meetings to discuss future IT projects. The person from another department making a request for an IT project is often referred to as the client or the customer. We have found that some organizations use the term customer only to refer to people external to the company, while others use customer to refer to the source of either internal or external requests. You need to be aware if there is any distinction in those terms at your company. A customer (either internal or external) may take a project request directly to your VP or CIO.
Regardless of who initiates a request or the event that triggers a request, the organization must review the request and make a decision on a course of action. Even though an initial request may not be detailed, you need to get enough information to adequately evaluate the request. As project manager, you need to meet with the requestor to clarify and further define the request, identify the functional and technical requirements, and document the high-level requirements.
High-Level Requirements
To clarify any project request, you need to develop what the Guide to the PMBOK refers to as a product description . In IT projects, a product description is often referred to as high-level requirements .
The high-level requirements explain the major characteristics of the product and describe the relationship between the business need and the product requested. In order to develop high-level requirements, you need to understand the problem or business need that generated the project request, and the functions you are providing or supporting.
Before you jump into completing your high-level requirements, you need to make sure the problem or need that generated the project request is clearly defined and understood. If the problem is unclear, the solution may be off target. You also need to understand the different categories of requirements and the importance of obtaining both functional requirements and technical requirements.
Defining the Problem
Have you ever been on a project where people are working furiously to meet a deadline, but no one appears to know why the work is being done? Then halfway through the project everything changes or worse yet, the whole thing gets canceled? If this sounds familiar, it may be that a solution was being developed without clarifying the problem. A project can get off to a bad start if the project manager does not take the time to clearly define the problem or need generating the project request.
The customer request may be nebulous and loosely worded. Your job as project manager is to figure out what the customer really means. You need to investigate the customer request and communicate your understanding of the request. This may result in the creation of a project concept document, which represents your first attempt at restating the customer request to demonstrate understanding of the project.
Problems also arise when project requests are proposed in the form of a solution. It is not uncommon, especially in the IT world, for clients to come to you with a very specific request. A client has already identified the solution required to satisfy the request. You may be thinking that is great news, because there is no need to tie up your calendar with a lot of meetings. The problem is, your client may not be asking for the right solution. As a project manager, you need to make sure that the problem has been identified before the solution is proposed.
Let’s say that you get a request for a new billing system, which would be a pretty major undertaking. The first thing you should do is meet with the person making the request to get more information. Why does she need a new billing system? What functionality is the current billing system not providing? What business need or opportunity does she believe this new system will solve? These kinds of questions will help you to understand what is behind the new billing system request. If your client is concerned about the number of customer calls related to general billing questions, the best solution might not be a new billing system, but rather a clearer explanation of the charges or a bill insert explaining each line item on the bill. If she is interested in a new look and feel for the bill, you may be dealing with requirements that range from reformatting the current bill data to using a different paper to print bills. Numerous business needs may cause your client to want a “new billing system,” but many of them may have nothing to do with developing an entirely new application. That is why a good project manager asks questions to uncover what is behind a request. Lack of up-front clarification and problem definition has been the downfall of numerous IT projects. Do not assume that a customer-requested solution is always the best solution until you understand the business need. Clearly defining the problem up front will give you and the client a better starting point for identifying the functional and technical requirements.
Requirement Categories
Once you have a clear idea of the problem behind your client’s request, you must also understand what the client’s requirements/objectives/expectations for the project outcome are. You need to identify three types of requirements: functional, business, and technical requirements.
Functional Requirements
Remember from Chapter 1 that a project produces a unique product. Functional requirements define what the product of the project will do. Functional requirements focus on how the end user will interact with the product. The requirements for a client whose business need is a new bill format are going to be very different than the requirements of a client who wants to introduce a new product or feature. This why it is so important to have the problem defined before you start looking at specific requirements. Knowing the problem will assist you in asking the right questions to identify the client requirements. For a new bill format, you need to know how the client wants the bill to appear. What are the categories of charges and credits? For a new product or feature, you will need very different data. Will this be a one-time fee or a recurring rate or both? If there is a monthly fee, is it a fixed rate or does it vary by usage? Are there discount periods? Is there a contract period or a penalty for breaking the contract?
Applications being used internally are an area where you should use extra caution in defining the requirements. Your client may assume things will work in a certain fashion without explicitly stating that assumption as a requirement. Let’s use a new order entry system for sales consultants as our example. Your client has told you that the system needs to display product availability, generate sales reports, and include a help feature. Although these may sound like good requirements, they are missing some critical data. What drives the product availability? How will the sales reports be generated? What information is included in the help feature? By asking these questions you come up with the following requirements:
Although functional requirements can be stated in more general terms than technical requirements, as a project manager, you must ask questions to drive out ambiguity. If your client requirement states that a new sales system must be easy for the sales consultants to use, do you know what that means? If the answer is no, you do not have a clear requirement, and you need to define what “easy to use” means to the client. It could be the flow of the screens, built-in help, or other criteria. The client needs to clarify the meaning so the requirement defines the functionality that will make the system easy to use. If you are not sure whether you have a clearly defined requirement, ask yourself how you would create a test scenario to validate the requirement. If there is no way to validate that the requirement has been met, you need to get more data.
Business Requirements
An organization’s business requirements are the big picture results of fulfilling a project. Business results can be anything from a planned increased revenue to a decrease in overall spending. They can even mean that an organization plans to downsize as a result of a project’s outcome.
Technical Requirements
Technical requirements , also known as non-functional requirements, are the product characteristics that are needed so that the product can perform the functional requirements. You can think of technical requirements as the things that happen behind the scenes to meet the client’s request.
There are many categories of technical requirements, and the need to include a specific type varies based on the product being developed. Some of the more common technical requirements include usability requirements, maintainability requirements, legal requirements, performance requirements, operational requirements, and security requirements.
If you work in a regulated industry, make sure you address the question of whether any specific government- or industry-related regulations impact the design or delivery of your product. Regulatory noncompliance is a serious offense and correcting infractions can be both time consuming and costly.
Industry or corporate standards may also impact your technical requirements if you are developing an application with interfaces to existing systems. The application interface may require a specific programming language or methodology. These restrictions need to be documented in the requirements, as they may impact activity duration or cost estimates that are completed in later planning processes.
Examples of technical requirements for an IT project are:
-
System response time can be no greater than 5 seconds.
-
The system must be available Monday through Saturday from 7 AM to 7 PM.
-
The system must run on both PCs and Macs.
Your client may be more prepared to discuss the functional requirements than the technical requirements. You need to be prepared with a list of standard questions. For a new customer service application you can ask for data such as the number of concurrent users, hours of operation, hardware platform, peak busy times, and other elements of the product that could impact the design and development of the new system. If your company has a requirements template or checklist, use it in your meetings with the client group.
 |
Projects often have legislative, regulatory, or other third-party restrictions imposed upon their processes or outputs. For example, suppose that you are managing a project that will create a new IT system for a funds management company, one that’s in the business of managing individual stock portfolios. You can imagine that this company is heavily regulated by the Securities and Exchange Commission (SEC) and that your new system, in turn, will encounter several regulatory guidelines that you must follow. Especially pertinent will be the security aspect of your new system. You must be able to assure the SEC and your shareholders that the system is hack-proof.
It’s important that a project manager be able to not only recognize the need to investigate specific industry regulations and requirements, but also to communicate this need and its associated impact on the project scope and project plan to the stakeholders. Here are a few examples of the many external considerations you need to account for:
Legal and regulatory conditions Know the statutes covering the type of activity your deliverable involves. If you collect information about customers, are you complying with privacy laws? Do you know which types of encryption can be exported legally? Also, you may face government reporting and documentation requirements or public disclosure rules.
Licensing terms Suppose that part of your project requires that developers write some code according to a Microsoft application programming interface (API). You need to be well aware of the licensing ramifications associated with using a Microsoft API. Trademark, copyright, and intellectual property issues all enter into this category.
Industry standards Your project may utilize various interfaces between systems. Is there some standard that governs such things? For example, Microsoft uses the Web-Based Enterprise Management (WBEM) standards to move management data from one place to another. You will need to find out how your new system can use the Windows Management Instrumentation (WMI) interface to provide support for a heterogeneous system that you’re developing. Theoretically, you would need to determine what, if any, specific methodologies or approved coding practices should be used in the implementation of your project.
Considerations such as these will help you refine the scope of the project, thus producing a more accurate project timeline.
|
Vendor Bids
Occasionally, project initiation depends on the receipt of bids from outside vendors. This situation occurs if the project request involves a new technology that requires outside expertise or if it is known up front that the project timeline cannot be completed internally.
If your project or a key component of your project is going to be completed outside your organization, you may be involved in writing or providing input for a Request For Proposal (RFP) . An RFP is a document that is sent out to of vendors requesting them to provide a proposal on providing a product or service.
Once a vendor is selected, a statement of work (SOW) is completed. The SOW is a description of what product or service the vendor will provide under the terms of the contract agreed to with the selected vendor.
The use of an outside vendor involves unique considerations that would not apply to an internally developed project. The contract is a legal document that needs to be taken into consideration as you move forward to complete the project scope and the overall project plan.
RFPs, SOWs, and contracts are part of Procurement Planning, which will be covered in more detail in Chapter 6, “Additional Planning Processes.”
Documenting the Requirements
Once you have clarified what problem your client is trying to solve and defined the functional, business, and technical requirements, you are ready to start documenting the requirements and complete the product description.
The high-level requirements document is part of the formal request for project approval. It is also the basis for defining the project scope, estimating the cost of the project, identifying the resources required, and developing the schedule. The high-level requirements should contain the following information:
Problem Statement:
What issue or problem generated this request?
What is the specific business need that the client wants to address?
Objectives:
How do you define project success?
What is the end result?
What are the deliverables leading to the end result?
What are the goals?
How are the goals measured?
Strategic Value:
How does this product fit the strategic vision of the corporation?
Is there a link to other proposed or ongoing projects?
Requirements:
What work functions are required?
Are there interfaces to existing systems?
What are the performance criteria?
What are the support requirements?
Timing:
When does the customer need the project completed?
Are there market windows involved?
Are there significant business expenses to be incurred if the project is not complete?
Is there an impact to corporate revenue if the project is delayed?
Historical Data:
Have there been similar projects in the past?
Were they successful?
Can pieces of previous projects be reused for this project?
Clearly defined high-level requirements with measurable objectives and good supporting data regarding strategic value, timing, and relevant historical information on similar projects is critical to project approval as well as ongoing communications regarding the project.
|
Objective 2.8 of the CompTIA exam specifications talks about the ability to decompose , or break down, the initial project requirements, as approved by the stakeholders and passed down to the project manager into functional, business, and technical requirements. This means you take the requirements initially given to you and try to boil out the different facets that will make these requirements come about. Then you make a determination as to whether the requirement is functional, business, or technical in nature. Additionally, “maintaining trace ability within strict configuration control”, as alluded to in the objective, means that you’re careful to make sure that the requirements you’ve decomposed continue to match the type of requirement you noted in the first place and you do not allow the requirement to morph into something else. Let’s try an example:
Stakeholder Requirement: Users throughout the company’s fifty-three campuses will be able to connect to a centralized database system via browser in order to manage sales and inventory information . You and the stakeholders have agreed upon this high-level requirement and you are now ready to decompose this complex requirement into its baser elements.
Decomposition To decompose the stakeholder requirement, we’ll pick out the main elements and determine the types of requirements these entail.
Noting these elements, it is now within your obligation to make sure as you go forward and boil the requirements down even further into the tasks, dependencies, milestones, and resources required, and that you do not violate the spirit of each of these requirements. If, for example, a business unit came to you and said: “We don’t want to connect to a centralized system because our network connection is very slow. This will just serve to slow it down further!” You might be tempted to raise a huge red flag and say “Wait a minute!” But in reality, this business unit has pointed out a fundamental issue that has to be examined for factualness and rectified if true. It does not alter the initial high-level requirement that started the project in the first place.
|
| Note |
A number of the elements described in this table will also be included in your scope statement, which will be discussed in Chapter 3, “Scope Planning.” |
