Picture this: you’re an IT professional, and your manager informs you that the entire network, from the physical cabling to the network cards in each machine, has to be replaced with something bigger, better, and faster.

After you recover from choking on your coffee, you ask, “Something? What exactly did you have in mind?”

And what does your boss say? “I dunno. Something faster. Just figure it out and let me know what’ll work. By the way, we can’t spend too much. See ya.”

While this may not be a typical way for a project to begin, you can see that before any charter, scope, or cost-estimating talks get underway, you have a ton of research and planning to do. Where does that planning begin, and how can you formalize your results? And what subject matter experts will you call upon to help? This chapter will answer these questions and help you streamline your efforts.

How to Plan

Don’t laugh. Many IT project managers, executives, and professionals don’t know how to plan. Oh sure, they think they do, but the reality is they don’t. When these folks begin planning, their efforts consist of searching the Internet randomly, leafing through vendor brochures, and chatting with other professionals about similar problems they’ve encountered and how those problems were resolved. On the surface, this looks like a great effort. The Internet, vendor brochures, and interviews are all essential elements to IT research. The trouble, however, is there’s little rhyme or reason, little approach, and, most important, few results to show for the effort.

The type of project management you use, agile or predictive, will also affect your planning efforts. Recall that predictive projects plan everything in detail early in the project. The goal is to predict what will happen. Agile projects also do some upfront planning, but the focus is more on the requirements of the project, not how and when everything will take place. Agile projects plan and execute in short bursts, while predictive projects plan and then execute with opportunities to return to planning as needed.

The goal of research is to come to a conclusion, a discovery, and hard-hitting facts upon which a decision, a plan, or an implementation can be based. Now here is the key: good research stems from an organized, concentrated effort. In order to do good research, you also have to know what you’re researching for. This means you’ll need to understand the business opportunity or the problem that the project will address—and you’ll do that through stakeholder interviews. Some of these efforts in your organization may reside with the business analyst—but as the project manager, you still need to understand why a project is being initiated and what the project is to accomplish.

In order for a predictive project to be successful, the project manager and the key stakeholders must know exactly what it is the project will create. Agile projects start with a general idea of the key requirements and then, over time, typically add more requirements to the project scope. Often, especially in information technology, the customers of the project don’t know what they want or what your project should create. They may have a general idea of a scenario they’d like you to create for them. Through interviews, quantitative analysis, and in-depth research, you’ll propose solutions to them. Project managers need to link project solutions to terms, scenarios, and conditions the stakeholders can understand.

When creating a solution for a customer, the project manager must have the same vision the customer has for the final product. While there will, no doubt, be iterations and revisions as the project progresses, it’s better to understand up front what the project deliverables consist of. Root cause analysis allows the project manager and the customer to work together to find the solution for the problem, opportunity, or other condition the project is to resolve.

When you go about researching anything, from real-time transaction servers to wireless networking, you must possess a plan of attack, maintain laser-like focus, and document your efforts. How do you plan? Here is a sure-fire, six-step method that works:

1.   Define the purpose of the research in writing. Writing a concise concept definition statement of the project helps form the research you are undertaking. The concept definition statement defines the intent of the project based on the high-level goals, problem to solve, or opportunity the project aims to capture. This document will help you develop the laser focus you’ll need for success. Keep that statement in plain view as you research. Don’t lose track of your purpose, or you’ll meander through your research like a lazy walk in the woods. You might know the concept definition statement as a current and future state assessment, a needs assessment, or even a solution scope. It’s a document defining the purpose of the research.

2.   Determine what resources you will use during this research. Make a list of avenues of information you’ll use. This is not to rule out any possible source of information, but to list your sources and then organize them in priority. Sources can include

•   Organizational process assets such as historical information, files from past projects, and documented experience with the related technology

•   Expert judgment such as consultants, subject matter experts, and other people in the organization

•   Qualified, quality Internet sites

•   Specific trade magazines

•   IT books directly related to the topic

•   Vendor brochures

3.   Delegate. If you have team members in mind for this project, use them to help in the research. You’ll need their expertise and experience to develop the best solution for the project purpose. Break down the planning into multiple components and then delegate portions of the research to team members. You might use a roles and responsibilities matrix to identify who’ll research what area of the business problem or solution. Many hands may lighten the load, but accurate workers with knowledge develop the plan.

4.   Get to work. Begin reading, evaluating, and taking notes on your discoveries. If you use the Internet, bookmark useful pages you’ve found. Few things are worse than knowing there’s a great page out there somewhere, but you can’t remember when or where you saw it. Record the names of books and magazines you’ve used and associated page numbers. This supporting detail will help you later when you present a solution to your stakeholder and formalize your project plan.

5.   Organize and document. Compile all of the information you and your team have gathered. This is the start of a feasibility study. One key management skill is the ability to organize and recall the needed information at short notice. A knowledge management system is ideal for any project manager because it can help you quickly access information.

6.   Evaluate and do more research. Once your research has come together, determine if the collected data answers the research purpose. If it does, move on. If it does not, continue to research following these same six steps as your guide.

This method of research is simple and direct, but it will produce results. One key element is time; don’t get bogged down in the research process. “Analysis paralysis” is the ongoing study of a problem to delay actually addressing the problem. Of course, quality takes time, but set a deadline to reach step 5. As you can see in Figure 2-1, the steps to successful research also follow a projected timeline.

Figure 2-1  Time management is crucial to effective research.

Defining the Business Value

Projects aren’t done for fun—there must be a business value behind the decision to invest capital in a project. It’s no secret that IT projects are risky: they fail, come in late, run over budget, and sometimes are never completed at all. Even the best project manager can wrestle with risks, issues, and unforeseen delays in IT project management; this is why management and stakeholders need assurance that there is a genuine need and return on investment for their organization’s efforts and funds.

Defining the business value is a project management research activity that overlaps with business analysis duties. If you’re lucky enough to have a business analyst doing this bit of work for you, offer your sincere thanks. If you’re the person responsible for linking the need to a project solution, you’ll have some extra duties, but you’ll also have a deeper understanding of what the project needs to accomplish. The business value addresses the business need and why the project should happen.

The business value will help the project manager define the project scope and the project management plan in a predictive environment. In an agile project, the business value is represented in the prioritized product backlog. To understand the business need fully, to write a feasibility study or business case, you need to experience the problem or interview people who have experienced the problem. It’s also possible that the business need isn’t a problem, but an opportunity, so you’ll have to see the possible outcomes, good and bad, of a proposed solution that could create a loss or a return on investment. These elements help the project manager and the project team understand the stakeholder requirements and what the project must accomplish.

Determining the Business Objectives

A business objective defines the specific outcome the business wants to achieve. It paints a picture of what the organization should look like once your project is done. When you go about identifying the business goals and objectives, it’s helpful to do a current state assessment: document what’s happening right now in the environment that prompts your stakeholders to want a change. Once you’ve identified the current state, you’ll next create a description of the desired future state; this is where the organization wants to go. The difference between the current state and the desired future state is the high-level view of the project scope.

The purpose of defining the business goals and objectives is not to create a solution. While your research, conversations with stakeholders, and organizational process assets from past projects may point you toward a solution, that’s not the purpose just yet. When you define the business goals and objectives, you’re simply defining the end results of what your project will create. Common business goals and objectives for IT are to

•   Cut costs.

•   Increase revenue.

•   Secure the organization’s technology assets.

•   Improve customer satisfaction.

•   Improve employee satisfaction.

•   Seize a marketplace opportunity.

•   Adhere to new or pending regulations.

•   Become more efficient.

And there are probably hundreds of other technology-related goals. The purpose is to understand why a project needs to be created to get to how the desired future state can be reached. Business goals and objectives will also help you and the stakeholders realize the needed time and required costs for the project later in planning.

To create the business goals and objectives, you’ll use six typical tools, as described in the following sections. Keep in mind that these tools aren’t solo activities. You’ll include your project team, the identified stakeholders, management, and maybe even subject matter experts. Determining business goals and objectives is crucial to understanding the problem so that you can create an accurate and cost-effective solution.

Benchmarking  This tool compares one component to a similar component. In IT, you’ll often use benchmarking when you have multiple choices between software packages or hardware solutions. For example, you might compare the benefits of Oracle software to SQL. The comparison could track technical metrics but also things like interoperability, support, learning curve, and maintenance costs.

Brainstorming  This approach encourages participants to generate ideas about an opportunity or business problem. Brainstorming at this stage of research is useful to determine different types of outcomes for the project. You should encourage the participants to come up with as many ideas as possible, which then can be sorted and researched more in depth after the session.

