You are a project manager and you want to earn the CompTIA Project+ certification. First, you can do this! Many others have done this and so can you. Second, you know that managing an IT project is different from managing any other type of project that you may have worked on in the past. In the world of information technology, we face attacks on all fronts: ever-changing business needs, hardware compatibility, software glitches, security holes, and network bandwidth, not to mention careers, attitudes, and office politics. To pass the CompTIA Project+ exam successfully, you can rely in part on your experience to answer many of the exam questions, but you’ll also need to know some facts, processes, and activities that a project manager should do in a formal project management approach, which are covered in this book.

IT projects are overwhelmingly the most common project type for most organizations. IT projects are also the most challenging and exciting place to be in a company. The IT projects that you manage will affect the entire organization, will have an impact on its success, and can boost your career, confidence, and life to the next level.

IT project management can be as exciting as a whitewater rafting excursion or as painful as a root canal; the decision is yours. What makes the difference between excitement and a sore jaw? Many things do: leadership, know-how, motivation, and, among other things, a clear vision of what each project will produce, what it will cost, and when it will end.

This first chapter will help you build a strong foundation for managing successful IT projects. Like anything else in the world, project management requires adequate planning, determination, and vision for success. Ready to start this journey? Let’s go!

Defining the Project Management Framework

A project management framework is a structure the project exists in. The project management framework is the skeleton of the project and how the project operates. It defines the approach and expectations for how the project will operate. While every organization can have different rules and standard operating procedures (SOPs) for how projects work in their environment, there are some generally accepted practices when it comes to project management. The CompTIA Project+ exam will test you on the common, widely accepted practices of IT project management, not the nuanced variations of project management.

Everyone talks about projects: data projects, hardware replacement projects, software development projects, and a host of other activities that have the project label smacked onto them. But are all these activities really projects? It’s important to define and understand clearly what a project is and is not.

Projects are temporary; they do not, thankfully, last forever. Another term, operations, describes the ongoing core business of an organization. Operations are the day-to-day tasks, business focus, and purpose of an organization; they’re what companies do. Projects are unique endeavors that don’t fit into the day-to-day model and activities of an organization. Projects are special undertakings that create unique products, services, and conditions.

A project, technically, is a temporary endeavor to create a unique product or service. A project is an undertaking outside of the normal operations of an entity. For example, you might roll out a new application, install new monitors, create a new portion of a website, or establish a new call center for application support. In some organizations, such as those composed of application developers or consultants, or IT integration companies, everything they do is a project, because they complete projects for other organizations. Consider a company that creates custom applications for other organizations. Its operation is an ongoing series of projects. The organization that completes the project work is the performing organization.

It’s not unusual in the IT world to encounter companies that perform projects for other organizations. Your company might even be one of those entities, or it might purchase goods and services from a company that completes projects for it. An organization whose main income is generated by completing projects for others might be referenced as a company that does management by projects. Even in these companies, however, a distinction still exists between operations and projects, although the distinction is becoming less clear in companies that are adopting the emerging trend of merging project teams with operations to avoid the risk of knowledge loss at project handover. This concept is incorporated into the product life cycle, which describes the creation, support, and eventual sunsetting of a product.

Exploring Project Characteristics

How do you know you’re managing a project rather than an operations task? Projects always have a foreseeable conclusion. Operations, on the other hand, have no end in sight and will continue to go on as long as the organization exists. So, the task of maintaining hardware or keeping software current is not a project—it’s an operational activity. Operational activities are ongoing and projects are not. Operational activities support the organization and should have management, a budget, and their own set of processes and controls that are totally different from those of a project.

In addition to projects being temporary, they are unique. Every project is different: different goals, different stakeholders, different risks, and so on. No two projects are exactly alike—just like snowflakes, thumbprints, and IP addresses. Although organizations may carry out similar projects, such as building houses or designing applications, each project will always be unique. Projects are not assembly lines; they are unique and special.

Projects are led by project managers (PMs), individuals who are responsible for the coordination of the project events, the orchestration of team members and activities, and the management of all facets of the project. All these facets, such as scope and costs, are integrated with one another. What the project manager does in one portion of the project has a direct effect on the other portions of the project. For example, if the project manager does a poor job in quality control, that will directly affect the risk management activities of the project. So the project manager is a coordinator not just of the people, but also of the processes that help achieve the results of the project.

Working with Project Management Entities

In many organizations, the project is a special activity in which people are assigned to the project and led by the project manager; when the project is done, the team disbands and everyone goes back to their day-to-day work. Nothing is wrong with that approach at all; in fact, that’s pretty common in many organizations. There are other ways to structure projects than the simple (and clean) stand-alone project approach, especially in larger organizations, where politics, goals, and outcomes can be complex. In these types of organizations, a project may not live in its own bubble, but may be part of a larger structure with its own rules and procedures that supersede and direct the project manager’s activities.

Identifying Programs and Projects

A program is the most common structure that projects live within. A program is a collection of related projects all working together toward a common goal. A program is led by a program manager, who orchestrates the activities of the projects, through the project managers, to achieve benefits that wouldn’t be realized if all the projects acted independently of one another. The perfect example of a program is the construction of a skyscraper. Think of all the different types of projects that could happen in the construction of a skyscraper: concrete, framing and metalworking, plumbing, electrical, glass windows, and the list could go on. Each one of these types of major components could easily be a project. The program manager coordinates the projects so that they work together efficiently to save time, costs, and frustration.

Programs almost always are a collection of related projects, but a program could have a subprogram. In Figure 1-1, you can see how a program could be structured with subprograms and projects. Each program is led by a program manager, and each project is led by a project manager. Each project manager would report to her respective program manager, and each subprogram manager would in turn report to the program manager of the entire program. Note that it’s possible to mix projects and subprograms within one program entity.

Figure 1-1  Programs are a collection of projects and subprograms working toward a common goal.

Reporting to a Project Management Office

A project management office (PMO) provides centralized management, support, and guidance for all projects within an organization. Rather than each department or line of business managing projects with its own approach and methodology, the PMO centralizes the project management approach for the organization. This ensures consistency of the practices, tools, reporting, and methodologies project managers use within the organization. It also helps to set expectations for stakeholders and provides consistency throughout all projects. The PMO can establish the formal project management framework for the organization that all project managers will be expected to perform within.

The PMO can also help the project managers within the organization better communicate with one another, share resources, provide training, and ensure that compliance is happening throughout the projects. Having a predetermined approach to project management that all project managers adhere to is ideal when many projects are in motion. The standardized approach helps everyone act the same way, provides consistency of practice, and ensures that the same processes, forms, software, tools, and techniques are being used throughout.

There are three types of PMOs:

•   Directive  The PMO directly manages the project for others. The PMO directs the entire project. You could say the directive PMO owns the project.

•   Controlling  The PMO controls the project through compliance with standards, a strict framework, methodologies, forms, templates, and the mechanics of project management.

•   Supportive  The PMO is more of a consultant to the project managers within the organization. The supportive PMO helps by providing templates, consultation, and lessons learned.

A PMO can be created for an entire organization, or, more likely, within each department or line of business. For example, the sales, marketing, IT, and human resources departments within the same company could each have a unique PMO that is implemented differently from the PMOs of other departments within the company.

Respecting the Organization Portfolio

A portfolio is a way to describe a company’s collection of investments. Just like you might have a stock portfolio or an investment portfolio, when it comes to projects and programs, an organization’s portfolio describes the collection of projects and programs it has invested in or will invest in. The items within the portfolio are seen as investments, so there’s a financial aspect to the cost of each investment, the expected return on investment (ROI), and a business case for why it has been selected. The reason why a project is launched is the business value of doing the project. Projects aim to increase revenue or reduce cost.

Items within the portfolio are usually just projects and programs. Each project or program is reviewed by a portfolio committee or steering committee. This is a group of executives that reviews each proposed investment and determines the priority of the project or program to happen, its ROI, the risk of the investment, and other factors. Throughout the year, this committee will meet and review the status of the projects and programs. In some instances, the committee may determine not to invest in a project or program for financial reasons, technological advances that cause items to be no longer needed, or changes in the marketplace. The review is an opportunity to see that the items are doing well, or if they are not performing well, there may be a discussion on cancelling the investment.

Working with Predictive Projects

A predictive project management approach means that you and your project team predict what should happen in the project. Predictive projects involve deep planning before the work begins, and the project manager and the project team know, or at least predict, what should happen in the project. Before you hop into the launch of a predictive project, it’s paramount that you understand the life cycle of project management.

