Managing Client Expectations

,

Somehow clients always seem to expect more than project managers are prepared for or capable of delivering. I have seen this expectation gap manifest itself time and time again. I believe that it is more the result of a failure to communicate than it is anything else. This lack of communication starts at the beginning of a project and extends all the way to the end. The project manager assumes he or she knows what the client is asking for and the client assumes the project manager understands what they are asking for. In many cases that is simply not true and little is done to check the validity of either of those assumptions. That stops right here! I believe that miscommunication does not have to happen. The section “Conducting Conditions of Satisfaction” describes a tool that I have used successfully for many years. It is a tool that establishes a language of communication and understanding between the project manager and the client. Understand at the outset that the tool is easy to explain and understand, but demands constant attention if it is to make a difference.

Wants versus Needs

The root cause of many communications problems originates from disconnects between what the client says they want and what they really need. If the project manager doesn't pay attention that disconnect may not be very obvious. The disconnect may come about because the client is so swept up in a euphoria over the technology (for example, they may be enamored with what they see on the Web) that they have convinced themselves they have to have it without any further thought of exactly what it is they really need.

Wants and needs are closely linked to one another but are fundamentally different. From my experience client wants tend to be associated with a solution to a problem that the client envisions. Needs tend to be associated with the problem. If wants are derived from a clear understanding of needs, then it is safe to proceed based on what the client wants, but you cannot always know that this is the case. To be safe, I always ask the client why they want what they want. By continuing this practice of asking why, you will eventually get to the root of the problem and needs will then become clear. This is not unlike a Root Cause Analysis (described in Chapter 15). The solution to that problem will be what the client really needs. Your job as project manager is to convince the client that what they want is what they really need.

The disconnect can also come about because the client does not really know what they need. In many cases, they can't know. What they need can be discovered only through doing the project. Traditional project management (TPM) forces them to specify what they want. If there is any reason to believe that what the client says they want is different from what they need, the project manager has the responsibility of sifting and sorting this out before any meaningful planning or work can be done. It would be a mistake to proceed without having the assurance that wants and needs are in alignment or can be brought into alignment. You should never start a project without knowing that the solution is in fact what will satisfy the client. That is one of the reasons for the Conditions of Satisfaction, discussed in the next section. It is a tool I have used for more than 20 years, and it has served me well.

Project Scoping Process

Figure 4-1 is a diagram of the Project Scoping Process that I use in my consulting practice. It is described in detail in this section.

Figure 4-1: Project Scoping Process

Conducting Conditions of Satisfaction

If I had to pick one area where a project runs into trouble, I would pick the very beginning. For some reason, people have a difficult time understanding what they are saying to one another. How often do you find yourself thinking about what you are going to say while the other person is talking? If you are going to be a successful project manager, you must stop that kind of behavior. As a project manager, it is essential that you cultivate good listening skills.

To that end you should begin every scoping exercise with a Conditions of Satisfaction (COS) session. The COS is a structured conversation between the client (the requestor) and the likely project manager (the provider). Figure 4-2 illustrates the COS process.

The deliverable from the COS is a one-page document (with attachments) called the Project Overview Statement (POS). The POS is a template that is used to clearly state what is to be done. It is signed by the requestor and the provider as a record of their COS session. When the POS is approved by senior management, the Scoping Phase is complete and the project moves to the Planning Phase, which is the topic of Chapter 5.

Figure 4-2: Establishing the COS

The process of developing the COS involves the following four parts:

1. Request — A request is made by the client.
2. Clarification — The provider explains what he or she heard as the request. This conversation continues until the client is satisfied that the provider clearly understands the request. Both parties have now established a clear understanding of the request in the language of the requestor.
3. Response — The provider states what he or she is capable of doing to satisfy the request.
4. Agreement — The client restates what he or she understands the provider will provide. The conversation continues until the provider is satisfied that the client clearly understands what is being provided. At this point, both parties have established a clear understanding of what is being provided in the language of the provider.

Establishing a common language with which to communicate is critically important. If you don't have that and verify that you do, you are planting the seeds of failure.

Establishing Clarity of Purpose

By the time you leave the COS session, both you and the client have stated your positions and know that the other party understands your position. You have established the beginnings of a common language with common terminology. That is critically important. You and the client will have planted the seeds for a continuing dialog. As the project work progresses, any changes that come up can be dealt with effectively because the effort to understand each other has been made up front.

The final step in the COS process is to negotiate to closure on exactly what will be done to meet the request. Obviously, some type of compromise will be negotiated. The final agreement is documented in the POS.

More than likely, the parties will not come to an agreement on the first pass. As shown in Figure 4-2, this process repeats itself until there is an agreed-on request that is satisfied by an agreed-on response. As part of this agreement, the POS should include a statement of success criteria that specifies when and how the request will be satisfied. It is important that this statement be very specific. Do not leave it up to interpretation whether or not the conditions have been met. An ideal statement will have only two possible results: the criteria were met or the criteria were not met. There can be no in-between answer here and no debate over the outcome. The success criteria (a.k.a. doneness criteria) will become part of the POS.

This early step of establishing and agreeing to what will be done is very important to the project's success. It is difficult to do a thorough job, especially when everyone is anxious to get to work on the project. It is also a painful process. People can be impatient; tempers may flare. You may be inclined to skip this step. (“Pain me now or pain me later” — you choose what you are willing to live with.) Even if the request seems straightforward, do not assume that you understand what the client has asked or that the client understands what you will provide, even if the request seems straightforward. Always use the COS to ensure that you both understand what is expected and that you have a language with which the two of you can communicate clearly.

Specifying Business Outcomes

As indicated in the previous section, it is a good idea to specify within the COS exactly what outcomes demonstrate that the COS has been met. The outcomes have been called success criteria, explicit business outcomes, and objectives, among other names. Whatever term you use, you are referring to a quantitative metric that signals success. That metric is discussed in more detail later in the chapter. For now just understand that it is a quantitative measure (for example, profit, cost avoidance, and improved service levels) that defines success.

Conducting COS Milestone Reviews

The COS is not a static agreement. It is a dynamic agreement that becomes part of the continual project monitoring process. Situations change throughout the project life cycle and so will the needs of the client. That means that the COS will change. Review the COS at every major project status review and project milestone. Does the COS still make sense? If not, change it and adjust the project plan accordingly.

The Project Scoping Meeting

You have a variety of ways to scope a project. At one extreme is a formal multiple-day meeting and at the other extreme is scoping on the back of a napkin over a cup of coffee at the local coffee stand. Both extremes and all of the variants in between are valid. It all depends. This section suggests the best way to scope a project based on my experiences.

The Project Scoping Meeting is your first substantive encounter with the client. You may have had a COS session and agreed on a high-level scope for the project but need more detail in order to write a POS. The Project Scoping Meeting takes the COS deliverable to the next level of detail. In this meeting, the core project team will be present, as will the client, several key managers, staff, a facilitator, and representative users of the project deliverables.