Business Rules Analysis  If the project outcome will likely affect the way your organization does business, you should study the business rules. Business rules define the internal processes to make decisions; provide definitions for operations; define organizational boundaries; and afford governance for projects, employees, and operations.

Focus Groups  Focus groups are a type of stakeholder analysis. An impartial moderator leads stakeholders through a discussion about the opportunity or problem. A scribe or recorder keeps the minutes in the meeting, and then the business analyst, product owner, product manager, project manager, and other key stakeholders will analyze the results. An average focus group has 6 to 12 participants. The participants can be considered homogeneous if they all share the same characteristics, such as all salespeople. Or you can use a heterogeneous group, in which the participants are stakeholders with different backgrounds, such as users of a software product from different departments within your organization.

Functional Decomposition  This method simply takes a large problem and breaks it down into smaller, manageable components. While it sounds easy, it’s tricky. You want to break down the problem into subcomponents that are as small as possible so that each “subproblem” can be managed independently of the other problems. You will need to link the components together so that one solution to a subproblem doesn’t adversely affect the solutions to other components in the decomposition.

Root Cause Analysis  You’ll see this approach often in project management. Root cause analysis involves studying the effect that’s being experienced and then determining the causal factors of the effect. This is one of the purest forms of analysis, and the results are often graphed in a cause-and-effect diagram. You’ll also use this approach in quality control.

Creating a Feasibility Study

A feasibility study is a documented expression of what your research has told you. It helps you determine the validity or scope of a proposed project or a section of a project. Feasibility studies can help solidify whether a problem is solvable or whether the organization can realize an opportunity. You might also be tasked with writing a feasibility study to determine the financial aspects of the project—including potential return on investment.

Feasibility studies are often written with upper management in mind, so they’re direct, organized, and generally factual rather than opinionated. As you approach your project, keep in mind that the goal of any IT project is not technology for technology’s sake, but to add value to the organization. The feasibility study determines if the proposed project can be feasibly accomplished.

As you draft the feasibility study, think like an executive and write with the business in mind, focusing on how the proposed technology will benefit the organization. If you approach any project as if it were a business venture and you were the proprietor of the business, you’ll be much more successful in your work. As the “project proprietor,” you assume ownership and responsibility of the project and its success or failure.

Organizing the Feasibility Study

To begin writing the feasibility study, refer to the concept definition statement and the business goals and objectives you used in the research phase. The business goals and objectives define why you initiated the planning process and should reflect the proposed project. As Figure 2-2 demonstrates, the concept definition statement is the foundation of the feasibility study structure.

Figure 2-2  The concept definition statement is the foundation of the feasibility study.

For example, suppose an international company is investigating implementing a new, to-be-determined application that will need to manage multiple calendars, resources, and e-mail. The company’s concept definition statement at the start of the research reads as follows: “To determine the selection of a web-based calendaring system that can provide resource management, e-mail, public and private meetings, and workgroup collaboration, the application must be proven, be able to integrate with our current network operating system, and address international time zones.” This statement would introduce the feasibility study.

The feasibility study is divided into eight sections:

•   Executive summary

•   Defined business problem or opportunity

•   Purpose of the study

•   Options assessed

•   Assumptions used in the study

•   Audience impacted

•   Financial obligations

•   Recommended action

Each section is vital to the study and should be direct, be full of facts, and provide references to the historical information and supporting evidence you’ve used to create the study. The feasibility study is usually created when large projects with high priorities are proposed. You won’t need to create a feasibility study for every project.

Executive Summary

The feasibility study should start with an executive summary, the purpose of which is twofold: to draw the reader into your findings and to define the key points of your analysis. As its name implies, it provides a summary of your findings so that the entire document doesn’t have to be read. It should include a summation of each of the remaining sections in your feasibility study.

Defined Business Problem or Opportunity

This section describes the business problem and its effect on the organization or the opportunity the organization may seek. The business goals and objectives can be used in this section to link the proposed product or solution to the identified opportunity or problem to be solved. You’ll also document the benefits of the technology you’ve investigated and are recommending. Ideally, you’ll investigate several solutions, performing what is sometimes called alternative identification, so as not to marry the organization to any one solution before examining all options.

You should write this section to pinpoint the audiences impacted by the proposed technology. This section may also include

•   Benchmark results of the alternative identification

•   Support for the recommended product(s)

•   How the recommended product(s) may dovetail with the current technology

•   Vendor history

•   Other organizations that have successfully implemented the product

•   Any shortcomings or risks involved with the proposed product

Purpose of the Feasibility Study

Most feasibility studies are launched to determine if an identified opportunity is valid or to determine if an identified problem can be resolved. Feasibility studies can also be initiated for a number of other reasons:

•   Compare hardware solutions.

•   Compare software solutions.

•   Determine buy-versus-build opportunities.

•   Determine capability gaps with new technical solutions.

•   Determine disaster recovery options.

•   Investigate maintenance of the organization’s technical status.

This section describes the intent of the feasibility study, considers why it was initiated, and connects the feasibility study to the business goals and objectives.

Options Assessed

Feasibility studies examine multiple options, often called alternative identification, for the business problem or opportunity to determine the best solution for the organization. The project manager needs to explain which options were assessed in the study, why the options were selected, and how the options differ from one another. For example, you might investigate for your sales reps four types of mobile phones and service packages from different companies. Each phone may have similar traits but may differ in application usage, costs, maintenance, and interoperability with existing technology.

Assumptions Used in the Study

An assumption is something you believe to be true but you have not proven to be true. In a feasibility study, you may have to make certain assumptions with the technology you’re assessing for the sake of time and cost. For example, you might assume that your server configuration will work with each of the software options you’re researching because it meets the hardware specs provided by the vendor. You’d choose this assumption rather than testing the software options on a live production server.

Audience Impacted

The feasibility study should address issues concerning the users, capability resource gaps, and who will be affected by the implementation:

•   How much downtime will the audience experience because of the implementation?

•   What is the learning curve of the new software?

•   Will training classes be needed for all users?

•   How will the recommended software transfer or work with your organization’s existing technology?

•   How long before this software will be upgraded again?

•   How long before it will be retired, obsolete, or no longer supported by the organization?

Also in this section of the plan, you need to mention how the technology will be implemented. If one part of the organization switches to the new technology before other parts of the organization, for example, will the technology have an impact on work and communication between the two parts of the organization? How long will the technology implementation take?

Financial Obligations

This section of the feasibility study provides an overview of the cost of the technology rather than a full-blown budget. Consider these factors:

•   Price of the technology product

•   Necessary licenses

•   Training for the implementation team

•   Cost of labor to create or implement the solution

•   Technical support from the vendor

•   Outside talent and contractors to install the technology

•   Monthly fees that may be associated with the technology (for example, service-related fees such as those for using a remote data backup service)

•   Cost of not implementing the solution

The financial obligation section can also include return on investment (ROI) analysis. You should demonstrate how the technology will increase productivity, be easier to use, increase sales, or otherwise prove relevant. Of course, back up your facts with references from your research.

Recommended Action

Within this section of the feasibility study, you’re ready to make your pitch for, or against, a technology to solve the problem. You should present a general overview of how the technology works, how it will be implemented, and what types of resources are required to make it work in your environment. You can also make a recommendation to investigate other options or newer technologies at this time—just be certain to explain why.

The solution and actions you recommend must be in alignment with the project purpose. A recommended action must address and satisfactorily answer the purpose of the project. Consider the reason why the project may be initiated, including

•   To solve an existing problem

•   To increase productivity

•   To become more efficient

•   To reduce costs

•   To increase revenue

•   To become more competitive in the marketplace

Now that you know the different parts of the plan, take a look at the executive summary of a sample feasibility study in the sidebar, “Executive Summary for Murray Enterprises.” This company is moving to a new facility and will need to create a new network.

Creating the Business Case

Another document the project manager may be required to create is the business case. Sometimes the business case is done in tandem with the feasibility study, and sometimes it’s a stand-alone document. Either way, its purpose is the same: to help the organization determine whether it can justify the cost of the project in proportion to the return on investment. The business case links the value of the project’s solution to the organization.

You’ll need to do some research and analysis based on the business objectives and goals. Considering what the goals of the project are and the proposed solution to reach those goals, the project manager can predict the costs of the project, the duration until a break-even point is reached, and the anticipated ROI. It’s not uncommon to include information on cash flow, related opportunities, and life cycle costing for the solution. Life cycle costing describes the cost to maintain the solution; usually management wants to know the maintenance costs for the solution for each year the solution is to be used.