Predictive projects move through a logical progression of activities to reach the project closing. You could examine a project in construction, health care, manufacturing, or technology, and you’d see the same set of project management processes that move the project forward. The framework that all projects share is called the project management life cycle—it’s universal to all predictive projects. The project management life cycle describes the evolution of project process groups that will move a project from initiation to closure. Figure 1-2 captures the project management life cycle and shows how projects use different process groups to move the project toward its closing.

Figure 1-2  The project management life cycle uses process groups to move the project forward.

You might hear the terms “project life cycle” and “project management life cycle” used interchangeably. Technically, however, these are not the same thing. The project management life cycle is universal to all predictive projects and consists of the five process groups: initiating, planning, executing, monitoring and controlling, and closing. A project life cycle describes the unique phases of a project that are specific to the discipline and nature of the project. For example, you would not have the same phases in a construction project that you’d experience in a software development project. The phases of the project compose the project’s life cycle, whereas all predictive projects use the project management life cycle that’s composed of the process groups.

Initiating the Project

Project initiation is the official launch of the project. Initiation is based on identified business needs that justify the expense, risk, and allotment of resources for the project to exist. It’s important for IT project managers to keep the idea of the business need in mind throughout the project. Companies don’t launch projects because of cool technology or fast gadgets and gizmos or to be on the bleeding edge of technology—there must be a financial reason behind the project initiation. The business need is linked to the organization’s strategies and tactics, goals and mission, and responsibility to its shareholders, owners, and customers. Your CompTIA exam will address the business need identification as part of the pre-project discovery phase.

I’ll dive into project initiation more in this chapter, but for now, know that the initiating process group is responsible for creating the project charter and identifying the project stakeholders. The project charter is the official document that authorizes the project manager and the project to exist within the organization. The project stakeholders are all the people and organizations that are affected by the existence of the project and the project’s outcome. If you’re the project manager, you’re a stakeholder. More on this in just a bit—I promise.

Planning the Project

Good projects need good plans. You, the project team, and many of your stakeholders will need to know where your project is going and how you plan on getting there. Planning is an iterative project process group that communicates the intent of the project manager. It shows which processes will be used in the project, how the project work will be executed, how you’ll control the project work, and, finally, how you’ll close down phases and the project at its end. Planning requires time, resources, and often a budget for testing, experimenting, and learning.

The primary result of the planning process group is the project management plan. This document is a collection of smaller plans that address different areas of the project. In Chapter 2, I’ll go into the details of each of these project plans, but for now, here’s a quick overview of what the planning processes help the project manager create:

•   Scope management plan

•   Scope baseline

•   Change management plan

•   Configuration management plan

•   Requirements management plan

•   Cost management plan

•   Cost performance baseline

•   Schedule management plan

•   Schedule baseline

•   Quality assurance plan

•   Process improvement plan

•   Resource management plan

•   Communications management plan

•   Risk management plan

•   Procurement management plan

•   Stakeholder engagement plan

•   Transition plan/release plan

Some project documents, forms, and checklists can also go into this plan, but these are the headlines. Many of these plans don’t have to be created from scratch each time—that’d be a pain. You can adapt previous, similar project plans as templates for your current projects to save time and effort and to use the benefit of historical information during planning. Planning, I want to stress, is an iterative activity. You’ll come back to planning over and over throughout the project; planning is not a one-time activity.

Executing the Project

Here’s the heart of a predictive project: getting the work done. After being presented with your approved project, your project team goes about the business of getting the project work done and creating key results. Project execution is unique to each discipline and is led and directed by the project manager. This is also the process group where members of your project team will spend the bulk of their time and effort and where the project will cost the bulk of your budget. It’s the heart of the project’s mission: to create the product or service the stakeholders are expecting.

Project execution includes the quality assurance process, as the project team must create the project work correctly, ideally the first time. It’s almost always more cost effective to do the work right the first time than to pay for it to be fixed later. In IT, simple mistakes can mushroom into costly wastes of time and materials. I’ll talk all about quality and the IT projects in Chapter 11.

It is also in the project execution process group that you’ll acquire, develop, and manage the project team. It’s a fine line between managing your project team and leading the project team. Management is really all about key results: you want your project team to get their work done as planned, on time, and according to budget. You want your team to be as committed to the project work as you are. Good project management balances management with leadership. Leadership is about aligning, motivating, and directing your project team.

The final process in execution is linked to the costs of your project: procurement. You’ll need to understand the procurement process, how contracts work, and the rules and policies your organization has established regarding the procurement process. Most IT projects need to purchase resources—that is, materials such as software and hardware—to satisfy the requirements of the stakeholders. Conducting the procurements according to the procurement management plan can be a time-consuming process, and when time is of the essence, that can cost your project.

Monitoring and Controlling the Project

In tandem with project execution is the monitoring and controlling process group. This set of processes ensures that the project work your team is doing is being completed accurately and according to plan. If there are problems, issues, or risks, then the project shifts back to project planning to figure the stuff out before moving back into execution. Monitoring and controlling the project is based on your project plans, the work of the project team, and shifting conditions within the project.

You’ll manage scope, time, and cost changes with the monitoring and controlling processes. It’s also in this process group that you’ll work with the project stakeholders to verify that the project scope has met their requirements so that they’ll accept the project deliverables the project team has created for them. Scope verification is an inspection-driven process that leads to acceptance decisions for the project.

Another inspection-driven process that’s done without the stakeholders is quality control. Quality control involves you and the project team inspecting the project work to confirm that it’s done correctly before the stakeholders look at what you’ve created. Quality control is all about your team keeping mistakes out of the customers’ hands. This is actually a great example of how project execution and monitoring and controlling work together. Recall that quality assurance is about doing the project work correctly the first time. Quality control is about proving that the work was done correctly—and if it was not, the team takes corrective actions to fix the errors.

Monitoring and controlling also provides communication for reporting the overall performance of the project, the performance of key project deliverables, and information on project specifics, such as the time, cost, and risk portions of the project. Monitoring and controlling also requires that the project manager oversee and administer the procurement agreements with the project vendors.

Closing the Project

I’ll address the project closure in detail in Chapter 12, but it’s important to address project closing at the beginning of the project. Because projects are temporary, the project manager, project team, and other key stakeholders all need to be in agreement as to where the project is going. You’ll need to define indicators that signal the project is complete. Because technology can change so quickly and frequently, it is vital that you define what constitutes the project closure. You don’t want a project that drones on and on because of loosely defined requirements.

The closing process group allows project phases and the project as a whole to be closed. Some documentation, final reports, and communications happen in the final activities of the project. All of the project information should be archived for future usage—sometimes called organizational process assets. Basically, the work you’ve done in your project can be used for supporting the solution you’ve created, or other project managers can use your project files to help their projects.

The closing process group also includes the close procurement process. Contracts will define how the relationship between the buyer and the seller should end. This includes post-delivery support, warranties, inspections, and payments. When it comes to closing out the procurement, your company may require a procurement audit to determine how and where the project monies were spent, what was purchased, and that all the invoices and contracts are complete.

Introducing Agile Project Management

Agile project management focuses more on quick results and less on predicting and planning what should happen in a project. Agile project management acknowledges that predicting how everything will go in a project is really difficult, if not impossible, and instead embraces the idea of short bursts of work, changing requirements, and delivering the most important parts of a project first to the customers. Agile project management is very different than predictive project management and is most suited for software development projects.

If you’re building a house, you really do have to predict what you’re building. You’ll work with architects and engineers to predict what the end result of the house should look like. You must do lots of planning for all the different parts of the house. And then the physical labor of building the house, the inspections for compliance, and you can see the progress of the construction. That’s a great example of a predictive project: you plan, execute, control, and can see the work as the project moves toward closing.

Now think of a software development project. You have to plan for the big picture, but whereas you can easily see that an electrician is actively working on your house project, you can’t simply look at a programmer and know whether they are thinking of a solution for your software development project or thinking of what they’ll have for dinner.

Agile projects are typically suited for knowledge work projects, where the bulk of the work happens through mental efforts, creativity, and trial and error. Industrial work is what you’ll often find in a predictive project—–where you can see the effort taking place. One approach is not better than the other, it’s just a different project management approach depending on the type of work the project is completing.

Exploring Agile Projects

There are several different frameworks for agile projects, but they all have one thing in common: change is welcome. Change in an agile project, which is almost always a knowledge-work project, is much easier to implement than in a predictive, industrial-work project. In other words, it’s much easier to add a dialog box in a piece of software than it is to add a swimming pool inside a house. Agile projects welcome change at any time in the project.

Because agile projects welcome and expect change, they operate in short bursts of planning and work. Agile projects begin with a big list of features and functions that should be included in the project. That big ol’ list is called the product backlog and it includes everything the customer could possibly want as a finished project. The product owner will examine the product backlog and prioritize the requirements from most important to least important. The stuff at the top, which is the most important, is what the development team will create first.