Purpose

The Scoping Meeting has two purposes. The first is to draft the POS. The second is to create the Requirements Breakdown Structure (RBS). The RBS is used as further input to the POS and to help the team decide which project management approach is the best fit for this type of project.

Attendees

A Project Scoping Meeting attended by 15–20 people is large but manageable. An experienced meeting facilitator could manage a group of more than 20 people, but it requires breakout groups and their coordination. This is definitely the territory of a skilled facilitator and that is not the project manager. The project manager needs to focus on the scoping of the project, not on conducting the Scoping Meeting. The two activities require different skill sets. I prefer that the project manager draw on their project management skills and the facilitator draw on their meeting facilitation skills. Unfortunately the reality is that the project manager is usually recruited as the facilitator. If the Scoping Meeting requires more than 20 attendees, you might consider breaking the project up into two or more subprojects of lesser scope each or having more than one Scoping Meeting.

The following three groups need to be represented at the Scoping Meeting:

• The client group — Decision makers as well as operations-level staff should be represented. Among them should be the individual(s) who suggested the project.
• The project manager and core members of the project team — The core members are the experienced professionals who will be with the project from beginning to end. For larger projects, they will be the future subproject managers and activity managers. In some cases, critical but scarce skilled professionals might also be present.
• The facilitator group — This group comprises two or three individuals who are experienced in conducting scoping and planning meetings. The facilitator group will have a meeting facilitator, a requirements gathering facilitator, and a position that I call a technographer. The two facilitators are often the same person. A technographer is the recording secretary for scoping and planning meetings who has solid experience using a variety of high-tech tools. Larger projects may require two such professionals.

Agenda

A typical agenda for the Scoping Meeting includes:

• Introductions
• Purpose of the meeting (led by the facilitator)
• Review COS
• Description of the current state (led by the client representative)
• Description of the problem or business opportunity (led by the client representative)
• Description of the end state (led by the client representative)
• Requirements decomposition (led by the facilitator)
• Discussion of the gap between the current and end states
• Choose the “best-fit” project management approach to close the gap (led by the project manager)
• Draft and approve the POS (whole group)
• Adjourn

For very small projects, the agenda can be accomplished in one day. It would not be unusual for larger, more complex projects to require a full work week to cover the agenda. As an example of the latter, I ran a very complex Web-based decision support system project that was initially budgeted for three years and $5M. The Scoping Meeting took 3 days. But at the end of those three days the group had a common understanding of the project and how to approach it from a process perspective. As testimony to the effectiveness of the scoping process we used, the project finished early and under budget.

Project Scoping Meeting Deliverables

As shown in Figure 4-1, the Project Scoping Meeting includes the following deliverables:

• RBS
• Assessment of completeness of RBS
• Project classification
• Determination of best-fit PMLC model
• The POS

These are described in the following sections.

Creating the RBS

Requirements definition takes place immediately following the COS session and before the POS is written. Requirements decomposition, which involves describing in detail how the requirement will be met, can take place at different times in the project life cycle:

• As input to the POS
• During the Project Scoping Meeting
• During the Project Planning Meeting

My advice is to begin requirements documentation by initially identifying the requirements with no decomposition. That is usually enough detail for POS purposes. Requirements decomposition can take place after the POS has been approved and the project is deemed feasible. Either the Project Scoping Meeting or the Project Planning Meeting will be the appropriate event at which requirements decomposition can be done. If you expect requirements decomposition to be complex, take several days, and consume too many resources, you might want to wait until after the POS has been approved and your project idea is judged to be feasible before you spend the resources needed to generate the RBS. Creating the RBS before you know if your project stands a chance at being approved will be a big waste if POS approval is not given. And so after the POS is approved and you enter the planning phase is the better time to create the RBS. Both options are shown in Figure 4-1.

The RBS is not static but in fact is quite dynamic. The details can change several times throughout the life of the project for one or more of the following reasons:

• Changes in market
• Actions of a competitor
• Emergence of new or enhanced technologies
• Organizational priorities change
• Changes in sponsors
• Learning and discovery from simply doing the project

Because of the volatility of requirements I choose not to use the IIBA definition of a requirement because it guarantees that requirements cannot be fully identified at the beginning of a project. Instead I recommend that you use my definition of requirements, which results in a complete list of requirements at the beginning of the project. This may seem like a trivial difference but it has a profound impact on assessing the resulting business value that is not evident from the IIBA definition because in that definition the requirements that generate business value are embedded in all the other requirements.

Requirements decomposition is presented in the form of a hierarchical diagram (Figure 4-3) that I call the Requirements Breakdown Structure (RBS). In its most detailed rendering it consists of the following levels of decomposition:

 

As you gather and document requirements by whatever method you choose, place them in their appropriate level in the RBS. The graphical format shown in Figure 4-3 works well. Alternatively, you could present the RBS in an indented outline format. It's all a matter of taste.

Figure 4-3: The Requirements Breakdown Structure

Each requirement may consist of one or more functions. Each function may consist of one or more sub-functions, and so on. Depending on the level of complexity the decomposition can include all or any combination of the preceding levels. The simplest requirement might only need a list of its features to describe it completely. Here's a brief description of each level:

• Function — At the discretion of the project manager, the highest level of decomposition may be at the function level. This level comprises the functions that must be performed in order for a solution to be acceptable. It is important to understand that the RBS reflects what is known about the solution at the time the RBS is first defined. This initial list of functions may or may not be complete. Neither you nor the client can be expected to know if that list is complete. You might know that it is incomplete, but you wouldn't know that it is complete. How could you? For the sake of generating the RBS, you have to proceed on the basis that the initial list will be complete. If it turns out that it is not, you will discover that as part of doing the project.
• Sub-function — At the next level of decomposition are sub-functions. For some functions, you may not have any idea of what those sub-functions might be and that is okay. In any case, the project team should make every effort to identify the sub-functions that further define a function. Once these sub-functions have been developed, the function they define will now be complete. This is the same as the premise underlying the WBS architecture and is very intuitive. For many adaptive projects, additional sub-functions will be discovered as part of doing the project.
• Process — Complex functions and sub-functions can be further described with the business processes that comprise them. These are the business processes that are commonly used in today's organizations. To make them more understandable the functions might be decomposed into sub-functions and the business processes that comprise the sub-functions then decomposed to processes.
• Activity — Activities are otherwise known as process steps.
• Feature — At the lowest level of decomposition are features. These are the visible enhancements and characteristics of the entity that they describe.

Requirements decomposition is the first and very challenging task that the project manager and client will face in the life of the project. To do this effectively is as much an art as it is a science. On the art side of the equation, the project manager will have to prepare the client to engage in the decomposition and documentation process. The attitude, commitment, willingness to be meaningfully involved, and preparation of the client are major determinants in the choice of approach. This preparation will include the choice of approach to be used and perhaps some preliminary training of the client and the core team. Some clients will be open and proactive in participating; others will not. Some will be sure of their needs; others will not. Some will be expressing their wants, which may be very different from their needs. The project team should be searching for needs.

