Chapter 1-6:Organizational Structure Impacts

Organizational Structure Impacts

The structure of your organization has a great impact on many aspects of project management, including the authority of the project manager and the process to assign resources.

Project managers can often become frustrated by what appear to be roadblocks in moving the project forward. It many cases the root issue is the organizational structure and how it operates. You must understand how your project fits within the organization in order to know the correct approach to resolving issues.

Functional Organization

The classic organization structure is the functional organization, as shown in Figure 1.2. In this structure, the staff is organized along departmental lines, such as IT, marketing, sales, network, public relations, customer support, and legal. Each person within a department has a clearly identified superior.

Figure 1.2: The Functional Organization

A project that is approved within a functional organization often has silos of work that are completed independently within each department. These silos may even be managed as separate projects.

The typical characteristics of a functional organization are limited authority for the project manager, part-time rather than full-time project resources, and an issue resolution process that must go up the departmental chain of command and laterally to other departments.

Project managers in functional organizations are often frustrated, because they are held accountable for the results of the project, but they have no means of holding team members accountable for project deliverables. The functional manager controls a team member’s salary, bonus, and job rating. You may see some functional organizations that allow project managers input into team member compensation and rating, but the amount of weight it carries may not always be in proportion to the time spent on the project.

A project manager in a functional organization will benefit greatly from developing a good relationship with the functional managers. These managers can greatly influence the success of the project. Often they are asked to provide more resources to projects than they have available or qualified people. Working with the functional manager to resolve these issues is critical.

Matrix Organization

Another common organizational structure is the matrix organization, which is depicted in Figure 1.3. Matrix organizations typically are organized along departmental lines, like a functional organization, but resources assigned to a project are accountable to the project manager for all work associated with the project.. The project manager is often a peer of the functional staff managers. The project team members have two or more bosses; their functional manager and the project manager(s) they are reporting to.

Figure 1.3: The Matrix Organization

The typical characteristics of a matrix organization are low to moderate authority for the project manager, a mix of full-time and part-time project resources, and better interdepartmental communication. There are both weak and strong matrix organizations: the stronger the matrix, the more authority for the project manager.

Project managers in a matrix organization need to be very clear with both the project team members and their respective functional managers which results the team member is accountable for to the project manager and which are accountable to the functional manager. The team member should only be accountable to one person for a given result to avoid conflicting direction. Another trouble area in a matrix organization is how thin resources may be spread. If you have a resource assigned 50 percent to your project, it should be reflected in the work assigned by the functional manager or other projects to which the team member has been assigned. Addressing resource issues up front will prevent problems down the road.

Projectized Organization

The last type of organization structure we are going to discuss is the projectized organization, which is depicted in Figure 1.4. This organization is far less common in our experience than the other two. In this type of an organization, most of the work is project work, and the company is organized by projects.

Figure 1.4: The Projectized Organization

The typical characteristics of a projectized organization are a high level of authority for the project manager, full-time project resources, and a dedicated project support staff.

Project managers in a projectized organization are responsible for all decisions regarding the project. Team members are usually colocated, which enhances communication and efficiency.

The big drawback of a projectized organization is the how to handle staffing as one project ends. There may not always be a new project waiting for resources. The timing of increasing or decreasing resources can become very complex

Chapter 1-5:Project Life Cycles

Project Life Cycles

Every project has a number of phases to mark the beginning, middle, and end of the project. The project life cycle is the composition of these multiple phases, which can be laid out on a timeline. In an ideal world, all deliverables from one phase would be complete and approved prior to the start of the next phase. In reality, the various phases of a life cycle can overlap. The term for starting one phase prior to the completion of a previous phase is fast tracking. This is normally done to shorten the project schedule.

Project life cycles vary widely between different industries and to some degree even within an organization. Although project life cycles are diverse, you will find several key elements. A project life cycle should depict at the highest level the deliverables for each phase and the category of resources involved. A life cycle should also depict how the project will be folded into the operational business on completion.

Now let’s take a look at some examples of typical life cycles of IT projects.

IT Project Life Cycles

Every IT project has a life cycle and a series of phases. The software development life cycle (SDLC) closely parallels project management process groups with its five phases: planning, analysis, design, implementation, and operation and support. The following is a closer look at each of these phases.

Systems Planning

The systems planning phase begins with a formal request to IT for a system that will solve a problem, or provide an upgrade or improvement to an existing system. The formal request is called a systems request and embodies the problem and business processes that need to be addressed within the given system.

A systems request has two potential outcomes: a preliminary investigation and a feasibility study (depending on the size of the system). The preliminary investigation basically maps to the preliminary requirement-gathering process that you go through when you’re in the Initiation process group of project management. From this preliminary investigation you may derive a feasibility study that denotes the cost-benefits associated with the request as well as recommendations that drill down into the various factors involved, such as operational, time, economic, or technical conditions.

But systems planning goes beyond the notion of “we’ve got a system we’d like for you to build.” It also gets into the idea of how that system fits into the overall corporate scheme of things—does the system enhance the corporate vision and goals?

Additionally (and more subtly), good systems planning may well point back to the need for a change in business processes in order to more closely accommodate the stated desired results. Sometimes automation and technology can’t (or shouldn’t) solve a problem, when a change in the way that a business process is currently being done will do nicely.

Systems Analysis

You’ve solidified a feasible system request and you’re planning on going forward. The systems analysis segment is the next logical step in your progression. In this phase you develop a logical model of the system by diagramming the logical flows of the data. You’ll map out what the requirements are for the new system.

Note

Some good system analysis techniques (but beyond the scope of this book) include data flow diagrams (DFDs) and use case scenarios and entity relationship diagrams (ERDs) that illustrate the various inflows and outflows of the system, in addition to the anticipated way that people will interact with it.

If you understand the goals of the business manager that is requesting the system and you couple that with the logical flows that you derive for the system by going through a business process analysis, you can make your job much easier in diagramming, at a high level, how the proposed new system will operate. A visual representation of the basic business flows will also help others understand how the system parts interoperate and help nontechnical people understand how you think about their business process.

In the analysis phase you begin to knock out what it is—the nuts and bolts—that this system consists of. Through your previous analysis process, including interviewing various stakeholders, performing fact-finding analysis, and formulating solid objective ideas about what the system should be comprised of and what it should do, you can build various enterprise models that include the data objects themselves. You also can understand the various process and data models that are involved. Also, fleshing out a prototype at this point will prove to be a worthwhile effort because prototypes give stakeholders a way to visualize the new system.