The business case documents the quantitative value of the solution and the ROI, but it can also include an analysis of the qualitative values: morale, comfort level, and appreciation. In Chapter 1, I introduced the concept of the business case and its components. Now let’s dig in a little deeper and explore four must-have elements you’ll need for your business case.

Benefits of the Solution  This section is the primary purpose of the business case. It defines the quantified benefits of the solution, justifies the costs, and defines the ROI for the project. The benefits of the solution can also include qualitative benefits, but there needs to be some evidence that the qualitative benefits will actually come into existence for the project. The solution benefits should be analyzed through SWOT analysis, a technique to determine a component’s strengths, weaknesses, opportunities, and threats.

Cost of the Solution  The business case should estimate the total costs of the solution. Cost estimates in the business case include the anticipated costs of the development of the solution, the life cycle cost of the solution, and the total cost of ownership once the solution is implemented. If you’ll be outsourcing the solution to a vendor, you’ll need to assess potential vendors and their abilities and potentially request and review proposals. You might also need to define the opportunity cost of the solution should your organization implement one solution over another viable opportunity. Opportunity cost is the total amount of the opportunity that could not be implemented because this solution is selected instead.

Risk Assessment  The business case should include an initial risk assessment that defines the obvious risks in the project, the anticipated impacts and probabilities of the risks, and the risks of not doing the project. In IT project management, this initial risk assessment primarily focuses on the inherent technical risks such as downtime; data loss; delay in project deliverables; and risks specific to hardware, software, networking, or software development. It’s not practical to include a full review and assessment of all project risks at this point of the project development. Once the project is green-lighted, risk identification and assessment happen at a much deeper level.

Results Measurement  Everyone wants a good project, but what’s good to the project customer may not be the same definition of good to the project manager. Metrics and key performance indicators (KPIs), such as cost, schedule, quality, and scope, need to be defined so that project requirements and goals can be established and agreed upon. When subjective terms are tied to the project requirements, too much is left to interpretation. Key performance indicators establish the project components that will be measured to determine the success of the solution.

Writing the Project Scope Statement

Now it’s time to create one of the most important documents in your planning process: the project scope statement. This document defines all of the deliverables the project will create, the boundaries of the project, and the work that the project team will need to complete in order to create the project deliverables. This document is based on the project requirements, the feasibility study, the business goals and objectives, and the business case document. Note that project scope statements are used in predictive projects but not in agile projects.

The project scope statement usually passes through rounds of research and refinements before the project manager, the project sponsor, and the key project stakeholder(s) approve it. You might know this progression of scope refinement as progressive elaboration, which means that you start with a broad definition and then elaborate on the specifics of the deliverables through a series of refinements.

The project scope is a primary input to the remainder of the project planning and serves as a reference for all future project decisions. The project scope defines what’s in the scope—but it also defines what’s out of scope. For example, your project scope statement focuses on creating the new software, but the project won’t include deploying it to the 10,000 users in your organization. Project boundaries are important to define so that stakeholders don’t make false assumptions about what’s in or out of the project scope.

One of the primary jobs of the project scope is to define how the project will be measured for its performance. You’ll use KPIs to gauge how well the project is meeting the objectives of the scope; these indicators are usually linked to milestones at the end of project phases, schedule, cost, quality, and other objectives that you, management, or other stakeholders define. You’ll use KPIs to determine what’s important to the project stakeholders and to link project performance to satisfying those objectives by completing the project scope.

The project scope, in a predictive project, should be protected from change. Once the research, requirements gathering, and scope definition have been completed, the project scope statement should be averse to changes. Changes are allowed in a project, but all proposed changes should flow through a change control system so that they’re documented, reviewed, and then (perhaps) approved for the project scope. Approved changes cause the project scope statement to be updated. (I’ll talk more about change control for the entire project in Chapter 10.)

Your project scope statement will likely go through revisions on its way to final approval. It’s important to involve the project stakeholders in the scope creation and to seek their approval of the project scope statement. This is part of scope validation—confirmation that what you’ve written in the project scope statement is what the project stakeholders expect from the project. Scope validation is needed to ensure that what’s in the project scope statement satisfied the original business need of the stakeholders. Scope validation is also the customer acceptance of the scope once you’ve completed the project work.

The project scope statement has six components, as described next.

Product Scope Description  The product scope is a description of the features and functions the customer will receive as a result of your project team completing the project. The product scope is the thing the project will be creating. For example, if a customer wants you to create a new piece of software, they’ll describe the product scope, how it will be used, the functional components of the software, and the tangible components of the solution.

Product Acceptance Criteria  The project scope defines either directly or by reference the technical requirements, expected deliverables, and/or the detailed design documents that constitute the product deliverables. The product acceptance criteria clearly define what the project must create in order for the project to be accepted by the customer and for the project to be considered completed. This portion of the project scope is important, as vague requirements and product acceptance criteria allow the project duration to linger. You and the project customers must be in agreement at the start of the project as to what constitutes the acceptance and closure of the project.

Project Deliverables  The project will create deliverables that the customer will accept in the form of the completed product scope. The project may also create or purchase other deliverables such as tools, templates, reports, plans, and other ancillary deliverables that the organization will retain as a benefit for completing the project work. The project deliverables that the organization retains become part of organizational process assets so that other project teams can benefit from these deliverables in their relevant projects.

Project Exclusions  The project scope statement must define the boundaries of the project to communicate what will not be included in the project deliverables. It’s important to define what’s excluded so that there’s no confusion when the project manager wants to close the project and the project customers are expecting more deliverables.

Exclusions are items that are explicitly not in the project scope. You don’t want the project customer to believe they are getting something that’s not in the project scope. For example, your project may create the new software, but your project will not distribute the software as part of the project scope. Exclusions communicate exactly what’s not included in the project scope and help to remove any assumptions about what the customer will receive at the project closure and operational transfer.

Project Constraints  Constraints are things that limit the project manager’s options. Predetermined budgets, deadlines, resources, preferred vendors, and required technology are all examples of constraints. Project management always has three constraints: time/schedule, cost/budget, and scope. These are sometimes called the triple constraints of project management. The project manager should identify and document all the known constraints. These are also called The Iron Triangle of Project Management. Each side of the triangle represents one of these constraints and all three sides must remain of equal length to the other sides.

Project Assumptions  As part of planning, there may be assumptions that must be made in order to plan effectively and timely. Assumptions about hardware and software compatibility, resource availability, longevity of the solution, and a stakeholder commitment to the project are all common assumptions. This portion of the project scope should also include information on the impact of the project’s success should the assumptions prove to be false. All project assumptions should be evaluated later in planning to determine their risk for the project should the assumptions prove untrue.

Planning in Agile Projects

Agile projects use short bursts of planning and execution to move the project forward, but there is some upfront planning that takes place before or at the very launch of the project. The business case and feasibility can also be utilized in agile projects to help identify the business value and the features and functions of the product. Agile projects focus on creating business value and limiting the amount of time spent planning things that likely are going to change in the project. I’ll talk in more detail about agile projects coming up.

One of the most common approaches to agile project management is called scrum. Scrum comes from the rugby term where the team huddles around the ball to get things in play and get the game moving again. Figure 2-3 shows the typical flow of a scrum project. The following list describes the common meetings, called ceremonies, and documents, called artifacts, that you’ll see in a scrum project. These steps are repeated iteratively in this order throughout the project until the project is completed.

Figure 2-3  Scrum projects follow an iterative approach to project completion.

•   Product backlog prioritization  The product owner works with the customers, business analysts, executives, and other key stakeholders to gather, document, and prioritize all of the currently known project requirements. This prioritized list of project requirements is the product backlog. The product owner maintains the list, adds or removes features as needed, shifts the priority of requirements, and works with the development team to clarify any requirements, features, and functions.

•   Sprint planning meeting  At the launch of the sprint, the development team, the product owner, and the project manager (called the scrum master in scrum projects) plan how much work the team can do in the next iteration, called a sprint. Sprints are time-boxed sessions of work that last from two to four weeks. Starting at the top of the product backlog, the development team selects a chunk of work that they believe they can complete in the sprint. The team always pulls items from the top of the prioritized product backlog so that the items with the most business value are being created first. The team also determines who will do what work during the sprint planning ceremony.

•   Sprint backlog  The items that are selected from the product backlog to be completed in the current sprint are called the sprint backlog. From the sprint backlog, the tasks and responsibilities are determined. Now the team can get to work.

•   Daily scrum  Every workday, at the same time and place, the development team meets for a 15-minute ceremony called the daily scrum. Although other stakeholders, such as the product owner, may attend, only the development team members speak. It’s quick and the agenda asks the same three questions each day: What did you work on since we last met? What will you work on today? Are there any impediments that need to be resolved?

