Project Initiation

ProjectInitiation

THE COMPTIA IT PROJECT+ EXAM TOPICS COVERED IN THIS CHAPTER INCLUDE

The Initiation process group is the first of the five process groups that PMI lays out in the Guide to the PMBOK . Initiation covers the receipt of a request through the authorization to start a project. This process can be formal or informal, depending on the organization.

Initiation includes reviewing a customer request with the client to refine and clarify measurable deliverables and to develop a high-level requirements document.

A project selection process or criteria may be used to determine project approval. In this chapter we will discuss the most common methods used for project selection: cost-benefit analysis, scoring models, financial analysis, and expert judgment.

You will learn about project stakeholders: the people with a vested interest in the outcome of the project, including one of the most important stakeholders: the project sponsor.

The end result of the Initiation process is a project charter and the formal assignment of a project manager.

This chapter marks the start of an ongoing IT case study that will be used to demonstrate the application of these process groups.

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:

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:

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.

Real World Scenario ”Assessing the Impact of Regulations and Requirements

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.

Decomposing Requirements

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.

Project Selection

We received a project request and defined and documented the high-level requirements, so it must be time to actually start working on the projectright? A little wishful thinking perhaps, because our project still needs to be approved. The good news is that it is time to move on to the final hurdle to get our project authorized: project selection.

Multiple projects compete for limited budget dollars and human resources. No organization we are familiar with has ever been in a position to complete all the requests for projects that it receives. The organization evaluates project requests to determine which projects will be approved to receive funding and resources. In some instances the client is the sole approver, but often approval is required at a cross-functional or executive level.

An organization can use a number of techniques to select new projects. You need to understand the basic concepts of these techniques, so that you understand how the project selection process works and are prepared to present the appropriate data for your project.

Selection Techniques

Project selection is used to determine which proposed projects are approved to move forward. It usually includes the allocation of high-level funding. Project selection may take place using formal documented guidelines, or it may be informal, requiring only the approval of a certain level of management.

Typically, a high-level board or committee will do project selection. This committee may be cross-functional in nature and accountable for corporatewide project selection, or selection can be done on a departmental basis. A committee at the corporate level is composed of representatives from all corporate departments such as IT, sales, marketing, networking, and customer service. In other companies, an internal IT committee may review and select all IT projects.

Complex projects, especially those involving new technology or a major business process change, may be required to undergo an additional step called a feasibility study prior to review by the project selection committee. This is a more detailed look at the request than what is normally required at initiation. All aspects of the request, including profitability, marketability , risks, and alternatives will be evaluated, typically by people not associated with the project request.

Project Selection Criteria

A project selection committee uses a set of criteria to evaluate and select proposed projects. The selection method needs to be applied consistently across all projects to assure the company is making the best decision in terms of strategic fit as well as the best use of limited resources. The exact criteria varies, but selection methods usually involve a combination of decision models and expert judgment.

Decision Models

A decision model is a formal method of project selection that helps managers make the best use of limited budgets and human resources. Requests for projects can span a large spectrum of needs, and it can be difficult to determine a priority without a means of comparison. Is an online order entry application for the sales team more important than the addition of online help for the customer support team? To the impacted departments, each project is probably viewed as a number one priority. The problem is there may not be adequate budget or staffing to complete both requests, and a decision must be made to approve one request and deny the other. Unless you can make an apples to apples comparison of the two requests, the decision will be very subjective . A decision model uses a fixed set of criteria agreed on by the project selection committee to evaluate the project requests. By using the same model to evaluate each project request, the selection committee has a common ground on which to compare the projects and make the most objective decision. You can use a variety of decision models, and they range from a basic ranking matrix to elaborate mathematical models.

There are two primary categories of decision models: benefit measurement methods and constrained optimization models.

Benefit Measurement Methods

Benefit measurement methods provide a means to compare the benefits obtained from project requests by evaluating them using the same criteria. Benefit measurement methods are the most commonly used of the two categories of decision models. Three common benefit measurement methods are cost-benefit analysis, scoring model, and economic model.

A cost-benefit analysis calculates the cost, projected savings, and projected revenue of a project. This model is a good choice if the project selection decision is based on how quickly the project investment will be recouped from either decreased expenses or increased revenue. The weakness of using just a cost-benefit analysis is that it does not account for other important factors like strategic value. The project that pays for itself in the shortest time is not necessarily the project that is most critical to the organization.

A scoring model has a predefined list of criteria against which each project is rated. Each criterion is given both a scoring range and weighting factor. The weighting factor accounts for the difference in importance of the various criteria. Scoring models can include financial data, as well as items such as market value, organizational expertise to complete the project, innovation, and fit with corporate culture. Scoring models have a combination of objective and subjective criteria. The final score for an individual project request is obtained by calculating the rating and weighting factor of each criteria. Some companies have a minimum standard for the scoring model. If this minimum standard is not obtained, the project will be eliminated from the selection process. A benefit of the scoring model is that you can place a heavier weight on a criterion that is of more importance. Using a high weighting factor for innovation may produce an outcome where a project with a two-year time frame to pay back the cost of the project may be selected over a project that will recoup all costs in six months. The weakness of a scoring model is that the ranking it produces is only as valuable as the criteria and weighting system the ranking is based on. The development of a good scoring model is a complex process that requires a lot of interdepartmental input at the executive level.

An economic model is a series of financial calculations that provide data on the overall financials of the project. A whole book can be dedicated to financial evaluation, so we will give you a brief overview of some of the common terms you may encounter when using an economic model: discounted cash flow, net present value, and internal rate of return.

Discounted Cash Flow (DCF) Discounted cash flow (DCF) compares cash inflows and outflows over the life of the investment. It uses the concept of opportunity cost in discounting the cash flows. There are several measurement methods associated with DCF.

Net Present Value (NPV) Net present value (NPV) is the discounted value of future cash flows associated with a business activity. NPV measures increase in wealth and assumes that cash inflows are re-invested as capital. It is a measure of marginal return.