On the science side of the equation are the many techniques that have been used successfully to decompose and document requirements. I have had good success using facilitated group sessions, prototyping, business process diagramming, and use cases. Those are the four approaches discussed later in this chapter.

It is very important to realize that requirements identification and decomposition are critical to understanding the direction of the project. It is now that the framework for the project begins to take shape.

The steps to generate requirements begin by looking at the business function as a whole. This is followed by the selection of a method or methods for gathering requirements. This effort must be planned. There are several approaches to requirements elicitation. (See Table 4-1.)

I single out facilitated group sessions, business process diagramming, prototyping, and use cases for a more detailed discussion because I have had the most success with them. Typically, more than one method is chosen to decompose requirements. Selecting the best method(s) for the project is the responsibility of the project manager, who must evaluate each method for costs, ease of implementation and comfort with the client, and risks. Further, selection of a particular method should be based on specific product and project needs, as well as proven effectiveness. Certain methods have been proven effective for specific client groups, industries, and products. An example of this would be using physical, three-dimensional prototypes in product development and construction. I'll come back to a more detailed discussion of these four methods of requirements decomposition later in this chapter.

Regardless of the method you use to generate the RBS, I strongly advise creating an RBS for every project for the following reasons:

• The RBS is most meaningful to the client.
• The RBS is a deliverables-based approach.
• The RBS is consistent with the Project Management Body of Knowledge (PMBOK) defined by the Project Management Institute (PMI).
• The RBS remains client-facing as long as possible into the planning exercise.
• The RBS is the higher order part of the Work Breakdown Structure (WBS). (See Chapter 5.)

Approaches to Decomposing Requirements

The most commonly used requirements decomposition methods are as follows:

• Facilitated group sessions
• Interviews
• Observation
• Requirements reuse
• Business process diagramming
• Prototypes
• Use case scenarios

Table 4-1 briefly describes the strengths and risks associated with each method.

Table 4-1: Methods for Requirements Decomposition

Facilitated Group Sessions

This is probably the approach used in every requirements decomposition session and it often integrates one or more of the other approaches. There are a number of ways to structure these sessions that I want you to be aware of. You'll need to do a little planning to decide how best to approach the facilitated group session.

• One single group session — This works well for smaller projects and for projects that involve only one business group. I prefer this approach whenever possible. All involved parties hear the same discussion and conclusions.
• Separated group sessions — As the project gets larger you might consider breaking the project into sub-projects for the purposes of requirements decomposition. That would allow you to invite those business groups with specific expertise or interest in a particular sub-project. This approach has the added step of combining the results of the multiple sessions. Resolving differences can become an issue and some type of shuttle diplomacy may be required. Compromises are often needed to come to closure.

Business Process Diagramming

Often, you will choose to start identifying requirements for the project by mapping the current business process (the “As Is” process) or processes that are going to be affected. You might also want to map the business process after the solution is installed (the “To Be” process). Both of these are excellent artifacts to use as input to creating the RBS.

From the business process development perspective, gathering requirements details often begins with knowledge of the current or “As Is” business process and ends with the “To Be” business process. The gap between the “As Is” and “To Be” processes is filled with new or enhanced project deliverables. Having the “As Is” and the “To Be” business process flow diagrams is an invaluable aid in the ensuing solutions development effort.

It is an ongoing dictum of today's business that you must continuously improve your business processes. The old “If it ain't broke, don't fix it” adage no longer applies. If you aren't improving your processes and the way that they support your clients, you run the risk of losing market share. Your client should also be taking the lead in approaching your teams to demand process improvement. Conversely, they are your clients, and you should be ever watchful for ways to improve the service that your clients provide to their clients.

All organizations are under pressure to improve. The pressure can come from their clients, the competition, environmental changes, or a combination of the three. The improvements can be in their products or their processes. All too often, the client doesn't give their business to the company with the best product. When clients find that a supplier is too difficult to deal with, they will decide to use a “second best” supplier who is easier to deal with.

This also applies to internal organizations. One reason for outsourcing is a belief (frequently inaccurate) that other groups will be easier, faster, or cheaper to deal with. Internal organizations need to counter this belief by clearly demonstrating that they are continuously improving what they can deliver and their methods of delivery.

What Is a Business Process?

A business process is a collection of activities that takes one or more kinds of input from one or more different sources and produces value for the client (see Figure 4-4). The focus of the business must be to ensure that the effort of dealing with the process does not outweigh the value received from completing the process.

Figure 4-4: A business process

Order entry and fulfillment is a clear example of a business process. From the client's viewpoint, the process starts when the client places an order; it ends when the client receives the goods requested. There are numerous activities in between. Credit checks may be run to confirm that the client can pay for the order. Inventory is assessed to confirm you have what the client is requesting. A typical list of activities would include the following:

• Receiving the order
• Logging the order
• Verification of completeness
• Client credit check
• Determining the price
• Inventory checking
• Production request
• Order picking
• Order packaging
• Shipment

You will notice that the activity in a high-level business process may include activities that can be regarded as processes in and of themselves. Processes can be decomposed into other processes until you reach the task level where some interim component is produced. The key is to start with the client as the focus of the original process and then define the sub-processes by their contribution to added value.

Creating a Business Process Diagram

How do you diagrammatically represent a business process? You can use the standard flowchart to keep it simple and couched in symbols you are already familiar with. Figure 4-5 shows the more commonly used symbols.

Figure 4-5: Standard flow chart symbols

The symbols shown in the figure denote the following process steps:

• Operation — Denotes that a change has taken place. The input is somehow changed as a result of having gone through this process.
• Movement — Denotes the movement of output from one process step to become the input to the next process step.
• Decision — Denotes that a question needs to be answered. There are two flow paths that emanate from a decision box: Yes or True and No or False. You follow one of these paths based on the decision.
• Inspection — Someone other than the person producing the output must inspect it for quality, conformance, or some other tangible characteristic. Often an approval is included as a successful inspection.
• Document — Denotes a paper document.
• Delay — Denotes a wait state in a process. It's usually associated with something joining a queue and waiting for the operator of the next process step to become available.
• Storage — Indicates that an item has been placed in storage and must wait for a release before moving to the next process step. This usually represents wasted time that must be removed from a process.
• Annotation — Provides added detail about some process, which is needed for clarification. It might also include the position title of the person responsible for the process.
• Direction of Flow — Denotes the order of process steps.
• Transmission — The interrupted arrow indicates when information is to be transmitted from one physical or virtual location to another.
• Connector — Connects the flow between two separate locations; often used as an off-page connector.
• Boundaries — Denotes the initiating and closing processes of a flow diagram. Usually the words START or BEGIN are associated with the initiating process, and STOP or END with the closing process.