This is important: the prioritized backlog orders the requirements from most important to least important based on the customer’s business value. Business value is why the project is being done. Business value is the profitability, the cost saving, the opportunity, the heart of the project’s existence. In agile projects, we say that we eat our dessert first, meaning we get to create the most exciting things for the customer right away. For both the CompTIA Project+ exam and your agile projects, focus on the business value to see what’s most important to the customer and why the project has been launched.

Let’s go back to the predictive house project. The customer gets the business value only when the entire house is done. Typically, your customer can’t move into the house until it’s entirely done and they have a certificate of occupancy from the inspectors. Nobody wants to live in a house that’s still under construction. In an agile project, however, you don’t have to complete the entire piece of software for the customer to begin using what you’ve created. Business value can be realized while the software project continues.

You’ve probably visited websites or purchased early released software that has some significant business value to you. And then a bit later, the website and software is updated with more features. And then again later you’ll see additional releases. That’s a great example of an agile project. The whole project isn’t done, but you, the customer, can start using the most important features of the software. You get to eat your dessert first.

Comparing Iterative and Incremental Approaches in Agile

There’s one additional big concept you need to know for agile project management: incremental and iterative approaches. It’s really pretty straightforward, but these terms get confused by many in our industry:

•   Incremental  You and your project team create increments of a deliverable ready for the customer to use.

•   Iterative  You and your project team repeat the development of the product over and over until it’s ready for use by the customer.

Imagine your customer wants a software solution that lets employees clock into work, track the different tasks they complete, reserve time for meetings, and even schedule their holidays and vacation days. You and the customer identify lots of features to include in this time management software. The customer insists that the most important feature of the software is the capability for employees to clock in and out of work; the other features are great, but not as important. Your team creates a software version that attacks the most important feature first—clocking in and out of work—and the customer can begin using the software in its limited initial version right away. The project team will continue to work on the other prioritized features and append them to the software in new versions and releases. Each release of the software with new features is an increment of the final product.

Now imagine this same project, but this time the customer wants everything complete and polished before any releases happen. So you and the team will go through rounds, or iterations, of creating, perfecting, and polishing the software until there is a wholly complete and approved project for the customer. It’s like you’re sketching a picture, then painting over the sketched lines, then adjusting some colors, and then doing the final touches, and then framing the artwork ready to be displayed. It’s the same product, but there are lots of steps and iterations to achieve the final completed work.

Technically, a project can be both iterative and incremental. For example, the customer in our imaginary time-keeping software could have you move through iterations of product design, build, and perfections and then release a portion of the project for utilization. Then you’d repeat the work in other areas of the software. You’re iteratively creating and perfect the software, but releasing it in big increments for the end users.

Developing the Project Charter

In order to have a project, you need a project charter. A project charter is a document that comes from someone in the organization that has authority over all the resources used and affected by the project. The project charter, which is the first process in project initiation, sets the high-level objectives of the project and gives the project manager authority to manage the project and its resources. Resources are people and physical things, like equipment, materials, and facilities the project will need. The project charter should be written and signed by the project sponsor, project steering committee, project management office, or any entity that has authority over all resources to be used in the project. The project manager might write or help write the charter, but it’s signed by someone with organizational authority.

According to Moore’s Law, a principle authored by Intel co-founder and Chairman Emeritus Gordon Moore, the processor chip speed of technology doubles every 18 months. Today that law is practically defunct, because processor speeds are no longer doubling at the same rate. The basic concept of Moore’s Law, however, is often applied to practically all other areas of technology, which means that, in turn, the role of an IT project manager can be expected to change just as rapidly. IT project managers everywhere struggle with keeping teams, budgets, and goals focused. IT project management becomes even more tedious when you consider the economy, the instantaneous expectations of stockholders and management, the constant turmoil in the IT industry, and the flux of each team member’s commitment to their own career.

Why do so many projects fail from the start? Projects fail for many different reasons: other projects take precedence, team members lose sight of the purpose of the project, and project managers try to do the work rather than lead the team, among other reasons. At the root is a fundamental problem: vision. Vision, in project management terms, is the ability to see the intangible clearly and recognize the actions required to get there. One of your jobs is to develop, nurture, and transfer the vision to everyone on your team. As a project manager, you cannot have a clear vision of the project if the project’s needs are never clearly established. The project charter helps to define and communicate the project vision to keep everyone focused on the big picture of the future state the project aims to create.

Creating Reasonable Expectations

Once you’ve discovered your vision, create a goal. A goal should be a clearly stated fact, such as, “The new database will be installed and functional by December 6 of next year.” A goal sums up the project plan in a positive, direct style. Every member of your team should know and pursue the goal. It’s not all up to you. The goal establishes the direct need and purpose for undertaking the project. The goal can be expressed as part of the project charter or in an entirely separate document that comes after the project charter is created.

When creating a goal for your project, be reasonable. Just as it would be foolish to say, “I’m going to lose 60 pounds this month,” it would be unreasonable for you to create an impossible goal.

A logical goal is not just an idea, a guesstimate, or some dreamy date to be determined. A goal is actually the end result of a lot of hard work. Each IT project will, of course, have different attributes that determine each goal.

Let’s say, for example, that your company is going to be migrating your servers and desktops to the latest and greatest operating system. With this scenario, certain questions would have to be answered to determine the ultimate end date for the goal: Is the hardware adequate for the new OS? Will the applications work with the new OS? Will the team have adequate time to be trained and experiment with the new OS? These questions will help you create the end date for the goal.

Creating the Project Charter

The project charter is an official, detailed document in line with your organization’s vision and goals. Obviously, a project can stem from a broad, general description of an IT implementation. A goal narrows the description and sets a deadline. A project charter formalizes the goal and serves as a map to the destination. Above all, however, a project charter formally authorizes the project.

Not only does a charter clearly define the project, its attributes, and its end results, but it also identifies the project authorities—usually the project sponsor, project manager, and team leaders (if necessary). The charter also specifies the role and contact information for each authority.

Why do you need a project charter? Why not just hop right in and get to work? In a small company, plowing right into the project may turn out just fine. However, in most companies a project charter is the foundation for success. Consider what the charter accomplishes:

•   It authorizes the project.

•   It defines the business need in full.

•   It identifies the sponsor of the project.

•   It identifies the project manager.

•   It makes the project manager accountable for the project.

•   It assigns authority to the project manager on behalf of the project sponsor.

Two items warrant additional discussion from the contents of the project charter: the project sponsor and the project manager. You know who the project manager is—that’s you. The project sponsor is a person who has the authority to launch the project. The project sponsor is seen as the management champion of the project and has authority over all resources in the project. It’s so important to ensure that the project sponsor for the project is the right person; choosing the wrong project sponsor can create risks, issues, and drama in a project.

Project Charter Elements

When the project charter is created, you can include just about any information pertaining to the project that you’d like to include. Generally, though, consider these elements:

•   Official name  Every project needs a name.

•   Project sponsor and contact information  The project sponsor should be someone in the organization who has the authority to assign the project manager power over the project resources.

•   Project manager and contact information  The project manager is officially named in the project charter.

•   Project purpose  The purpose defines the problem statement or opportunity the project will address.

•   Business case  The business case defines why the project needs to happen and synchronizes the project to the organization’s strategic plan. The business case does not necessarily need to be included in the project charter, but it should be referenced.

•   Key deliverables  These are the primary products, services, or results the project should create.

•   Preliminary scope statement  The charter can include a preliminary scope statement that clearly defines the items that are in scope and out of scope. Identifying out-of-scope items is a way to clarify what the project won’t accomplish and helps to address assumptions. For example, the project will create the new software, but it will not create the training and support documentation.

•   General statement about the team’s approach to the work  You might reference a software model you’ll use or an approach you’ve used on similar projects in the past. This is where you’ll communicate if your project management approach will be predictive or agile.

•   Basic timeline for project milestones  A milestone is an event in the project that shows progress. Milestones typically come at the end of a project phase.

•   Resources, budget, staff, and vendors  Some of this information will be known at the launch of the project, given the nature of the work or the structure of the organization. Often, however, only the roles and responsibilities are known, and the project is organized after the project charter is created.

•   Summary budget  Depending on the organization’s rules and project approaches, the budget is usually based on a rough order of magnitude cost estimate with a defined range of variance or a maximum dollar amount for the project.

•   High-level assumptions and constraints  An assumption is something that’s believed to be true but hasn’t necessarily been proven to be true, such as operating system and hardware compatibility. A constraint is anything that limits the project manager’s options, such as a requirement to use the cinnamon roll software development model.

