Chapter2-1:Receiving a Project Request
Initiation is the formal authorization of a project and is the only process in the Initiation process group.
Before you can initiate a project, you need to have a request. A number of events can drive a new project request. These requests fall into one of the following categories:
-
New product development to meet a market demand
-
Internal business need, such as a new invoice system
-
External customer request
-
New technology
-
Legal requirement
-
Social need, such as infrastructure in a developing country
The manner in which a project request is received can vary widely in different organizations. Requests may come from inside your corporation or from external customers. Your IT organization may have business analysts who are assigned to work with various departments and proactively document departmental requests. The company may have regular interdepartmental meetings to discuss future IT projects. The person from another department making a request for an IT project is often referred to as the client or the customer. We have found that some organizations use the term customer only to refer to people external to the company, while others use customer to refer to the source of either internal or external requests. You need to be aware if there is any distinction in those terms at your company. A customer (either internal or external) may take a project request directly to your VP or CIO.
Regardless of who initiates a request or the event that triggers a request, the organization must review the request and make a decision on a course of action. Even though an initial request may not be detailed, you need to get enough information to adequately evaluate the request. As project manager, you need to meet with the requestor to clarify and further define the request, identify the functional and technical requirements, and document the high-level requirements.
High-Level Requirements
To clarify any project request, you need to develop what the Guide to the PMBOK refers to as a product description . In IT projects, a product description is often referred to as high-level requirements .
The high-level requirements explain the major characteristics of the product and describe the relationship between the business need and the product requested. In order to develop high-level requirements, you need to understand the problem or business need that generated the project request, and the functions you are providing or supporting.
Before you jump into completing your high-level requirements, you need to make sure the problem or need that generated the project request is clearly defined and understood. If the problem is unclear, the solution may be off target. You also need to understand the different categories of requirements and the importance of obtaining both functional requirements and technical requirements.
Defining the Problem
Have you ever been on a project where people are working furiously to meet a deadline, but no one appears to know why the work is being done? Then halfway through the project everything changes or worse yet, the whole thing gets canceled? If this sounds familiar, it may be that a solution was being developed without clarifying the problem. A project can get off to a bad start if the project manager does not take the time to clearly define the problem or need generating the project request.
The customer request may be nebulous and loosely worded. Your job as project manager is to figure out what the customer really means. You need to investigate the customer request and communicate your understanding of the request. This may result in the creation of a project concept document, which represents your first attempt at restating the customer request to demonstrate understanding of the project.
Problems also arise when project requests are proposed in the form of a solution. It is not uncommon, especially in the IT world, for clients to come to you with a very specific request. A client has already identified the solution required to satisfy the request. You may be thinking that is great news, because there is no need to tie up your calendar with a lot of meetings. The problem is, your client may not be asking for the right solution. As a project manager, you need to make sure that the problem has been identified before the solution is proposed.
Let’s say that you get a request for a new billing system, which would be a pretty major undertaking. The first thing you should do is meet with the person making the request to get more information. Why does she need a new billing system? What functionality is the current billing system not providing? What business need or opportunity does she believe this new system will solve? These kinds of questions will help you to understand what is behind the new billing system request. If your client is concerned about the number of customer calls related to general billing questions, the best solution might not be a new billing system, but rather a clearer explanation of the charges or a bill insert explaining each line item on the bill. If she is interested in a new look and feel for the bill, you may be dealing with requirements that range from reformatting the current bill data to using a different paper to print bills. Numerous business needs may cause your client to want a “new billing system,” but many of them may have nothing to do with developing an entirely new application. That is why a good project manager asks questions to uncover what is behind a request. Lack of up-front clarification and problem definition has been the downfall of numerous IT projects. Do not assume that a customer-requested solution is always the best solution until you understand the business need. Clearly defining the problem up front will give you and the client a better starting point for identifying the functional and technical requirements.
Requirement Categories
Once you have a clear idea of the problem behind your client’s request, you must also understand what the client’s requirements/objectives/expectations for the project outcome are. You need to identify three types of requirements: functional, business, and technical requirements.
Functional Requirements
Remember from Chapter 1 that a project produces a unique product. Functional requirements define what the product of the project will do. Functional requirements focus on how the end user will interact with the product. The requirements for a client whose business need is a new bill format are going to be very different than the requirements of a client who wants to introduce a new product or feature. This why it is so important to have the problem defined before you start looking at specific requirements. Knowing the problem will assist you in asking the right questions to identify the client requirements. For a new bill format, you need to know how the client wants the bill to appear. What are the categories of charges and credits? For a new product or feature, you will need very different data. Will this be a one-time fee or a recurring rate or both? If there is a monthly fee, is it a fixed rate or does it vary by usage? Are there discount periods? Is there a contract period or a penalty for breaking the contract?
Applications being used internally are an area where you should use extra caution in defining the requirements. Your client may assume things will work in a certain fashion without explicitly stating that assumption as a requirement. Let’s use a new order entry system for sales consultants as our example. Your client has told you that the system needs to display product availability, generate sales reports, and include a help feature. Although these may sound like good requirements, they are missing some critical data. What drives the product availability? How will the sales reports be generated? What information is included in the help feature? By asking these questions you come up with the following requirements:
Although functional requirements can be stated in more general terms than technical requirements, as a project manager, you must ask questions to drive out ambiguity. If your client requirement states that a new sales system must be easy for the sales consultants to use, do you know what that means? If the answer is no, you do not have a clear requirement, and you need to define what “easy to use” means to the client. It could be the flow of the screens, built-in help, or other criteria. The client needs to clarify the meaning so the requirement defines the functionality that will make the system easy to use. If you are not sure whether you have a clearly defined requirement, ask yourself how you would create a test scenario to validate the requirement. If there is no way to validate that the requirement has been met, you need to get more data.
Business Requirements
An organization’s business requirements are the big picture results of fulfilling a project. Business results can be anything from a planned increased revenue to a decrease in overall spending. They can even mean that an organization plans to downsize as a result of a project’s outcome.
Technical Requirements
Technical requirements , also known as non-functional requirements, are the product characteristics that are needed so that the product can perform the functional requirements. You can think of technical requirements as the things that happen behind the scenes to meet the client’s request.
There are many categories of technical requirements, and the need to include a specific type varies based on the product being developed. Some of the more common technical requirements include usability requirements, maintainability requirements, legal requirements, performance requirements, operational requirements, and security requirements.
If you work in a regulated industry, make sure you address the question of whether any specific government- or industry-related regulations impact the design or delivery of your product. Regulatory noncompliance is a serious offense and correcting infractions can be both time consuming and costly.
Industry or corporate standards may also impact your technical requirements if you are developing an application with interfaces to existing systems. The application interface may require a specific programming language or methodology. These restrictions need to be documented in the requirements, as they may impact activity duration or cost estimates that are completed in later planning processes.
Examples of technical requirements for an IT project are:
-
System response time can be no greater than 5 seconds.
-
The system must be available Monday through Saturday from 7 AM to 7 PM.
-
The system must run on both PCs and Macs.
Your client may be more prepared to discuss the functional requirements than the technical requirements. You need to be prepared with a list of standard questions. For a new customer service application you can ask for data such as the number of concurrent users, hours of operation, hardware platform, peak busy times, and other elements of the product that could impact the design and development of the new system. If your company has a requirements template or checklist, use it in your meetings with the client group.
 |