The systems planning and analysis phases roughly correlate to the Initiation and Planning process groups, which we’ll discuss in more detail in Chapter 2.

The final outcome of the systems analysis phase is called a systems requirements document. The document spells out what you heard the business representatives say that they wanted in the new system. You got here by going through a variety of processes including interviewing various experts in the business process, sitting with them to watch how they go about their work, questioning the manager, and other such methods. The document is about the business for the business. Like a da Vinci charcoal drawing intending to help the artist understand what it was he was going to paint, the business requirements doc will help you derive your new system.

Systems Design

In the systems design phase you denote all the components that will be included in your IT project, including all of the inputs (such as data flowing into the system or keyboard input by a data-entry clerk), outputs (such as screen displays or reports), and processes involved. Additionally, at design time you flesh out the various controls required, whether automated or manual, that will contribute to the system’s successful operation. If you’re working on a project in which code has to be written, you’ll draw out the architecture that the application(s) will use in a document, called the system design specification (SDS), a detailed document that allows the project team members to exactly build the desired system. The SDS illustrates exactly how programmers are to create the system.

If the system doesn’t require software development, but does require database or infrastructure creation or enhancement, it’s key that all stakeholders, from management to end users, understand what you’ve designed and how you imagine it will work, and that technicians be able to build the desired system. If you’re using a Commercial Off The Shelf (COTS) program, you’ll design its integration into the system that you’re building.

Note too that other elements such as infrastructure additions or renovations, cabling upgrades, WAN connectivity (including wireless), new types of computing such as PDAs, telephony integration, and a host of other things may be included in the design of your system. Just because your system primarily uses software does not mean that the underlying components don’t need to be addressed and freshened as well.

Systems Implementation

In the systems implementation phase of the IT project life cycle, the system is constructed. Whether that means that programmers write programs, you purchase COTS programs, or you come up with some in-between system that uses elements from both worlds, you’ll want to deliver a completely functional and fully documented system.

This phase includes such elements as the conversion of old data to new tables, training the users, testing, and migrating to the new system. You’ll also prepare a write-up called the systems evaluation to provide an earmark as to how well the system performs relative to your stipulations in the system design specification.

Systems Operation and Support

Mapping somewhat to the Closing process group, which we’ll discuss in just a moment, the systems operation and support phase means that you put the system into routine operation, and provide a method whereby the system can be supported if there is trouble. However, the operation and support phase goes beyond Closing in that it calls for elements such as change management where you have maintenance or enhancements that need to be performed and you provide for some modicum of scalability in the system, should it need to be added to later.

You need to know two other things as a manager of projects in the IT project life cycle: setting milestones and checkpoints. Let’s discuss this further.

Project Concept Documentation

Let us mention here another type of document that you might want to consider when you’re meshing two management methodologies together (i.e., project management and the SDLC): the Project Concept Document. At initial requirements-gathering time, the systems analyst will generate a document that contains the high-level requirements she discovered upon examining the customer request. This document could act as a starting point in the project planning process as well. A systems analyst may not be a project manager, or may be—it depends on the way your company is laid out and the complexity of the project before you. But we know that good quality systems analysis and design leads to high-efficiency systems, especially when built under a well-developed project management paradigm. A starting-point document for both players—the project concept document—is an ideal way to flesh out the skeleton of the project and get the two parties talking.

Note that the systems analyst will go on to develop some very elaborate flows out of her initial requirements—the project manager must be in lockstep with the elements being worked out.

IT Project Milestones and Checkpoints

Any good SDLC process should include the milestones on which you see the project pivoting. For example, perhaps a significant milestone for an e-commerce project would be the purchase, acquisition, installation, configuration, and deployment of the web servers that will be used for the system. A very discreet set of tasks are needed in order to accomplish this milestone. At its accomplishment, in the systems design world, we’d step back and ask project stakeholders such as the managers and technicians to give us a go/no-go decision regarding whether the project should move forward.

Additionally, in between milestones, good projects include several checkpoints along the way that reveal whether we’re on time and within budget in our project. A prudent number of checkpoints (not too many to be burdensome) can reveal the pulse of the project at any given point.

Chapter 1-4:Project Processes

As we discussed earlier, PMI defines project management as a series of processes that are executed to apply knowledge, skills, tools, and techniques to project activities to meet project requirements. These processes have been organized into five groups.

The process groups are tightly linked, as the outputs from one group are the inputs to another group. Figure 1.1 shows the links between the groups. The process groups may overlap. You may begin planning the project before all of the initiation activities are complete.

Figure 1.1: PMI Process Groups

As we discuss each group, notice the correlation between the process groups and the domains covered in the CompTIA IT Project+ exam. The process groups are the foundation of project management. You need to understand each group and how it contributes to the completion of the project.

Initiation Processes

Initiation processes include all of the activities that lead up to the authorization to start the project. These activities include such items as business need identification, high-level requirement definition, and cost justification. Because the Initiation process is an integral part of Domain 1.0 on the IT Project+ objective blueprint, we will take a more detailed look at the initiation process in Chapter 2, “Project Initiation.”

Planning Processes

Planning processes are where the project goals and objectives are refined and broken down into manageable pieces of work. Project managers create time and cost estimates, and determine resource requirements for each activity.

Several other critical areas of managing a project require up-front planning. These areas include communication, risk, quality, and procurement.

Note

The Planning process group, which is included in both Domains 1.0 and 2.0 of the exam, is undoubtedly one of the most critical stages of managing a project. For that reason Planning will be covered in detail in Chapters 3–7.

Executing Processes

Executing processes are where the work to complete the project is done. The project manager must coordinate all the project team members as well as other resources assigned to the project.

Executing processes include the actual execution of the project plan, team development, quality assurance, and information distribution. We will examine this more closely in Chapter 8, “Project Execution.”

Controlling Processes

Controlling processes are the activities that monitor the progress of the project to identify any variances from the project plan. Requests for changes to the project scope are included in this process. This area is also where any corrective action will be taken.

Other areas of the Controlling process group are cost control, quality control, performance reporting, and risk control. In Chapter 9, we will spend considerable time discussing the various methods for monitoring progress, specifically change control and quality control.

Closing Processes