Internal Rate of Return (IRR) Internal rate of return measures the rate of return earned on money committed to a capital investment. IRR states the profitability of an investment as an average percent over the life of the investment.

Constrained Optimization Models

Constrained optimization models are mathematical models, some of which are very complex and require specially trained resources. They are typically used in very complex projects and require a detailed understanding of statistics and other mathematical concepts. Further discussion of these models is beyond the scope of this book.

Expert Judgment

Expertise may be sought regarding the requested product. A project sponsor, key stakeholders, other departments, consultants , or industry groups can provide this expertise.

Expert judgment can be used in conjunction with one of the decision models. We have frequently seen a combination of decision models and expert judgment used if the top project request rankings obtained from a decision model are very close to each other.

Companies with an informal project selection process may use only expert judgment to make project selection decisions. Although using only expert judgment can simplify the data required to complete project selection, there are dangers in relying on this one technique. It is not likely that the project selection committee members will all be authorities on each of the proposed projects. Without access to comparative data, a project approval decision may be made based solely on who has the best slide presentation or who is the best salesperson.

Political influence can also be part of the expert judgment. An executive with a great deal of influence may convince the selection committee to approve a particular project.

Project Stakeholders

The refinement of high-level requirements and the project selection process is where you will first interact with a very important group of people: stakeholders. You have probably seen or heard references to project stakeholders. But what exactly is a stakeholder and why is it important to identify all your key stakeholders?

A stakeholder is a person who is either actively involved in the project or is impacted by the project. Stakeholders have something to gain or lose, and you need to meet their expectations. Stakeholders may be interested and involved with the project at different phases.

Some stakeholders may not support your project. A project that creates a major impact on operational procedures may be viewed as a threat. Change can be a frightening proposition. Projects that result in a more efficient business operation may cause a staff reduction. Fear of job loss may cause certain people or organizations to work against a project.

Dealing with your stakeholders is where you will put to use many of the general management skills we discussed in Chapter 1. Individual stakeholders may have very different priorities regarding your project, and you will do a great deal of negotiating with your stakeholder group. Building consensus among a group with diverse viewpoints starts with up-front negotiation during Project Initiation and continues with ongoing communication throughout the life of the project. In Chapter 6 we will discuss Communications Planning in detail, including how you define and implement a communications plan geared to the needs of individual stakeholders.

Set up individual meetings or interviews early on in the project to get to know your stakeholders and understand their perspectives and concerns about the project. These people will not go away, and if you ignore some of your stakeholders, the issues they raise will become more difficult to resolve.

Project Sponsor

The project sponsor is a special type of stakeholder. Although projects have multiple stakeholders, whom we will discuss shortly, there is (or should be) only one project sponsor.

The sponsor is the person who champions the project throughout the organization. The sponsor acts as an advisor to the project manager. The project manager keeps the project sponsor informed of current project status, including conflicts or potential risks. The project sponsor typically has the following accountabilities:

Other Project Stakeholders

A complete list of stakeholders varies by project and by organization. The larger and more complex your project is, the more stakeholders you will have. Sometimes you will have far more stakeholders than you want or need, especially on high-profile projects. I recommend that you define who you think the other stakeholders are on the project and review the list with your project sponsor. He or she is often in a better position to identify what we refer to as political stakeholders ”influential people in the organization who have expressed a desire to be involved in this project, without a direct or obvious connection. You do not want to ignore these people just because their role is not obvious, and your sponsor can assist you in identifying the needs of these stakeholders.

Some stakeholders are more obvious and much easier to identify. In addition to the project sponsor, the following are generic stakeholders you should find on most projects:

Project manager We have already talked about the project manager in detail. This is the person responsible for managing the work associated with the project.

Project team members These are the experts who will be performing the work associated with the project. Depending on your organizational structure, these people may report directly to the project manager, matrix report to the project manager, or simply be provided by another department. Project team members may be assigned to the project either full-time or part-time. Most projects have a combination of dedicated and part-time resources. If you have part-time resources, you need to understand the other obligations of these team members to make sure they are not being over allocated.

Your project team may include only people from other IT groups, or it may include other departments such procurement, legal, public relations, marketing, sales, and customer service.

Functional managers If your resources are supplied by another organization, the functional managers who assign those resources are critical stakeholders. Normally multiple projects compete for the same resource pool. You need to establish a good relationship with your functional managers. Documented agreements on the amount of time a resource will be available to the project as well as the deliverables the resource is accountable for will prevent future misunderstandings. You should obtain up-front agreement as to your input in such areas as appraisal, salary increase, and bonus opportunity.

The functional manager is the decision maker in these areas. If you approach functional managers with these questions up front, there will be much greater clarity as to your role and your authority.

Customer/Client The customer is the recipient of the product or service created by the project. In some organizations this stakeholder may also be referred to as the client. A customer is often a group or an organization rather than a single person. A customer can be internal to the company, as would be the case if you were on a project to install a server system for the sales organization. An example of external customers is the people who purchase a new feature.

End user The term end user denotes the person who directly uses the product produced by the project. This term is often seen in IT projects to distinguish between the organization purchasing the output of the project and the group who will use it on a daily basis. As an example, the sales department may be viewed as the customer for an online order entry system, while the frontline sales consultants are the end users of this system.

End users may participate at some level in requirements review or functional testing of the product.

As you can see from even this generic list, your stakeholders represent a wide range of functional areas and very diverse wants and needs relative to your project. To keep track of everyone, you may want to develop a stakeholder matrix.

Who Are Your IT Project Stakeholders?

Typically your IT stakeholders will come from the corporate business unit(s) requesting the project. Because IT touches virtually every facet of an organization s business, it s very likely that as time goes on you ll encounter a variety of projects from all or a combination of the business units that your particular IT shop supports. You re likely to encounter three classes of IT projects that will affect specific groups of stakeholders: single business unit projects, multiple business unit projects, or enterprise projects. Let s talk about each of these in more detail.

Single Business Unit Project

In a single business unit project, you might be approached by a representative from, say, marketing or sales, for example, to help design and build a system that meets a specific business requirement.