Business Process Diagram Formats

Three common formats are used to render business process diagrams. The first (shown in Figure 4-6) is the top-down and left-to-right format. It is commonly used in program and system flow charts. The second is the “swim-lane” format (shown in Figure 4-7). It identifies the actors who participate in the business process.

Figure 4-6: The top-down, left-to-right format

Figure 4-7: The swim-lane format

Software developers are typically most familiar with the top-down, left-to-right format. It harkens back to the early days of programming and is the standard they adopted several decades ago. It follows the logical thought patterns of software developers and is therefore their popular choice.

However, I prefer the swim-lane format when diagramming business processes. For one, it is a client-facing format. By that I mean it is intuitive to the client and represents their processes in a way that they can easily understand. Part II of this book uses swim lanes extensively.

Context Diagrams

One way to describe your process at a very high level is with the context diagram. It is a good starting point. A context diagram describes a rough process or a set of processes. It generally has only the following few components:

• A stick figure representing the external entity that is triggering the process
• A large circle representing the organization responding to the request
• A text block showing each organization or process acting to fulfill the request
• Arrows showing the rough flow between text blocks

The context diagramming process (shown in Figure 4-8) requires that the group identify one or more candidate processes. For example, a process might start with a client request or action and end with a fulfillment. The modeling activity starts by identifying those two points. You show the process start by using an arrow from the client to the organization. You show the process end by using an arrow from the organization to the client. That provides an initial bounding of the process, and the group can decide whether that particular process has enough issues to warrant more time diagramming. If the process merits more discussion, the diagramming process continues by identifying the first group to receive the request and the action sequence that the organization performs to fulfill the request. Simply put, the group uses Post-it notes and arrows to show what goes on in the organization to fulfill the request. This should be done at a high level, and the constrained area of the circle helps maintain this high-level perspective.

Figure 4-8: Context diagramming process

Frequently the group will make refinements as they go. The most common refinement is a clearer identification of the existing client being focused upon or the transaction being performed. For example, “client” might become “existing client” if the process is different (or should be different) for an existing client versus a new client. The group can then annotate the process with success criteria, issues, and so on.

Business Process Work Flow Diagrams

The flow chart is an intuitive tool to use when you need to identify the actual and ideal path that any product or service follows. It is a picture of steps in a process, and can be used to examine the relationship and sequence of steps; to identify redundancy, unnecessary complexity, and inefficiency in a process; and to create common visual understanding of the process flow.

Considered one of the simplest tools, the flow chart can be as basic or technically intricate as the process it is used to illustrate. Each type of process step is traditionally identified on the chart by a standardized geometric shape. A flow chart illustrates a process from start to finish and should include every step in between. By studying these charts, you can often uncover loopholes, which are potential sources of trouble. Flow charts can be applied to anything from the travels of an invoice and the flow of materials to the steps in making a sale or servicing a product.

In process improvement, flow charts are often used to clarify how a process is being performed or to agree upon how it should be performed. When a process is improved, the changes should be noted on the flow chart in order to standardize the revised flow.

Follow these steps to create a flow chart:

1. Decide on the process to be diagrammed.
2. Define the beginning and ending steps of the process, also known as boundaries.
3. Describe the beginning step using the Boundaries symbol.
4. Keep asking “What happens next?” and writing each of the subsequent steps in Operations symbols below the Boundaries symbol.
5. When a decision step is reached, write a yes/no question in a diamond and develop each path.
6. Make sure that each decision loop reenters the process or is pursued to a conclusion.
7. Describe the ending step using the Boundaries symbol. Sometimes a process may have more than one ending boundary.

Prototyping Your Solution

Many clients cannot relate to a narrative description of a system but they can relate to a visual representation of that system. For requirements decomposition purposes, the idea of a prototype was conceived several decades ago. Its original purpose was to help clients define what they wanted. By showing them a mock-up of a solution, they could comment on it and give the developers more insight into what constitutes an acceptable solution. Originally these prototypes were storyboard versions, not production versions. (Later prototypes did become production versions of the solution when used in agile projects but that is another story presented in Part II.)

Use Cases

Use cases are an excellent forum for working with the client to define the functions and features of the solution. They tell the story of how the solution will operate in the mind of the client and are documented following a specific graphic and textual format. The Unified Modeling Language (UML) and Business Process Management Notation (BPMN) are commonly used. These representations should be rendered in the language of the client and for that reason UML and BPMN have found favor with most developers. This section describes use cases in sufficient detail to get you started. The bibliography in Appendix B has several additional references for those who would like to explore use cases in more detail. Figure 4-9 depicts the position of use cases in the overall project scoping.

Figure 4-9: Use cases in the Scoping Phase

Project scoping can be part of the Scoping Process Group or Planning Process Group. It is a matter of procedure and protocol in the organization. In Figure 4-9, project scoping is between the Scoping Process Group, which has the POS as output, and the Planning Process Group. It will be the same regardless of where you position it in your project management process. After the use cases have been defined and documented, a single requirements document is assembled, and the project can move to the approval stage or, if the approval stage has already been reached, to the Planning Phase.

There are two artifacts in use cases: use case diagrams and use case flow of events, as described in the following sections.

Use Case Diagrams

A use case diagram is a simple way to describe how an individual interacts with a business process. It consists of one of more stick figures (the actors), ovals (the process steps), and connecting arrows (the interactions), as shown in Figure 4-10.

Figure 4-10: Use case diagram

An actor initiates the use case by interacting directly with the system. The system gathers information from the actor, processes it, and returns a result to the actor. In the simple example shown in Figure 4-10, the system asks the actor a question, the answer is processed by the system, and a result (money in this case) is delivered to the actor. This is the so-called “happy path.” Several scenarios may spin off of this simple example. In one scenario, the actor may provide the wrong answer, and the system aborts the request. Alternatively, the system may give the actor a second opportunity to provide the correct answer. If this were an ATM scenario, it may be that the client wants to withdraw more money than is in the account, and the system will return the appropriate message — without the money, of course. In this example, there is only one actor — referred to as the primary actor. There may be secondary actors as well. For example, if the online bank transaction requires another actor to verify account status, that actor is called a secondary actor. Again, the secondary actor may be someone or something, such as another system.

This document reads like the script in a play. It is initiated with an action by the primary actor, the system responds, the actor takes another action, and this back and forth exchange continues until the use case ends. Consider the case study described in the following sidebar of an order entry transaction for a company called PDQ (Pizza Delivered Quickly). In this use case, the actor is a client who has direct access to the system. If a person (instead of a system) were taking the order from the client, he or she would be the actor and not the client.

Types of Requirements