The closing processes drive the formal acceptance of the project work and provide a means to fold the product into the ongoing organization structure.

Closing processes include sign-off, archive of project documents, turn over to a maintenance group, release of project team members, and review of lessons learned. Although some of these activities may seem fairly straightforward, several areas deserve close attention. Chapter 10, “Project Closure,” will explore the last stages of an IT project and how they can differ from other projects.

Chapter 1-3:General Management Skills

General Management Skills

Project managers possess many skill sets that are unique to running a project. Successful project managers also possess general management skills, sometimes referred to as soft skills. These are skills that any good manager uses on a daily basis to manage resources and meet goals. You probably already use some of these skills in your day-to-day work activities. General management encompasses many skill areas including:

• Leadership

• Oral communication

• Written communication

• Listening

• Organization

• Time management

• Planning

• Problem solving

• Consensus building

• Conflict resolution

• Negotiation

• Team building

A project manager looks at the big picture and interacts with a broad spectrum of stakeholders. Good management skills are as critical to the success of a project as the correct technical skills.

In the following sections, we are going to take a look at a few key general management skills and how they apply to project management. We will also examine how these fundamental skills translate into your industry.

Leadership

A project manager needs to be a good leader. A project team comes together for the life of the project, which can sometimes only be a few months. Team members will have very different skill sets and project experience. IT projects commonly have both technical team members and representatives from other areas, such as marketing, sales, customer service, or training. Team members may not have worked together in the past. To add even more complexity, team members may roll on and off the project at different times.

The project manager is accountable for sharing the strategic vision that created the project and providing overall direction to the team members. A good project manager knows how to align and motivate diverse people with varying backgrounds and experience.

Communication

Successful project managers will tell you that they spent a great deal of time communicating. Even the most detailed project schedule can fail without proper communication.

Project managers must develop a communication strategy that includes the following critical components:

• WHAT you want to communicate

• AUDIENCE to receive the communication

• MEDIUM used for communication

• MONITOR outcome of communication

Keeping these components in mind and developing a comprehensive communication plan up front will prevent misunderstanding and conflict as the project progresses.

Problem Solving

Projects always have problems. Some are just more serious than others. Project managers must use problem-solving techniques throughout the life of the project.

Real World Scenario—Negotiating with the Business Unit

You’re working on a software development project for a business unit in your company. You’ve gotten past the initial project request steps and you’re now in the process of honing in on the details of the requirements for the project.

You require subject matter expertise from the business unit in order to more fully understand and appreciate the business processes that your software is going to automate.

You set up a meeting with the director of the business unit. At the meeting you ask her two things. First, you want to know if you can use someone from the business unit to assist you in understanding the business process flows. You make it clear that the assigned individual must be an SME in the business process. Second, you ask if you can have this individual full-time for a minimum of two weeks. You suggest the name of someone whom you think will perform very adequately as a business SME.

The director is shocked that you require so much time from one of her people. She asks you to more thoroughly explain your need. You explain to her that in order for you to develop software that fully meets the business need, you must understand the flows that are involved in the business process. Further, you describe the process of generating a data flow diagram (DFD), a block diagram that shows, at a very high nontechnical level, the process as you see it, noting that you’ll need the SME to validate the DFD.

After some bantering back and forth, the two of you come to an agreement that you can have a week and a half of someone’s time and that you’ll use not one but two different business SMEs, splitting their efforts accordingly so that neither one has to fully dedicate their time to the business flow discovery process. The director stresses repeatedly to you that her people are so busy, she is being very generous in letting you have them at all.

You agree to the specifications, thank her for her time, and get to work figuring out the best questions to ask the SMEs in order to complete the business flow discovery process in as efficient and timely a manner as possible.

The key to problem solving is to recognize that a potential problem exists. Early recognition of warning signs will simplify the process. Pay close attention not only to your project team’s formal progress reports, but also to what team members say and do.

If you do identify a potential problem area, take the time to clearly identify the problem. A vaguely stated problem may drive the wrong solution.

Once a problem is clearly and concisely identified, the project manager works with the appropriate project team members to brainstorm alternatives. These alternatives can now be evaluated and a solution chosen. A project manager monitors the implementation of the solution to ensure that the problem is resolved.

Negotiation

A project manager is involved in negotiating throughout the life of the project. Negotiation is the process of obtaining mutually acceptable agreements with individuals or groups.

Depending on the type of organizational structure, you may start the project by negotiating with functional managers regarding assignment of resources. Project team members may negotiate specific job assignments. Project stakeholders may change the project objectives, which drives negotiations regarding the schedule, the budget, or both. As you execute the project, change requests often involve complex negotiations, as various organizations propose conflicting requests.

If your project includes deliverables from an outside vendor, you will be involved in negotiating a contract. This area is specialized and may involve representatives from a legal or procurement department.

Organization and Time Management

A project manager oversees all aspects of the work involved to meet the project goals. The ongoing responsibilities of a typical project manager include tracking schedule and budget updates, conducting regular team meetings, reviewing team member reports, tracking vendor progress, communicating with stakeholders, meeting individually with team members, preparing formal presentations, and managing change requests.

Meetings consume valuable project time. Effective meetings do not just happen; they result from good planning. Whether you conduct a formal team meeting or an individual session, you should define the purpose of the meeting and develop an agenda of the topics to be discussed or covered. Time allocation for each item is critical to keep a meeting within the allotted time.

Clear documentation is critical to project success, and it must be available for immediate use. Without an efficient system for maintaining documentation, a project manager will waste precious time searching for the latest version of the schedule.

An excellent way to learn organization and time management techniques is to spend time with an experienced project manager willing to act as a mentor

Chapter 1-۲:Defining Project Management

Defining Project Management

You are now equipped to identify a project and have a better idea of what types of IT projects you will be managing. But what exactly is project management? You may have already heard a lot of different answers to that question. To eliminate any confusion, we define project management and associated terms according to the standards set by the Project Management Institute (PMI) . PMI is the leading professional project management association, with over 100,000 members in over 125 countries worldwide. PMI is a leader in the development of project management standards, which are listed in what is called the Guide to the PMBOK .

The Guide to the PMBOK