Often in such situations you re presented with a system that the business unit is currently using but is not satisfied with. In a lot of cases, business unit stakeholders have already done some research into what they want and have some recommendations to offer for COTS applications that they think will meet their needs. As a project manager you should scrutinize the software very carefully because it may not meet the scalability requirements that larger shops have. Additionally, if the software being put forward is from another firm that wrote a custom application but is willing to loan their code you need to be doubly careful to make sure that the application being considered is solid, reliable, and, most important, supportable by your IT shop.

In some cases, the business unit has no idea about any other software applications that are available to meet a business objective or solve a business problem and they re coming to you to formulate a project that fulfills the goal. You re afforded much more leeway in a situation such as this. Generally speaking, COTS applications are so plentiful today that you will probably be successful finding a fairly close match to what the business unit is asking for. However, some instances may require that a new software application be written to custom specifications. It is up to you as the project manager wearing a systems analysis hat (or vice versa) to make the best educated decision about the proper approach to the solution.

Multiple Business Unit Project

Sometimes two or more business units can make use of a system in order to meet business objectives or solve a business problem. Document imaging and management systems (DMS) are an example of this. In a multiple business unit project , you might be approached by two or more business units that have determined that they collectively have enough capital funding to go in together on a DMS that they can all use.

Now your task has gotten more difficult because you have a variety of stakeholders involved, all with different agendas , but similar interests. Gaining consensus in such stakeholder environments will be the most important item of the day.

Additionally, you ll be forced to understand each business unit s logical flows in order to make collective sense out of the system that you design and build. One business unit, for example, may not require quality control procedures for incoming documents, for example, because they re already quality checked by the sender due to some regulation or another. But another participating business unit does have a quality control step that they need to continue to maintain. Solving for such stakeholder irregularities makes for interesting project management issues.

Enterprise Project

Another interesting project is one that impacts the entire enterprise. What we mean by the word enterprise is the complete array of business units ”everyone in the company or division is affected.

You may not be aware of it, but you ve probably been a part of or at least interacted in some way with an enterprise project . Two distinct examples come to mind: your organization s email system and its corporate intranet. All persons interact with each of these enterprise systems, and yet at most probably one group of IT people is involved with each respective system s maintenance.

Real World Scenario ”The Shared DMS

Marvin works as an IT specialist for a business unit in a company. His business unit managers have voiced a need for a DMS in order to scan in old documents and archive them in some DMS software. Any new documents will be electronically submitted and automatically populated into the DMS software.

Another business unit with similar needs has gotten wind of the project and approached Marvin s managers. Together the managers of both business units have agreed to partner to procure and implement the new system. The other business unit does not have an IT department, so they ll be relying on Marvin to assist with their implementation. They will be assisting by providing some funding for the project.

Marvin is not the owner of the datacenter, where the new DMS servers will be housed. This function is handled by the central IT shop (called Ops ) responsible for enterprise operations. He will manage the software on the servers, but Ops will be responsible for maintaining the server hardware and the database on the system.

In this case Marvin has a very complex stakeholder environment. Ops and the other business unit are both stakeholders in the efforts that Marvin s business unit is making. Success or failure can be had at the hand of any of these stakeholders. If, for example, the second business unit drops their funding, then the project is in jeopardy. If Ops cannot or will not manage the server, the primary business unit will have to find some other workaround, potentially resulting in increased project costs or duration or both. Ops must rely on Marvin s training in the new DMS software in order to make sure that users can reliably utilize the system.

Enterprise projects bring interesting stakeholder issues. Who are your stakeholders in enterprise systems? Generally, everyone will use the system. So you have to look at representatives from each group as your key stakeholders, or conversely, at certain select groups as the primary stakeholder for the system. For example, when considering a new email system, your corporate records manager; that is, the person or group responsible for setting down document retention policies, will be a very important stakeholder in any decisions you make about the retention of email items. In a new corporate intranet project, all users will be stakeholders, but most likely the content providers for each business unit will be the key stakeholder for the project.

IT Project Team Members

The IT project team has several stakeholders in various positions . The IT project team is different than a team you re assembling for a construction project. Construction workers work within their own areas of expertise (a plumber doesn t necessarily care, or have to care, what the electrician is doing, for example). But in an IT team, you have individuals who have specialized in their respective areas of IT and who may well have a clue, perhaps a substantial one, about the other team member s functions. A software developer has to be fairly database savvy, for example, because he or she will be working extensively with writing data taken from user input screens to a database somewhere. Database administrators (DBAs) must be extremely knowledgeable about the things software developers do, plus they need to understand how servers work and also how users connect to databases across the network wire. Server administrators must understand that their servers are there to support business functions ”that the underlying network operating system (NOS) isn t the sum total of what the server s about. And woven through it all are systems analysts, business analysts, business subject matter experts, and others who are participating together to bring in the project s deliverables.

Following is a list of the kinds of people you might expect to join you on any given IT project team, depending on the deliverables you re trying to produce:

Software developers Software developers are often called on to work on IT projects. This category of team member may also include folks who specialize in writing programs that run on application servers such as JBOSS, Microsoft BizTalk, or BEA WebLogic; user-interface developers; firmware coders who write software that works inside hardware devices; database stored procedure developers; and Internet/intranet developers and specialized module developers (for things such as printer and communications modules).

Server administrators These team members are responsible for bringing up the servers (whether Intel-, mid- or mainframe-based) that will house your project.

Database administrators (DBAs) DBAs are responsible for creating the database schema (structure) and associated requirements, plus planning out the backup and recovery methodologies for the data. DBA work includes the concept of reducing the table structures to their lowest operable form, a process called normalization .

Internetworking specialists Internetworking specialists are the folks who handle the routers, switches, LAN cabling, and WAN connections.

Telephony specialists The people who manage the company s telephone equipment and operations are telephony specialists. It s amazing how many systems today interoperate with telephony. Think of a telephone-based menu system, called Interactive Voice Response (IVR), realizing that a software developer had to write that code that intercepts the incoming call, provides a menuing system for the user to pick from, then routes the call back out to the appropriate party. The IVR software runs on a server but is connected to the telephony backbone.