•   Sprint review  At the end of the sprint the development team demonstrates what it has completed during the sprint. The sprint review ceremony demonstrates results that are completely done (not nearly done) are demonstrated for the scrum master, the product owners, and the key stakeholders. This allows the stakeholders to see progress, get excited about the project deliverables, and offer feedback for any changes, approval, or clarifications.

•   Sprint retrospective  The sprint retrospective allows the team to discuss what did and did not work well in the past few weeks of the project. This is not a meeting to blame each other for faults but to discuss successes and failures and how to improve the project in the next sprint. Retrospectives are a kind of lessons learned meeting to immediately put the lessons learned into action during the next iteration of the project work.

These are the key steps of a scrum project, and they are repeated throughout the project until the project’s conclusion. This example examined scrum project management, but the other types of agile project management have very similar concepts that we’ll look at later in this book. For now, scrum is a good introduction to show the iterative planning that happens in all agile projects.

Establishing Project Priority

As a project manager, you’ll likely find yourself managing multiple projects. You may also find yourself going head-to-head with other departments implementing similar projects or, worse, conflicting projects. Given that every organization has different approaches to project management, your odds of success will increase if you know your organization’s approach.

Project priority may shift from quarter to quarter or year to year. Project portfolio management is a process an organization takes to pick and choose which projects are needed, are worthy, and should continue. Just as you might manage your financial portfolio, an organization has a responsibility to manage its portfolio of projects. The value of the project, the project sponsor, the current success rate of the project manager, and the purpose of a project are all factors an organization may use to determine which project takes the highest priority.

If your organization relies on a project management office (PMO), you may have some assistance in addressing project priority with senior management. Recall from Chapter 1 that the role of the PMO is twofold: it offers traditional project management services for an entire organization or portion of an organization, and it serves as a governing committee for all projects throughout an organization. If your organization were to participate in a PMO relationship, conflict resolution, budgeting, and the process of implementing projects and controlling projects would follow a system of checks and balances unique to your organization.

Your project sponsor should be as excited and motivated by the technology to be implemented as you are. The sponsor, hopefully, will be able to come to your defense, or more accurately, your project’s defense, should the need arise. This is one of the fundamental reasons why the right sponsor is needed for the project. A sponsor who lacks the authority, commitment, and ability to protect and promote the project does little to move the project forward.

The goal of a project sponsor is to increase profits or reduce costs through the implementation of the technical project. The project manager acts on behalf of the project sponsor. While ideally project sponsors serve as mentors and guides through the project phases, a sponsor in many organizations is little more than a figurehead, and the project manager has no one to shield the project. Hopefully that’s not the case in your organization.

Ideally, the project sponsor can help clear any roadblocks from the project’s progress. A roadblock is anything that is preventing the project from moving forward, and the project manager can’t resolve the issue alone. The project sponsor has the authority and power to clear the roadblocks and keep the project moving forward. It’s important that early in the project the project sponsor is introduced to the stakeholders and it’s communicated that the project manager is acting on behalf of the project sponsor.

One of your project management jobs is to relay updates from the project team to the project sponsor and from the project sponsor to the team, as defined in your communications management plan. A communications management plan defines all the required communications, scheduled meetings, and expected types of communications, depending on the project scenarios. I’ll talk more about creating this plan in Chapter 6, but for now, know that you’ll need the communications management plan to keep stakeholders informed. By keeping your sponsor informed of the project status, you personalize the project for him—as it should be. Figure 2-4 shows the path of communication among the project sponsor, project manager, and the project team.

Figure 2-4  The project manager directs the flow of communication between the team and the sponsor.

The project sponsor typically has delegated the management of the project to you. You delegate some, or all, of the tasks of the project research and implementation to the team members. Your job, like that of the project sponsor, is not to micromanage, but to organize and keep the team on track. As part of this delegation from the project sponsor to the project manager, and from the project manager to the project team, there needs to be a clear message that outlines the consequences of non-performance. Everyone needs to know the role they’re assigned, what it means to be successful in that role, and what will happen for non-performance. Performing in the project means hitting goals, completing assignments correctly, and participating in the project.

Depending on your role in an organization, the project may be assigned to you or created by you. Should the project be assigned to you to manage, the role of the project sponsor is like that of the parent in a parent-child relationship. This is to say, the project sponsor is the parent of the project, which is the child, and is deemed responsible to complete and manage the tasks required to finish the project.

If you’ve created the project, the role of the project sponsor is similar to that of the investor in an investor-entrepreneur relationship. You, of course, are the entrepreneur. You’ve done the research, presented the facts, and then sold the sponsor or the organization on the project idea. The project sponsor has invested their credibility in your plan.

Internal Competition

IT projects can grow quickly and spin out of control and size. Imagine you are doing an operating system upgrade for the client workstations. Your plan calls for using Transmission Control Protocol/Internet Protocol (TCP/IP) for all of the hosts. You have decided to use Dynamic Host Configuration Protocol (DHCP) to assign all of the IP addresses for all of the workstation operating systems. (Without dynamically assigned IP addresses, users won’t be able to access network resources.) Unbeknownst to you, another related team is working on segmenting the network and positioning switches and routers at key points.

Can you see the trouble brewing? If you’re not a network person, this scenario may look innocent enough; however, for either team to be successful, each team’s plans must take the other team’s plans into account! Figure 2-5 shows a map of the network. If the router and IP addressing information are not agreed upon between the two teams, the entire network can crumble.

Figure 2-5  Teams must work together for projects to succeed.

The routers and switches team must agree on the network addresses, IP addresses for gateways, types of broadcasts that are permitted to pass through the routers, and more. The client OS team has to agree on which ranges of IP addresses to use, the positions of the DHCP servers and DNS servers, and the assignment of any static addresses for printers and servers within each segment.

This scenario is an example of interproject dependencies. Your project needs coordination with the routers and switches team, and they’ll likely need information from you to cooperate. Interproject dependencies require communication, mutual respect for one another, and a spirit of working together. They can, however, cause problems such as scheduling issues, scope overlap concerns, and resource contention.

Resource contention happens when two projects need the same person or resource at the same time. This demand for a resource among projects creates an interproject resource contention that must be addressed as soon as the contention is discovered. Hopefully, the project managers can work together to resolve the issue with the needed resource, but in some instances, the contention has to be escalated to the project sponsors to help find a solution. This can often create frustration among those involved in the projects, as one project may have to wait before it can move forward with its execution.

Most organizations should have strategic tie-ins among departments, lines of communication between project managers, and ways to resolve differences and work together when conflicting projects arise. It is surprising, however, how many organizations do not.

At the basis of this problem are myriad issues that project managers find themselves dealing with: greed, personal achievement, personality conflicts, politics, and grudges. These are all issues that can take the focus off of the success of the project and can ultimately throw the project off track and even bring any progress to a halt. When these situations happen, and they will happen, a project manager can take a few steps to bring the project back in line:

1.   A meeting should take place with just the project managers from the conflicting projects. These individuals should outline their projects and discuss how both teams can work together and continue with their projects. The project managers should be diplomatic, willing to negotiate, and eager to find an agreeable solution.

2.   If the project managers cannot find a solution between them, the next step is to conduct a meeting with the project managers and the sponsors of the conflicting projects. The project sponsors should lead the discussions and help the project managers find an agreeable, win-win solution.

3.   If an agreeable solution can’t be found among the project sponsors and the project managers, then the discussion can continue to work its way up the organizational chart until a decision or agreement between parties has been made. Ultimately, the good of the organization should win based on the priority of the projects.

4.   The conflicting projects must be evaluated and weighed, with the goal being to determine which project will benefit the company the most. Once that has been determined, a solution must be created so the two projects can continue, one is dissolved, or one is put on hold. While that seems easy enough, it’s not uncommon for a lower-priority project to need to be completed so that a higher-priority project can continue.

This entire struggle would be unnecessary if departments would simply communicate with each other. This internal struggle tears down morale, wastes time and finances, and hurts the organization. IT project managers must learn to work together, to be reasonable, and to communicate.

Every entity that has multiple project managers should create a system to share information on projects. An intranet solution would be easy to implement and manage. As new projects are being researched, a quick look into existing projects on the organization’s intranet would allow teams to work together, accomplish more, and, again, be more productive. Far too often, unfortunately, projects are kept secret, fiefdoms are established, and domains are guarded among departments, managers, and lines of business.

Obtaining Budget Dollars

Research for any project must include information on the financial obligation required to implement the technology. Chapter 5 will focus on all aspects of budgets; this section introduces the financial planning stages of a project.