Project management ’s standards are documented in A Guide to the Project Management Body of Knowledge ( Guide to the PMBOK) . PMI also manages a very rigorous certification program, the Project Management Professional (PMP) certification. The Guide to the PMBOK is the basis for the exam portion of the PMP certification. If you continue in a career in project management, you may move on to the PMP certification. The material you have studied to prepare for the IT Project+ exam is an excellent foundation on which to build your project management knowledge. PMI members were involved in the revision of the IT Project+ exam, and the questions on the exam are consistent with the Guide to the PMBOK standards.

The Guide to the PMBOK defines project management as “the application of knowledge, skills, tools, and techniques to project activities to meet project requirements.”

The project manager (PM) is the person who oversees all of the work identified to complete the project and applies a variety of tools and techniques. Successfully managing a project involves dealing with competing needs for your resources, obtaining adequate budget dollars, identifying risks, managing to the project requirements, interacting with stakeholders, staying on schedule, and ensuring a quality product. Sounds a little overwhelming at times, doesn’t it? Guide to the PMBOK categorizes each of these into nine knowledge areas. Let look at these in more detail.

Later in this chapter we will look at the five process groups that cover these knowledge areas.

Project Management Knowledge Areas

Successful project management is dependent on the use of key processes. These processes must cover the core knowledge areas critical to project management. The Guide to the PMBOK defines the nine Project Management Knowledge Areas as:

• Scope Management

• Time Management

• Cost Management

• Quality Management

• Human Resources Management

• Communications Management

• Risk Management

• Procurement Management

• Integration Management

As you move through subsequent chapters, we will cover these items in more detail. These areas make up the total realm of project management, and Guide to the PMBOK threads each of these knowledge areas into a series of process groups, which will be discussed later in this chapter. These knowledge areas may not have equal importance in your specific IT job area. For example, if you do not have outside contracts for your project, Procurement Management may not apply. The IT Project+ exam has a strong focus on the knowledge areas that are part of the planning processes and the project execution processes.

Chapter 1: ITProject Management Overview

Defining a Project

What makes a new assignment a project? How do you know if you are working on a project? What distinguishes a project from an ongoing operational activity? Both new project managers and team members frequently ask these questions. Projects involve a team of people, but so does day-to-day business. Projects and ongoing operations often fight for the same limited resources. They both involve following a plan or a process with consequences for actions taken. So what is so special about a project?

A project is a temporary work effort that delivers an exclusive product or service. A project always has a designated start and finish—thus it is temporary. A project has clearly defined and measurable goals, which are used to determine project completion and success. A project brings about a unique product or service—something that has not existed in the organization heretofore.

Tip

The word “service” is tricky in this definition because, obviously, there is a difference between ongoing service (operations) and a one-time or specified period of time service (project). Providing janitorial services on contract is operations; providing contract JAVA coders for 18 months to work on an IT project (providing programming services) is a project .

Another project management term you may have heard is program. A program is a grouping of related projects, that are managed together in some sort of harmonized fashion. Programs are often used in the defense industry or large government contracts. From an IT perspective, a large customer support application can be set up as a program, with separate projects representing billing, sales, and repair.

Let’s take a closer look at the criteria that defines a project.

A project is typically undertaken to meet a specific business objective.  It involves doing something new, which means that the end result should be a unique product or service. These products may be marketed to external clients, or they may be used internally.

A project is always temporary. In addition to a unique end result, it has a defined start and a defined finish.  Projects can vary in length from a few weeks to several years, depending on the complexity of the product, but they are not an ongoing set of daily activities.

A project must begin with a clear goal and stakeholders.  A project starts when the goal is clearly defined and the appropriate stakeholders have provided approval. A project ends when those goals have been met. A project can also end by being canceled if it is determined that the goal can no longer be met.

With this information under our belts, let’s take a look at some IT scenarios to determine whether they are projects or an ongoing operations.

Defining an IT Project

The activities associated with an IT project cross the entire genre of things typically categorized as projects, whether large or small. The reason is in almost every project, some component of IT must be included in the project plan.

For example, if you were building a submarine, you’d need to provide a datacenter, servers, infrastructure wiring, and many other IT elements associated with the project. If your project was to create a manufacturing facility, again, you would need to consider how computers and IT fall into such an effort.

Setting up a vineyard and winery? Again, the scientific basis behind today’s wineries is completely enveloped in the things that IT can offer—any great winery would also have a great facility for ascertaining when those grapes are precisely ready for the crush.

You would probably agree that you could come up with very few projects that do not in some way involve aspects of IT.

So What Is an IT Project?

While an IT project can and should closely follow the regimen of the project management guidelines PMI set, how closely you follow that regimen, of course, depends on the complexity of the project before you. All of the characteristics of any well-managed project, no matter how large or small, are embodied within the Guide to the PMBOK . The size and complexity of the project will dictate the level of detail that you go to in order to bring about the project’s deliverables.

Let’s take a minute to discuss some of the different IT projects you may find before you.

Software Development

When working on a software development project, not only must you follow high-quality project management techniques, but also be conscious of the software development methodology that you use. You will learn the project phases specific to software development later in this chapter.

Infrastructure—Old or New

When we say infrastructure , generally we’re talking about the cabling, wide area network (WAN) connectivity, and routing/switching plant. In many cases the infrastructure also includes the telephone wiring and switching infrastructure as well.

You might, for example, be moving into a new building with virtually no infrastructure— your project is to come up with the design and deployment of that infrastructure. Or, you may have projects in which you rewire the building, upgrade the switches and routers, or upgrade the WAN connectivity you have between sites. All of these kinds of projects involve the infrastructure.

The primary room where most of the cabling terminates, typically called the datacenter (see the following), is usually referred to as the Main Data Facility (MDF) . Wiring then flows from the MDF to switchgear and routers in other closets within your campus or building. These other closets are called Intermediate Data Facilities (IDF) . A building may have many IDF closets spread throughout but generally speaking there is only one MDF per building.

Datacenter Creation/Improvements

The datacenter is the place where the servers, mid-range computers, mainframes, large tapebackup devices, and telephony equipment such as Post Branch Exchanges (PBXs — telephone switchgear) live. The WAN connections coming into a building, be they T1 Frame Relay, Asynchronous Transfer Mode (ATM — a WAN protocol), Integrated Services Digital Networks (ISDN — a telecommunications protocol), or other are demarcated at the datacenter (MDF) location. As a general rule, the datacenter and demarcation location (or “demark”) are usually one and the same, though some companies may have a demark at a different spot in the building than the datacenter. In any event, you should think about a datacenter as the place where the hub of your computing business gets done.