Whether you use the IIBA definition or my definition, requirements define the product or service that constitutes the deliverable of the project. These requirements are the basis for defining the needs that the client is seeking to solve a problem or to take advantage of a business opportunity. At this early stage, the client, the project manager, and their teams are tasked with going through the process of establishing the requirements baseline for the project. This process is a systematic, step-by-step effort that requires the patience and diligence of both teams. It is these requirements that will eventually be used for estimating the cost, time, and resources required to do the project. Ultimately, these requirements drive acceptance of the product or service by the client. Requirements are separated into the following four categories.

• Functional requirements
• Non-functional requirements
• Global requirements
• Product and/or project constraints

Functional Requirements

Functional requirements specify what the product or service must do. They are actions that the product or service must take, such as check, calculate, record, or retrieve. For example: “The service shall accept a scheduled time and place for delivery.”

Non-Functional Requirements

Non-functional requirements demonstrate the properties that the product or service should have in order to do what it must do. These requirements are the characteristics or qualities that make the product or service attractive, usable, fast, or reliable. Most non-functional requirements are associated with performance criteria and are usually requirements that will establish the product or service boundary. Non-functional requirements can sometimes be generated by the refinement of a global requirement. Non-functional requirements are usually associated with performance criteria that set the parameters for how a system is to function. For example: “The product shall have a homemade appearance” or “The product shall be packaged so as to be attractive to senior citizens.”

Global Requirements

Global requirements describe the highest level of requirements within the system or project. Global requirements describe properties of the system as a whole. During the initial stages of a project, many requirements end up being global requirements. The project manager and the team then refine them through the methods of requirement generation. Global requirements is a relatively new term. In the past, these have been called general requirements, product constraints, or constraining requirements. Be careful in your use of global requirements because in most cases they can be turned into non-functional requirements simply by asking the questions associated with what, why, or how. In fact, it is wise to move a global requirement to a non-functional requirement in order to gain a better focus on what the requirement really is. For example: “The system shall run on the existing network” or “The system must be scalable.”

Product and/or Project Constraints

Product and/or project constraints are those requirements that, on the surface, resemble design constraints or project constraints. Design constraints are preexisting design decisions that mandate how the final product must look or how it must comply technologically. Project constraints cover the areas of budget and schedule along with deadlines and so on. One important note here is that product constraints can be listed as global requirements, but project constraints cannot. For example: “The maximum system response time for any client-based transaction must not exceed 4 milliseconds” or “The total out-of-pocket cost plus five-year maintenance must not exceed $35 million.”

Assessing the Completeness of Requirements Decomposition

Assessing completeness of the RBS is a subjective exercise. You might be able to tell if the RBS is complete but because you might have imperfect knowledge of the solution you might not recognize an incomplete RBS. The safe assumption is to assume that it is incomplete and proceed accordingly. To err on that side of the decision is not a serious error but to err on the other side by assuming it is complete when it is not can have serious consequences. I prefer to take the safe ground!

Project Classification

The question to answer here is whether the project should be managed by a PMLC model that is Linear, Incremental, Iterative, Adaptive, or Extreme. (See Table 4-2.) The answer is somewhat subjective and depends mostly on the degree to which you and the client see the RBS as complete.

Table 4-2: Project Characteristics as a Determinant of Which PMLC Model to Use

PMLC MODEL TYPE	WHEN TO USE IT
Linear	The solution and requirements are clearly defined. You do not expect too many scope change requests. The project is routine and repetitive. You can use established templates.
Incremental	Same conditions as the Linear approach, but the client wants to deploy business value incrementally. There may be some likelihood of scope change requests.
Iterative	You feel that requirements are not complete or may change. You will learn about remaining requirements in the course of doing the project. Some features of the solution are not yet identified.
Adaptive	The solution and requirements are only partially known. There may be functionality that is not yet identified. There will be a number of scope changes from the client. The project is oriented to new product development or process improvement. The development schedule is tight and you can't afford rework or re-planning.
Extreme	The goal and solution are not clearly known. The project is an R & D type project.

You'll explore each of these in more detail in subsequent chapters. In Chapter 10, I discuss the Linear and Incremental PMLC models. In Chapter 11, I discuss the Iterative and Adaptive PMLC models. In Chapter 12, I discuss the Extreme and Emertxe PMLC models. Each of these models will have other adaptations that result in special-case models. These will also be discussed in detail. The final picture is one of a rich family of models that cover the entire project landscape and fit any project situation you are likely to encounter.

You have now reached the point where a critical decision needs to be made about how to manage this project. At this point, the project management gurus would agree that you cannot say that the requirements list is complete. You can never really know that until the project is complete and all success criteria have been met. However, you can say that the requirements are not complete. Certain parts are missing, and you know they are missing. The more that is missing, the more complex the process of managing the project will be. The development manager and the client manager must make an initial decision on the best-fit PMLC based on the degree to which requirements are complete. Completeness is more of an expression of the comfort level you have with the RBS than it is any quantitative measure of completeness. It is a subjective call, and it is not a “once for the whole life of the project” decision — it can change as the clarity and completeness of the requirements changes. For example, at some point in the project life cycle, the project team may experience the great “AHA!” At last the project team sees what the complete solution looks like. Does it make sense to change the PMLC? It might. It might not. Here are some criteria to consider:

• What are the cost and time penalties for abandoning the current PMLC and changing to a different PMLC?
• Can the project team adapt to the new PMLC?
• How certain are you and your client that a change will result in a better solution?
• What is the cost versus the benefit of the change?

As you can see, gathering and documenting client requirements is extremely difficult even in the simplest of situations. Poorly defined requirements are the root cause of many project failures, so it is critical that you approach this task with the best-fit requirements gathering approach available to you. For clients, the requirements gathering approach you use is difficult because they are being asked to think about satisfying their needs using tools that they may not be familiar with. For project managers, the requirements documentation approach they choose may be difficult because they may not have made the distinction between client wants and client needs. For both parties, generating the RBS is a learning experience. How well the client and the project manager are able to learn will be the key to project success. Therefore, the choice of PMLC will be a critical success factor for that learning to take place and for successful requirements documentation.

In addition to being a good representation of the requirements, the RBS works very well as a requirements gathering approach for any project because of the following characteristics:

• It does not require a trained facilitator.
• It does not require learning one of the contemporary approaches to requirements gathering.
• It presents an intuitive approach to gathering requirements.
• It allows the client to work with the project team in an environment that is familiar to them, enabling them to stay in their own comfort zone.
• It paints a clear picture of the degree to which the solution is clearly defined.
• It provides the input needed to choose the best-fit PMLC model and the appropriate project management approach.

Determining the Best-Fit PMLC Model

The choices come from among such approaches as Waterfall, Scrum, and many, many others. Organizations will have a preference and will have skilled and experienced potential team members to adequately staff their preferences. Scrum is an extremely powerful and popular choice in many organizations, but it requires a senior level developer who can work without supervision in a self-managed situation. That puts a strain on many organizations whose developers will often be less experienced.

Based on the project characteristics, which specific PMLC model is the closest fit? This decision is made without a consideration of the environment in which it will be implemented. It is based solely on goal and solution clarity.