When you are considering implementing new technology, you must take a long, hard look at estimating the project expenses. Any organization can throw money at technology and hope for the best, though that free-for-all in IT is long gone for most organizations. Throwing money at a problem with little or no planning is as promising an investment as playing craps. The technology you recommend the organization to purchase needs to be the right power, the right size, and the right price.

In the technology world, it’s easy to fall in love with the latest application, multiprocessor server, or network operating system. But is the technology good for the organization? Ask yourself these questions when making decisions on technology:

•   How will this technology enable the organization to be more productive?

•   Will the technology promise an acceptable ROI?

•   How is the technology the right selection for the organization?

•   How soon will this technology need to be replaced?

•   What is the break-even point (also called the payback period) for this investment?

•   When does it become profitable?

If you cannot answer these questions fully and accurately when selecting new technology, then you have not completed your research.

Value vs. Investment

Value and investment, when purchasing anything, often are incorrectly seen as the same concept. Value is a perception. Investments are a reality.

Here’s a simple example: Imagine you are purchasing a bag of flour. The one-pound bag of flour is priced at $1.00. The three-pound bag of flour is priced at $1.92. Reason says that it’s better to spend 92 cents more for the three-pound bag of flour, because it lowers the price to 64 cents per pound. The problem is, unless you actually use more than one-and-a-half pounds of flour, the purchase isn’t a value, it’s a loss. Use a little more than a pound-and-a-half of flour and you’ve used approximately $1.00 of flour at a better price.

How does this relate to IT projects? When you are making your technology selections for your organization, it’s imperative that you know what technology will produce the desired results. The largest piece of technology is not always the best. Some consultants will advise you to buy the biggest chunk of technology you can afford, because it will be outdated in six months anyway. Wrong!

Always buy the right technology that will help your organization achieve the desired results of the project. And as for the consultants with the “spend big” mentality, question their credibility along with their advice. Take note that it’s not their budget, their career, or their project. It’s always wise to buy hardware and software that’s scalable, but you must research how much larger the demand for a given resource will be in an organization. And you need to consider whether the value gained for speed, bandwidth, or any other resource is worth the investment.

A contributing factor in all projects is the expected level of quality. Quality is the ability and the completeness of the project deliverables to meet the requirements the stakeholders have defined for your project. Technically, quality is a conformance to the project requirements and a fitness for use. Within the confines of quality, you’ll find grade. Grade is the ranking of service or materials. For example, you can purchase different grades of cables, monitors, computer equipment, and so on. You can also subscribe to different levels of software support: bronze, silver, and gold.

Within a project, you must evaluate the expected level of quality and then the correct grade of the materials and services needed to satisfy the requirements. Low quality is always a problem; low grade may not be. In addition, you must consider what happens if you overshoot the expected level of quality. While it’s better to err on the side of caution, it can also be wasteful to deliver a level of quality that far exceeds what the customer was expecting. Some unscrupulous project managers consume their entire project budget by adding features, further testing, and other deliverables that were not called for in the project scope. They’re trying to use all the monies in their budget by adding project extras—this is called gold plating, and it’s a waste.

I’m sure some project managers will want to argue this point. They’ll say that it’s unreasonable to surrender funds in the budget. Or that management will cut future project budgets based on the performance of the current project. Or they’ll look foolish with funds left over after they’ve committed the organization or customer to a set fee. This type of thinking is faulty for several reasons. First, the monies spent on gold plating extras is a defect in quality. Since quality is a conformance to requirements, anything that doesn’t conform exactly to requirements is poor quality. Second, the monies wasted on gold plating are funds that may be needed elsewhere in the organization. Finally, the time and monies spent to deliver the gold-plated extras may affect the customer’s ability to realize a faster return on investment, shorten the market window, or delay their usage of the project deliverables.

I do believe there’s nothing wrong with presenting value-added changes to the project customer when there are funds and time left in the project. Gold plating consists of changes that the project manager adds without the customer’s approval, simply to eat up the project budget, not to improve the project value.

Another budgeting concern you must consider during the research phase of your project is time—one of the largest and often overlooked expenses of project management. For example, if you have five members on your team and a project that will take three months to implement the technology, that’s 15 months of combined labor time. If you want to see it on a more common, accessible scale, just look around the room during the next meeting that’s a waste of everyone’s time. Take a two-hour meeting with ten people, and there goes 20 hours of the cost of labor down the drain. Figure 2-6 shows how an increase in time must be tempered by specific goals and a deadline; otherwise, costs run awry.

Figure 2-6  More time equals more expense.

So? If the project team is on the project full time, that’s 15 months of time away from regular duties, 15 months of salary, and 15 months of time that can never be recovered. When implementing the technology, consider the time commitment required from each team member and yourself. While not all organizations assign team members to a project on a full-time basis, you still must account for the sum of the project team’s time and its value to the project.

Should you decide to implement the plan through a third party, such as a value-added reseller (VAR) or the original vendor of the product, consider their costs combined with the time they’ll need to complete the job. There are usually three different ways VARs will bill for technology implementations, and all can be costly if you don’t stipulate all of the conditions:

•   Time and materials  Most technology integrators like to bill time and materials because there may be some additional problem discovered in the midst of the project that can result in the vendor working extra hours toward a solution. The trouble with time and materials billing is that some deceptive vendors take advantage of the situation and stretch the hours to increase the invoice. If you choose this billing method, you’ll want a not-to-exceed (NTE) clause in your contract. You will also spend more time managing the contract to ensure you are getting the appropriate value for the time you are paying for.

•   Fixed-fee contracts  Some vendors know exactly what it will take to complete their technology installation and will offer a set fee. The trouble with set fees is that your organization may feel cheated when the installation takes very little time and is completed long before you thought it would be. Understand that most installers probably have developed a script or routine that automates much of the installation process. They can do the job in less time and with less frustration than you could on your own. Fixed fees are generally a low-risk solution for the buyer, as any cost overruns go back to the vendor.

•   Cost-plus contracts  A cost-plus contract represents a set fee for the procured work plus a fee for the work. For example, a vendor may charge $7,500 for a new server, rack, and cabling plus the cost of any materials used during the installation. Some unscrupulous vendors try to use a cost plus a percentage of costs contract where they expect you to pay for the cost of the materials plus 10 percent (or more!) for the materials. Cost-plus contracts are the pits for most buyers, as the vendor can drive the price up by actually wasting materials. There are some cost-plus contracts that include incentives and penalties if the vendor finishes early or late—though you can add these terms to a fixed-fee contract if you want.

With any contract method, consider the vendors’ costs and calculate the ROI. Finally, make the companies completing the implementation guarantee their work in the contract you negotiate. Again, some vendors will want you to entertain a cost-plus-fee contract. These contracts demand a cost for the project materials, labor, or other elements of their implementation plus a fee for the project to be completed. The fee portion of the contract is usually fixed, while the materials and labor can fluctuate—giving the vendor an opportunity to drive the costs up and leaving you with more risk. As a general rule, you want to avoid cost-plus contracts. I’ll talk more about procurements and contracting in Chapter 6.

Creating an Approach

When you begin to do your planning, you need a plan of attack. How much time will you commit to this phase of the project? What, or who, will be your resources? What is the goal of the research? Who else will be assisting you? These are all questions you should answer as your research begins.

The size of the project can help you determine how much time you’ll need for planning. Of course, not all planning happens in one big chunk. You’ll have some up-front planning, and you’ll revisit the planning process throughout the project. For example, if your project team is creating an application, you’ll meet with the stakeholders to determine their needs, create an approach to developing the application, and so on. As it moves into execution, your team may need additional planning time to solve problems within the development.

Here’s a basic guide to determine how much planning time you can expect for the type of projects you’ll manage:

It’s easy to get bogged down in planning and hop from resource to resource rather than focus on a specific objective. While quality research takes time, an organized approach will allow you to find the information you’re seeking in less time.

Create a Milestone List

One of the primary goals of planning is to determine how the project will be completed, what resources will be required, and what tasks will be involved in the project. Part of planning any project is to create a task list, which simply comprises the major steps required from the project’s origin to its conclusion. You create a task list after the technology has been selected and before you create the implementation plan. Some projects use a task board that shows each task, who is responsible for completing the task, and the progression the task is making through the project.

There are multiple approaches to creating a task list, but some things must be accomplished before the task list can be created. In Chapter 4, we’ll focus on creating the work breakdown structure (WBS), a cornerstone of project management. The WBS is a deliverables-oriented collection of the project. The WBS provides a true reflection of all the deliverables the project will create, and using this, you can create an accurate and complete task list. In this early phase of your project, you’ll likely need a task list to ascertain how long the project may take, what types of resources are needed, and even how much the project will cost. One of the best and most direct approaches is a simple outline of what needs to be accomplished and in what order. For example, if you were creating a task list for the installation of new software on every workstation, your task list might look like this:

1.   Test the software in our lab.

A.   Test with current laptop hardware.

B.   Test with Microsoft Office.

C.   Test with Windows operating systems.

D.   Test hardware with printers, scanners, and digital cameras.

2.   Resolve and document any bugs or glitches from the testing phase.

3.   Create installation methods for each OS.

A.   System policies

B.   Image deployment options

C.   SMS server packages and database of hardware and software

4.   Test rollout methods and document.

5.   Roll out to pilot group of users.

6.   Begin offering training of software and hardware to population.

A.   Instructor-led training

B.   Web-based training

C.   Documentation for users

7.   Finalize rollout plans and documentation.

A.   Roll out software to users as they complete training class.

B.   Work with help desk to answer support calls.

While the list is simple and direct, it allows the technical project to begin to take shape. It also allows the project manager to determine the type of talent, number of team members, and time commitment involved with the project.

The outline approach, as just demonstrated, is not always the best method, however. Some of the tasks in the preceding scenario can be completed simultaneously rather than sequentially. In these instances, a visual decomposition can really be beneficial. Using the same scenario, Figure 2-7 shows how the project would look in an organizational chart using parent-child relationships.

Figure 2-7  Charts can help you visualize the work to complete in a project.

Another approach is to use a software program such as Microsoft Project. Project enables you to enter tasks and then edit them in more detail as the project develops, as shown in Figure 2-8. If you are using Microsoft Project or other project management software, you may want to consider starting your entire project planning stages with the software. Certainly, there is nothing wrong with creating an outline or flowchart and then transferring it into your project management software. Be cautious, however; a project management information system is a tool to help manage the project, not a guaranteed solution for project success.

Figure 2-8  Microsoft Project is an excellent project management tool.

Of course, planning starts very broad. You may have to do some initial planning and present your results to management so that they may determine if the project should be chartered. Once the project has a charter, you’ll revisit planning to map out the milestones to complete the project. With the milestones in sight and with your WBS, you’ll determine the activities required to get from milestone to milestone. Planning is iterative. You’ll be visiting the planning processes throughout your project.

Agile projects use a product roadmap to show when releases from the agile project will be available. The roadmap shows milestones that identify the creation of key features. For example, a milestone in a software project might be to do a release when it completes three of four key features of the software. These features may take three to six increments to reach, which would mean a release would happen every 12 to 24 weeks depending on the software being created, the business cycles in the organization, and the desire from the customer to have the releases. The product owner is responsible for creating the product roadmap.

Manage the Planning

If you are completing the majority of the planning phase with your project team, pay close attention to the amount of time the team invests. Quality research doesn’t come easily and takes a commitment of resource labor to produce quality results. However, too much time invested in research can lead to muddied results, meandering from topic to topic, and project burnout. It is always in your best interest to set a specific goal and deadline for the initial research.

To set a research goal, create a list of questions that you’ll need answered to manage your research time. In the online resources that accompany this book, you’ll find a document called Research Objectives. (If you need assistance accessing this file, refer to Appendix C.) While this worksheet is simple and direct, it can keep you focused on resolving fundamental issues and then branching into more detailed objectives.

If you are fortunate enough to have multiple people helping you research the project, don’t be tempted to micromanage. Assign research topics to the team members, give them objectives that their research should produce, and then give them a deadline. There is no need to watch someone research. Let your team complete their assignments, and wait for the results.

Once your team members have completed the research, create a way for the information to be compiled quickly and easily so that it can be assessed and then you and the key project stakeholder can decide on what should happen in the project. If you have the resources, and depending on the project research, conduct a meeting and have the team members report their findings to the key project stakeholders. Face-to-face meetings are more productive than a report or an e-mail.

As the findings are being shared, have someone collect the notes and record any dialogue, controversy, or other information from the meeting. After the meeting, organize the collected data and disperse it to the team members. From the discussion on the collected research, the compiled report, and your own intuition, you should be ready to make an intelligent decision on how the project should move forward.

Contingency Plans

Every project needs at least one contingency plan. You may call these fallback plans, rollback plans, worst-case-scenario plans, or disaster-recovery plans. A contingency plan is a predetermined decision that will be enacted should the project go awry. If you ignore the creation of a contingency plan, you are tempting fate. A project that runs askew without a contingency plan will force your project to be late and most likely over budget.

Depending on the size of your project and its impact on your organization, your contingency plan may include a business continuity response. While business continuity usually addresses disasters and how the business can quickly react and continue to serve its clients, a large project failure can have an immense impact on an organization as well. You, management, and key stakeholders should examine the risk of failure and how it may affect the organization’s continuity. This would include worst-case scenarios, disaster recovery, and any warning signs that the event is likely to occur.

As you complete the research and as the foundation for your project develops, think about how you would react if any phase of the project were to falter. As most IT projects will certainly have multiple steps to completion, there are plenty of opportunities for things to go wrong. And they will. Figure 2-9 shows how contingency plans are used and built into a successful project.

Figure 2-9  Contingency plans are “in case of emergency” decisions.

As part of the project planning process, record reported troubles, document any conflicts with other technology, and bookmark any articles or Internet sites that offer warnings on the technology you’re implementing. By researching the negative possibilities of your technology, it can keep your love of the implementation from overriding reason and heighten your awareness that any technology can have flaws.

Use if-then statements such as the following to compose most contingency plans: “If the software conflicts with our video driver, then we’ll write a driver that allows it to work.” While this seems simple, a series of if-then statements can allow you to create a quick and concise contingency plan.

One of the primary reasons for creating contingency plans during the research phase of the project is in preparation of the next phase: dealing with management. Management loves to play devil’s advocate. Some will swear they are the devil, but they aren’t—usually.

By having a documented, logical contingency plan for each facet of your project, you are working with management prior to the face-to-face meeting with them. This will build trust, confidence, and support of your project even before they say, “Make it happen.”

Introducing Agile Methodologies

As I discussed in Chapter 1, traditional project management uses a predictive approach. Predictive project management is when you plan the entire project up-front. All of the requirements of the project are known, documented, and agreed upon. Lots of time is spent in planning at the beginning of the project, and additional planning time is sprinkled throughout the project life cycle. Predictive project management is also very averse to change requests. Changes are often frowned upon in predictive project management because changes can cause lots of effects in a predictive project.

Agile methodologies, however, use an iterative approach to planning and doing a project. You’ll most likely find agile methodologies being implemented in software development. While there are many different types of “agile” methodologies to choose from, they all have some common characteristics—chief among these characteristics is that change is expected and welcome in an agile project.

The whole concept of agile projects stems from the “Manifesto for Agile Software Development,” commonly called the “Agile Manifesto.” This document was created in 2001 by 17 software developers. The developers were looking for a better approach to managing software development projects, because so much is unknown at the launch of a software development project when compared to a predictive project. It’s also important to note that agile projects are also known as knowledge work projects—it’s more brain than brawn power in the execution and creation of the project’s scope.

The Agile Manifesto centers on four key values:

•   Individuals and interactions over processes and tools

•   Working software over comprehensive documentation

•   Customer collaboration over contract negotiation

•   Responding to change over following a plan

While the items on the right side of “over” in these statements are important in software development and knowledge work projects, the items on the left side of “over” are more valuable in an agile approach.

Introducing Scrum Agile Project Management

Scrum is widely accepted as the most common type of agile project management. Scrum has predetermined segments of iterations within the project. These iterations allow for planning, executing, team review, and a type of scope verification throughout the project. While there are lots of nuances of scrum (well beyond the scope of this book), there are five ceremonies within scrum that warrant identification. A ceremony within scrum comprises key activities with the project manager (called the scrum master), the development team, and the product owner. Let’s take a quick review of these ceremonies now.

Sprint Planning

This first ceremony is based on a prioritized list of features and stories, called the product backlog, that need to be created in the project. The product owner, usually a representative of the project customers or end users, prioritizes these features and presents the items during the sprint planning session.

Sprint Iteration

The sprint iteration, usually just called a sprint, takes two to four weeks, while the development team creates the items selected from the product backlog. The selection of items from the product backlog is called the sprint backlog—it’s the list of things the team has promised to complete in the current sprint for the customer.

Daily Scrum

The daily scrum is a daily meeting with the scrum master and the team. This is a 15-minute time-boxed meeting.

Sprint Review