Systems analysts Systems analysts (SAs) are people trained and skilled in IT subjects, but who operate at the functional level of taking the system requirements and boiling them down to a system design specification that the system developers can use to build the project. SAs today use very cool software such as the offerings from Rational that help them quickly and accurately model the system from business flows.

Business analysts Often one and the same as the system analyst, business analysts (BAs) are able to work at the high level of the business unit in order to understand their needs but are also able to interface with the IT folks to help them understand what it is the business unit really wants. BAs can be IT-savvy folks who come from the business unit, or business-savvy people who are in the IT shop.

System architects System architects have a very technical level of knowledge about systems and are able to draft out the blueprint of the proposed system. Sometimes the system analyst can be the architect; other times, a developer or perhaps even the project manager is in charge of architecture. However, in larger systems, it is not unusual for project managers to use the assistance of an actual system architect.

Budget analyst Especially in very large projects, a budget analyst is required to keep track of the project s budget and associated expenses.

Security analyst The security analyst is a new, yet indispensable character on most systems project teams . The security analyst is the person who makes sure that all security aspects are ironed out. Security is a unique specialty and really requires, especially in mid- to large- sized projects, someone who has a firm background and understanding of the subject.

Technical writers In larger projects a technical writer is put in charge of writing all of the documentation (with the exception of the comments directly entered into the code) for the project. This includes training documents as well as user manuals, help-desk cheat sheets and other documentation.

All of these people must be able to understand technical jargon and acronyms, and be able to fully function and get along with one another. It s important that these people feel a sense of freedom to be able to question something that s being done and to work closely with one another in making sure that the right decisions are being made going forward. There is little room for superstars or Lone Rangers (those who prefer to work alone and not associated with project teams) in efforts such as these. The project team must consist of a group of people who understand the project s goals and who come together with a cohesive purpose. Otherwise chaos will occur.

Additionally, people on project teams must be great self-starters, able to work on their tasks with little guidance apart from the system design specification. System project teams are usually not a good place for a beginner to start out because you need folks who have some basis of experience for what they re being asked to create.

As the project manager of a technical project team you must realize that you ll be working with a wide variety of personality types and you ll have to somehow manage the psychology of process accordingly . While you need to have a firm grasp on all of the technological ramifications of the deliverables being created, you must also understand team dynamics and how humans interact with one another in high-stress settings. You should be prepared to handle grievances, to mediate arguments, to gather around a whiteboard and draw out a logical function so all stakeholders understand it, to communicate in one person s lingo what the other person is trying to say, and so forth. Clear, concise and adequate communications are essential in IT project management.

Real World Scenario ”Matching the Project Charter to the Project Team

By writing a good quality project description, you ll probably have a fairly clear idea of exactly the kinds of people you ll need on your team before you even start assembling the team. Take, for example, the project description in the sidebar, IT Project Descriptions :

IT will create a set of computer programs and databases that will allow the vehicle service department to track all warranty work performed on any given vehicle. The system will be intranet-based and accessible via browser from any computer in the environment. The database will contain fields to house all relevant pieces of information for warranty work performed by the department. Reports will be generated that can be electronically shipped to the vehicle manufacturer for reimbursement. Drop- downs using lookup tables will be provided on the user interface wherever possible to minimize data entry time and incorrect data entry. Consistency checking will be performed on key fields that require double-checking of the data (such as VIN).

Clearly you can tell from this short description that you re probably going to need at least one web programmer. You don t know yet whether you ll opt for Java, C#, or some other Internet programming language ”that s not important just yet. You also know that you re going to need at least one DBA because there are databases to be created. You ll doubtless need the assistance of a server administrator to assist you in placing the databases and software that you ll develop. You ll also need a good BA to help you understand the business processes and translate them into the computer programs.

As you drill into the project a little more, you ll discover how many of each you need, but for now you ve at least identified the relevant technology people.

Stakeholder Matrix

If you have a large project with multiple stakeholders, it may be appropriate to create a stakeholder matrix to help you keep track of everyone. A stakeholder matrix should include a list of the stakeholders with the following information on each one:

This matrix can be a useful tool to review during project execution, as conflicts arise. It can help the project manager understand and deal with various behaviors. It is of particular value if your project has some of the political stakeholders I mentioned earlier.

Since project stakeholders can move on and off the project at different times, it is very important that the project manager reviews the project charter and the project plan as stakeholders become involved in the project.

Project Charter

The result of the Initiation planning process is the project charter . This document provides formal approval for the project to begin and authorizes the project manager to apply resources to the project. This is a major milestone, as the charter is the first official document of your approved project. All that hard work in the Initiation process has finally paid off.

The person or group approving the project issues the project charter. If your organization has a formal project selection committee, it may define who issues the project charter. This is typically someone in upper management, but this will vary between companies or departments. It may or may not be the project sponsor.

The charter is the project blueprint; similar to the blueprint you develop if you build a new home. The finished product will look a whole lot different, but at least you now have a map to help you get started.

Organizational standards drive the specific format of a project charter and the information it contains. As a project manager, you always want to determine if there is a template or required format to follow. At a minimum, your charter should contain a description of the project, the business need that created the project, and formal approval for the project to begin. If your project was involved in a formal selection process, you will have more data and can develop a project charter that contains the project description, project team information, goals and objectives, high-level business case, and formal approval.

Let s discuss the components of a charter in more detail.

Real World Scenario ”IT Project Descriptions

An IT project description needs to be a quick-read paragraph that encapsulates and describes in a few sentences what the project s product will do. It documents the key characteristics of the product or service that you re going to create as well as the work required to deliver the project.

The following are some examples of IT project descriptions:

Project Description

The project description documents the key characteristics of the product or service that will be created by the project and the work required to deliver the product. The description in the charter will be high level and more detail will be added when you develop the project scope statement, which is discussed in Chapter 3. The project description documents the relationship between the product being created and the business need that drove the project to be requested . This description needs to contain enough detail to be the foundation for the scope planning process that will be the next step.