•   High-level risks  A risk is an uncertain event or condition that may have a positive or negative effect on the project. For example, data loss, network downtime, and the loss of key resources are all typical IT risks.

Every project needs a charter. It authorizes the project, creating a sense of responsibility for the project manager, a sense of ownership for the sponsor, and a sense of teamwork for the project team. The project charter will save you headaches, establish who’s in charge, and move you to your goal more quickly and with more confidence.

Following is an example charter, based on a fictional company, Best Enterprises. While I’ve purposely kept the technology vague, a real project charter would call out the exact technology the project will install. The fictional company’s network currently consists of 380 computers running Windows workstations. It has made a decision to move all the workstations to a current standard Microsoft operating system and all the servers to the latest version of Microsoft Server.

Your project charter can include as much or as little information as you deem necessary. Project charters (with the exception of the budget) are often shared with the entire organization, so you may need to make a few revisions before the charter is complete. Sharing a project charter with the entire organization, especially if it will affect all users as in the sample charter, can get everyone involved, excited, and aware of coming changes. A project charter also creates a sense of responsibility for all involved.

Your project team members will get distracted, be pulled in different directions, and lose interest. Vacations pop up, kids get sick, people quit. Realize at the onset that not everyone will be as dedicated to your project as you are. Do your best to inspire, motivate, and lead. Set aside politics, egos, and aspirations and work toward the goal.

Finally, keep in mind that a charter can be called different things in different organizations and that the level of detail can vary, depending on the organization and the project being created. Most charters, however, accomplish two primary things: authorizing the project work and defining the project work.

Gathering Project Information

Everybody talks about project management, but what is it exactly? In some organizations, any task or duty is considered a project that requires someone to manage it. Puh-leeze! Project management is the ability to administer a series of chronological tasks resulting in the desired goal. Some tasks can’t be completed until others are finished, while other tasks can be done in parallel. Some tasks require the skill of a single individual; other jobs in the project require that everyone chip in and lighten the load.

IT project managers must be able to balance their love for and implementation of technology while leading and inspiring their team members. Of course, the goal of project management is not technology for technology’s sake, but rather a movement toward things like improved customer service, enhanced product quality, and increased profitability. Add to that mix external factors such as market conditions, competition, demands for new technology, and even the changing pace of technology, and it’s no wonder IT projects can become so frustrating. As you can see in Figure 1-3, project management is a high-wire balancing act.

Figure 1-3  A project manager must balance stakeholders, technology, and the project.

The business value, or why a project has been created, really drives the implementation of a project. This is part of the project’s discovery/concept phase. Business value can be to increase efficiency, to increase productivity, to respond to a customer request or a new regulation, or countless other reasons a project is initiated. The project manager must understand what’s driving the project and how the project supports the business needs and mission of the organization, and how the deliverable of the project will be used by the stakeholders.

Establishing the Project Requirements

Before the actual project work can begin, the project manager must establish the project requirements with the project stakeholders. Stakeholders are any individuals, groups, or communities that have a vested interest in the outcome of the project. For some projects, the stakeholders may be just one department. For projects that affect every department, the stakeholders include people and departments throughout the entire organization. Identifying stakeholders is important, because their input to the project requirements early in the project can ensure the project’s success.

Of course, on most projects, there will be key stakeholders who influence the project’s outcome: department managers, customers, directors, end users, and other folks who have direct power over the project work or results. With the input of these key stakeholders—specifically their requirements for the project, constraints on the project, and time and cost objectives for the project—the project manager will be able to gather the project requirements to begin building a project plan to create the project deliverables. Common stakeholders can include the following:

•   Customers and users  These are often called the end users, clients, or recipients of the project deliverables. These stakeholders could be internal to your organization or quite literally customers who purchase the deliverable your project creates.

•   Project sponsor  This is a person in the organization who has the authority to grant the project manager power over the project resources, assign a project budget, and support the existence of the project. This person also signs the project charter to launch the project officially and assigns the project manager to the project.

•   Portfolio review board  This group of stakeholders is responsible for determining which projects are worthy of the organization’s capital. This board defines the governance of projects and programs within an organization and oversees the selection of the projects, while considering a number of factors such as return on investment, project value, risk to reward of proposed projects, and predicted financial outcomes of launching a new project.

•   Program managers  A program is a collection of projects working together to realize benefits that the organization could not realize if the projects were managed independently of one another. The program manager oversees all of these orchestrated projects in her program. If your project is operating within a program, then the program manager is a stakeholder.

•   Project management office (PMO)  Some organizations use a PMO to centralize and coordinate the management of projects within an organization, line of business, or department. PMO functions can vary by organization, though most offer project management support, guidance, and direction for projects within their business domain. It’s not unusual for a PMO to direct the actual project management of a project.

•   Project team  These are the people who work on planning and executing the project plan. Depending on the organization, the project team members may work full-time or part-time on the project, and they can come and go as the project work warrants or stick around for the duration of the project.

•   Functional management  Functional management consists of managers of the administrative functions of an organization: consider finance, human resources, and accounting. Functional managers have their own staff and their own day-to-day duties to keep the operations stable.

•   Operations management  These are managers of the core business area such as design, manufacturing, and product development. Operations managers oversee and direct the salable goods and services of the organization.

•   Business partners  These are the sellers, vendors, and contractors that may be involved in a project through a contractual relationship. Business partners can provide goods and services such as hardware, software, and subject matter experts (SMEs) such as developers, technical writers, and software testers that you might need on your project.

•   Project manager  You are a stakeholder for your project. You’re responsible for developing the project plans, keeping the project on track, monitoring and controlling the project, and communicating the project status and performance. As the saying goes in project management, if the project succeeds, it’s because of everyone’s efforts; if the project fails, blame the project manager.

•   Product owner  If you are working in an agile project management framework, you will have a stakeholder that represents the customers. This role is typically called the product owner, though you might also see it called the customer representative. The product owner is responsible for prioritizing the product backlog and explaining the requirements in detail to the project team.

•   Product manager  Some projects may include a product manager as a stakeholder. Product managers are responsible for identifying the features and functions of a product, how changes or improvements to the product may be allowed, and will monitor the project for quality in the product.

Clarity is paramount. When the decision has been handed down that your organization will be implementing some new technology and you’ll be leading the way, you need a clear, thorough understanding of the project’s purpose. Ambiguous projects are a waste of time, talent, and money. Before the project begins, you need to know what exact results signal the project’s end. A project truly begins when you know exactly what the project will produce.

Once the predictive project is defined, you need clearly stated objectives, requirements, and boundaries for the project. Although management may have an ideal timeline for project completion, it’ll take some planning and research to determine the exact duration of the project. The role of a project manager is not permanent, but temporary. As the project manager, you are responsible for setting the goal, developing the steps to get there, and then leading the way for your team to follow.

Agile projects operate with a fixed deadline and budget, but the scope of work can change. Recall that the agile project begins with a prioritized list of product features and requirements called the product backlog. The team works to complete as many items as possible from the top of the list, because those are most important, to the bottom of the list, as these are of least value. I’ll talk more about the agile approach throughout this book. Stay tuned.

The end result of the project, the vision, is also called the Definition of Done, or the DoD. How will you know what the end result of the project is to be? Ask! Who do you ask? Stakeholders such as the project sponsor can answer these kinds of questions. You must have a clear vision of the end result, or the project will drone on and on forever and you’ll never finish. Too often, IT projects can roll into project after project, stemming from an original, indecisive, half-baked wish list. Whether you are a full-time employee within an organization or a contract-based project manager, you must have a clear understanding of what the end results of the project will be.

Imagine your favorite archeologist maneuvering through a labyrinth of pitfalls, poison darts, and teetering bridges to retrieve a golden statue. In the movies, there’s always some fool who charges past the hero straight for the booty and gets promptly beheaded. Don’t be that person. Before you can rush off toward the goal of any given project, you’ve got to create a clear, concise path to get there.

To create this path, you’ll have to interview the decision makers, the users the change will affect, and any principals involved in the development of the technology. These are the stakeholders—the people who will use the project deliverables on a daily basis or will manage the people who will use the project deliverables. You must have a clear vision of what the project takes to create it or you’re doomed. Often projects start from a wish list and evolve into a catalog of complaints about the current technology. One of your jobs in the early stages of the project will be to discern valid input from useless gripes.

As you begin your project, consider the questions presented in the following sections.

Does the Predictive Project Have an Exact Result?