Based on the project environment how does that model need to be adjusted to establish the best fit model? An example is the best way to convey this information. Suppose the project is in the adaptive category and Scrum is the obvious choice. Scrum requires meaningful client involvement through their representative, the Product Owner, but such an individual cannot be identified. As an alternative an iterative approach, such as RUP or Evolutionary Waterfall, might be used. The difference being that the project manager and a senior level BA can function as co-project managers and together they can take a more proactive role that otherwise would have been done by the Product Owner.

For another example, consider a project that is best categorized as iterative and RUP would be the best-fit choice. However, past projects for that client have been disappointing because the client could not fully participate. One alternative would be to step back and use an incremental approach to compensate for the shortcomings of the client involvement and allow the project manager and BA to take up the slack. An approach I have used is to go ahead with the choice of a RUP approach but to strengthen it by holding concurrent workshops with the client to help them better understand their role and responsibilities. For example, a workshop on use cases could be helpful if run concurrently with the requirements gathering exercises.

Writing the POS

The more complexity and uncertainty associated with the project, the more likely senior management will want assurances that the approach that will be used to solve the problem or to take advantage of a business opportunity makes good business sense. A very important question will be, “Does the resulting business value exceed the total cost of the deliverables?” Validation may take the form of using the organization's templates to establish validity. You may have to simulate the deliverables by building a prototype of the solution. You can expect to provide any number of financial analyses such as cost/benefit, Return on Investment (ROI), breakeven, and cash flow analyses, among others. Some of these might accompany the POS.

The COS and the deliverables from the Project Scoping Meeting if one is held are the primary inputs you need to generate the Project Overview Statement (POS). The POS is a short document (ideally one page) that concisely states what is to be done in the project, why it is to be done, and what business value it will provide to the enterprise when completed.

The main purpose of the POS is to secure senior management's approval and the resources needed to develop a detailed project plan. It will be reviewed by the managers who are responsible for setting priorities and deciding what projects to support. It is also a general statement that can be read by any interested party in the enterprise. For this reason, the POS cannot contain any technical jargon that generally would not be used across the enterprise. After it is approved, the POS becomes the foundation for future planning and execution of the project. It becomes the reference document for questions or conflicts regarding the project's scope and purpose.

My idea for the POS originated at Texas Instruments in the early 1960s. They used a form of the POS as part of a process whereby anyone in the organization could suggest an idea for increasing efficiency, improving productivity, or seizing a business opportunity. One particular example has stayed with me over all these years. It involved a maintenance man whose only equipment was a Phillips-head screwdriver. He walked the halls of an approximately 1,800,000-squfare-foot building and tightened the screws that held the wall-mounted ashtrays in position. You could smoke inside the building in those days. They became loose from people or equipment bumping into them. The maintenance man had an idea for replacing these screws with another fastening device that would not work loose, and he presented his idea using a POS. The project was funded, and he was appointed project manager. The project was completed successfully, and his job was thus eliminated. (I hope he was able to move on to something a little more challenging and rewarding!) Today, several organizations use the POS or some adaptation of it.

Because the POS can be drafted rather quickly by one person, it serves to capture a brief statement of the nature of the idea. Senior management can react to the proposed idea without spending too much time. If the idea has merit, the proposer will be asked to provide a detailed plan. The idea may be conditionally accepted, pending a little more justification by the proposer. Again, the idea is pursued further if it has merit. Otherwise, it is rejected at this early stage, before too much time and too many resources are spent on needless planning.

The POS can serve other purposes as well. Here are a couple of examples.

Parts of the POS

The POS has the following five component parts:

• Problem or opportunity
• Project goal
• Project objectives
• Success criteria
• Assumptions, risks, and obstacles

Its structure is designed to lead senior managers from a statement of fact (problem or opportunity) to a statement of what this project will address (project goal). Senior management is interested in the project goal and whether it addresses a concern of sufficiently high priority; therefore, they need details on exactly what the project includes (project objectives). The business value is expressed as quantitative business outcomes (success criteria). Finally, conditions that may hinder project success are identified (assumptions, risks, and obstacles). The following sections take a closer look at each of these POS components. An example POS is shown in Figure 4-11.

Figure 4-11: An example POS

Stating the Problem or Opportunity

The first part of the POS is a statement of the problem or opportunity that the project addresses. This statement is fact — it does not need to be defined or defended. Everyone in the organization will accept it as true. This is critical because it provides a basis for the rest of the document. The POS may not have the benefit of the project manager's being present to explain what is written or to defend the reason for proposing the project to management. A problem or opportunity statement that is known and accepted by the organization is the foundation on which to build a rationale for the project. It also sets the priority with which management will view what follows. If you are addressing a high-priority area or high-business-value area, your idea will get more attention and senior management will read on.

Here are several examples of situations that will lead to a statement of the problem or opportunity that has given rise to this POS.

Establishing the Project Goal

The second section of the POS states the goal of the project — what you intend to do to address the problem or opportunity identified in the first section of the POS. The purpose of the goal statement is to get senior management to value the idea enough to read on. In other words, they should think enough of the idea to conclude that it warrants further attention and consideration. Several submissions may propose the same issue. Because yours will not be the only proposal that's submitted, you want it to stand out among the crowd.

A project has one goal. The goal gives purpose and direction to the project. At a very high level, it defines the final deliverable or outcome of the project in clear terms so that everyone understands what is to be accomplished. The goal statement will be used as a continual point of reference for any questions that arise regarding the project's scope or purpose.

The goal statement must not contain any language or terminology that might not be understandable to anyone having occasion to read it. In other words, no “techie talk” is allowed. It is written in the language of the business so that anyone who reads it will understand it without further explanation from the proposer. Under all circumstances, avoid jargon.

Just like the problem or opportunity statement, the goal statement is short and to the point. Keep in mind that the more you write, the more you increase the risk that someone will find fault with something you have said. The goal statement does not include any information that might commit the project to dates or deliverables that are not practical. Remember that you do not have much detail about the project at this point.

The specification of a date deserves further discussion because it is of major interest to the client and to senior management. First, and most important, you do not control the start date and therefore you cannot possibly know the end date. For example, it might be that the most specific statement you could make at this point is that you could complete the project approximately 9 to 12 months after starting. Even such a broad statement as that is fraught with risk because you do not know the particulars of the project yet. Senior management will need some type of statement regarding completion before they will give authorization to continue the project to the planning stages. Your objective is to postpone giving any fixed duration or completion date until you have completed the project plan.

Unfortunately, most managers have a habit of accepting as cast in stone any number that they see in writing, regardless of the origin of the number. The goal statement should not include a specific completion date. (I realize that this is easier said than done.) If you expect management to ask for a date, estimate the date to the nearest quarter, month, or week as appropriate, but with the caveat that the estimated delivery date will become more specific as you learn more details about the project. The first instance of that will be the project plan. It will specify the total duration of the project, not a specific end date. It is important that management understand how some of the early numbers are estimated, and that a great deal of variability exists in those early estimates. Assure them that better estimates will be provided as the project plan is built and the project work is undertaken. Leave the specific dates for the detailed planning session, when a more informed decision can be made.