Project Team

The project charter should formally identify the project manager and his or her authority. Detailing the project manager s authority in writing early on will prevent misunderstandings or issues down the road. Authority areas to document include personnel management and budget authority.

All known project team members can be listed. A charter does not normally list project team members by name , but lists the category of resources required. Job titles such as Business Analyst, Systems Analyst, Programmer, and Tester can be listed. Charters for cross-functional projects should also list known team members from other departments such as a Product Manager, Marketing Communications Manager, Training Developer, or Contract Specialist.

Goals and Objectives

The charter documents the high-level goals and objectives of the project. The project charter is the first communications document to explain what the project is all about.

A charter needs to include a clear statement as to what end result the project will produce and how success will be measured. Goals and objectives must be clear and stated in such a manner that the end result can be measured against the objective. Instead of stating , Install a fast customer record retrieval system, a goal should state a measurable outcome like Retrieve customer records in an average of 5 seconds.

Working with the client to document quantifiable and measurable goals is key to the project success. It puts the client, the sponsor, key stakeholders, the project manager, and team members on the same page. Fuzzy objectives with no measurement create vastly different perspectives as to what constitutes project success.

Business Case

Approval of the project charter also marks the initial approval for project funding. The amount of funding initially approved for the project is linked to the business case. A business case formally documents components of the project assessment generated by the project selection process. It includes a description of the analysis method and the results.

A business case is typically a stand-alone document that is initially created at a very high level with multiple iterations over the course of the project. Details to the business case are added at various points in the project planning process. Many organizations have business case templates, with some of the sections completed at the time of project selection.

A business case summary in the project charter may include high-level costs, benefits, and payback period estimates.

Costs All costs estimated at the time of project approval should be listed. These costs include estimates for materials, equipment, and human resources. The estimates in a project charter are very high-level estimates based on costs of similar projects or estimates from experts familiar with the type of work involved.

In a typical IT project, there are both capital and expense costs. Capital costs would include the purchase of new equipment such as servers or workstations. Expense costs include items like salaries, travel, and training.

Benefits A key benefit is revenue. Revenue is the cash flow generated by providing a billable good or service to an external customer. Not all projects generate revenue, but for those projects that will be sold to external customers, this is a critical component. The early revenue estimates are provided by the marketing organization based on a target price and a forecast of sales.

Revenue is a benefit that can be quantified and measured. A new product may be projected to bring in $2M in revenue during the first year of product launch.

Other benefits, such as increased customer satisfaction, may be more difficult to quantify. Benefits that cannot be easily quantified in dollars are sometimes referred to as soft benefits.

Payback period The payback period identifies when the project will pay for itself. For a revenue-generating project, this can be a timeline of the project costs compared to project revenue.

There can also be a payback period on a project that does not generate revenue. A new call handling system with menu options may drive efficiencies in a call center operation that will allow the center to grow without adding additional staff. This cost avoidance figure can be used to calculate when the system will pay for itself.

Formal Approval

The project charter should be signed by the executive with the authority to move the process forward. This person could be the project sponsor, the project client, or a representative of the project selection committee. The key is making sure the person signing the charter is at the appropriate level within the company to authorize the project.

This sign-off provides the project manager with the authority to move forward with the work required to complete the project. This approval may be required prior to the release of purchase orders or the formal commitment of functional managers to provide resources to support the project.

Issuing the project charter moves the project from the initiation phase into the planning phase. Regardless of who actually signs the project charter, now is the time to make sure you have buy-in from your stakeholder group. All of the stakeholders need to receive a copy of the charter. It is also a good idea to schedule a meeting to review the charter, review next steps, and answer any questions or concerns. To eliminate any future disagreements regarding the outcome of the meeting, all key points and any decisions made should be documented in a memo sent to all the stakeholders. Issues that are dealt with as soon as they surface are easier to resolve. Ignoring concerns or not keeping stakeholders in the loop can create escalations to higher management and start your project off on the wrong foot . The support of management is critical and the best way to maintain this support is through ongoing communications. Maintaining consensus among stakeholders is a key part of the project manager s responsibility throughout the life cycle of the project.

IT Chain of Command

When considering the overall project, especially in context of the charter and the associated names of people in that charter who are able to authorize the resources necessary to enact the project, it will be beneficial for you to understand who s in the IT chain of command so that you know who is capable of doling out this authorization. While most IT shops are somewhat smallish (i.e., just a few members in each specialty group ”servers, programming, etc.) these groups can be broken out among various managers who each have their own budget, and who can call the shots for the employees under them. For example, your project might call for a telephony person, who reports to the telecommunications department, of which there are four or five employees and who have a manager over them who is responsible for their day-to-day operations. This person is one who must appear on the charter because he has the ability to authorize the use of the resources you require. Ditto for programmers, who probably come from a different group, with a different manager. You can t schedule a telecommunications person using the authorization of the programming manager because she doesn t manage the telecom folks! So it s prudent to understand the chain of command that s involved with any given technological project.

The IT chain of command can vary widely depending on the size and spread of the organization you re working for. Generally speaking, however, there will always be a supervisor or manager of the software development, network operations, server administration, telephony, security, Internet/intranet, architecture, and database teams .

Typically, these supervisors/managers report to a director-level individual or perhaps even the chief technology officer (CTO) or chief information officer (CIO) (the so-called C- band executives) of the company. This, of course, depends on the company s size. See Figure 2.1 for an example of the IT reporting hierarchy.

Figure 2.1: The IT reporting hierarchy

In Figure 2.1 you ll see a department called the project management office (PMO). Some (not all) enterprises have realized that many endeavors benefit from a professional project manager overseeing the project ”whether the project is technical in nature or not. So the idea of a PMO was formed ”a centralized location for all project managers, staffed and managed by project professionals, and capable of taking on any project in the organization.

The Frustrations of Hierarchy