Predictive projects that are as indecisive as a six-year-old at an ice cream stand are rarely successful. As a project manager, you must ensure that the project has a definable, obtainable end result. At the creation of the project, every project manager, project sponsor (the initiator of the project), and team member should know and recognize the end result of the project. Beware of projects that begin without a clearly defined objective.

Although you should be looking for exact requirements that a project is to include, you must also look for requirements that are excluded from a project (for example, a project that requires all mail servers to be upgraded in the operating system, but not the physical hardware). As the project takes form, the requirements to be excluded will become obvious given management, the time allotted for the project’s completion, and the given budget.

Are There Industry or Government Sanctions to Consider?

Within your industry, there may be governmental or self-regulating sanctions you will have to take into account for your project. For example, a banking environment will involve regulations dealing with the security of the technology, the backup and recovery procedures, and the fault tolerance for the hardware implemented. Government regulations vary by industry, and if your company is a government contractor, there are additional considerations for the project deliverables. These are compliance requirements you must plan for in your project.

You also need to be aware of other regulations and standards that apply to your industry. Regulations are “must-haves” that are required by law. For example, pharmaceutical companies, utility companies, and food packaging companies have regulations that dictate their practices. If companies break regulations, fines and lawsuits may follow. Standards, however, are generally accepted guidelines and practices within an industry. Standards are heuristics, sometimes called guidelines, which are not laws but are usually followed. The project manager must be aware of regulations and standards that affect the project’s work and deliverables.

Does the Project Have a Reasonable Deadline?

Massive upgrades, software rollouts, application development, and system conversions take teamwork, dedication, and time. Projects that don’t have a clearly stated, reasonable deadline need one. Projects should not last forever—they are temporary. Acknowledge the work. Do the work. Satisfy the stakeholders with deliverables of the project. Once you’ve accomplished this, the project is done.

We’ll talk more about project scheduling in Chapter 7, but the project manager must be aware of the project calendar and the resource calendar. The project calendar defines the hours in which the project work can take place. For example, if your project is to rewire an entire building with new network cable, the project calendar may specify access to the building between the hours of 8:00 P.M. and 6:00 A.M. The resource calendar is specific to the project team members and takes into consideration the hours employees are available, their vacations, and company holidays.

In addition, the project manager must consider how many working hours project team members will be able to devote to the project in a given day. Six hours of productivity is typical of an eight-hour day, because of impromptu meetings, phone calls, and other interruptions. These factors directly influence the project schedule and whether the project can meet the project deadline with the given resources.

Does the Project Sponsor Have the Authority to Initiate the Project?

Most IT folks hate politics, but we all know politics, personal interests, and department leverage are a part of every organization. Make certain the project sponsor is the person who should be initiating the project—without stepping out of bounds. Make certain this individual has the resources to commit to the implementation and has the support of the people up the organizational chart. And do this with the full knowledge and support of management.

The project sponsor should be an individual within the organization who has the power to assign team members, allocate funds, and approve decisions on the project work. The project sponsor is typically above the functional managers of the project team members assigned to the project work.

Does the Project Have a Financial Commitment?

If you do not have a clear sense of a financial commitment to the completion of the project, put on your hard hat and don’t stand under any fans. Technology costs money because it makes money. The goal of a project in the corporate world is the same goal of any company: to make or save money. A tech-centric project requires a financial investment for quality hardware, software, and talent. If the project you are managing has a budget to be determined somewhere down the road, you’ve got a wish list, not a project at all.

Is Someone Else Doing This Already?

In large companies, it’s easy for two projects to be competing against each other for the same end result. This comes back to communication among departments, teams, and the chief information officer. In a perfect world, IT projects fall under one umbrella, information is openly shared among departments, and everyone works together for the common goal of a company (to make money). This process can be administered through a project or program management office where projects are tracked across the enterprise. Of course, that doesn’t always happen. You should do some initial research to ensure that your project isn’t being accomplished elsewhere in the company before you invest time, finances, and your career on it.

Do the Stakeholders Understand Agile?

If your organization is new to agile project management, there will be a learning curve. Stakeholders, including the project team members, may be used to working in a predictive environment, sometimes called a waterfall approach. Agile doesn’t have all the top-heavy, front-loaded planning that you find in waterfall projects, but uses short bursts of planning and execution to move the project forward. If you and your stakeholders are new to agile, there will be a learning curve you’ll need to consider to bring everyone up to speed on the agile framework.

Possessing Multiple Personas

Are you an optimist? A pessimist? A realist? A project manager has to be all of these when identifying project requirements. You have to be an optimist so that you can lead your people, manage the resources, and identify the technology needed for the project. You have to be a pessimist, secretly of course, because you need to look at the worst-case scenario for each piece of the technology implementation. You have to be a realist because you need to look at the facts of the projects completely, unattached, unemotionally, and unencumbered.

When your project is developing, you should play devil’s advocate to each cornerstone of the project. You need to question the concepts, the technology, and the time it may take for each step of the implementation. As you can see in Figure 1-4, you should question everything before you begin.

Figure 1-4  Project managers must question all aspects of a project.

The following sections present the questions to consider.

How Will This New Technology Affect Your Users?

Not all technology you implement has a direct effect on your users, but most of it does. Your life may be IT, but the accountant in the finance department doesn’t like change. She likes everything the way it is now—that’s everything from having to click OK on a redundant error message to installing her favorite screen saver. If your technology changes her world, you should let her know ahead of time; otherwise, she’ll be certain to let you know afterward. Your primary objective must be to make her job easier.

As technology has become integrated in practically all areas of an organization, users have become more tech-sophisticated. They want to know why the change is happening, why the change is needed, and how it will help them. This brings us back to requirements gathering and communication. Ninety percent of a project manager’s job is communication. If the project manager wants buy-in from the stakeholders, particularly the users, he must communicate the benefits and rationale behind the technology project.

Will This Technology Affect Other Solutions?

How many times have you installed software without testing it, only to discover that it disrupts something as unrelated as printing? I hope never, but it happens. You must question and test the ability of the new technology to work with your current systems. Of course, if you’re considering a 100-percent change in technology, then there really isn’t a software compatibility issue. You might see these issues called roadblocks, blockers, or impediments, especially in agile projects.

Will This Technology Work with Any Operating System?

How many operating systems are in your organization? Though the goal may be just one, I’d wager that two or three different OSs are floating around. Think about those graphic designers and their Macs. Remember those salespeople and their old Windows laptops? And what about those mainframe and server-based Linux users? If your company uses multiple operating systems, you’ve got to question the compatibility of the technology for each.

What Other Companies Are Using This Technology?

The assumption is that you are buying this solution rather than building it. Therefore, is it a bleeding-edge solution? Are you first in line? No one likes to be first, but someone has to be. When embracing and implementing a new technology, ask that question of the vendor’s salesperson. Hopefully the salesperson will be happy to report about all the large companies that have successfully installed, tested, and implemented the vendor’s product. That’s a good sign. If someone else has done it, you can, too.

Does the Vendor of This Technology Have a Good Track Record in the Industry?

From whom are you buying this technology? Has the vendor been around for a while and implemented its product many times over? Does the vendor have a history of taking care of problems when they arise? This is not to say you should not buy from a startup—every major IT player was a startup at some time in its history. You should feel fairly confident, however, that the vendor selling the product today will be around to support it tomorrow.

What Is the Status of Your Network Now?

You may not always have to ask this question, but with so many network-intensive applications and new technologies today, it doesn’t hurt. You don’t want to install the latest bandwidth hog on a network that’s already riding the crest of 90-percent utilization. You and your organization won’t be happy. By asking this question, you may uncover a snake pit that needs to be dealt with before your project can begin.

What If…?

Finally, you need to dream up worst-case scenarios and see if there are ways to address each. Find out how the technology will react when your servers are bounced, lines go down, and processor utilization peaks. Ask these questions and have answers for them now rather than waiting for the crisis that hits during your four-week vacation to Alaska.

No Other Choices?

At the start of a project, at its very genesis, ensure that the proposed technology is the correct technology. Of course, sometimes you have no control over the solution that is to be implemented because some vice president and decision maker heard about the product from his golf buddy who is CIO at another large firm and is now having you install it everywhere. It happens.

Other times, hopefully most of the time, you have some input to the product implemented to solve a problem. You are the professional, the guru, so you should have a definite say regarding the technology that you’ll be in charge of delivering. You’ll need to create a list of questions and then find the appropriate technology that offers the needed solution, works with your current systems, and fits within your budget. Having the right technology to begin with ensures success at project’s end.

Interviewing Management

To have a successful project, you need a clear vision of the delivered result. You need to know why the project is being implemented. You need a strong commitment to the project from management. You need to share management’s vision of how the end results will benefit the company. How will you discover these facts? Ask!