George Doran's S.M.A.R.T. characteristics provide the following criteria for a goal statement:¹

In practice, I have incorporated the S.M.A.R.T. characteristics into both the POS and the project plan. The Specific characteristic can be found in the problem or opportunity statement and the goal statement (discussed previously), and the objective statements (discussed next). The Measurable characteristic is incorporated into the success criteria, discussed later in this section. The Assignable, Realistic, and Time-related characteristics are part of the project plan and are discussed in Chapter 5.

Defining the Project Objectives

The third section of the POS describes the project objectives. Think of objective statements as a more detailed version of the goal statement. The purpose of objective statements is to clarify the exact boundaries of the goal statement and define the boundaries or the scope of your project. In fact, the objective statements you write for a specific goal statement are nothing more than a decomposition of the goal statement into a set of necessary and sufficient objective statements. That is, every objective must be accomplished in order to reach the goal, and no objective is superfluous.

A good exercise to test the validity of the objective statements is to ask if they clarify what is in and what is not in the project. Statements of objectives should specify a future state, rather than being activity-based. They are statements that clarify the goal by providing details about the goal. If you think of them as sub-goals, you will not be far off the mark.

One variation that I have seen work particularly well is to state what is not in the project. When you are having trouble defining what is in the project, think of this as an added convenience for clarification. Don't get carried away with this though. I have also seen senior management add some of the “what is not in the project” objectives to the project objectives.

It is also important to keep in mind that these are the current objective statements. They may change during the course of planning the project. This will happen as details of the project work are defined. We all have the tendency to put more on our plates than we need. The result is that the client and subsequently the project team will often include project activities and tasks that extend beyond the boundaries defined in the POS. When this occurs, stop the planning session and ask whether the activity is outside the scope of the project; and, if so, whether you should adjust the scope to include the new activity or delete the new activity from the project plan.

The objectives might also change during the course of doing the project. This occurs in cases where the requirements are not completely and clearly defined during the scoping activities but are subsequently discovered during the project. This is quite common, so don't be too alarmed.

An objective statement should contain the following four parts:

• An outcome — A statement of what is to be accomplished.
• A time frame — A preliminary estimate of duration.
• A measure — Metrics that will measure success.
• An action — How the objective will be met.

In many cases, the complete objective statement will be spread across the POS rather than collected under the heading of “Objectives.” This is especially true for the time frame and measures of success.

Identifying Success Criteria

The fourth section of the POS answers the question, “Why do we want to do this project?” It is the measurable business value that will result from doing this project. It sells the project to senior management.

Whatever criteria are used, they must answer the question, “What must happen for us and the client to say the project was a success?” The COS will contain the beginnings of a statement of success criteria. Phrased another way, success criteria form a statement of doneness. It is also a statement of the business value to be achieved; therefore, it provides a basis for senior management to authorize the resources to do detailed planning. It is essential that the criteria be quantifiable and measurable, and, if possible, expressed in terms of business value. Remember that you are trying to sell your idea to the decision makers.

No matter how you define success criteria, they all reduce to one of the following three types:

In some cases, identifying the success criteria is not so simple. For example, client satisfaction may have to be measured by some pre- and post-surveys. In other cases, a surrogate might be acceptable if directly measuring the business value of the project is impossible. Be careful, however, and make sure that the decision maker buys into your surrogate measure. Also be careful of traps such as this one: “We haven't been getting any client complaint calls; therefore, the client must be satisfied.” Did you ever consider the possibility that the lack of complaint calls may be the direct result of your lack of action responding to complaints? Clients may feel that it does no good to complain because nothing happens to settle their complaints.

The best choice for success criteria is to state clearly the bottom-line impact of the project. This is expressed in terms such as increased margins, higher net revenues, reduced turnaround time, improved productivity, a reduced cost of manufacturing or sales, and so on. Because you want senior management's approval of your proposal, you should express the benefits in the terms with which they routinely work.

Even if you recognize the bottom-line impact as the best success criteria, you may not be able to use it as such. As an alternative, consider quantifiable statements about the impact your project will have on efficiency and effectiveness, error rates, reduced turnaround time to service a client request, reduced cost of providing the service, quality, or improved client satisfaction. Management deals in deliverables, so always try to express your success criteria in quantitative terms. By doing this, you avoid any possibility of disagreement as to whether the success criteria were met and the project was successful.

Senior management will also look at your success criteria and assign business value to your project. In the absence of other criteria, this will be the basis for their decision about whether or not to commit resources to complete the detailed plan. The success criteria are another place to sell the value of your project. For example, one success criteria can be as follows:

From that statement, management may conclude the following:

Alternatively, they may respond as follows:

Subjective measures of success will not do the job. You must speak quantitatively about tangible business benefits. This may require some creativity on your part. For example, when proposing a project that will have an impact on client satisfaction, you will need to be particularly creative. There may be some surrogates for client satisfaction. A popular approach to such situations is to construct and conduct pre- and post-surveys. The change will measure the value of the project.

Listing Assumptions, Risks, and Obstacles

The fifth section of the POS identifies any factors that can affect the outcome of the project and that you want to bring to the attention of senior management. These factors can affect deliverables, the realization of the success criteria, the ability of the project team to complete the project as planned, and any other environmental or organizational conditions that are relevant to the project. You want to record anything that can go wrong.

The project manager uses the assumptions, risks, and obstacles section to alert management to any factors that may interfere with the project work or compromise the contribution that the project can make to the organization. Management may be able to neutralize the impact of these factors. Conversely, the project manager should include in the project plan whatever contingencies can help reduce the probable impact and its effect on project success.

Do not assume that everyone knows what the risks and perils to the project will be. Planning is a process of discovery about the project itself as well as any hidden perils that may cause embarrassment for the team. Document them and discuss them.

There are several areas where the project can be exposed to influences that may inhibit project success. They are as follows:

Attachments

Even though I strongly recommend a one-page POS, some projects call for a longer document. As part of their initial approval of the resources to do detailed project planning, senior management may want some measure of the economic value of the proposed project. They recognize that many of the estimates are little more than an order-of-magnitude guess, but they will nevertheless ask for this information. I have seen the following two types of analyses requested frequently:

• Risk analysis
• Financial analysis

The following sections briefly discuss these analysis types. Check the bibliography in Appendix C for sources where you can find more information about these topics.