Sometimes called the iteration review, this ceremony brings together the scrum master, the team, the product owner, and any relevant stakeholders, such as the project customer, to review what the team has, or has not, accomplished in the sprint.

Retrospective

This final ceremony is an opportunity for the team to discuss how the project is going. The team discusses any issues experienced in the past iteration, discusses what is working, and makes recommendations for team improvement and performance improvement in the next iteration of the project.

Reviewing Agile Management Principles

Agile aims to be flexible in its project management approach. Lots of formal overhead, forms, and documentation don’t fit well within an agile environment. The overhead of traditional project management is something that project managers moving into a scrum environment often struggle with. The concept of project management in an agile approach isn’t the predictive and directive approach many project managers are used to. Agile embraces the concept of servant leadership for the project manager. Servant leadership is based on four principles for agile projects:

•   Shield the team. Servant leaders shield the team members from distractions that take their focus away from the requirements of the current iteration. To keep stakeholders at bay, hold minimal meetings and communicate on behalf of the team.

•   Remove impediments. One of the topics from the daily standup meeting is to define what impediments are in the way of the project team’s progress. The servant leader takes action to remove these impediments to keep the team working on the requirements of the current iteration.

•   Keep the team vision. The vision of the project is communicated again and again by the servant leader to keep the team and stakeholders focused on the big picture of the project. The vision is a clear description of what “done” means for the project.

•   Carry food and water. Okay, you’re not really carrying food and water, but this servant leader characteristic means that you’re providing the things the team needs to do the work. This can be access to resources, technical needs, and support from key stakeholders.

Another aspect of agile that is important is to keep things visual. A visual approach to project status and what’s in the work queue are vital to success in an agile project. These visual items are sometimes called information radiators.

There are three visual items you should be familiar with when it comes to agile project management: burnup and burndown charts, dashboards, and Kanban boards.

Using a Burnup and/or Burndown Chart

Burnup and burndown charts are used in agile project management to show how many tasks have been completed by the project team during the current iteration. A burndown chart starts with the number of tasks assigned and “burns down” as tasks are completed in the project iteration. The goal of a burndown chart is to show the diminishing number of tasks still to do in the iteration. A burnup chart is similar but shows the accumulation of tasks completed in the iteration and “burns up” toward the goal or tasks to complete in an iteration. Figure 2-10 shows a burndown chart created in Microsoft Project.

Figure 2-10  Burndown charts show the remaining work items for the project or for the current iteration.

Creating a Dashboard

Dashboards have become popular for project management over the past several years. A dashboard is like a quick report of all the important topics for a project. The dashboard organizes the information so anyone can quickly see the topics. Typical items in the dashboard can be activities in the queue, items in testing, items in the sprint backlog, number of defects found, and items currently being worked on.

Kanban Boards

Kanban boards are sign boards that visualize the flow of activities in a project. The development team writes features or tasks on sticky notes and then moves them across the board’s categories as needed. For example, a task will start in the backlog, move into analysis, then development, on to testing, and finally move into the completed category on the sign board. It’s like a to-do list of activities, but it shows what’s in motion, what’s done, and what’s waiting to start. The category of “development” is called work-in-progress (WIP) in agile projects.

CompTIA Project+ Exam Highlight: Planning Processes

This chapter doesn’t actually map to any one chunky CompTIA Project+ exam objective—don’t let that bother you one bit. You’ll need all of the information in this chapter in your day-to-day world as an IT project manager, and it’s the foundation for creating the project plans—something that’s a big part of your CompTIA Project+ exam. You will need to be familiar with the terminology and concepts in this chapter to plan your projects successfully, which is something you can expect questions on during your CompTIA Project+ exam.

1.2 Compare and contrast Agile vs. Waterfall concepts  Agile project management is a way to describe the iterative approach to managing a project; it’s most often found in software development. Agile is based on the “Agile Manifesto,” a document that defines the principles of agile, self-led teams; collaboration with project customers; and expectations for change in the project. While scrum is the most common flavor of Agile, Lean, XP, and Crystal are other agile methodologies that have a common iterative and change-is-expected attitude.

The scrum approach to agile project management is based on a product backlog of features and items to be created by the team. The product owner, a role in the scrum methodology, works with the customers and the project team to prioritize the backlogged items. The team selects the top items from the backlog and enters a sprint to create the items. The team may have a sprint backlog, which are items the team must create in the current iteration.

Waterfall projects, also called predictive projects, predict each phase of the project and the work that will happen within each phase. It’s called “waterfall” because the project progression flows down through the identified phases of the work like a waterfall. These project types are plan-driven and are averse to change. Predictive projects like to predict everything that should happen in the project management plan.

2.1 Explain the value of artifacts in the discovery/concept preparation phase for a project  Projects are launched to achieve business value. Business value describes why the project is important to the organization: it increases revenue or reduces costs. Business value is usually expressed in a business case. Recall that the business case examines the financial effect of the project, return on investment, the current and future state of the organization, and other financial considerations.

Project managers may not be the individual who do the research and write the business case. A business analyst may write the business case and gather requirements for the project before the project manager gets involved. It’s not unusual for a project manager to receive the fully developed business case at the launch of the project and to work with the business analyst to refine the requirements or clarify the goals and expectations of the project.

2.3 Given a scenario, perform activities during the project planning phase  Planning is important in both predictive and agile projects. While predictive projects plan in depth at the beginning of the project, agile projects plan iteratively as each iteration of the project begins. Planning in predictive projects is about predicting exactly what should happen. Planning in agile projects is more about the intent of the team and is always barely sufficient. For the CompTIA Project+ exam you’ll need to be familiar with planning activities in both predictive and agile projects.

When it comes to planning, you’ll often need to first consider the project constraints. Project constraints are things that limit your options. Common constraints are also usually tied to the key performance indicators: time, cost, and scope. Constraints can also include resources, quality requirements, and even the environment you’re working in. Constraints create a boundary for the project and often can create problems for the project manager and the project team to work through.

The three big constraints of time, cost, and scope are often called the Iron Triangle of Project Management and the triple constraints of project management. The concept of the “iron triangle” states that time, cost, and scope must balance one another in the project. You cannot have a tremendously large project scope and not have enough time or monies to create the scope. All three sides of the iron triangle must be in balance.

The other common constraints, such as quality and environment, are often set upon the project as part of the project requirements and may be seen as part of the project scope. The project scope defines everything that is included in the project and exclusions that are not included in the project. The scope in an agile project is represented by the product backlog. Items in the backlog can change throughout the project, in which case the product owner will reprioritize the product backlog so the most important items are always at the top of the product backlog list.

3.3 Given a scenario, analyze quality and performance charts to inform project decisions  Agile projects utilize burnup and burndown charts to show project progress and performance. A burndown chart shows the consistent decline in the number of features left to create in the project against the number of iterations the project has completed. A burnup chart is a similar concept but shows the accumulation of features actually created in the project. Burnup and burndown charts are used primarily in agile projects, but you can also use them in a predictive project to show the consumption of the project budget and how much money is left in the project budget.

4.4 Summarize basic IT concepts relevant to IT project management  IT project managers need to have relevant knowledge about the technology they are managing. Many IT project managers drift away from the technical side of the house as they get bogged down with managing the project rather than immersing themselves in the technology—and that’s not necessarily a bad thing. However, it’s important to maintain relevant knowledge, to continue to learn about the technology the project affects, and how the project solution may disrupt or affect other technical solutions and lines of business within the organization.

The project scope statement should address the computing services, architecture, networking, data, and software components of the technical project. You’ll also need to identify and document how the project may affect any cloud services and software used by the organization. You’ll need to see the big picture of the solution and work with stakeholders to fully understand the solution from their perspective to ensure that your project doesn’t interrupt critical work or financial systems.

Chapter Review

Every project has constraints. Before you can begin to implement a project, assess budget dollars, or define a project goal, you must know the boundaries of the project. A project manager must know the business value the project aims to create. Based on the business value, the project manager and team can collaborate and plan. The initial goal of project planning is to answer questions in regard to the project scope. Planning allows decisions to be made, teams to be assembled, and the wheels of productivity to begin to turn. The constraints of the project are identified, documented, addressed, and managed throughout the project.

Create and evaluate a feasibility study to determine the project goal, the validity of the project, and the desired results of the project. Work together with your team to research, report, and develop the study. The feasibility study allows all parties to evaluate the project, its results, and its estimated ROI.