Projects often have legislative, regulatory, or other third-party restrictions imposed upon their processes or outputs. For example, suppose that you are managing a project that will create a new IT system for a funds management company, one that’s in the business of managing individual stock portfolios. You can imagine that this company is heavily regulated by the Securities and Exchange Commission (SEC) and that your new system, in turn, will encounter several regulatory guidelines that you must follow. Especially pertinent will be the security aspect of your new system. You must be able to assure the SEC and your shareholders that the system is hack-proof.
It’s important that a project manager be able to not only recognize the need to investigate specific industry regulations and requirements, but also to communicate this need and its associated impact on the project scope and project plan to the stakeholders. Here are a few examples of the many external considerations you need to account for:
Legal and regulatory conditions Know the statutes covering the type of activity your deliverable involves. If you collect information about customers, are you complying with privacy laws? Do you know which types of encryption can be exported legally? Also, you may face government reporting and documentation requirements or public disclosure rules.
Licensing terms Suppose that part of your project requires that developers write some code according to a Microsoft application programming interface (API). You need to be well aware of the licensing ramifications associated with using a Microsoft API. Trademark, copyright, and intellectual property issues all enter into this category.
Industry standards Your project may utilize various interfaces between systems. Is there some standard that governs such things? For example, Microsoft uses the Web-Based Enterprise Management (WBEM) standards to move management data from one place to another. You will need to find out how your new system can use the Windows Management Instrumentation (WMI) interface to provide support for a heterogeneous system that you’re developing. Theoretically, you would need to determine what, if any, specific methodologies or approved coding practices should be used in the implementation of your project.
Considerations such as these will help you refine the scope of the project, thus producing a more accurate project timeline.
|
Vendor Bids
Occasionally, project initiation depends on the receipt of bids from outside vendors. This situation occurs if the project request involves a new technology that requires outside expertise or if it is known up front that the project timeline cannot be completed internally.
If your project or a key component of your project is going to be completed outside your organization, you may be involved in writing or providing input for a Request For Proposal (RFP) . An RFP is a document that is sent out to of vendors requesting them to provide a proposal on providing a product or service.
Once a vendor is selected, a statement of work (SOW) is completed. The SOW is a description of what product or service the vendor will provide under the terms of the contract agreed to with the selected vendor.
The use of an outside vendor involves unique considerations that would not apply to an internally developed project. The contract is a legal document that needs to be taken into consideration as you move forward to complete the project scope and the overall project plan.
RFPs, SOWs, and contracts are part of Procurement Planning, which will be covered in more detail in Chapter 6, “Additional Planning Processes.”
Documenting the Requirements
Once you have clarified what problem your client is trying to solve and defined the functional, business, and technical requirements, you are ready to start documenting the requirements and complete the product description.
The high-level requirements document is part of the formal request for project approval. It is also the basis for defining the project scope, estimating the cost of the project, identifying the resources required, and developing the schedule. The high-level requirements should contain the following information:
Problem Statement:
What issue or problem generated this request?
What is the specific business need that the client wants to address?
Objectives:
How do you define project success?
What is the end result?
What are the deliverables leading to the end result?
What are the goals?
How are the goals measured?
Strategic Value:
How does this product fit the strategic vision of the corporation?
Is there a link to other proposed or ongoing projects?
Requirements:
What work functions are required?
Are there interfaces to existing systems?
What are the performance criteria?
What are the support requirements?
Timing:
When does the customer need the project completed?
Are there market windows involved?
Are there significant business expenses to be incurred if the project is not complete?
Is there an impact to corporate revenue if the project is delayed?
Historical Data:
Have there been similar projects in the past?
Were they successful?
Can pieces of previous projects be reused for this project?
Clearly defined high-level requirements with measurable objectives and good supporting data regarding strategic value, timing, and relevant historical information on similar projects is critical to project approval as well as ongoing communications regarding the project.
|
Objective 2.8 of the CompTIA exam specifications talks about the ability to decompose , or break down, the initial project requirements, as approved by the stakeholders and passed down to the project manager into functional, business, and technical requirements. This means you take the requirements initially given to you and try to boil out the different facets that will make these requirements come about. Then you make a determination as to whether the requirement is functional, business, or technical in nature. Additionally, “maintaining trace ability within strict configuration control”, as alluded to in the objective, means that you’re careful to make sure that the requirements you’ve decomposed continue to match the type of requirement you noted in the first place and you do not allow the requirement to morph into something else. Let’s try an example:
Stakeholder Requirement: Users throughout the company’s fifty-three campuses will be able to connect to a centralized database system via browser in order to manage sales and inventory information . You and the stakeholders have agreed upon this high-level requirement and you are now ready to decompose this complex requirement into its baser elements.
Decomposition To decompose the stakeholder requirement, we’ll pick out the main elements and determine the types of requirements these entail.
Noting these elements, it is now within your obligation to make sure as you go forward and boil the requirements down even further into the tasks, dependencies, milestones, and resources required, and that you do not violate the spirit of each of these requirements. If, for example, a business unit came to you and said: “We don’t want to connect to a centralized system because our network connection is very slow. This will just serve to slow it down further!” You might be tempted to raise a huge red flag and say “Wait a minute!” But in reality, this business unit has pointed out a fundamental issue that has to be examined for factualness and rectified if true. It does not alter the initial high-level requirement that started the project in the first place.
|
| Note |
A number of the elements described in this table will also be included in your scope statement, which will be discussed in Chapter 3, “Scope Planning.” |
Chapter 2: ProjectInitiation
THE COMPTIA IT PROJECT+ EXAM TOPICS COVERED IN THIS CHAPTER INCLUDE:
-
1.1 Given a vague or poorly worded customer request or business need, determine the appropriate course of action in order to handle various business- and project-related issues.
-
1.2 Given a set of criteria that outlines an enterprise's minimal requirements for a project charter, together with stakeholder input, synthesize a project charter.
-
1.3 Identify strategies for building consensus among project stakeholders. Select an appropriate course of action involving negotiation or interviewing strategies, meetings, memos, etc.
-
1.4 Recognize and explain the need to obtain formal approval (sign-off) by the project sponsor(s) and confirm other relevant management support to consume organization resources as the project charter is refined and expanded.
-
1.8 Given a project charter or contract including a statement of work (SOW) recognize and explain the need to investigate specific industry regulation requirements and contractual/legal considerations for their impact on the project scope definition and project plan.
-
1.13 Recognize and explain the need to build management buy in and approval into the structure of the project, and describe strategies for doing so.
-
1.15 Recognize the need to conduct a review meeting as the project transitions from the initiation phase to the planning phase. The review should include an assessment of key items.
-
2.7 Describe the goals of useful project requirements, review with the client (e.g., verify mutual understanding of client’s product delivery, product performance, and budget requirements, etc.) and describe when it is important to have such reviews.
-
2.8 Given the client’s approved project requirements and the input of stakeholders, decompose these requirements into functional, business, and technical requirements while maintaining trace ability within strict configuration control.
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.
Chapter 1-7:Summary
Summary
A project is a group of activities that produces a unique product or service with a measurable goal. It has a defined start and finish. Project management is the application of tools and techniques to organize the project activities to successfully meet the project goal. A project manager manages these activities.
A project manager needs not only technical knowledge of the product or service being produced by the project, but also a wide range of general management skills. Key general management skills include leadership, communication, problem solving, negotiation, organization, and time management.
Projects have life cycles that are composed of multiple phases. Applying tools and techniques from process groups completes these phases. The five process groups defined by the Guide to the PMBOK are Initiation, Planning, Executing, Controlling, and Closing. The type of organizational structure impacts how projects are managed and staffed. The primary structures are functional, matrix, and projectized. The traditional departmental hierarchy in a functional organization provides the project manager with the least authority. The other end of the spectrum is the projectized organization, where resources are organized around projects, and the project manager has the authority to take action and make decisions regarding the project. The matrix organization is a middle ground between the functional and the projectized organization.
The Systems Development Life Cycle (SDLC), with its distinct phases of Planning, Analysis, Design, Implementation and Operations and Support augments the overall project planning elements. In a new software development project, for example, not only would you utilize highquality project planning principles, but you’d mesh them with the elements of SDLC so you’re assured that the system you’re delivering is adequate and correct for the requestors
Chapter 1-6:Organizational Structure Impacts
Organizational Structure Impacts
The structure of your organization has a great impact on many aspects of project management, including the authority of the project manager and the process to assign resources.
Project managers can often become frustrated by what appear to be roadblocks in moving the project forward. It many cases the root issue is the organizational structure and how it operates. You must understand how your project fits within the organization in order to know the correct approach to resolving issues.
Functional Organization
The classic organization structure is the functional organization, as shown in Figure 1.2. In this structure, the staff is organized along departmental lines, such as IT, marketing, sales, network, public relations, customer support, and legal. Each person within a department has a clearly identified superior.
Figure 1.2: The Functional Organization
A project that is approved within a functional organization often has silos of work that are completed independently within each department. These silos may even be managed as separate projects.
The typical characteristics of a functional organization are limited authority for the project manager, part-time rather than full-time project resources, and an issue resolution process that must go up the departmental chain of command and laterally to other departments.
Project managers in functional organizations are often frustrated, because they are held accountable for the results of the project, but they have no means of holding team members accountable for project deliverables. The functional manager controls a team member’s salary, bonus, and job rating. You may see some functional organizations that allow project managers input into team member compensation and rating, but the amount of weight it carries may not always be in proportion to the time spent on the project.
A project manager in a functional organization will benefit greatly from developing a good relationship with the functional managers. These managers can greatly influence the success of the project. Often they are asked to provide more resources to projects than they have available or qualified people. Working with the functional manager to resolve these issues is critical.
Matrix Organization
Another common organizational structure is the matrix organization, which is depicted in Figure 1.3. Matrix organizations typically are organized along departmental lines, like a functional organization, but resources assigned to a project are accountable to the project manager for all work associated with the project.. The project manager is often a peer of the functional staff managers. The project team members have two or more bosses; their functional manager and the project manager(s) they are reporting to.
Figure 1.3: The Matrix Organization
The typical characteristics of a matrix organization are low to moderate authority for the project manager, a mix of full-time and part-time project resources, and better interdepartmental communication. There are both weak and strong matrix organizations: the stronger the matrix, the more authority for the project manager.
Project managers in a matrix organization need to be very clear with both the project team members and their respective functional managers which results the team member is accountable for to the project manager and which are accountable to the functional manager. The team member should only be accountable to one person for a given result to avoid conflicting direction. Another trouble area in a matrix organization is how thin resources may be spread. If you have a resource assigned 50 percent to your project, it should be reflected in the work assigned by the functional manager or other projects to which the team member has been assigned. Addressing resource issues up front will prevent problems down the road.
Projectized Organization
The last type of organization structure we are going to discuss is the projectized organization, which is depicted in Figure 1.4. This organization is far less common in our experience than the other two. In this type of an organization, most of the work is project work, and the company is organized by projects.
Figure 1.4: The Projectized Organization
The typical characteristics of a projectized organization are a high level of authority for the project manager, full-time project resources, and a dedicated project support staff.
Project managers in a projectized organization are responsible for all decisions regarding the project. Team members are usually colocated, which enhances communication and efficiency.
The big drawback of a projectized organization is the how to handle staffing as one project ends. There may not always be a new project waiting for resources. The timing of increasing or decreasing resources can become very complex
Chapter 1-5:Project Life Cycles
Project Life Cycles
Every project has a number of phases to mark the beginning, middle, and end of the project. The project life cycle is the composition of these multiple phases, which can be laid out on a timeline. In an ideal world, all deliverables from one phase would be complete and approved prior to the start of the next phase. In reality, the various phases of a life cycle can overlap. The term for starting one phase prior to the completion of a previous phase is fast tracking. This is normally done to shorten the project schedule.
Project life cycles vary widely between different industries and to some degree even within an organization. Although project life cycles are diverse, you will find several key elements. A project life cycle should depict at the highest level the deliverables for each phase and the category of resources involved. A life cycle should also depict how the project will be folded into the operational business on completion.
Now let’s take a look at some examples of typical life cycles of IT projects.
IT Project Life Cycles
Every IT project has a life cycle and a series of phases. The software development life cycle (SDLC) closely parallels project management process groups with its five phases: planning, analysis, design, implementation, and operation and support. The following is a closer look at each of these phases.
Systems Planning
The systems planning phase begins with a formal request to IT for a system that will solve a problem, or provide an upgrade or improvement to an existing system. The formal request is called a systems request and embodies the problem and business processes that need to be addressed within the given system.
A systems request has two potential outcomes: a preliminary investigation and a feasibility study (depending on the size of the system). The preliminary investigation basically maps to the preliminary requirement-gathering process that you go through when you’re in the Initiation process group of project management. From this preliminary investigation you may derive a feasibility study that denotes the cost-benefits associated with the request as well as recommendations that drill down into the various factors involved, such as operational, time, economic, or technical conditions.
But systems planning goes beyond the notion of “we’ve got a system we’d like for you to build.” It also gets into the idea of how that system fits into the overall corporate scheme of things—does the system enhance the corporate vision and goals?
Additionally (and more subtly), good systems planning may well point back to the need for a change in business processes in order to more closely accommodate the stated desired results. Sometimes automation and technology can’t (or shouldn’t) solve a problem, when a change in the way that a business process is currently being done will do nicely.
Systems Analysis
You’ve solidified a feasible system request and you’re planning on going forward. The systems analysis segment is the next logical step in your progression. In this phase you develop a logical model of the system by diagramming the logical flows of the data. You’ll map out what the requirements are for the new system.
| Note |
Some good system analysis techniques (but beyond the scope of this book) include data flow diagrams (DFDs) and use case scenarios and entity relationship diagrams (ERDs) that illustrate the various inflows and outflows of the system, in addition to the anticipated way that people will interact with it. |
If you understand the goals of the business manager that is requesting the system and you couple that with the logical flows that you derive for the system by going through a business process analysis, you can make your job much easier in diagramming, at a high level, how the proposed new system will operate. A visual representation of the basic business flows will also help others understand how the system parts interoperate and help nontechnical people understand how you think about their business process.
In the analysis phase you begin to knock out what it is—the nuts and bolts—that this system consists of. Through your previous analysis process, including interviewing various stakeholders, performing fact-finding analysis, and formulating solid objective ideas about what the system should be comprised of and what it should do, you can build various enterprise models that include the data objects themselves. You also can understand the various process and data models that are involved. Also, fleshing out a prototype at this point will prove to be a worthwhile effort because prototypes give stakeholders a way to visualize the new system.
The systems planning and analysis phases roughly correlate to the Initiation and Planning process groups, which we’ll discuss in more detail in Chapter 2.
The final outcome of the systems analysis phase is called a systems requirements document. The document spells out what you heard the business representatives say that they wanted in the new system. You got here by going through a variety of processes including interviewing various experts in the business process, sitting with them to watch how they go about their work, questioning the manager, and other such methods. The document is about the business for the business. Like a da Vinci charcoal drawing intending to help the artist understand what it was he was going to paint, the business requirements doc will help you derive your new system.
Systems Design
In the systems design phase you denote all the components that will be included in your IT project, including all of the inputs (such as data flowing into the system or keyboard input by a data-entry clerk), outputs (such as screen displays or reports), and processes involved. Additionally, at design time you flesh out the various controls required, whether automated or manual, that will contribute to the system’s successful operation. If you’re working on a project in which code has to be written, you’ll draw out the architecture that the application(s) will use in a document, called the system design specification (SDS), a detailed document that allows the project team members to exactly build the desired system. The SDS illustrates exactly how programmers are to create the system.
If the system doesn’t require software development, but does require database or infrastructure creation or enhancement, it’s key that all stakeholders, from management to end users, understand what you’ve designed and how you imagine it will work, and that technicians be able to build the desired system. If you’re using a Commercial Off The Shelf (COTS) program, you’ll design its integration into the system that you’re building.
Note too that other elements such as infrastructure additions or renovations, cabling upgrades, WAN connectivity (including wireless), new types of computing such as PDAs, telephony integration, and a host of other things may be included in the design of your system. Just because your system primarily uses software does not mean that the underlying components don’t need to be addressed and freshened as well.
Systems Implementation
In the systems implementation phase of the IT project life cycle, the system is constructed. Whether that means that programmers write programs, you purchase COTS programs, or you come up with some in-between system that uses elements from both worlds, you’ll want to deliver a completely functional and fully documented system.
This phase includes such elements as the conversion of old data to new tables, training the users, testing, and migrating to the new system. You’ll also prepare a write-up called the systems evaluation to provide an earmark as to how well the system performs relative to your stipulations in the system design specification.
Systems Operation and Support
Mapping somewhat to the Closing process group, which we’ll discuss in just a moment, the systems operation and support phase means that you put the system into routine operation, and provide a method whereby the system can be supported if there is trouble. However, the operation and support phase goes beyond Closing in that it calls for elements such as change management where you have maintenance or enhancements that need to be performed and you provide for some modicum of scalability in the system, should it need to be added to later.
You need to know two other things as a manager of projects in the IT project life cycle: setting milestones and checkpoints. Let’s discuss this further.
Project Concept Documentation
Let us mention here another type of document that you might want to consider when you’re meshing two management methodologies together (i.e., project management and the SDLC): the Project Concept Document. At initial requirements-gathering time, the systems analyst will generate a document that contains the high-level requirements she discovered upon examining the customer request. This document could act as a starting point in the project planning process as well. A systems analyst may not be a project manager, or may be—it depends on the way your company is laid out and the complexity of the project before you. But we know that good quality systems analysis and design leads to high-efficiency systems, especially when built under a well-developed project management paradigm. A starting-point document for both players—the project concept document—is an ideal way to flesh out the skeleton of the project and get the two parties talking.
Note that the systems analyst will go on to develop some very elaborate flows out of her initial requirements—the project manager must be in lockstep with the elements being worked out.
IT Project Milestones and Checkpoints
Any good SDLC process should include the milestones on which you see the project pivoting. For example, perhaps a significant milestone for an e-commerce project would be the purchase, acquisition, installation, configuration, and deployment of the web servers that will be used for the system. A very discreet set of tasks are needed in order to accomplish this milestone. At its accomplishment, in the systems design world, we’d step back and ask project stakeholders such as the managers and technicians to give us a go/no-go decision regarding whether the project should move forward.
Additionally, in between milestones, good projects include several checkpoints along the way that reveal whether we’re on time and within budget in our project. A prudent number of checkpoints (not too many to be burdensome) can reveal the pulse of the project at any given point.
Chapter 1-4:Project Processes
As we discussed earlier, PMI defines project management as a series of processes that are executed to apply knowledge, skills, tools, and techniques to project activities to meet project requirements. These processes have been organized into five groups.
The process groups are tightly linked, as the outputs from one group are the inputs to another group. Figure 1.1 shows the links between the groups. The process groups may overlap. You may begin planning the project before all of the initiation activities are complete.
Figure 1.1: PMI Process Groups
As we discuss each group, notice the correlation between the process groups and the domains covered in the CompTIA IT Project+ exam. The process groups are the foundation of project management. You need to understand each group and how it contributes to the completion of the project.
Initiation Processes
Initiation processes include all of the activities that lead up to the authorization to start the project. These activities include such items as business need identification, high-level requirement definition, and cost justification. Because the Initiation process is an integral part of Domain 1.0 on the IT Project+ objective blueprint, we will take a more detailed look at the initiation process in Chapter 2, “Project Initiation.”
Planning Processes
Planning processes are where the project goals and objectives are refined and broken down into manageable pieces of work. Project managers create time and cost estimates, and determine resource requirements for each activity.
Several other critical areas of managing a project require up-front planning. These areas include communication, risk, quality, and procurement.
| Note |
The Planning process group, which is included in both Domains 1.0 and 2.0 of the exam, is undoubtedly one of the most critical stages of managing a project. For that reason Planning will be covered in detail in Chapters 3–7. |
Executing Processes
Executing processes are where the work to complete the project is done. The project manager must coordinate all the project team members as well as other resources assigned to the project.
Executing processes include the actual execution of the project plan, team development, quality assurance, and information distribution. We will examine this more closely in Chapter 8, “Project Execution.”
Controlling Processes
Controlling processes are the activities that monitor the progress of the project to identify any variances from the project plan. Requests for changes to the project scope are included in this process. This area is also where any corrective action will be taken.
Other areas of the Controlling process group are cost control, quality control, performance reporting, and risk control. In Chapter 9, we will spend considerable time discussing the various methods for monitoring progress, specifically change control and quality control.
Closing Processes
The closing processes drive the formal acceptance of the project work and provide a means to fold the product into the ongoing organization structure.
Closing processes include sign-off, archive of project documents, turn over to a maintenance group, release of project team members, and review of lessons learned. Although some of these activities may seem fairly straightforward, several areas deserve close attention. Chapter 10, “Project Closure,” will explore the last stages of an IT project and how they can differ from other projects.
Chapter 1-3:General Management Skills
General Management Skills
Project managers possess many skill sets that are unique to running a project. Successful project managers also possess general management skills, sometimes referred to as soft skills. These are skills that any good manager uses on a daily basis to manage resources and meet goals. You probably already use some of these skills in your day-to-day work activities. General management encompasses many skill areas including:
-
Leadership
-
Oral communication
-
Written communication
-
Listening
-
Organization
-
Time management
-
Planning
-
Problem solving
-
Consensus building
-
Conflict resolution
-
Negotiation
-
Team building
A project manager looks at the big picture and interacts with a broad spectrum of stakeholders. Good management skills are as critical to the success of a project as the correct technical skills.
In the following sections, we are going to take a look at a few key general management skills and how they apply to project management. We will also examine how these fundamental skills translate into your industry.
Leadership
A project manager needs to be a good leader. A project team comes together for the life of the project, which can sometimes only be a few months. Team members will have very different skill sets and project experience. IT projects commonly have both technical team members and representatives from other areas, such as marketing, sales, customer service, or training. Team members may not have worked together in the past. To add even more complexity, team members may roll on and off the project at different times.
The project manager is accountable for sharing the strategic vision that created the project and providing overall direction to the team members. A good project manager knows how to align and motivate diverse people with varying backgrounds and experience.
Communication
Successful project managers will tell you that they spent a great deal of time communicating. Even the most detailed project schedule can fail without proper communication.
Project managers must develop a communication strategy that includes the following critical components:
Keeping these components in mind and developing a comprehensive communication plan up front will prevent misunderstanding and conflict as the project progresses.
Problem Solving
Projects always have problems. Some are just more serious than others. Project managers must use problem-solving techniques throughout the life of the project.
|
You’re working on a software development project for a business unit in your company. You’ve gotten past the initial project request steps and you’re now in the process of honing in on the details of the requirements for the project.
You require subject matter expertise from the business unit in order to more fully understand and appreciate the business processes that your software is going to automate.
You set up a meeting with the director of the business unit. At the meeting you ask her two things. First, you want to know if you can use someone from the business unit to assist you in understanding the business process flows. You make it clear that the assigned individual must be an SME in the business process. Second, you ask if you can have this individual full-time for a minimum of two weeks. You suggest the name of someone whom you think will perform very adequately as a business SME.
The director is shocked that you require so much time from one of her people. She asks you to more thoroughly explain your need. You explain to her that in order for you to develop software that fully meets the business need, you must understand the flows that are involved in the business process. Further, you describe the process of generating a data flow diagram (DFD), a block diagram that shows, at a very high nontechnical level, the process as you see it, noting that you’ll need the SME to validate the DFD.
After some bantering back and forth, the two of you come to an agreement that you can have a week and a half of someone’s time and that you’ll use not one but two different business SMEs, splitting their efforts accordingly so that neither one has to fully dedicate their time to the business flow discovery process. The director stresses repeatedly to you that her people are so busy, she is being very generous in letting you have them at all.
You agree to the specifications, thank her for her time, and get to work figuring out the best questions to ask the SMEs in order to complete the business flow discovery process in as efficient and timely a manner as possible.
|
The key to problem solving is to recognize that a potential problem exists. Early recognition of warning signs will simplify the process. Pay close attention not only to your project team’s formal progress reports, but also to what team members say and do.
If you do identify a potential problem area, take the time to clearly identify the problem. A vaguely stated problem may drive the wrong solution.
Once a problem is clearly and concisely identified, the project manager works with the appropriate project team members to brainstorm alternatives. These alternatives can now be evaluated and a solution chosen. A project manager monitors the implementation of the solution to ensure that the problem is resolved.
Negotiation
A project manager is involved in negotiating throughout the life of the project. Negotiation is the process of obtaining mutually acceptable agreements with individuals or groups.
Depending on the type of organizational structure, you may start the project by negotiating with functional managers regarding assignment of resources. Project team members may negotiate specific job assignments. Project stakeholders may change the project objectives, which drives negotiations regarding the schedule, the budget, or both. As you execute the project, change requests often involve complex negotiations, as various organizations propose conflicting requests.
If your project includes deliverables from an outside vendor, you will be involved in negotiating a contract. This area is specialized and may involve representatives from a legal or procurement department.
Organization and Time Management
A project manager oversees all aspects of the work involved to meet the project goals. The ongoing responsibilities of a typical project manager include tracking schedule and budget updates, conducting regular team meetings, reviewing team member reports, tracking vendor progress, communicating with stakeholders, meeting individually with team members, preparing formal presentations, and managing change requests.
Meetings consume valuable project time. Effective meetings do not just happen; they result from good planning. Whether you conduct a formal team meeting or an individual session, you should define the purpose of the meeting and develop an agenda of the topics to be discussed or covered. Time allocation for each item is critical to keep a meeting within the allotted time.
Clear documentation is critical to project success, and it must be available for immediate use. Without an efficient system for maintaining documentation, a project manager will waste precious time searching for the latest version of the schedule.
An excellent way to learn organization and time management techniques is to spend time with an experienced project manager willing to act as a mentor
Chapter 1-۲:Defining Project Management
Defining Project Management
You are now equipped to identify a project and have a better idea of what types of IT projects you will be managing. But what exactly is project management? You may have already heard a lot of different answers to that question. To eliminate any confusion, we define project management and associated terms according to the standards set by the Project Management Institute (PMI) . PMI is the leading professional project management association, with over 100,000 members in over 125 countries worldwide. PMI is a leader in the development of project management standards, which are listed in what is called the Guide to the PMBOK .
The Guide to the PMBOK
Project management ’s standards are documented in A Guide to the Project Management Body of Knowledge ( Guide to the PMBOK) . PMI also manages a very rigorous certification program, the Project Management Professional (PMP) certification. The Guide to the PMBOK is the basis for the exam portion of the PMP certification. If you continue in a career in project management, you may move on to the PMP certification. The material you have studied to prepare for the IT Project+ exam is an excellent foundation on which to build your project management knowledge. PMI members were involved in the revision of the IT Project+ exam, and the questions on the exam are consistent with the Guide to the PMBOK standards.
The Guide to the PMBOK defines project management as “the application of knowledge, skills, tools, and techniques to project activities to meet project requirements.”
The project manager (PM) is the person who oversees all of the work identified to complete the project and applies a variety of tools and techniques. Successfully managing a project involves dealing with competing needs for your resources, obtaining adequate budget dollars, identifying risks, managing to the project requirements, interacting with stakeholders, staying on schedule, and ensuring a quality product. Sounds a little overwhelming at times, doesn’t it? Guide to the PMBOK categorizes each of these into nine knowledge areas. Let look at these in more detail.
Later in this chapter we will look at the five process groups that cover these knowledge areas.
Project Management Knowledge Areas
Successful project management is dependent on the use of key processes. These processes must cover the core knowledge areas critical to project management. The Guide to the PMBOK defines the nine Project Management Knowledge Areas as:
-
Scope Management
-
Time Management
-
Cost Management
-
Quality Management
-
Human Resources Management
-
Communications Management
-
Risk Management
-
Procurement Management
-
Integration Management
As you move through subsequent chapters, we will cover these items in more detail. These areas make up the total realm of project management, and Guide to the PMBOK threads each of these knowledge areas into a series of process groups, which will be discussed later in this chapter. These knowledge areas may not have equal importance in your specific IT job area. For example, if you do not have outside contracts for your project, Procurement Management may not apply. The IT Project+ exam has a strong focus on the knowledge areas that are part of the planning processes and the project execution processes.