Because the charter speaks to the types of people who will be required to complete the project (note that we may not necessarily know the names of the people at this point in time, but we do know that we need a certain class of individual) understanding the chain of command makes your job easier when it comes to understanding who s got to sign off on who s joining the project. You can t, for example, stipulate that you need a programmer but not list the head of the programming department as one of the persons who must authorize the usage of his or her resources.

Here s the problem with a chain-of-command hierarchy in a standard IT shop: The director of applications development s goals may not be the same as the director of operations. Your job as a member of the project management office (PMO) is to try to get these two on the same page with respect to your project ”to see that the outcome of this project is of paramount importance and that the two must agree on this. But that s not always the case. So you wind up doing a lot of resource allocation planning, working with the leaders of each unit in order to come up with convenient windows of time when the people you need are going to be available. You don t usually have the luxury of a manager telling you You can have my best programmer for as long as you need him or her!

Another similar, only worse , problem arises when the directors of these various units don t report to the same individual, as shown in Figure 2.2.

Figure 2.2: Business units not associated with the IT hierarchy

Now you ve got an issue where you not only need to coordinate resources across various managers but also across executive leaders. While the executive might say Sure, you can use so-and-so! the manager may not be so wild about the idea. Or vice versa.

Still more confusing is the hierarchy in which the business unit has some IT staff and you also have some IT folks who are going to work on the project. This is similar to the CIO/CTO model shown in Figure 2.2 except that the business unit s objectives may be quite different than the objectives of executives who are committed to IT. You may well find that you get an initial commitment from the business unit director to use a staff IT person, but that permission is yanked back at the last minute due to other pressing issues. Or you might find that your assigned staff person is a yo-yo, being pulled constantly off of the project in order to put out business unit IT fires.

Unfortunately, there is no really good way to manage such complicated scheduling issues, apart from doing your best to anticipate problems up front and then planning into your project enough leeway to handle such issues. Business unit leaders need to understand that a commitment to an important IT project means that the staff you need are available to you at the time you need them and they cannot be used for other work!

Case Study: Chaptal Wineries Email and Intranet Systems

This case study will follow you through the remainder of the book. It s designed to be complicated enough to require the use of all of the project management components we talk about, using information from each chapter you read.

You work for a mid- sized winery ”Chaptal (named for the process of adding sugar to wine to increase its alcohol level ”chaptalization) ”in the Sonoma county region of California.

Business has been very, very good! Wine is hot, hot, hot all over the country and your wine maker, Rachel Ranee, has gained in stature and favor throughout the major wine circles.

The owner of the winery, Kim Cox, has decided to set up shop in other interesting parts of the world: Chile, southeastern Australia, and western France. She has established strong partnerships in these areas and is now ready to connect the three sites together into one network so that she can keep track of the daily activities of each new winery. The prospective new wineries are as follows :

France LaCroix is in the Bordeaux region of France. Chaptal s partner is Guillaume Fourche, a long-time Bordeaux negociant , one who buys wine from the various smaller wine merchants to blend into interesting cuvees that are then bottled and sold. Kim wants to set up an international distributorship with this man, utilizing Rachel s wine-making skills to seriously kick up the quality of the wines that LaCroix distributes.

Chile Metor Sanchez in the Aconcagua Valley has been making wonderful Chilean red wines for several years now. Metor Sanchez is interested in branching out internationally and understands that a partnership such as one through Chaptal would be beneficial for both wineries.

Southeastern Australia In Adelaide, Australia, a new renegade winery has sprung up. Roo Wines, headed up by a young new upstart wine maker, Jason Jay, holds Kim in a spell with the luscious dark Shiraz wines that they release.

Kim has entered into financial agreements and working partnerships that allow her to own a stake in each of the wine company s output, while allowing them to retain their original look and feel. The people who work for each entity will ultimately report to Kim, but each endeavor is free to continue doing what it does best. Kim has committed to not creatively interfere.

As the head of IT for Chaptal, you ve been with the winery since it had one little fileserver on which Kim kept the spreadsheets for the various accounts and Rachel kept track of the residual sugar readings of the grapes.

Today Kim has told you that she wants you to install an email server in each of the other three locations, connecting them so that everyone can quickly communicate with one another. She also wants an intranet site set up so that the new wine releases can be easily pre-released to all sites for comment and approval.

Having just recently passed the CompTIA IT Project+ test, you understand that there are some basic elements you need to capture in this first meeting:

Basic Requirements You have two requirements that you must fulfill:

  1. Set up an email system between the four sites.

  2. Set up an intranet.

Stakeholders Clearly, Kim is the project sponsor, but who will be the stakeholders? In addition to Kim there are three primary stakeholders:

  1. Guillaume Fourche

  2. Metor Sanchez

  3. Jason Jay

But in addition to this list, various staff members will benefit from the new changes. Also, the support entities that assist in the production of the various wines will be stakeholders as well.

Summary

Initiation is the formal authorization for the project to move forward. It starts with the identification of a problem, a business need, or a requirement that in turn sparks a project request. Events that trigger a project request are market demand, internal business need, legal requirement, new technology, external customer request, technological change, and social need.

The initial project request needs to be clarified to create high-level requirements, or the product description. High-level requirements and associated cost estimates are presented during a project selection process. This stage may be formal or informal, and may be done on a corporate basis or departmentally.

Project selection techniques involve the use of decision models, such as a cost-benefit analysis and expert judgment, to allocate limited resources to the most critical projects.

Project stakeholders are people who are involved in the project or people who will be impacted by the result of the project. Some project stakeholders you will likely encounter, besides yourself as the project manager, include team members , functional managers, customers (both internal and external), and end users. A project sponsor is a stakeholder who will promote the project and is available to mentor the project team as applicable .

The output from the Initiation process is the project charter. This contains the signature of the person or persons who have the authority to move the project forward. This document will be the basis for more detailed project planning. It should contain the project description, information on the project team, measurable objectives, and a high-level business case.

Exam Essentials

Be able to define the Initiation process. Initiation authorizes the project to move forward.

Be able to describe the events that drive new projects. Market demand, internal business need, legal requirement, new technology, external customer request, technological change, and social need are events that drive new projects.