Establishing project priority, through researching the project, enables teams to work together for the good of the company. As conflicts, politics, and personal achievement arise, a set path of conflict resolution needs to be established between project managers, project sponsors, and upper management. The project sponsor should always win by putting the good of the organization ahead of the desire of others. In a perfect world, departments, management, and teams share information, work together, and strive to dovetail projects to create a powerful organization. It is achievable but not always probable.

Financial obligations to a project should be considered during the planning phase. A successful project manager evaluates the cost of the technology and the ROI. As a project manager, you must know the difference between value and investment and determine which technology will be the best investment. For each major phase of a project, you should create a contingency plan. A contingency plan enables you to make predetermined decisions in the event of project phases gone awry. A contingency plan also enables a project team to work with management, allows for different variables to a project, and adds a touch of realism to an expected flawless execution. As Henry Ford said, “Before everything else, getting ready is the secret of success.”

In this chapter, we also discussed the popular project management approach that is largely used in software development projects: agile project management. Agile projects use time-boxed phases throughout the project to move the project work forward toward completion. Unlike predictive projects, agile projects expect and welcome change. The project manager and the development team work with the product owner to prioritize the product backlog, queue work for each iteration, present the completed work in a sprint review, and, before starting the next iteration of ceremonies, pause for a sprint retrospective to discuss the project.

Exercises

These exercises allow you to apply the knowledge you have learned in this chapter and are followed by possible solutions.

Exercise Solutions

The following offer possible solutions for the chapter exercises.

Questions

1.   You are an IT project manager for the UYQ Organization and are working on a new project to create new software for manufacturers. You are just starting to work on the intent of the project, the high-level goals, and the opportunity for the organization to formulate a document that links the project objectives to the business needs. What type of document are you creating?

A.   The project scope statement

B.   The concept definition statement

C.   The key performance indicators

D.   The project charter

2.   Jane is the project manager for her organization. She is preparing the business case and identifying the business goals and objectives for an identified problem that a project may solve. Jane is comparing two different applications for performance, cost, scalability, and the expected time for the end users to learn the software applications. What tool is Jane using as part of her creation and documentation of the business goals and project objectives?

A.   Benchmarking

B.   Brainstorming

C.   Business rules analysis

D.   Functional decomposition

3.   What research technique breaks down large problems into smaller, manageable components?

A.   Root cause analysis

B.   Functional decomposition

C.   Focus groups

D.   Brainstorming

4.   Mark is the project manager of the BGH Project. This project doesn’t have much time for planning, as the project customer is urgent for a solution to be implemented. Mark has a limited amount of time to complete the research for the solution. When time is of the essence, what can a project manager do to increase research productivity?

A.   Delegate the research topics among team members.

B.   Use only one or two research outlets.

C.   Limit the time spent doing the research.

D.   Hire a vendor to do the implementation.

5.   Gary is the business analyst for his organization, and he’s created a proposed solution for the company to implement. Management has asked you to create a feasibility study based on Gary’s findings. What is a feasibility study?

A.   A plan for researching the project

B.   A plan based on the project research

C.   A plan that recommends the proposed technology

D.   A plan that does not recommend the proposed technology

6.   Of the following, which topic is not usually included in a feasibility study?

A.   Executive summary

B.   Market research

C.   Defined business problem

D.   Assumptions used in the study

7.   You are the project manager for the JHW Organization. Management has come to you with a proposed solution to standardize all workstations and laptops in your organization. They would like you first to complete a feasibility study for the solution with a focus on the total cost of the project implementation. You agree but insist that you should also address the users of the project who will be affected by the change the project will create. Why must a project manager address the users impacted by the technology in a feasibility study?

A.   To determine their willingness to use the product

B.   To determine how many users will use the product

C.   To determine the downtime caused by the product

D.   To determine the validity of changing or adding technology

8.   Why should a project manager demonstrate return on investment (ROI) in the financial obligation portion of a feasibility study?

A.   They should not; it will be determined by the project sponsor.

B.   They should include ROI to demonstrate the validity of the project.

C.   They should include ROI to demonstrate the initial cash outlay for the technology.

D.   They should include ROI to make certain his project is approved.

9.   You are the IT project manager for your organization. Several projects being initiated in your organization have large financial requirements, entail extensive usage of human resources, and require access to network facilities. You suggest that project priority be established. What is project priority?

A.   It is the ability of a project manager to determine which project is the most valuable to an organization.

B.   It is the ability of a project sponsor to determine which projects should be implemented and which should be discarded.

C.   It is a process project managers and project sponsors must go through when conflicting projects arise within an organization.

D.   It is a process project sponsors use to determine which project is of greater importance when two projects conflict.

10.   A new project has been launched by Shelly Dere, the project sponsor. Shelly insists that the project manager have total autonomy over the project decisions, but Shelly will retain the control of the project budget. What is the goal of a project sponsor?

A.   To manage the project manager

B.   To delegate duties to the project manager

C.   To increase profits through the project led by the assigned project manager

D.   To increase productivity through technical implementations

11.   The “Agile Manifesto” values what more than processes and tools?

A.   Completed activities

B.   Customer collaboration

C.   Individuals and interactions

D.   Product backlog

12.   What is project portfolio management?

A.   It is the risk the project manager is taking when implementing a project.

B.   It is the pool of available project managers.

C.   It is the management and selection of which projects will be engaged, allowed to continue, or stopped based on conditions within the organization or project.

D.   It is the relationship between the project manager and a third party that will implement the proposed technology.

13.   Percy is the project manager of a large project that spans three countries. The project team is operating as a virtual team. There have recently been some arguments among the project team members over the technical implementation of the project. What causes internal conflicting IT projects?

A.   Lack of communication

B.   Lack of planning

C.   Technology that develops too quickly

D.   Conflicting technology

14.   Beth is an agile project manager and she wants to create a dashboard for her team. A dashboard can also be known as a what?

A.   Information radiator

B.   Kanban board

C.   Burnup chart

D.   Queue

15.   How long does a daily standup meeting last in an agile project?

A.   One day

B.   15 minutes

C.   As long as needed

D.   One hour

Answers

1.   B. You are creating the concept definition statement. This document defines the high-level goals and proposed solution for the project. It links the project objectives to the business needs.

2.   A. Jane is using the benchmarking approach to compare the costs and benefits of one solution to another.

3.   B. Functional decomposition breaks down a large problem into smaller, manageable components.

4.   A. Many hands lighten the load. Whenever possible, a project manager should delegate the planning among team members. The project manager rarely completes planning alone. It may be tempting to hire a vendor to complete the implementation of the project, but the focus of the question is on the research of the project.

5.   B. A feasibility study is a plan based on the project research. It contains a summary of the information you’ve discovered in an organized approach. It is a factual document that determines whether the project is feasible to complete.

6.   B. Market research is not included in a feasibility study. Feasibility studies include eight sections: executive summary, defined business problem or opportunity, purpose of the study, description of the options assessed, assumptions used, audience impacted, financial obligations, and recommended actions.

7.   C. A project manager must evaluate any downtime caused by the product implementation. Downtime for users, whether through a learning curve or lack of productivity, is an expense for the organization. Too high of a learning curve or long periods of inactivity due to lack of planning is unacceptable when there’s a primary concern about the initial cost of the technical project implementation.

8.   B. To implement the technology, an organization will have an initial cash outlay. The ROI will show how the technology can earn back the initial expense and more by increasing productivity. If the ROI is too little, the project may be scrapped.

9.   A. A project manager may have multiple projects to manage. Project priority is the ability to determine which project takes precedence, as it is most important to the success of an organization.

10.   C. The goal of a project sponsor is to increase profits through the proposed project. A project manager will carry out the implementation of the project. A project sponsor may manage a project manager, but it should not be the project sponsor’s goal to do so. It’s not unusual for the functional management to retain control over the project budget while allowing the IT project manager control over project decisions.

11.   C. The “Agile Manifesto” values individuals and interactions over processes and tools.

12.   C. Project portfolio management is a process that management uses to determine which projects should be engaged and which should not be. Project portfolio management is also used to determine if projects should be halted because of a shift in priorities, conditions within a project, or conditions within an organization.

13.   A. Lack of communication causes conflicting IT projects. When a project manager is managing a virtual team, as Percy is in this instance, it’s important to take extra steps to encourage communication among the project team members. If, within the organization, departments, teams, project managers, and project sponsors would effectively share plans, research, and needs, there would be fewer conflicts and more successful IT implementations.

14.   A. A dashboard can also be known as an information radiator. Information radiators are visual boards or postings of key project information, such as work-in-progress, testing status, defects, and more.

15.   B. Daily standup meetings should last 15 minutes. Standup meetings are short daily meetings to discuss what’s been accomplished, what’s in motion, and anything that may be preventing the project from moving forward.