Datacenters include elements such as a raised floor (for air-conditioning airflow under the servers as opposed to above), commercial quality power- and air-conditioning units, security systems for secure entry into the datacenter, uninterruptible power supplies (UPS), and often a power generator in the event that the power fails to the datacenter.

A datacenter project might involve installing a datacenter in a new building, replacing old power- or air-conditioning equipment, adding server racks to accommodate new servers, or upgrading the power distribution units (PDUs) that provide breakers and power for different systems. Note that a datacenter project isn’t necessarily about servers—it’s about the place where you’re keeping the servers.

Server/System Deployment

With the exception of regular file servers, which store user files, you will seldom deploy servers without planning on some sort of system for running on them. For example, you might have a large database system that you need to deploy. Or you might have a Commercial Off The Shelf (COTS) program that your company purchased to fulfill a business requirement and it needs a place to run. Or, you might have a combination of some code that your company’s software development shop wrote, coupled with a database and other systems in the enterprise. A deployment that relies on the components of several disparate systems is called an integrated system and requires careful dexterity on the part of the project manager so that all the parts work together harmoniously.

It’s not unreasonable to expect that your telephony systems might need to interact with a server system. For example, perhaps you have a project to install some call-routing software that handles call-center traffic, making sure that customer calls are answered as quickly as possible.

Generally speaking, most system deployments are going to require, at a minimum, server(s), the network operating system (NOS) to run on them, any required software applications, network connections, and testing. A system may be deployed across several campuses, greatly increasing the complexity and requirements of the project.

Storage Area Network (SAN)

Another unique IT project is the installation of a Storage Area Network (SAN) . This installation is specialized and may involve fiber-channel switches, fiber-optic cabling, big SAN arrays, WAN connectivity, and so forth. To set up a moderately sized SAN you’re facing a fairly complex project that’s going to consume several months of your project team’s time. A big SAN installation is one in which you’re very likely to require contract assistance from the manufacturer for deployment.

Enterprise Resource Planning (ERP)

The largest and most complex of IT projects centers on the installation of Enterprise Resource Planning (ERP) software such as that offered by SAP, Siebel, PeopleSoft, Oracle, Great Plains, Lawson, or other ERP manufacturers. ERP software is designed to handle most of an enterprise’s business computing needs from human resources to accounting and payroll and even manufacturing. As a result, the systems can be complex and esoteric in nature, requiring significant contract expertise to deploy.

ERP rollouts generally require massive server power, coupled with large-scale enterprise databases such as Oracle or Microsoft SQL Server. Additionally, because an ERP rollout can create diversity of roles—including the implementation of a portal—no one individual can know it all about the deployment. Many different business functions must be involved, requiring the participation of several different managers and stakeholders, encompassing the notion of matrix management of a project.

Note

When we talk about matrix management—the notion that you’re deriving workers from various departments and thus you and their supervisor must jointly manage their time—you should keep in mind that an ERP rollout probably represents most fully the notion of matrix management within the realm of IT projects.

Automated Systems

Some systems can be migrated from a manual process to a more automated approach. Think of an assembly line where cars are built. In the early days of automobile production, people assembled cars by hand. Today, robots do much of the welding and assembly of the components of the cars.

The same is true of many systems within industry; electronic pharmaceutical delivery systems count pills and put them in bottles, freeing pharmacists to do other things, for example. An IT project in which you’re going to replace a formerly manual process with an automated one will require robust understanding of the business function that you’re augmenting and may include plenty of training.

IT Project Considerations

IT projects rely on expertise, process, and communication in order to be successful. For all IT projects you put together the necessary hardware and software components, utilizing expertise in each area in order to make things work. Think about a building engineer responsible for managing a project to erect a high-rise building. The engineer doesn’t necessarily have to understand how the hundreds of sinks and toilets in the building operate, but the engineer must understand that they are connected to a big piping system. So it is with your IT project—you may not understand absolutely every nuance of the system you’re putting together, but you’re far better off if you can put in context how all the pieces interoperate.

The key to understanding IT projects is to think about the process of getting from point A to point B and the highway that got you there. How does, for example, an Internet user navigate a screen that in turn communicates with a database? By moving through servers and security processes over cabling, routing, and switching components. All of these elements, whether germane to your particular project or not, are part of the end-to-end process that you must consider.

Finally, it’s important that IT project teams are highly communicative. You can’t afford to have a rogue programmer miscommunicate the way that he or she designed the system, for example. When you have live business personnel testing it (called a pilot test ), you don’t want to run into any programming surprises.

Common Job Roles for the IT Project Manager

IT project managers have a difficult job. They must fit into a variety of molds in order to fully comprehend the project and to bring it in on time and under budget. Following are some of the hats that an IT project manager wears:

Project manager (PM)  As the project manager (PM) it is your primary responsibility to formulate the project team, develop and assign tasks, and manage the project in such a way that the deliverables are built and deployed on time, with the required quality, and within budget.

Business analyst (BA)  While the business unit may donate a Subject Matter Expert (SME) or two to help you flesh out the project’s requirements, as the business analyst (BA) you must have some understanding of what the business entity does. You must have a robust comprehension of the various departments in your company, the job functions of each department, the constraints and obstacles that for each job, the type of people who work in the business unit, how they’re managed, and the impact that they have on meeting corporate objectives. You must, in essence, be a corporate department SME of sorts, well able to describe all of the departments (at least the major ones) in your organization.

Systems analyst (SA)  In larger projects, the systems analyst (SA) function may well wind up being handled by another person, but you still must have a solid grasp of systems analysis and design techniques (see sidebar “Understanding SDLC, Systems Analysis, and Business Processes”). In smaller projects, the SA is also the BA.

Negotiator  Not only do you have to negotiate with business unit heads, you must also negotiate with contractors, vendors, and other business unit managers who need to supply you with elements that you require.

Budget analyst  As a budget analyst , you also have to keep track of the project’s budget. Generally you’re given a specific pot of money with which to accomplish your goals and you will have some heavy explaining to do if you go over budget.

Legal analyst  IT PMs must also understand the legal, ethical, and regulatory ramifications of their projects. This subject has become much more important since the advent of Sarbanes-Oxley document retention mandates, among others.