• Risk Analysis — In my experience, risk analysis is the most frequently used attachment to the POS. In some cases, this analysis is a very cursory treatment. In others, it is a mathematically rigorous exercise. Many business-decision models depend on quantifying risks, the expected loss if the risk materializes, and the probability that the risk will occur. All of these are quantified, and the resulting analysis guides management in its project-approval decisions.

  In high-technology industries, risk analysis is becoming the rule rather than the exception. Formal procedures are established as part of the initial definition of a project and continue throughout the life of the project. These analyses typically contain the identification of risk factors, the likelihood of their occurrence, the damage they will cause, and containment actions to reduce their likelihood or their potential damage. The cost of the containment program is compared with the expected loss as a basis for deciding which containment strategies to put in place.

• Financial Analyses — Some organizations require a preliminary financial analysis of the project before granting approval to perform the detailed planning. Although such analyses are very rough because not enough information is known about the project at this time, they will offer a tripwire for project-planning approval. In some instances, they also offer criteria for prioritizing all of the POS documents that senior management will be reviewing. At one time, IBM required a financial analysis from the project manager as part of the POS submission. Following are brief descriptions of the types of financial analyses you may be asked to provide.

Submitting the POS

After you have completed the POS, you need to submit it to your senior management for approval. The approval process is far from a formality. It is a deliberate decision on the part of senior management that the project as presented does indeed have business value and that it is worth proceeding to the detailed planning phase. As part of the approval process, senior management asks several questions regarding the information presented. Remember, they are trying to make good business decisions and need to test your thinking along the way. My best advice is to remember that the document must stand on its own. You will not be present to explain what you meant. Write in the language of the business, and anticipate questions as you review the content of the POS.

During this process, expect several iterations. Despite your best efforts to make the POS stand on its own, you will not be successful at first. Senior management always has questions. For example, they can question the scope of the project and may ask you to consider expanding or contracting it. They may ask for documentation showing how you arrived at the results that you claim in your success criteria. If financial analyses are attached, you may have to provide additional justification or explanation of the attachments.

The approved POS serves three audiences, as follows:

• Senior management — The approval of senior management is their statement that the project makes enough business sense to move to the detailed planning stage.
• The client — The client's approval is his or her concurrence that the project has been correctly described and that he or she is in agreement with the solution being offered.
• The project team — The approved POS serves as a message to the project team from senior management and the client that the project has been clearly defined at this high level of detail.

Approval of the POS commits the resources required to complete a detailed plan for the project. It is not the approval to do the project. Approval to proceed with the project is the result of an approval of the detailed plan. At this early stage, not too much is known about the project. Rough estimates of time or cost variables (also referred to as WAGs, for “wild a** guesses,” or SWAGs, for “scientific wild a** guesses”) are often requested from the project manager and the project team. You may also be asked to describe what will be done and how this will benefit the enterprise. More meaningful estimates of time and cost are part of the detailed plan.

Gaining management approval of the POS is a significant event in the life of a project. The approving manager questions the project manager, and the answers are scrutinized very carefully. Even though there isn't a lot of detailed analysis to support it, the POS is still valuable to test the thinking of the proposer and the validity of the proposed project. It is not unusual to have the project manager return to the drawing board several times for more analysis and thought as a prerequisite to management approval. As senior managers review the POS, you can anticipate the following review questions:

• How important is the problem or opportunity to the enterprise?
• How is the project related to our critical success factors (CSFs)?
• Does the goal statement relate directly to the problem or opportunity?
• Are the objectives clear representations of the goal statement?
• Is there sufficient business value as measured by the success criteria to warrant further expenditures on this project?
• Is the relationship between the project objectives and the success criteria clearly established?
• Are the risks too high and the business value too low?
• Can senior management mitigate the identified risks?

The approval of the POS is not a perfunctory or ceremonial approval. By approving the document, professionals and managers are saying that, based on what they understand the project to involve and its business value, it demonstrates good business sense to go to the next level — that is, to commit the resources needed to develop a detailed project plan.

Participants in the Approval Process

The following managers and professionals will often participate in the approval process:

• Core project team — At the preliminary stages of the project, a core project team may have been identified. This team will be made up of the managers, the professionals, and perhaps the client who will remain on the project team from the beginning to the very end of the project. They may participate in developing the POS and reach consensus on what it contains.
• Project team — Some potential members of the project team are usually known beforehand. Their subject-matter expertise and ideas should be considered as the POS is developed. At the least, you should have them review the POS before you submit it to upper management.
• Project manager — Ideally, the project manager will have been identified at the start and can participate in drafting the POS. Because you will manage the project, you should have a major role to play in its definition and its approval.
• Resource managers — Individuals who will be asked to provide the skills needed for the project are certainly important in its initial definition and later during its detailed planning. There is little point in proposing a project if the resources are not or cannot be made available to the project.
• Function or process managers — Project deliverables don't exist in a vacuum. Several business or functional units will provide input to or receive output from the project products or services. Their advice should be sought. Give them an early chance to buy into your project.
• Client — Clients play a significant role in the PMLC. As previously discussed, the COS is a prerequisite to, or a concurrent exercise in developing, the POS. Many professionals are not skilled in interpersonal communications. Developing the COS is a difficult task.

  In some situations, the client is the project manager — for example, if the development of a product or service affects only one department or in projects where the client is very comfortable with project management practices. In these situations, I encourage the client to be the project manager. The benefits to the organization are several: increased buy-in, lower risk of failure, better implementation success, and deliverables that are more likely to meet the needs of the client, to name a few. Commitment and buy-in are always difficult to get. This problem is solved when the client is also the project manager. For this approach to work, the technical members of the project team take on the roles of advisor and consultant. It is their job to keep the feasible alternatives, and only the feasible alternatives, in front of the project manager. Decision making will be a little more difficult and time-consuming. However, by engaging the client as the project manager, the client not only appreciates the problems that are encountered but also gains some skill in resolving them. I have seen marvelous learning-curve effects that pay off in later projects with the same client.

• Senior management — Senior management support is a critical factor in successful projects and successful implementation of the deliverables. Their approval says, “Go and do detailed planning; we are authorizing the needed resources.”

Approval Criteria

The approval criteria at this stage of the project life cycle are not as demanding as they will be when it's time to approve the project for execution or addition to the organization's project portfolio. All that senior management is looking for at this point is a rough estimate of the value of the project to the organization. Their approval at this stage extends only to an approval to plan the project. That detailed project plan will give them a more specific estimate of the project costs. Knowing the actual costs, senior management can calculate the return that they can expect from the project.

Project Approval Status

Senior management may not be ready or willing to give their approval to plan the project at this point. Instead, they might take one of the following courses of action:

• They may reject the proposal out of hand. That decision will often be based on a comparison of expected benefits versus total cost coupled with a time frame as to when the benefits will be realized.
• They may request a recalibration of the goal and scope of the project followed by a resubmission to seek approval to plan the project.
• They might decide that a later resubmission is in order. In other words, they are not ready to commit to the project at this time.
• Finally, the approval may be associated with a consideration to add the project to the organization's project portfolio. This is discussed in Chapter 14 as part of the project portfolio management topic.