Understand the three categories of requirements. Functional requirements define how the user will interact with the system. Business requirements are the big picture of what the business wants from the system. Technical requirements define what the system does to meet the business and functional requirements.

Be able to identify the most common project selection methods . The most common project selection methods are decision models such as benefit measurement or constrained optimization and expert judgment.

Be able to define a project stakeholder and list stakeholders common to most projects. A stakeholder is a person who is either actively involved in the project or is impacted by the project. Stakeholders include the sponsor, the project manager, project team members , functional managers, the customer, and end users.

Be able to describe a project charter and list the key components . A project charter provides formal approval for the project to begin and authorizes the project manager to apply resources to the project. The key components are the product description, the project team, goals and objectives, business case, and approval.

Understand the basic makeup of a project team upon reading the project charter project description. You need to quickly recognize the types of IT people youll require for a given IT project such as programmers, network people, or telecommunications folks.

Key Terms

Before you take the exam, be certain you are familiar with the following terms:

benefit measurement methods

Interactive Voice Response (IVR)

business case

internal rate of return

business requirements

multiple business unit project

constrained optimization models

net present value (NPV)

cost-benefit analysis

network operating system (NOS)

customer

normalization

database administrators (DBAs)

product description

decision model

project champion

decompose

project charter

discounted cash flow (DCF)

project description

economic model

project management office (PMO)

end user

project selection

enterprise

Request For Proposal (RFP)

enterprise project

scoring model

expert judgment

sponsor

feasibility study

stakeholder

functional requirements

statement of work (SOW)

high-level requirements

Technical requirements

initiation

Review Questions

  1. The process of project Initiation includes which task?

    1. Assigning work to project team members

    2. Sequencing project activities

    3. Approving a project and authorizing work to begin

    4. Coordinating resources to complete the project work

  2. You receive a request from customer service to develop a desktop management system for the customer support staff. What type of project request is this?

    1. Internal business need

    2. Market demand

    3. Legal requirement

    4. Technological advance

  3. Project stakeholders have which of the following characteristics?

    1. Actively involved in the project.

    2. Will be impacted by the project.

    3. Have something to gain or lose from the project product.

    4. All of the above.

  4. The project sponsor has which of the following attributes?

    1. The person who initially makes the project request.

    2. The CIO.

    3. The person who champions the project throughout the organization.

    4. The project selection committee.

  5. Which of the following would be responsibilities of the project sponsor?

    1. Provides or obtains financial resources

    2. Monitors delivery of major milestones

    3. Runs interference and remove roadblocks

    4. All of the above

  6. Which of the following is NOT a component of a high-level requirements document or product description?

    1. Testing scenarios

    2. Historical data

    3. Technical requirements

    4. Problem statement

  7. Which of these is NOT an example of a project selection method?

    1. Cost-benefit analysis

    2. Expert judgment

    3. Top-down estimating

    4. Scoring model

  8. Which stakeholder provides the employees to do the project work?

    1. Project manager

    2. Functional manager

    3. Customer

    4. Sponsor

  9. Which of the following is true of the project charter?

    1. Describes the project schedule

    2. Contains cost estimates for each task

    3. Authorizes the start of the project work

    4. Lists the responsibilities of the project selection committee

  10. You receive a confusing request from the marketing department to develop a new billing system. What is the first step you should take?

    1. You meet with the marketing person to identify the reason for the request.

    2. You assemble a team of programmers.

    3. You submit a request to the project selection committee.

    4. You request the finance department to do a cost-benefit analysis.

  11. Jane is a person affiliated with your project who has very sophisticated technical expertise. Shes quite enamored with the project and serves to provide enthusiasm , critiques, energy, communication, and motivation for your project. What is Janes role?

    1. Project sponsor

    2. Project champion

    3. Project team member

    4. Business analyst

  12. Youve been presented with a project in which youre going to develop a client/server application. Your companys collections department will equip their field personnel with tablet PCs that will wirelessly connect with the server and database. The manager of the collections department brought the request forward. You work for the PMO and are managed by the director of administrative services. The IT department is managed by the director of IT. The telecommunications segments, including wireless, are managed by the director of telecommunications. Who is the project sponsor?

    1. Manager of Collections

    2. Director of Administrative Services

    3. Director of IT

    4. Director of Telecommunications

    5. All of the above

    6. None of the above

    7. Not enough information

  13. Identify the items that should NOT be included in a project charter. (Select all that apply.)

    1. Anticipated budget

    2. Project objectives and success criteria

    3. High-level cost-benefit analysis

    4. Hardware needed

    5. Business case/mission

    6. Project description

    7. Project objectives and success criteria

    8. Project title and description

  14. Part of the work youre going to do will require a written document from an outside vendor indicating the type of work that needs to be done and the steps necessary to do them, along with the cost. What is this document called?

    1. SOW

    2. RFP

    3. RFI

    4. RFQ

  15. Youre undertaking a brand-new project in which users will connect to an application running on a server and post information to a database. At first glance, what kinds of IT people do you think youll need? (Select all that apply.)

    1. Database administrator

    2. Application developer

    3. Telecommunications specialist

    4. Server administrator

    5. Graphic designer

  16. Which of these will a project sponsor have to take into account when considering your project? (Select all that apply.)

    1. The priority of your project as it relates to others

    2. The human resources available for the project

    3. The technology that will be used to create the deliverables

    4. The budget dollars that are available

    5. The equipment that will be required

  17. From the options below, select the option that best demonstrates the functional requirements of a project (Select all that apply).

    1. System will display a final invoice.

    2. System will calculate business workdays, taking into account corporate holidays.

    3. System will be accessed through the corporate intranet.

    4. System will display in 1024 x 768 pixels.

  18. From the options below, select the option that is NOT contained in a high-level requirements description.

    1. Problem statement

    2. Objectives

    3. Strategic value

    4. Persons involved

    5. Requirements

    6. Timing

    7. Historical data

  19. Youve prepared a charter for a brand-new project. Who will formally sign the project charter? (Select all that apply.)

    1. Project client

    2. Project sponsor

    3. Chief stakeholder

    4. Representative of the project selection committee

    5. Project sponsor, chief stakeholder, and client combined

    6. Chief executive officer

  20. At what stage should the project sponsor get involved in the project?

    1. Customer contact with project manager

    2. Development of project concept document

    3. Development of project charter

    4. Revision of project charter

    5. Approval of the project charter