When your boss comes to you, for instance, and reports that you are to manage a project to upgrade the mail servers, you need to find out why. It may not be that the manager really wants the mail servers upgraded; he could just be having trouble opening a cartoon his frat brother from Utah sent him and is blaming it all on the company’s e-mail system.

When you approach management to find out why the project needs to happen, you aren’t questioning their decision-making ability. You are, however, trying to understand their vision for the project. In your organization, your immediate manager may be the most technically savvy genius in the world, and her decisions are always right on target. In other organizations, if not most, managers know that a technology exists and can be implemented. However, they don’t know exactly which technology they’re after. Figures 1-5 and 1-6 show the difference between effective decision-making abilities and poor decision-making abilities.

Figure 1-5  Well-informed decisions result in success for everyone, not just the project.

Figure 1-6  Decisions based on complaints, wishes, and sales spiels miss the mark.

As the project manager, your job is to ensure the success of your project and your career, and to ensure a successful impact on the bottom line. When you speak with management about the proposed project, you are on a fact-finding mission. Ask questions that can result in specific answers. For example,

•   What do you want technology so-and-so to do?

•   Why is this solution needed?

•   How did you discover this product?

•   What led you to the decision that this was the way for your organization to go?

Sometimes a manager may come to you with a specific problem for you to solve. In these instances, the project is wider and more open-ended, and you’ll have to drill deeper into the problem presented. Let’s say, for example, that a vice president is complaining about the length of time it takes her to retrieve customer information through the organization’s database. She just wants it faster.

Your questions may be something like this:

•   Can you show me how the process is slow?

•   Is it slow all the time or just some of the time?

•   How long have you experienced this lag?

•   Have others reported this problem?

You could do several things to increase the speed of the process. Each may require a financial commitment initially but will result in faster responses for all of the database users. Do you want to investigate this route?

Notice how you’re thinking like an executive. It’s not technology for technology’s sake. A new multiprocessor database server, gigabytes of memory, and faster switches are all cool stuff, but if they don’t earn their keep, they are just toys. When you are inventing a project, think like an executive of a company and show how the investment in software, hardware, and talent can create more dollars by increasing productivity, safeguarding data, or streamlining business processes and ultimately making customers happy.

Your organization may shift much of these requirement-gathering duties to a business analyst (BA). That’s fine, but you and the business analyst should work together to examine the goals, requirements, and objectives of the project that will eventually feed into your project scope. One approach that I’ve always liked is called SMART; for each project goal, determine whether it meets each of the following:

•   Specific  You must know what the specific requirements and deliverables are for your project.

•   Measurable  It’s a good idea to avoid vague terms such as fast, good, and happy. You need measurable metrics for the project requirements.

•   Achievable  The goals of the project should be achievable considering the resources, cost, and time required versus what’s available in the organization. Management and customers that ask for a long list of requirements without providing a balance of time and monies are setting themselves up for disappointment.

•   Relevant  The goal of the project shouldn’t be based on someone’s private agenda. The goals of the project should support the primary business need of the organization, provide an opportunity for the organization, or solve a problem. Basically, all projects should either increase revenue or cut costs.

•   Time-bound  Requirements that are dreamy, are open-ended, and don’t provide an easy link to a conclusion aren’t good requirements for accurate planning and goal creation.

Interviewing the Stakeholders

As you know, stakeholders are individuals, groups, or organizations that have a direct interest in the outcome of the project. Your project’s success or failure will directly affect the way they complete their work, use their existing technology, or continue to buy from your company. Stakeholders can include

•   Management

•   Project manager

•   Project team

•   Project sponsors

•   Customers

•   End users

•   Community

In a technical project, the largest group of stakeholders is typically the users. Any project that has an impact on users needs to be discussed with them. This can be done in several different ways. The most popular, and sometimes most disruptive, is by forming a focus group. Focus groups are often led by a professional, impartial moderator and are conversational in tone.

A focus group enables you to gather users from each affected department, present the project to them, and then listen to their input. You need to explain how the proposed technology will be better than the current one, how it will solve problems, and, if necessary, why the decision is being made to change. Input from focus groups can alter your entire project for better or worse.

Another way to interview users is through an intranet site. This method can be an effective form of communication because users have the opportunity to share their opinions and have some say about the project. Of course, with this route, it’s best to create an intranet site that asks for responses to a survey so that the results can be tallied quickly. See Figure 1-7 for an example of an online survey.

Figure 1-7  An online survey can quickly tally users’ input regarding a new technology.

Some project managers rely on the Delphi Technique, an approach that’s often used in risk management, but can be applied to any consensus-gathering activity. The participants and their comments are anonymous. The participants are allowed to comment freely on the technology, including their concerns and their desires for requirements. All of the comments are then shared with all of the participants, and they can agree or disagree with the comments according to their opinions and experience. Because the process is anonymous, there is no fear of retribution or backlash or of offending other participants. After several rounds of discussion, a consensus is formed on what is needed. An intranet site can automate the method and keep users anonymous.

Finally, you should learn how the users do their work now. This is especially important for projects such as new software development, application upgrades, and new hardware technologies. This can be accomplished in a usability laboratory, where mock screens resembling the technology being implemented are made available. Feedback from users helps design the solution to be implemented. By working with a user one-on-one, you can experience how he is using the current technology, how the new technology will affect him, and what the ultimate goal of a technical change should be: increased productivity and increased profits. Don’t lose sight of that fact.

This is really stakeholder observation, and it comes in two flavors:

•   Passive observation  The observer simply observes and documents the work and does not interact with stakeholders at all. It’s sometimes called invisible observation.

•   Active observation  The observer interacts with the users, stops their work to ask questions, and can even get involved in the actual work to experience the users’ processes. This approach is sometimes called visible observation.

As stakeholders are identified, they should be added to a stakeholder register. The stakeholder register helps with requirements gathering and also with project communication. The stakeholder register defines

•   Stakeholder identification information  This includes each stakeholder’s contact information, role in the project, and organizational position.

•   Assessment information  This includes each stakeholder’s specific requirements, project expectations, and project influence, along with the specific phases and deliverables each stakeholder is most interested in.

•   Stakeholder classification  Stakeholders who support your project are considered positive stakeholders. Stakeholders who oppose your project are considered negative stakeholders, or project resistors. Neutral stakeholders are indifferent to your project. This part of the stakeholder information may also include information on the stakeholder role in the organization, such as internal employee, customer, or vendor.

•   Stakeholder management strategy  This may be included in the stakeholder register, though it’s often a separate document. The stakeholder management strategy defines how the project manager will increase support for the project among the stakeholders and how interruptions and objections to the project can be minimized. The strategy considers which stakeholders wield power and influence over the project, interest level for the project, and strategies to overcome stakeholder objections.

Understanding how stakeholders complete their work can help the project manager and the project team appreciate how the project deliverables will be used. Understanding the end result of the project at project initiation will enable accurate identification of project goals.

Working with a Business Case

A business case is a document that explains why the project needs to be launched. Business cases are usually written by a business analyst who has studied the project need, the likely cost to complete the project, the likelihood of project success, and all of the factors that support the project need. Business objectives are the specific goals defined in the business case. In some instances, you, the project manager, may be called upon to write the business case for your project. The business case helps upper management determine the need for the project, the cost of the project, and the return on investment for completing the project. The business case can describe the current state and the future state the project will create.

A typical business case has seven components that appear in the following order:

•   Executive summary  Although this high-level summary of the business is the first part of the final business case document, you’ll probably write it last. The executive summary is an abstract of the actual business that provides all the quick and juicy information condensed into one page (usually); it’s often the only part of the document that management and key stakeholders actually read.

•   Problem statement  This section defines the goal, problem, or purpose of completing the project. It defines the problem quickly and directly. The problem statement may discuss what the project will solve, the opportunity the project will realize, the benefits of doing the project, and any ramifications the organization may face by not doing the project.

•   Analysis  The analysis is the documented study of the problem or opportunity. You’ll describe the problem, how the problem came into being, how the problem is affecting the organization and/or its customers, and how not solving the problem (or opportunity) will affect the organization in the future. Return on investment analysis clearly defines the likely cost of the project and the expected return for the investment.

•   Proposed solutions  The business case will offer at least two solutions regarding the problem, but often more. The two solutions are to do something about the problem or ignore the problem. More likely, the business case will include two or three specific actions to address the problem. Each solution will include a description of the actions, the expected outcomes, and any effects the solution will create.