Technologist  IT PMs, while not necessarily heavily technological, must have a modicum of understanding of most things having to do with IT. You can’t be in the middle of a meeting with the network manager, for example, and not know the difference between a switch and a router. All the network manager will have to do is step up to a whiteboard and draw a few diagrams and you’ll be completely snowed! It’s key that you familiarize yourself with all elements of IT related to your project, at least at a conversational level. This is a large thing to say and we’re certainly not mandating that you be an expert in all things IT—it’s not possible even if you’re in IT—but you should be clear in your communications when you’re confronted with a term or concept you don’t understand to try to gain some clarity on the subject.

Visionary and strategist  This function is tightly coupled with technologist. You have to read up on the latest trends in IT. For example, you may not want to recommend a fat client/server system when browser-based technologies are all the rage and your new system would benefit from a thin client. That being said, you also don’t want to put your project out on the “bleeding edge” utilizing unproven new technology.

Communicator  The most important job of all is to be a precise and thorough communicator. You’ll translate statements from one group to another. You’ll keep people abreast of the project’s status. You’ll be in front of important people telling them what the project is about— seeking their buy in. You’ll communicate with vendors and contractors. You’ll have regular meetings with your project team. You must have highly developed oral and written communications skills, the most important of which is listening .

Time manager  IT PMs must keep their finger on the pulse of all of the project’s activities and when there is a task slow-down, find out why. The PM has the clock running against him or her.

Team builder  The IT PM must able to manage a highly diversified team of people with significantly different skill sets in order to achieve the project goals. You’ll have project teams that have programmers, networking professionals, server administrators, security analysts, web page designers, and a potential host of other technological folks on your team. Getting these people to relate to one another and to work as a well-oiled team can be very challenging.

Clearly, the IT PM has a broad role, one that is crucial and sometimes unpopular. It’s vital that IT PMs understand the “20-60-20” rule of management. Twenty percent of the people are going to dislike you no matter what you do or don’t do. Sixty percent are neutral about you and have no opinion one way or the other. The remaining 20 percent think you’re the greatest thing since sliced bread and would swim across the ocean for you. As an IT PM you’re going to hear a wide variety of opinions, dissension, arguments, persuasion, and other kinds of communication. Some of the decisions you make and things you do will not be popular, at least with one or another group of people. But you can’t live in the popularity contest world. You have to operate within the context of producing the finest-quality deliverables possible within the budget and time constraints you’ve been given.

Understanding SDLC, Systems Analysis, and Business Processes

While the IT Project+ test doesn’t test you on your knowledge of the software development life cycle (SDLC) , when you’re working with software development teams you’re going to have to make sure that you have a solid understanding of it. It’ll be of great benefit to you to understand how SDLC maps to the PMI process groups so that you manage your project according to solid project management standards, while being able to recognize what SDLC phase your software development is in at any given time. The two do not precisely correlate, but they are similar enough that you’ll be able to precisely manage your project and keep your coders happy at the same time.

We strongly suggest that you consider taking a course in systems analysis and design so that you fully augment your understanding of project management with the essential design elements of a technological system. In a systems analysis and design class you’ll learn how Data Flow Diagrams (DFDs) , context diagrams, Entity Relationship Diagrams (ERDs), and other outputs will assist you in rapidly deploying a fully functional, robust system that meets your customer’s needs.

It’s also important to note that in the initial business request and requirement-gathering phases of your project, you do not try to apply any given technology as a solution to the request. Instead, your focus should be on the business process . If you understand the order of flows that users go through to accomplish their tasks, you’ll find that the technology will logically evolve. If you’re heavily technological, you might have a tendency to think in terms of how a given software or hardware solution from a well-known company will meet the business need. But you should reverse that and first think of the business need, then try to apply various technological alternatives to the process that you’ve discovered.

Finally, by paying attention to the business process first, you may find areas where the process can be changed in some way to simplify it, or reduce the complexity of the technologies you’re going to introduce. This is called business process re-engineering (BPR) and is often the first thing a systems analyst will recommend prior to applying any technology.

While developers know about and understand the SDLC, they don’t get it when it comes to project management. So, the trick is to translate where you are in the SDLC into the PMI process groups so that you can manage the project utilizing consistent methodologies that have been highly refined and are well understood.

Communication among the Various IT Job Roles

As an IT PM, you’ll deal with a wide variety of people. When speaking with executives, you’ll have to relate to them on their level so you put on your negotiator or your “businessperson” hat, in order to get your point across. Likewise, when you talk to a software developer, you will rely on your technical skills.With the executive, you probably won’t use heavily technical language or computer acronyms. With the software developer, he or she probably won’t have much tolerance for listening to budget dialog. The point is that you put on the appropriate hat for the person that you’re dealing with. So the IT PM must get into the habit of being able to switch communication hats very quickly in order to accurately convey the message.

Try to make your language as clear as possible for the person you’re dealing with. Avoid acronyms unless they’re likely to be well-understood by the person or group you’re talking to.

Note

The IT Project+ exam doesn’t actually test you directly on these elements, but you’ll find a certain indirect flavor in the questions regarding the different hats that the IT PM wears. When a question tells you, for example, that you are speaking with the project sponsor, think about that individual differently than you would a technical team member and see if it doesn’t make a difference in the answer you’d give.

جامعه اطلاعاتی2 (تعریف)