Answers to Review Questions

  1. C. Project Initiation is the formal acceptance of the project and authorizes the project manager to start the project work. Assigning work to team members and sequencing activities are part of the Project Planning process group . Coordinating resources to complete the project will be discussed in Project Execution.

  2. A. A request to support a process change from another department is an internal business need. A market demand is a request that is driven by the need for the organization to stay competitive. A legal requirement is a change that is mandated by a government agency or regulatory body. A technological advance is a request to use or develop technology that was not previously available.

  3. D. Project stakeholders such as the project team members can be very involved in the project. Stakeholders impacted by the project include the functional managers providing the resources and the client. End users are an example of stakeholders who may have something to gain or lose from the project.

  4. C. The project sponsor communicates the project purpose throughout the organization and acts as an advisor to the project manager. The project request can be initiated anywhere in the organization. The project sponsor could be a member of the project selection committee, but typically he or she would not participate in the selection of a sponsored project.

  5. D. A project sponsor is responsible for obtaining financial resources for the project, monitoring the progress of the project, and handling escalations from the project manager.

  6. A. A high-level requirements documents contains the problem statement, objectives, strategic value, functional and technical requirements, timing, and historical data. Testing scenarios would not be created at this point in the project.

  7. C. Cost-benefit analysis, expert judgment, and scoring are all project selection techniques. Topdown estimating is a type of cost estimating.

  8. B. The functional manager provides the employees performing the work of the project. The project manager is accountable for overseeing the work required to complete the project. The customer is the person or group that is the recipient of the product or service created by the project. The project sponsor champions the project throughout the organization and acts as an advisor to the project manager.

  9. C. The project charter formally approves the project and authorizes work to begin. The project schedule and cost estimates are developed later in the planning process.

  10. A. You must clarify the request to determine exactly what the marketing person needs. You need to understand the problem that needs to be addressed, so that you can define the high-level requirements. A cost-benefit analysis might be done following requirements definition if that is part of the project selection criteria. You would not start any programming work until after the project had been approved and further work had been done in the planning process.

  11. B. The project champion is generally a technical person aligned with the project for the purpose of supporting the project. She is not necessarily one who has a lot of power, but is one who understands the goals of the project and can help you keep the project moving forward.

  12. G. The project sponsor is an individual who is authorized to expend the resources necessary to bring about the deliverables of the project. That means that either (1) this individual has authority over all the others (such as an executive in charge of a large segment of the organization) and can therefore authorize the resources necessary from each department or (2) a consensus has been reached about who is going to be the project sponsor and that person will act as though he or she does indeed have all the necessary resources. This latter option, of course, requires that the managers dialog with one another and come to terms with the resources required and the length of time theyll be needed. So, in the question above, we really dont have enough information to make a good decision about who should be the project sponsor yet.

  13. A, D. In addition to the including your name as project manager, youll also denote the project title and description, key roles and responsibilities, project objectives and success criteria, highlevel cost-benefit analysis, business-case/mission, project deliverable description, performance criteria and enhancement opportunities, and a high-level risk assessment. The anticipated budget happens in the scope document (which well discuss in Chapter 3) and the hardware needed will show up in the project plan itself.

  14. A. The statement of work (SOW) is a document that indicates what a company will do for you and the associated charges. Requests for Information, Proposal and Quote (RFI, RFP, and RFQ, respectively) are documents that you send out prior to project WBS initiation in order to get an idea of what vendors can offer, what their costs are, and so forth. The R documents are requests for information and thus high-level whereas the SOW is a document that tells you exactly how something is going to be worked.

  15. A, B, D. You will for sure need to have someone who can handle the database, someone to program the application code, and someone who can manage the server for you. Whether you need a graphic designer will depend on how jazzy you want the application interface to bethat information may flesh out later. You probably dont need a telecommunications specialist for this project.

  16. A, B, D. The project sponsor will be concerned with the priority of the project as it relates to others that may be in the loop, and the resources, both budgetary and human, that will be available. Its you and your teams job to determine the equipment and technology thats required and put that in the project plan.

  17. A, C. Functional requirements talk about how the user will interact with the system. Functional requirements refer to how the user will interact with the system (via browser, thin-client, wireless connection, etc.). Functional requirements also refer to the notion of usabilitywhich screen pops up next after a transaction, how a user will be notified that the transaction has been successful, etc. Technical requirements are behind-the-scenes characteristics and refer to the hardware, programming, software and other technical underpinnings that will provide the backbone for the system. Note that there is a very fine line between a technical requirement and a functional requirementthe basic difference sitting with the idea of how the user interacts with the system. If youre thinking from a users perspective, youre generally describing a functional requirement, if youre thinking about servers or code, youre in the technical camp.

  18. D. High-level requirements have several specifications that you might want to consider. The persons involved do not need to be mentioned at this juncture.

  19. A, B, D. The project sponsor, project client, or a representative of the project selection committee (if you have one) can sign the project chartereffectively authorizing the project. The Chief Executive Officer (CEO) doesnt need to be the signer of a project charter for which she is not the sponsor. However, high-level projects probably deserve occasional CEO executive progress updates. The combination (letter E.) implies that all folks have to sign the charter. This isnt the casebut it is important that someone significant to the project sees and signs the charter. In some cases a project selection committee is utilized in the corporate world and it is a representative from this body that would sign the charter. Otherwise, the client or the sponsor could sign the charter. Its vital that all agree to the contents of the charter.

  20. E. Its not necessary to get the sponsor involved when youre in the early stages of business analysis and formulating a solid project concept document. A well-written project concept will, in fact, often sell the sponsor on the need for the project. However, at project charter signing time, and any time after that when the charter needs to be amended, the sponsor gets involved.

Related

Категории