•   Project overview  Next comes an overview of the project, should it get initiated, and the intended goals of the project. This section defines the likely costs, schedule, and resources needed to complete the project. Of course, this is a high-level overview, so you’ll also need to document any assumptions you’re making regarding the project. The business case doesn’t get into all of the research that the project manager, team, and experts will do during the project planning activities, but provides only a high-level insight into the proposed project.

•   Cost-benefit analysis  The business case also requires the proposed cost of completing the project and what costs the organization may incur if it doesn’t do the project. The costs of the project are usually described with a modifier, such as “+/– 50 percent,” depending on how confident you are about the costs of the project you’ve described in the project overview section. Note that this section also includes the costs of not completing the project: fines, waste, frustration, and other negative costs that aren’t purely financial.

•   Recommendations  Finally, you’ll offer your recommendations for the solution, the project initiation, and what the key performance indicators (KPIs) of the project should be. Your recommendations shouldn’t be too much of a sales pitch for the project, but should be factual and based on your analysis and study of the problem. It is entirely possible, and acceptable, for the proposed solution not to be used to implement a project, especially if the costs are too high or the benefits for completing the project are too few.

Business cases are not needed for every project, but larger projects almost always pass through the business case process before they begin. As mentioned, the process may be performed by a business analyst who interviews the customers, project managers, management, and other key stakeholders to formulate the description of the problem and the proposed solution for the organization.

Establishing the Completion Date

There’s a cartoon that’s probably posted in every auto mechanic’s garage. In the cartoon, a bunch of people are rolling around laughing uncontrollably. Above all this mayhem is the caption, “You want it when?” Of course, as an IT project manager, you can’t take that same approach, but a reasonable deadline has to be enforced.

A firm end date accomplishes a few things:

•   It creates a sense of responsibility toward the project.

•   It gives the team something to work toward.

•   It signifies a commitment from sponsors, team members, and the project manager.

•   It confirms that this project will end.

How do you find the completion date for a project, and how do you know if it’s reasonable? The magic end date is based on facts, research, and planning. In upcoming chapters, you’ll get a more detailed look at project end dates for predictive and agile projects and how you establish them. For now, know that projects are a sequence of steps, and each step will take time. The completion of each step will predict when a project should end. And it’s not just the project execution that you must account for. A project manager must also consider the time for planning, meetings, and responses to project risks, issues, and the consideration of change requests that are inevitable in technology.

Some project managers in predictive projects create a flexible deadline. Don’t do this. If you allow yourself a deadline that is not firm, you’ll take advantage of it. And so will your team, your sponsor, and your management. Set a deadline based on an informed opinion, and then stick with it. The charts in Figure 1-8 demonstrate how a missed completion date is bad for the project, the organization, and morale.

Figure 1-8  If a project schedule stays on track, so will the budget and the morale.

A rule of economics that affects scheduling is Parkinson’s Law, which states that work will expand to fill the time allotted to it. In other words, if you give yourself extra time to complete a project, the project will “magically” fill the extra time. A firm deadline gives the project manager and the project team a definite date to work toward.

Other factors can have an impact on your projected deadline:

•   Business cycles  Does your project deadline coincide with busy times of the year? Think of a retail giant. How willing do you think it would be to overhaul the database that handles shipping and store management in December?

•   Financial situations  An organization may be more (or less) willing to invest in new hardware or software at a particular time of the year due to taxes, fiscal year ending, or the advent of a new budget. You’ve got to consider these factors when you request finances for your project.

•   Time commitments throughout the year  When will your team members take vacation? How will their vacation plans coincide with the project’s deadline? What other internal time commitments do they have? Will they be traveling to other sites? These factors can delay a project for weeks and months—ultimately resulting in a missed deadline. Work with your team members to ensure that their availability coincides with their responsibilities within the project plan.

CompTIA Project+ Exam Highlight: Initiating Processes

If you’re using this book as a study guide for the CompTIA Project+ exam, you’re in luck. In each chapter you’ll find a sidebar like this one. In this sidebar, I’ll highlight the specifics that you absolutely must know in order to pass your CompTIA Project+ exam. All of these exam sidebars reflect the exam objectives as of this writing. I strongly encourage you to visit https://www.comptia.org/certifications/project and download the most recent exam objectives, because it’s possible they’ve changed since this writing.

This first chapter, “Launching a Technology Project,” maps to several portions of the CompTIA Project+ exam objectives. To help you study, I’ve called attention to the specific CompTIA exam objectives partially covered within this chapter. Following are the objectives and key points covered in this chapter.

1.1 Explain the basic characteristics of a project and various methodologies and frameworks used in IT projects  Projects are short-term endeavors to create unique products, services, or conditions. Projects aren’t part of operations, but they often create or deliver products and services that operations will use, such as software, workstations, servers, and even networks. Because projects do not last forever, they have a definite start and finish. This is evident in technology when you consider the temporary nature of technology—it’s always changing and evolving.

You know the five process groups of the project management life cycle, right? As a reminder, here they are

•   Initiating  This is the preproject setup and project launch.

•   Planning  This is an iterative group of project processes that communicate the intent of the project.

•   Executing  This is the process group where the project manager directs project plan execution and the project team does the work to complete the project objectives. It’s where the bulk of project funds and time is spent.

•   Monitoring and controlling  This process group happens in tandem with project execution. It oversees the project work to ensure that the work is being done according to plan.

•   Closing  These processes are used to close out a project phase and to close the project altogether. It’s also where you’ll find the close procurement process.

Although these process groups have distinct responsibilities and activities, there is plenty of overlap and movement between them. Consider how planning, executing, and monitoring and controlling all allow the project manager and the project team to shift between these groups of processes. These project management process groups are usually associated with a predictive project, but agile projects are also initiated, planned, executed, monitored and controlled, and closed, just in iterations rather than as a logical flow of work from the launch to completion of the project.

Projects are constrained by the available resources. Resources are people, equipment, and money. Recall that the portfolio review board can examine potential projects and determine their worth in investment. Organizations have only so much capital to invest in projects, and it’s the project manager’s responsibility to be accountable for the investment. Human resources constraints also affect projects; consider the availability, competence, and interest of the project team. Finally, resource constraints in technology projects can be older, slower equipment and software that the project must use or interact with.

1.2 Compare and contrast Agile vs. Waterfall concepts  Predictive projects are also called waterfall projects. They are phases of project work that fall into the next stage, like a waterfall. For example, in construction you do the foundation phase, then the framing phase, and then the electrical phase, and so on. In an IT project, a waterfall project you have phases of work that are conception, initiation, analysis, design, construction, testing, production/implementation, and maintenance. Waterfall projects plan, or predict, everything up-front, so this is why they are also called predictive projects.

Agile projects have much less emphasis on planning and upfront definition for the project than a waterfall project. Agile projects create a prioritized product backlog and the team works in short iterations of planning and execution. There are many different variations of agile project management that I’ll discuss later in this book. For now, know that agile projects welcome and expect change and work with a fixed deadline, a fixed budget, and a changing scope.

Predictive projects are plan-driven and are resistant to change, while agile projects are iterative, incremental, and welcome change.

2.2 Given a scenario, perform activities during the project initiation phase  In this chapter, this objective centered on why your organization needs a project, who’s demanding the project, and what opportunity the project will realize or what problem the project will solve. Remember that the business analyst may assist in needs assessment and requirements gathering and writing the business case, but you and the business analyst should work together to fully capture and understand the project purpose.

You’ll also need to prepare a project charter in order for the project to be authorized officially in the organization. The person who signs the project charter, the project sponsor, should have the authority to grant the project manager power over the resources the project needs to be successful. Some project charters may rely on contractual agreements if the vendor is the performing organization.

Charters authorize projects to exist in an organization, and they officially name the project manager. Charters have

•   Key project deliverables

•   High-level milestones

•   High-level cost estimates

•   Stakeholder identification

•   A general project approach

•   A problem statement

•   High-level constraints and assumptions

•   High-level risks

•   Overall project objectives

These components of a project charter are identified at a high level at project initiation. During project planning, the project manager and the project team will progressively elaborate on these components to fully create the project management plan.

The specific portion of this exam objective you learned about in this chapter is the justification of a project. All projects must be in alignment with the business case, the organizational strategic plan, and the mission of the organization. Projects that don’t map to these requirements should not be chartered.

You also learned about the identification of the project stakeholders. Project stakeholders are any people or groups that are affected by your project’s existence. Stakeholders invested in your project are considered positive stakeholders, while stakeholders who don’t favor your project are considered negative stakeholders. Part of stakeholder identification is to create a stakeholder register with each stakeholder’s contact information, project concerns, interests and threats, and information about how the stakeholder will be involved in the project.