به طور تحلیلی پنج تعریف از جامعه اطلاعاتی قابل تشخیص است.این تعاریف عبارتند از:فناورانه، اقتصادی، شغلی، فضایی، فرهنگی
فناورانه:
عمومی ترین تعریف از جامعهءاطلاعاتی، بر نو آوری چشمگیر فناوری تأکید می کند. تصور کلیدی این است که موفقیت علمی در پردازش، ذخیره و انتقال اطلاعات، کاربرد فناوری های اطلاعاتی را تقریباً به تمام گوشه و کنار جامعه گسترش داده است. در این تعریف کاهش شگفت آور قیمت کامپیوتر، افزایش عظیم قدرت آن ها و غلبه کاربرد آنها در هر کجا مورد توجه است.
شکل های پیچیده تر این جادهء فناورانهءمنتهی به جامعهء اطلاعاتی، تا حدی به یکپارچگی و در کنار هم قرار گرفتن حوزهء مخابرات و کامپیوتر توجه می کنند.شبکهء اطلاعات در هر کجا که نیاز به اطلاعات باشد آن را در اختیار می گذارد. این، البته فرایندی تکاملی است اما با تقویت ) I.S.D.Nشبکهء خدمات یکپارچهء رقمی) عناصر بنیادی نوعی جامعهء اطلاعاتی در اختیار ما قرار می گیرد.
I.S.D.N زیر ساخت پشتیبان جامعهء اطلاعاتی را تأمین خواهد کرد.
بدون شک، این تعریف فناورانه از جامعهء اطلاعاتی است. خواه این تعریفی باشد با این پیش بینی که جامعهء اطلاعاتی حاصل تأثیر چشمگیر نوآوری های فناورانه است یا آن را هم چون نتیجهء افزایش نظام های I.S.D.N تلقی کند، هر دو فناوری را ویژگی ممتاز اصلی در نظام جدید می دانند.
اقتصادی:
در اویل دههء 60، پیتر درا کر اعلام کرد: همچنان که از اقتصادی مبتنی بر کالا به اقتصاد دانش حرکت کرده ایم، دانش پایه و اساس اقتصاد مدرن شده است.
امروزه این بحثی رایج است که ما در جامعه ای متحول به سر می بریم با این ویژگی متمایز که دانش و سازمان، تولید کنندگان عمدهء ثروت هستند.
مارک یورات گزارشی نه جلدی از پیدایش اقتصاد اطلاعاتی ارائه داده است.
مک لاپ تعاریف گسترده ای از تولید دانش عنوان کرده که این تعاریف شامل آن صنایعی که با این اطلاعات مرتبطند، می باشد.
شغلی:
هنگامی که کار اطلاعاتی در میان حرفه ها تفوق یافت، ما به جامعهء اطلاعاتی دست یافته ایم. یعنی هنگامی که کارمندان، معلمان، حقوق دانان و نمایشگران از حیث عددی بر معدنچیان، فلزکاران وکارگران تفوق یابند جامعهء اطلاعاتی فرا رسیده است.
فضایی:
در این مفهوم نقش اصلی بر رروی شبکه های اطلاعاتی است که مکان هارا به هم متصل می کنند وتأثیرات چشمگیری بر برنامه ریزی های زمانی و مکانی دارد.
« جان گودار» چهار عنصر مرتبط به هم را درگذار به جامعهء اطلاعاتی شناسایی می کند:
1ـ اطلاعات در مقام « منبع کلیدی استراتژیک» در حال تصاحب موقعیتی مرکزی است که سازمان اقتصاد جهان به آن وابسته است و در نهایت موجب گسترش سریع حرفه های اطلاعاتی می شود.
2 ـ فناوری های کامپیوتر یو ارتباطی زیر ساختی را ایجاد کرده اند که قادر است اطلاعات را پردازش و توزیع کنند. این فناورری ها این امکان را به وجود آورده اند که اطلاعات به مقیاسی بی سابقه از نظر تاریخی مدیریت شود. یعنی تسهیل تجاری فوری وآنی و نظارت بر امور اقتصادی، اجتماعی وسیاسی در سطح جهان
3ـبا استفاده از رشد سریع و استثنایی بخش اطلاعاتی قابل دادو ستد رشد خدماتی مانند رسانه های جدید و پایکاه های پیوسته بزرگ تر می شود.
4 ـ رشد اطلاعاتی شدن اقتصاد، یکپارچگی اقتصاد های ملی ومحلی را تسهیل می کند.
چرخش اطلاع در بزرگراه های اطلاعاتی صورت می گیرد و هیچکس قادر نیست تعیین کند چه مقدار اطلاعات و با چه سرعتی باید در این راه ها جریان پیدا کند تا جامعه ای اطلاعاتی را بسازند.
فرهنگی:
ما در جامعه ای انباشته از رسانه زندگی می کنیمو فرهنگ معاصر به شکلی چشمگیر بیش از فرهنگ های قبل از خود انباشتگی سنگینی از اطلاعات دارد.ما در محیطی اشباع شده از رسانه ها زندگی می کنیم که نشانهء آن است که زندگی اساساً دربارهء نماد سازی، درباره ء مبادله و دریافت پیام هایی درباره ء خود و دیگران است. در تأیید این انفجار رسانه هاست که بسیاری از نویسندگان می پندارند که ما وارد جامعهء اطلاعاتی شده ایم.
منبع: نظریه های جامعهء اطلاعاتی
نویسنده: فرانک وبستر
ترجمه: مهدی داودی
چکیده ء کتاب جامعه اطلاعاتی


گرد آورنده: محیا برکت

عصر ارتباطات و فناوری اطلاعات(2)

از دیر باز اطلاعات نقش بسزایی در زندگی بشر داشته است، تا آنجاکه اعدادو ارقام وبعد از آن نظام شمارش از اولین دستاوردهای بشر می باشد.اما جهت استفاده از این سال ها و بلکه قرن ها به طول انجامید تا ابزار های جدید ایجاد شده اند.از اینکه جهان در عصر اطلاعات قرار گرفته است آگاهی کافی داریم و می دانیم هر کس در دریایی از اطلاعات غرق شده است که تمام توان بهره گیری از آن راندارد.اما شاید تعداد کمی از ما بپدیریم که وارد دوره ی تازه ای شدهایم که عصر دانش است و این عصر گرچه جدید است ولی حجم دانش آن آنقدر زیاد است که استفاده تام وتمام از آن از عهده ما خارج است.
شاید بتوانیم فناوری اطلاعات را استفاده از دانش علمی برای تعیین روش های انجام امور به شیوه تکرار شونده تعریف نماییم. و این انقلاب را یک رویداد تاریخی عمده که الوی یک گسستگی را در بنیان های اقتصادی، فرهنگی وسیاسی جامعه القا می کند می دانیم. آنچه که از تاریخ بر می آید دو نوع انقلاب به وقوع پیوسته است. که اولین آن انقلاب صنعتی است، رویداد نخست فناوری مانند ماشین بخار،ماشین ریسندگی و جایگزینی ماشین یا ابزار است و رویداد دوم که تقریبا صد سال از عمر آن می گذرد،اختراع برق است و به تبع آن آغاز فناوری ارتباطات و اختراع تلفن.
در عرصه ارتباطات و انتقال آن، حوادث متعددی از جمله اختراع خط،اختراع کتاب ، اختراع ماشین چاپ و در نهایت تولید اینترنت تأثیر گذار بوده اند.
اینترنت در دهه هفتار پا به عرصه وجود گذاشت و با چندین اختراع واکتشاف ونو آوری همراه بود. رواج استفاده از نیمه هاد در دهه1970 ، اختراع ریز پردازه هاو استفاده از آنها در ریز رایانه ها، معرفی اولین شرکت اپل و از همه مهمتر اختراع اولین شبکه جهانی(آرپانت)، نقش گسترده ای در رواج این پدیده داشته است.
اما این پدیده با پدیده های دیگر تفاوت اساسی دارد؛ زیرا موارد دیگر بر شالوده علمی استوار نبوده وحیطه و گستره استفاده از آن به چند کشور صاحب قدرت محدود شده بود.اما اینترنت با سرعتی باور نکردنی تمام دنیارا تحت سیطره خود درآورده است.
امروز فناوری اطلاعات به عنوان یکی از تکنولوژی های نوین بشری نه تنها خود دستخوش تغییرات شده است بلکه به سرعت در حال تأثیر گذاری بر روی الگوی زندگی، روش تحقیق، آموزش، مدیریت، حمل ونقل، مسائل امنیتی و دیگر زمینه های انسانی است. فناوری اطلاات در حدود دو هه قبل پا به عرصه های علمی و صنعتی گذاشته است و اروزه به عنوان یک تخصص میان رشته ای با تلفیق ریاضی، رایانه، اطلاعات، اطلاع رسانی و مخابرات در فهرست تکنولوژی های نوین جهان قرار گرفته است.لذا پیشرفت فناوری اطلاعات مدیون تحقیقات انجام شده در علوم ذکر شده است.
شاید در دو دهه قبل بسیاری از متخصصین عصر صنعتی با این سرعت به عصر اطلاعات تغییر یابد و امروز بشر آینده را رقم بزند. که در آن بعد زمانی ، معلولیت جسمی،مشکلات اقتصادی، فاصله جغرافیایی و ... مانعی برای حرکت وپیشرفت نباشند.
در عصر حاضر فناوری اطلاعات در تعریف قدرت وتمدن جوامع نقش کلیدی پیدا کرده است.
از این رو در دوهه گذشته کشور های پیشرفته و صاحب فناوری، به فناوری اطلاعات به عنوان محور بنیادین توسعه توجه کرده اند.رشد سریع ارتباطات و فناوری اطلاعات و ورود آن به سازمان ها و جامعه بدون آمموزش و انباشت های قبلی است.رویکردی که سازمان را دستخوش تحولات ناباورانه کرده است و اینتحولات هر چند که موجب خلق روش های نوینی برای پیشبرد هرچه سریعتر و یهتر کارها شده است، اما بدون شناخت کامل، جامعه و سازمان ها ی موجود در آن را از هدف اصلی خود تا حدودی منصرف کرده است.
عصر ارتباطات و اطلاعات پیچیدگی های روز افزونی را بر زندگی فردی و سازمانی انسان امروزی تحمیل کرده است.امروز، راه شرکت ها و سازمان ها در راستای کسب مزیت ها رقابتی وحفظ و توسعه آن ها،یاد گیری زود تر و سریع تر از رقبا و بر طرف کردن چالش های موجود بر سر راه آن مزیت هاست. چرا که سرعت حول این انقلاب آنقدر زیاد است که حتی نمی توان برای آن برنامه ریزی کرد.این فناوری به زندگی فردی و سازمانی ما وارد شد و هر روز نگاه افراد جامعه را بیشتر به سوی خود جلب کرد.
مدیران جامعه و سازمان ها بدون شناخت کافی از توانایی های این فناوری، همچنان نگاهی نه از روی تعمق و تفکر بلکه در حد استفاده از حداقل توانایی های آن دارند.
امروزه با گسترش فناوری اطلاعات امکان بهره گیری از منافع دیگران به سرعت و بدون نیاز به طی مسافتی، امکان همکاری و مشارکت گروهی از افراد و یا سازمان ها در قالب یک سازمان مجازی فراهم شده است. این تغییر در کسب و ار و بومی نمودن خلاقانه آن مستلزم بهره گیری توأمان از هنر وعلم مدیریت به همراه تسهیلات ارتباطات و فناوری اطلاعات و همچنین نیاز های محیطی جامعه پیرامونمان است. و برای کشف وشکار
فرصت ها از بصیرت و شناخت شهودی بیشتر از شناخت منطقی و فرایندی بهره گیری باید کرد.
فناوری اطلاعات در زمره زیر بنای حرکت جوامع و نسل آینده در کلیه زمینه هاست و به عنوان بستر وابزاری مهم برای رشد سایر بخش های مهم
می باشد.تأثیر فناوری اطلاعات بسیار عمیق است و نادیده گرفتن آن منجر به نداشتن جایگاهی در عصر جدید خواهد بود از این رو نگرش به آینده و حرکت های ایجاد می کند و در واقع نوعی تکنولوژی فراگیر است و دامنه تغییرات آن بسیار متنوع می باشد و از جانشینی اطلاعات به جای انرژی یا نیروی کار انسانی در بخش تولید صنعتی یا تغییر در بخش درونی خدمات، از خدمات پرسنلی تا خدمات اجتماعی و سیتم های توزیعی را در بر می گیرد و اطلاعات برای سییستم آنقدر مهم است که مانند خونی است که در شریان های سیستم در جریان است.
خونی که حیات سیستم به آن وابستگی دارد.
این میهمان ناخوانده باچنین سرعتی وارد کشورمان شد که حتی مسؤلان نتوانستند با بصیرت و آگاهی به این پدیده خوشامد گویند.هر چند که سرعت پیشرفت این فناوری فوق تصور است اما با انجام یک مهندسی مجدد در ساختار و قوانین کشور جهت سازگازی فرایند های جامعه با این فناوری، آنچنان اساسی می شود که هر روز تأخیر در آن موجب وارد آمدن زیانی مضاعف بر پیکره جامعه است.
ادامه دارد...
منابع:اصول و مفاهیم فناوری اطلاعات،دکتر محمود زرگر
www.hanafsh.net
در آمدی بر مطالعات ارتباطی، جان فیسک،ترجمه:مهدی عزائی،دفتر مطالعات و توسعه رسانه ها، 1385


گرد آورنده: سامان فرج پور