Stakeholder observation is a strategy to help you identify stakeholder needs and requirements and to learn how the stakeholders will use the project’s solution. Recall that passive observation simply records what the observer sees, while active observation allows the observer to interact with the stakeholders during their work.

Chapter Review

Have you ever seen one of those movies with the ace reporter scrambling into the newsroom with just minutes to go before his deadline? He writes a fantastic article on the mayor, the mob boss, or the sports team and submits it with just seconds to spare. Meanwhile, his cigar-chomping boss is ranting about this reporter’s usual skin-of-the-teeth behavior.

That’s how IT project management can be. The really awful part? Sometimes it’s not even that close. Projects are consistently late, over budget, and half-cooked. IT project management is not about implementing a technology. It’s about leadership, integrity, decision-making ability, planning, and time management.

To be a successful project manager, you have to start each project with a clear, concise vision of what the project will yield, when it will end, and how you can lead your team to that destination. Successful projects start with a solid business case, then the project charter, and into planning—all carrying forward the goals and vision of what the project will create and what success looks like for the project completion. Agile projects and predictive projects alike need a clear vision of the business value the project aims to create.

Project management is governed by business cycles, dedication, time, and sometimes weekends. Project management offices direct, support, and consult project managers in their projects. A clearly communicated framework of the project management approach is needed, whether it be agile or predictive, and the stakeholders all must agree to follow the defined structure. Successful project management takes more than implementing the latest whiz-bang technology. To succeed in project management is to succeed in leadership.

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.   What is project management?

A.   The ability to complete a task within a given amount of time

B.   The ability to complete a task with a given budget

C.   The ability to manage a temporary endeavor to create a unique product or service—on time and within budget

D.   The ability to administer a series of chronological tasks within a given amount of time and under budget

2.   All of the following are project management process groups except for which one?

A.   Initiating

B.   Planning

C.   Implementing

D.   Monitoring and controlling

3.   You are a project manager in your organization and would like to present a project to management. What organizational component is most likely to review your project to determine if it is worthy of investment?

A.   Project sponsor

B.   Functional management

C.   Program managers

D.   Portfolio review board

4.   What individual has the authority over all of the project resources?

A.   Project manager

B.   Program manager

C.   Project customer

D.   Project sponsor

5.   What is the purpose of the project charter?

A.   To launch the project team

B.   To identify the project manager

C.   To assign a budget to the project

D.   To authorize a project

6.   You are the project manager for your organization, and management has presented a new project to you. This project requires that you adhere to several government regulations for the project deliverable. In this instance, what are the government regulations considered?

A.   Scope

B.   Requirements

C.   Assumptions

D.   Standards

7.   Marci is a project manager in her organization and she is collecting requirements for a new project. She is working with Frances, an end user, to see how Frances is using the current software that Marci’s project deliverable will replace. Marci asks Frances questions as she works, stops Frances to explore the purpose behind the software activities, and quizzes Frances on each step of the software activity. What is Marci doing in this instance?

A.   Gathering project requirements

B.   Exploring the learning curve

C.   Cross-training

D.   Active observation

8.   You are the project manager for your organization, and you are starting an agile project. Which one of the following statements best describes agile projects?

A.   Agile projects plan the entire project and then work in short iterations.

B.   Agile projects utilize a prioritized product backlog and work in short iterations of planning and execution.

C.   Agile projects follow the logical phases of initiating, planning, executing, monitoring and controlling, and closing.

D.   Agile projects begin with a product backlog, and once all stakeholders approve, no additional changes can be added to the project.

9.   Management has asked that you hire a moderator for a new focus group. What is a focus group?

A.   An interview process for elective team members

B.   An interview process by the team members to determine the success of a project manager

C.   A sampling of users affected by the proposed technology

D.   A sampling of management affected by the proposed technology

10.   Why can a focus group be counterproductive?

A.   The participants may not understand the technology.

B.   The management involved may not like the technology being implemented.

C.   The participants may focus on the problems of the old technology rather than the goals of the project.

D.   Team members may have political agendas against the project manager.

11.   A project manager would like to use an anonymous tool to gain a consensus on the needs of the project. Which tool is the project manager likely to use?

A.   A survey on an intranet site

B.   The Delphi Technique

C.   An e-mail message to all users within the organization

D.   A Monte Carlo simulation

12.   You are working with management to evaluate and understand their goals for a new technical project you’ll be leading. You want to use the SMART approach in your assessment of the project goals. What does SMART mean?

A.   Specific, measurable, achievable, relevant, time-bound

B.   Specific, metrics, action, relevant, time-bound

C.   Schedule, monitoring, action, risk, time-bound

D.   Scope, metrics, action, risk, time-bound

13.   You are working with Sarah on developing a project charter for a new project. All of the following elements should be included in the project charter except for which one?

A.   Key project deliverables

B.   High-level milestones

C.   Stakeholders

D.   Company mission statement

14.   You are working with your project team and management to determine how long the predictive project will take. One of your team members suggests padding all of the activities by 10–20 hours to ensure there’s enough time in case there are problems with the work. You disagree with this idea. Why?

A.   Law of Diminishing Returns

B.   Moore’s Law

C.   Parkinson’s Law

D.   Pareto’s Law

15.   What is the primary difference between projects and operations?

A.   Projects are temporary and operations are ongoing.

B.   Projects are unique, while operations are administrative.

C.   Projects are constrained by time and costs, while operations have budgets.

D.   Projects are paid for by customers, while operations are paid for by management.

Answers

1.   C. Project management is the ability to manage a temporary endeavor to create a unique product or service on time, within budget. Completing a project under budget is nice, but it reflects inaccurate planning of what the budget should have been at the project outset. In addition, the project goal must be met.

2.   C. Implementing is not one of the five project management process groups. The five groups are initiating, planning, executing, monitoring and controlling, and closing. Some project managers remember the order of these groups by thinking about the syrup of ipecac, where each letter represents the order of the process groups (the “cac” means controlling and closing—not quite the same as monitoring and controlling, but similar).

3.   D. Of all the choices presented, the portfolio review board is the best selection. This board consists of upper management and organization decision makers. They’ll evaluate the worth of the project, its return on investment, and other factors to determine if the company should invest in the project or not. This is where “go/no-go decisions” originate.

4.   D. The project sponsor is the person who has control over all of the project resources. This individual must have enough authority to deal with managers and authorize the resources needed on the project. The project manager has authority, to some extent, over the resources once assigned to the project. The project sponsor, not the program manager, has the authority over all resources needed for each project.

5.   D. The purpose of the project charter is to authorize the project. The charter doesn’t select or launch the project team, but authorizes the project manager for the project and authorizes the project to exist within the organization. The project manager is named and identified in the project charter, but the purpose of the charter is to authorize the project.

6.   B. Government regulations are requirements and are never optional. You must always follow government regulations or your organization may face fines and penalties. Standards are optional and don’t necessarily have to be followed by the project manager, while regulations must be followed.

7.   D. Marci is participating in active stakeholder observation. She is working with Frances through the usage of the current software to understand better how the new software can be developed for the end users.

8.   B. Agile projects utilize a prioritized product backlog and work in short iterations of planning and execution. Agile projects do not plan the entire project in its entirety before starting. While agile projects do move through initiating, planning, monitoring and controlling, and closing phases, this isn’t the best definition of an agile project. Agile projects welcome change throughout the project.

9.   C. A focus group is a collection of users your project will affect. A moderator is an impartial person who leads the conversation of the focus group to help gather project requirements.

10.   C. The participants may focus on the problems of the old technology rather than the goals of the project. An improperly organized focus group can result in a gripe session about the old technology and its flaws rather than a discussion of the benefits and goals of the new project. A focus group requires a strong leader to help the participants focus on the future implementation rather than on their complaints with the current technology.

11.   B. The Delphi Technique allows for anonymous input from participants and provides rounds of discussion for consensus building. While the Delphi Technique utilizes a survey approach, it requires anonymous input.

12.   A. SMART is a method to assess project goals; it means that each goal should be specific, measurable, achievable, relevant, and time-bound. All of the other choices are incorrect meanings of the SMART approach to goal assessment.

13.   D. The project charter does not need to include the company’s mission statement. Project charters should include high-level milestones, high-level cost estimates, stakeholder identification, a general project approach, a problem statement, high-level constraints and assumptions, high-level risks, and the project objectives.

14.   C. Parkinson’s Law states that work will expand to fill the amount of time allotted for it. If you pad the project activities, they will likely expand to use all of the time allotted to each activity—something you don’t want when it comes to time estimates.

15.   A. Projects are temporary endeavors, whereas operations are ongoing initiatives. For example, a project could be to design a new software application, but the support of the application in the workforce would be an operational activity.