جمعه 31 فروردین‌ماه سال 1386

Chapter 3-3:Summary


Scope planning uses the output of the initiation process, the project charter, to create the scope statement and the scope management plan. The project scope statement is the basis for many of the other planning processes. It is also the basis for setting the boundaries of the project with the client and stakeholders.

A scope statement includes project justification, project description, major deliverables, time and cost estimates, success criteria, assumptions, and constraints. The scope management plan documents how you will manage changes to the scope. The work breakdown structure (WBS) is created by taking the major deliverables from the scope statement and decomposing them into smaller, more manageable components. The breakdown continues through multiple levels until the components can be estimated and resourced. Each lower level of deliverables includes the components that produce the next highest level in the tree. The lowest level of decomposition is the work package. The WBS includes all of the work required to complete the project. Any deliverable not listed on the WBS is assumed to be excluded from the project. The WBS is one of the most critical outputs of planning. A WBS is the basis for time estimates, cost estimates, and resource assignments.

Certain elements in IT shops need to be taken into account when dealing with IT projects. The size of the IT shop very definitely affects the project’s time estimates, as do deliverables that may be challenging to define. Business clients may have some hidden processes —“sidebars” that they’ve not revealed when you’re busy trying to discover the processes. Success criteria can be especially tough to define in IT projects. A key project team member leaving can have a remarkable affect on the status of the project’s scope.

جمعه 31 فروردین‌ماه سال 1386

Chapter 3-2:Evaluating Your IT Project Scope

Evaluating Your IT Project Scope

The scope of projects that IT project managers undertake should never deviate very far from the established deadline set down in the WBS. Yet there are elements within an IT shop that unexpectedly surface, serving to slip the scope far from its original moorings.

IT shops run into interesting twists and nuances that will very definitely impact the project scope and that may be beyond ordinary scope assessment and planning. Let’s examine some things that you’d want to think about when evaluating the scope of your IT project.

Size of the IT Shop

The size of an IT shop has a very direct impact on a project’s scope. If you have a shop of only a handful of people, all of whom are constantly engaged on one project or another, then it’s understandable that the scope of new projects depends highly on people’s schedules. A major constraint is the limitation you have with human resources. Project priority comes into play in smaller shops as well. Suppose, for example, that all of your folks are working on a project when suddenly you’re presented with a new project that’s of much higher importance to the organization. What do you do—drop everything you’re working on and begin on the new project or wait until you finish the first? It’s a tough call to make—one that small shops are frequently faced with. If adequate assumption gathering hasn’t been built into the first project (i.e., “we assume that the project might be interrupted by more important work”) then you may be faced with a huge dilemma, one that impacts the scope, time, and cost (probably quality too, because it’s tough for people to come back from a newer project and begin working on the old one without getting their sea legs back).

More importantly, IT shops that aren’t heavily staffed might have a hard time simply maintaining the balance of the day’s work, let alone take on new projects. And yet, in the interest of making sure that you meet your customer’s needs (your end users are your customers, right?) you might be tempted to take on projects that you think you can effectively manage. In such situations, the server administrator also might be the one who manages the databases and so forth.

IT projects in minimally staffed environments such as the above often suffer from not having well-formed requirements and a well-developed WBS, never mind the rest of the support documentation.

For projects that have to be developed by folks in small or understaffed IT shops, it’ll be key that you concentrate on making sure that the requirements are fully understood, that the WBS is very succinctly spelled out, and that your plan project fits within the confines of the schedules that the IT shop workers follow. In other words, you can’t expect that a new Oracle database server project will be brought online in just a few days’ time by people who are busy running around with their hair on fire most of each working day. That is, unless you expect them to bring up the server during the night (which is precisely what some administrators do—they’re just too slammed during the day to finish projects).


Communication with your business customers in such situations is very important—you have to be sure that you communicate to stakeholders why the project can’t be completed in the blink of an eye. Customers might suggest that some of the work be outsourced in the interest of time. But this recommendation (i.e., to bring in a vendor or consultant to help) might be met with some disfavor by the IT folks. The reasons for this are myriad. If the idea of outsourcing is acceptable to all concerned you should be quite sensitive to the way that you present the idea.

Definition of the Project Deliverables

Usually it’s easier to define the deliverables of an IT project with obvious requirement outcomes. For example, suppose that you’ve met with a business unit manager who wants a new software application written to meet a specific need. After some requirement-gathering efforts, you have a pretty firm idea of what the software’s supposed to do. In talking with the folks in your IT shop you determine that the majority of your servers are Windows Server 2003, that the database of choice is Microsoft SQL Server 2000, and that there is plenty of room and hardware beef on which to host your application. From there the deliverables are pretty straightforward—you just figure out how the program will be delivered to the user (thin-client? thick?), settle on a programming environment, and away you go.

But defining the deliverables when the outcome of the project is more esoteric can be challenging. For example, suppose that you have a project in which you’re going to replace your current help-desk software system with one that’s more robust. What are the deliverables? Well, they might include a new server or servers and certainly the new software. But other deliverables will also include conversion of the old help-desk database data to the new database, training the users how to use the new system, creating new custom reports that match reports you had in the old, and so forth.

It’s like skeet shooting: it’s easy to see that red clay disk when it’s flying across blue sky, much more difficult to spot it when it’s traversing the landscape. You have to think of all of the deliverables that a project is going to produce—some of which aren’t immediately obvious. As we mentioned earlier, for example, training stakeholders and creating support documentation are two of the deliverables you’re likely to overlook if you don’t really examine the complete output of your project.

Working with Your Business Clients

IT shops exist to serve the needs of the business unit end users. To that extent, an IT shop doesn’t really have ownership in the organization’s business processes and instead must rely on the input and expertise of the business unit to make a successful project. In other words you serve the business unit but you’re not necessarily a part of it.

There are all sorts of things that fall out of this relationship that you might spot as adversely affecting the scope of your project. For one, consider the business unit director that loses interest in the project halfway through. Since the director is one of the project sponsors, how can you possibly proceed and satisfactorily complete the effort without her dedication?

Also, consider a business unit that’s too busy to lend you an SME to help make sure that the deliverables actually match the unit’s business needs. It’s very difficult to simply assume that you know what your business unit needs when you don’t have reliable input from those who actually do the day-to-day work. Many projects get done this way and they produce poor results.

What about the business unit that does all of its own research for a new COTS application, finds one that they think will work, then asks you at the last minute (almost as an afterthought) to implement the new program? The business unit stakeholders’ idea of the project’s scope might very well be a whole lot different than your own!

You might handle these elements by putting them in the assumptions section of your scope statement. For example, “It is assumed that marketing will lend the project team one full-time business representative for the first 30 percent of the project.”

Success Criteria Tough to Define

Suppose that you are working on a new Internet-based e-commerce software application. One of the requirements of the application is that it must be guaranteed to be highly secure—that transactions taking place on the system are well-secured and not privy to hacking.

How on earth do you evaluate such a requirement in order to provide evidence that the system is safe? Furthermore, what happens when, well into the system’s creation, the operating system manufacturer reveals that there are known security gaps in the code and affected systems must be patched? How will this news affect the operation of the system you’ve just created? Will the patching in some way affect your system’s operation?

Like the items in the annual performance appraisal and report that your boss gives you every year, sometimes it’s tough to put metrics to a subjective outcome. But you should try to pinpoint tangible reasons for why you’re doing the project—what your customers hope to accomplish by creating the deliverables.

Sidebar Systems and Undisclosed Process Elements

Perhaps the most devastating scope killers arise out of the belief that you’ve completely uncovered the business processes only to find that your business end users are keeping track of some elements in their office automation software or, worse, they don’t disclose all of their business processes because they either didn’t think of them at the time you interviewed them, or they deliberately withheld some elements.

The first of these problems is what we call sidebar systems, meaning that users keep track of some things by using a spreadsheet or “mini-database” program, and then use that information to work with the primary system. For example, suppose that you have an old mainframe-based program that’s been in use for 30 years. Its functionality isn’t up to par with what the users require (and hasn’t been for years), so sidebar systems have been developed to overcome the system’s shortfalls. At requirement-gathering, business-process-discovery time, users just don’t reveal that these sidebar systems are in use—they probably don’t even connect the dots—and as a result your system winds up missing some key functionality.

Alternately, users might not fully disclose all of the process elements involved in a business transaction for whatever reason. In some cases, a user might just be forgetful about all of the processes he or she goes through in order to successfully conclude a transaction. But sadly, in some instances, a user might be (subconsciously?) trying to sabotage the new effort. This sounds paranoid, but it actually happens. You can imagine the consequences when you get far down the implementation road only to discover that some pretty important process has been left out!

“Mini-Project” Consultant/Vendor Relationships

In projects that are smaller in scope, your relationship with a vendor or contractor may not be as important to them as ones with bigger budgets. While the vendor or consultant is certainly very anxious to assist you, they may have another project on the hook that has the ability to demand instantaneous use of their time, resulting in you being left high and dry waiting for them to return. This, of course, shoots your planned scope out into the stratosphere while you wait on the contractor to come back to finish something.

You’re the applications development manager for your company’s IT department. You’ve recently been presented with a request from one of your business units to automate a function of theirs that currently takes a lot of time and person-hours to accomplish.

You assign a systems analyst to the project. She begins the business analysis methodology by working with users to identify the business processes involved and trying to firmly nail down the requirements of the project. She comes back with her standard well-drafted documentation, including DFDs that show the logical flow of the current process.

Everything looks great and you begin to go forward with your project. Halfway into the development of the system code, after going back to the stakeholders for routine communications updates, you find that little elements here and there are missing—almost as though your systems analyst didn’t fully perform her usual thorough discovery.

Upon re-interviewing some of the people that she initially sat with, you find a variety of sidebar systems that they evidently didn’t bring up at the first interview. One man, for example, keeps a little Excel file listing of computations that he has done toward accomplishing the business function. These things are extremely valuable pieces of information that really should be included somehow in the new system. Another person keeps sticky notes on her desk blotter as she goes through the process. You realize that these step-monitoring activities actually are quite important for the new program and yet you had no knowledge of them when you began.

Now you must go back to the design drawing board and add in these fundamental processes.

Delivery of parts is another issue that can dramatically affect the scope of your project without you being able to adequately spot it at scope-development time. For example, we recently completed a large Storage Area Network/Network Attached Storage (SAN/NAS) project. A simple element such as the rails for a server rack held up completion of an important project phase for almost a month! The vendor sent the wrong rails (ordered through a third-party provider) and was very slow in correcting the order. Finally, just to get a set of rails installed we wound up borrowing a set of the correct rails from another IT unit just so we could bring closure to this phase of the project.

Senior Project Technician Quits or Leaves

Suppose that you laid down your WBS tasks relying heavily on one of your more senior people. Further, suppose that the person moves on to greener pastures. What then? Do you have a less capable junior person to take his or her place? Recall that some IT teams aren’t very big. What if you don’t have anyone to take his or her place until someone’s hired? Voila! The scope juts out like a cowlick on a kindergartner!

Again, in your assumptions statement, you’d note that you assume a certain caliber of individuals will be available.

Project Goes across IT Shops

Perhaps you work for an organization that has several different IT shops that serve different business units. For example, maybe the manufacturing segment of your company is so big that it has its own IT arm. Ditto for the legal department. You handle the rest. Suppose that you have a project in which everyone in the company will use the primary deliverable—for example, an electronic timesheet system that’s going to be hosted through the company’s intranet. You need the assistance and buy in from the other IT shops so that you appropriately meet the needs of the end users who will use the system. The manufacturing arm, for instance, is the only unit that has 24/7/365 workers, so their timesheet posting will be quite different from others.

In such instances, project management takes on a political diplomat flavor in which you work hard to garner buy in and cooperation from entities that don’t necessarily have to play along (unless the CEO says “make go!”).

Understandably, in a situation such as this, the scope is very much shaped by the priorities that each IT shop has weighed against the importance of the project. You might get Joe the graphics designer from marketing for 15 percent of his time per week, for example.

Testing Elements Need Good Definition

Lots of different IT projects require that you go through some testing elements to verify that the deliverables meet the requirements. Software development, for example, requires that you perform extensive testing to make sure that you’re pushing out code that meets the user’s needs as stipulated in the project requirements documentation. There are three forms of testing to be concerned with:

Unit Testing — This test involves the technician performing tests on his or her modules or elements that are going to be included in the overall package of deliverables. For example, a server administrator might get done burning a server, then go through a litany of tests to make sure that it’s working as it’s supposed to. A programmer, after completing her module, might run through a variety of tests to validate that the module is performing as expected. When you think unit testing, think singular —that is, usually a single person testing a single element. While this isn’t a hard and fast rule, it gives you the flavor of what unit testing is all about.

Integration Testing — When you perform integration testing, you’re testing a bunch of elements that are combined together to form a whole. For example, perhaps you’ve got several servers that are now burned and that will work together in an array of load-balanced Web servers. Integration testing would test these servers as a whole, rather than in distinct units. A programming team might test several modules that, when combined together, form a complete program element. For example, one programmer may have coded the print module, another the calculational elements, another the reporting. When they’re combined, they should accurately calculate some figures, create a report, and print it out successfully. Integration testing would prove that this is so.

Life is tough for you. You’ve been forced to fly to Bordeaux to meet with Monsieur Fourche so that you can discuss the email server and intranet sites. You really needed to visit each site so that you could understand what the physical connectivity elements are like. For example, you need to get a picture of where the server could actually be placed. Additionally, you also need to understand what the telecommunications picture is like—what wide area network prices are for, say, a T1 circuit (called an “E1” in Europe), what the provision times are for such connectivity, and where the demarcation point will be at the Fourche site.

You have to do the same things for Senior Sanchez’ location and the Roo wines site.

On returning, you create a scope document containing the following elements:

Business Need  The president of Chaptal Wines, Kim Cox, has requested that the three new offshore acquisitions be connected to share email and calendar information as well as vinovital information such as residual sugar (RS) and other viticultural data, vintage charts, wine blends, regulatory updates, and so forth. Two systems are required: an email system that connects all four sites together and a system that runs an intranet site.

Deliverables Description  The deliverables will consist of the installation of a server or servers at each site. The servers will connect together via wide area networking technology. Email software will be installed on each server in such a way that all sites belong to a single email organization. Users will utilize conventional email software to keep their email and calendars online. Additionally, an intranet site will be created on a Chaptal winery server and key users in each of the offshore sites will be trained how to post important data to the intranet so that all employees have complete data at their fingertips.

Major Deliverables  The deliverables include the following elements:

Success Criteria  Your success criteria includes the following:

  1. Server gear will be installed at each site, baselined, and certified 100 percent functional.

  2. Email software will be installed on each site server, site connections with the other site servers validated, and languages installed 100 percent.

  3. Connectivity between sites installed and baselined by a telecommunications company.

  4. ISP for each site will be determined and contracted.

  5. Routers installed and router tables built. Firewalls installed, configured, and baselined. Administrator will be able to ping each site server within the network and send a test email to each site server. Port sniff will show ports 20 and 21 (FTP), 25 (SMTP), 80 (HTTP), and 443 (HTTPS) open, all others closed.

  6. Intranet site created and all initial elements requested by the business made operational.

  7. Users will be trained and documentation provided and maintained.

  8. Users in all sites will be able to send email to one another 100 percent of the time and access viti-vital information 100 percent of the time.

Assumptions  You have the following assumptions:

  1. No variance in the behavior of like hardware.

  2. Telecommunications companies in each nation will have reasonable wide area network setup request procedures and installation timelines.

  3. Average T1/E1 cost is assumed to be $350/month U.S. dollars.

  4. Intranet development time is assumed to be 60 person days (30 working days, 2 persons)

  5. All sites will provide reasonable access for installers and a secure, climate-controlled, power-conditioned room for the electronic gear.

  6. Routers will use Open Shortest Path First (OSPF) routing protocol.

  7. Contractual help will be used for configuration of the routers.

Constraints  Your constraints for the email server and intranet sites are:

  1. Language barriers

  2. Availability of people at any given site to be able to help with setup due to problems with the winemaking efforts

  3. Harvest and crush seasons

Work Breakdown Structure (WBS)  Finally, this list represents your WBS:

  1. 1.0 Hardware procurement—Chaptal administrator

    1.10 Purchase servers and network operating system (NOS) licenses

    1.20 Purchase internetworking gear

  2. 2.0 Wide area network telecommunications connection procurement—Chaptal administrator working with site business managers

    2.10 Provision an E1 connection with French telco

    2.20 Provision a T1 connection with So. Australian telco

    2.30 Provision a T1 connection with Chile telco

    2.40 Provision a T1 connection with California telco

  3. 3.0 Internetworking gear installation—installed by contractor

    3.10 Contractor installs router and switches at French site, configures, baselines, and tests.

    3.20 Contractor installs router and switches at So. Australian site, configures, baselines, and tests.

    3.30 Contractor installs router and switches at Chile site, configures, baselines, and tests.

    3.40 Contractor installs router and switches at California site, configures, baselines, and tests.

  4. 4.0 Server installation—installed by Chaptal administrator

    4.10 Install server at French site. Baseline and test.

    4.20 Install server at So. Australian site. Baseline and test.

    4.30 Install server at Chile site. Baseline and test.

    4.40 Install server at California site. Baseline and test.

  5. 5.0 Email software installation—installed by Chaptal administrator

    5.10 Install email software on French server. Baseline and validate the software is working correctly.

    5.20 Install email software on So. Australian server. Baseline and validate the software is working correctly.

    5.30 Install email software on Chile server. Baseline and validate the software is working correctly.

    5.40 Install email software on California server. Baseline and validate the software is working correctly.

  6. 6.0 Intranet development—contractor

    6.10 Develop intranet pages

    6.20 Test intranet

  7. 7.0 Training of users—Chaptal administrator

    7.10 Train French users on the use of email.

    7.20 Train French users on the use of intranet.

    7.30 Train So. Australian users on the use of email.

    7.40 Train So. Australian users on the use of intranet.

    7.50 Train Chilean users on the use of email.

    7.60 Train Chilean users on the use of intranet.

    7.70 Train California users on the use of email.

    7.80 Train California users on the use of intranet.

  8. 8.0 Unit, integration, and user acceptance testing

    8.10 Unit testing

    8.20 Integration testing

    8.30 User Acceptance Testing (UAT)

We’ve also included part of what the tree structure diagram might look like for this case study as well. (See below.)

Click To expand
End Sidebar

User Acceptance Testing (UAT) — The final element of testing happens when designated users are brought in to give the system a test drive. This is also probably the most revealing of all the testing phases you’ll go through because it points out how well the team has done its job, in terms of the way that the users interact with the system. Be prepared for brutally honest assessments of your product.

At any step in the testing, if things don’t work correctly the folks working on the problem must, of course, correct it. Significant testing errors will undoubtedly result in out-of-scope scenarios in which you’re burning time and money trying to solve a problem. This is why project managers really harp on the idea of pairing the correct person for a task—so that you’re sure the task gets done within the estimate that he or she provided.

جمعه 31 فروردین‌ماه سال 1386

Chapter3-1:Scope Overview

Scope Overview

Imagine trying to work on a project without knowing your expectations, limitations, or the nature of what you’re producing. Would you even be able to begin a project without knowing these things? Luckily, in the project management business, there are rules and processes that help project managers define the limits of a project.

Scope puts boundaries around your project. Scope is like putting a fence around your property. The fence is a clear definition of where your property starts and where it ends. It is clear to anyone looking at your property what is included and what is excluded. Scope planning serves this same purpose for a project.

The project scope is the work that is done to deliver the product or service. Although this sounds simple and straightforward, a poorly defined scope can lead to missed deadlines, cost overruns, and unhappy clients. Good scope planning helps ensure that all of the work required to complete the project is agreed on and clearly documented.

Scope planning builds on and adds detail to the outputs you have created for the project charter. Scope planning is the starting point for defining the activities required to deliver the product requirements that were discussed in Chapter 2.

Depending on the detail of work completed for project initiation, scope planning may also include a more detailed analysis of the product, a cost/benefit analysis, and a look at alternative solutions. You may find that some of the work required for scope planning has already been completed during the initiation process. If that is the case, congratulations, as you are now ahead of the game.

The processes to define the scope planning elements are iterative, do not always occur in sequence, and can overlap. Regardless of the sequence, scope planning produces a scope statement, a scope management plan, and a work breakdown structure. Let’s take a look at what is required to complete each of these.

It’s important to understand that PMI’s A Guide to the PMBOK defines scope definition as the process of breaking down the major deliverables from a scope statement to create the WBS. For the purposes of the CompTIA objectives and exam, scope definition is used in a much broader sense to cover several scope planning elements including the scope statement and the scope management plan.

Project Scope Statement

Have you ever received a bid to do remodeling work on your house? A remodeling bid typically includes a description of the work to be done, a list of the major deliverables, estimates for time and cost, and any assumptions and constraints. A contractor tells you in writing that he will remodel your bathroom (description) by replacing the countertops, flooring, and tile (deliverables) in six weeks at a cost of $4,550. The bid assumes no change to the existing bathroom fixtures and a stated grade of countertops and tile. The start of the project will be constrained by whether the chosen tile is in stock or must be special ordered. The bid documents the agreement between the contractor and the homeowner as to the scope of the remodeling work.

A project scope statement serves a similar purpose to the remodel bid. A project scope statement documents the agreement between the project manager and the stakeholders as to what is included in the delivery of the project. It is the foundation for defining the activities required to complete the project, and it will be used as a baseline to manage change requests to the project. Any major deliverable, feature or function, that is not documented in the scope statement is considered a change. Typically, the scope statement includes a project justification, product description, major deliverables, success criteria, time and cost estimates, assumptions, and constraints.

Let’s take a closer look at what is included in each of these.

Project Justification

In the project justification portion of your scope statement, you must state the reason the project is being undertaken and document the business need that the project will address. You want to be clear what is driving the project request. Is the project creating a new product for external customers? Is the project developing a new system for an internal organization? Is this a legal mandate? The project justification identifies the source of the project request.

It is very important that any legal requirement behind the project request be documented in this section. This alerts anyone reading the scope statement that this is not an optional project.

Product Description

In your product description , briefly describe the features or function of the product. The description is what makes the product unique . (Remember that uniqueness of the product is part of the definition of a project.) You need to be as precise as you can using all of the data you have available. It may be appropriate to include not only the features or functions the product includes, but features or functions it does not include, if doing so will add clarity to your description. You can use your existing product description from the project charter and make changes or refinements based on any additional information you have obtained.



By listing both included and excluded features, a product description narrows and clarifies the technical work that is required to produce this product—and keeps customers from coming back at product creation time to ask you for more for goodies to be added.

Major Deliverables

In the major deliverables section of the scope statement, you will list the summary level achievements that make up the delivery of the product. It can be easy to get hung up on just the end result when you are listing the major deliverables. When you are putting together the deliverables section, make sure that you focus on the entire project. Your end result may be a new software application for the company’s sales agents, but there are other deliverables besides the application itself. Do not overlook key areas such as user documentation, user training, or help-desk training, to name a few. If you include at least one deliverable from each organization represented on the project team, it will show the big picture of what is involved in completing this project.

Success Criteria

Under success criteria in the scope statement you will define the measurable business results the product is expected to produce. This section is where you address items such as an increase to corporate revenue, a higher productivity rate, compliance with regulatory procedures, or reduced staffing needs. This section is very important as a tool for evaluating the project after it is complete. This is the section the stakeholders can reference to compare the actual business impacts of the project with the projected impacts. You want to define the success criteria so that each one can be measured. Criteria such as “become an industry leader” or “provide world class service” may sound good, but aren’t measurable. It is much better to state a sales figure, a revenue figure, or a customer waiting interval that can be measured and compared to that same data collected prior to the completion of the project. The idea behind success criteria is to supply metrics by which people can gauge whether or not the project was successful.

Completion Criteria

Completion criteria denotes what needs to be delivered. For example, you may stipulate in your scope documentation that the system will be fully functional at delivery time. Or, you may choose to stipulate that the project will be considered complete after a 3-month period of testing to make sure that all components are working correctly.

Time and Cost Estimates

In the time and cost estimate portion of the scope statement, you’ll provide an estimate of the time it will take to complete all of the work and the current high-level estimates for the cost of the project. These will be order of magnitude estimates based on actual duration and cost of similar projects or the judgment of someone familiar with the work involved in the project. These do not have to be precise estimates. A high-level estimate may also use ranges for either time or cost, in some cases including a worst case, best case, and most likely scenario.



Estimates made during scope planning may be stated in different ways depending on the estimating method used. An estimate made strictly from the actual time and cost of a similar project is stated: “Based on the results of Project XYZ, it is estimated that New Project MAL will take three months to complete and cost $350,000.” An estimate for the same project based on using ranges is stated: “New Project MAL will take between one and six months to complete at a cost of $100,000 to $500,000. The most likely scenario is four months at a cost of $400,000.”

The time estimate for a new product created by market demand may also be defined based on the window of opportunity to market the product.

Target Completion

You may be asked to provide an estimated or target date for project completion. You really do not have enough data at this point to make a precise estimate. If you are forced to provide an estimated date in the scope statement, use either a month or a quarter, such as July 2004 or third quarter of 2004 instead of a specific date. When providing a target completion date, always include an assumed start date; otherwise, if the project starts later than anticipated, your sixmonth estimate may become three months.

Level of Confidence

Project estimates may include a caveat regarding the level of confidence the project manager has in the accuracy of the estimates. Estimates made during scope planning are based on very little detail, so don’t say you are 90 percent confident just because that is what your client or your sponsor wants to hear. Cost estimates made during scope planning are commonly as much as 75 percent off the actual budget figures. We will talk more about the different types of cost estimates and the typical range of accuracy for each estimate in Chapter 5, “Cost Planning.”


In the assumptions section of the scope statement, you’ll document the beliefs the team shares regarding the project. An assumption is an action, a condition, or event that is believed to be true. The problem with assumptions is that they may not be common among all project team members or stakeholders. You may think something is obvious, but if it is not written down, chances are other players will have a different opinion. Assumptions must be shared, agreed on, and documented.

A key area to review in defining assumptions with your team is to discuss and document both what is included and what is excluded from the project. This is a good way to further clarify and bound the project scope. If you are developing software for a new desktop support system, you may assume that the software will be deployed on the existing computers at the client site. The client may assume that new workstations are part of the project. You will need to document in the assumptions section that the software will be deployed on existing workstations.


The last part of your scope statement is the constraints list. A constraint is a restriction that will impact the outcome of the project. There are two types of constraints. The first are the constraints that apply to all projects. Every project faces potential constraints in time, budget, scope, or quality. From the start of the project at least one of these areas is limited. If you are developing software to support a new product with a very short market window, time will be your big constraint. If you have a fixed budget, money will be your constraint. If both time and money are constrained, quality may suffer. A predefined budget or a mandated finish date needs to be factored in to any discussion of project scope. Scope will be impacted if both time and budget are constrained. As the project progresses and scope changes are requested, scope may become a constraint that drives changes to time, cost, or quality.



You may have heard the term triple constraint bandied about by project managers. Some project management books reference only three constraints: time, cost, and quality. Although you may still see the phrase triple constraint used in project management, be advised that most project managers think about project scope as a fourth constraint.

The second type of constraint is that specific to a project. These constraints may involve the schedule or previous commitments of human resources you need or the availability of a test system.

The push and pull of project constraints is an issue the project manager must deal with throughout the project life cycle. If a constraint is placed on time, cost, scope, or quality during up-front planning, now is the time to communicate with your stakeholder team regarding the impact of constraints. The project manager needs to have an understanding as to how the client prioritizes these constraints and be able to communicate possible scenarios that might occur as the project moves forward. As an example, if cost is cast in concrete during the planning phase, the client may have to give up functionality and scale down the scope of the project once more definitive cost estimates have been made. As you can see, the scope statement contains a lot of important project information. Let’s take a look at a sample scope statement to help you put all the pieces together.

Real World Scenario—Sample Project Scope Statement

Imagine you are a project manager for a wireless telecommunications carrier in charge of a project for a new consumer product called Voice Activated Dialing (VAD). The product is critical to the corporate strategy to become one of the top three carriers in the markets where your company offers wireless service. Using your high-level requirements, the project charter, and input from various team members and stakeholders, you are ready to create your project scope statement.

Here is what your project scope statement might look like.

Project Justification: Market research and customer feedback indicate that a demand for Voice Activated Dialing (VAD) has increased 40 percent over the past three months. One of our competitors has already announced a launch date for this product, and two others are expected to follow within the next two months.

Our market share growth is expected to decline by 20 percent if we do not add VAD as part of our product mix.

Product Description: The product features included in Voice Activated Dialing are dialing by speaking a phone number or name into the phone and the ability to create address book entries from a website. Voice Activated Dialing does not include the ability to add/edit/delete address book entries over the phone or an interface to personal information managers.

Major deliverables:

·         Product requirements defined

·         System requirements defined

·         System requirements developed

·         Sales training developed

·         Customer service training developed

·         System enhancements implemented

·         3,000 Sales consultants trained

·         500 Customer service technicians trained

·         Marketing communication plans executed in all markets

·         VAD available in all markets

Success Criteria: The launch of VAD will generate $2.5 million in incremental annual revenue for the corporation.

The additional training required for sales consultants to be knowledgeable in offering the VAD product will increase the total sales consultant training package time by no more than two hours.

Time and Cost Estimates: VAD must be completed within six months for the company to be a viable player in this market.

The development and launch of VAD is estimated to cost $750,000. This includes all IT work, sales consultant training, customer brochures, and the marketing campaign. This is a high-level estimate based on the schedule and cost of a similar new product. Estimates will be refined as more detailed data is available.

Assumptions: IT has resources to implement system changes within the six-month time frame we need to start offering VAD.

Fifteen percent of our customers will add VAD to their current service option. Product will have a 15 percent take rate. VAD will be priced at $4.95/month.

Constraints: Billing releases are only done on a quarterly basis. The enhancement to bill for VAD must be scheduled within those parameters.

The window to obtain a share of the VAD market is six months.

As you can see, a lot of very important information is included in the project scope statement. From reading the VAD sample scope statement, you know the strategic value of the product, the features included and excluded in the product, the anticipated revenue the product will generate, and the aggressive schedule that must be met. This document can be used to give a clear and concise overview of the project to clients, team members, and other key stakeholders.


Review and Consensus

Once you have completed the scope statement, hold a review session with your entire project team to make sure that everyone is in agreement and there are no unresolved issues. Individual team members may have worked on specific sections of the scope statement, and a formal team review of the entire document will confirm that everyone is on the same page and prevent later misunderstandings of the project scope. Once the project team has resolved any outstanding issues, present the scope statement to all of the stakeholders and obtain approval from the project sponsor and the client. Other approvals may be required depending on the policies of your organization.

If any changes are made to the scope statement during the review with the client and the sponsor, you will need a follow-up meeting with the project team to cover the changes and discuss the impact on the project. One of your most important duties as project manager is to keep your team informed. We will talk a lot more about how to communicate with your project team in Chapter 6, “Additional Planning Processes.”

With our approved scope statement in hand, we are now ready to create a scope management plan.

Scope Management Plan

Now that you have an approved scope statement, the real work begins. You may have heard horror stories from other project managers. How do you keep this “thing” from growing out of control and choking any chance you may have to successfully complete the project? You need to master that dreaded demon that has plagued every project manager—scope creep. Scope creep is the term commonly used to describe all those minor changes or small additions that just seem to happen out of nowhere, until suddenly you are not managing the same project anymore. The solution, of course, is having a plan.

The scope management plan documents how you will manage changes to the scope. Project scope change is inevitable with the majority of projects. The key to dealing with scope change is how you handle it. In our experience, you save yourself a lot of pain during project execution if you take the time at the start of the project to define the basics of how the team will handle requests for any changes to the defined scope.

If the project team defines the basic scope management framework early in the planning process, each team member has a point of reference to communicate with clients and stakeholders who may come to them with something they forgot to mention when the scope statement was approved. Everyone involved in the project needs to understand that the rules set up at project implementation time need to be followed to make a request to change the scope of any project. Without a documented plan, you will soon find that interested parties are talking to team members and changes are happening. The team members will, understandably, want to try to accommodate the client’s needs. But without analysis of the impact these changes, adding 10 or 20 “minor” code changes may put your schedule or your budget in jeopardy.

Key items to consider when you are developing a scope management plan include:

Stability of the scope  You probably have some indication at this point in the project as to how stable the scope is based on the work you have already done to define requirements, prepare and review the project charter, and define the scope statement. If you found major disagreement between stakeholders or gaps in the product description, you have a high probability for scope instability.

Impact of scope changes  If you are constrained with a dictated finish date, any scope change can be critical. Adding to the scope of the project may also impact the budget. Do you have available resources to add to the project to complete the additional work? What is the process for securing additional funding?

Scope change process  One of the primary reasons a project gets out of control is the lack of a documented process for scope changes. Clients and stakeholders will go directly to team members and before you know it, people will be working on deliverables that were never included in the scope statement.

Your scope change process needs at a minimum:

·         A standard form to submit the request. Information required on a scope change request includes a description of the change, the reason for the change, and the originator of the request.

·         An analysis of the impact of the request on the scope, budget, schedule, and quality of the project. The results of the analysis can be added to the form used to submit the request, so that all pertinent data in is one location.

·         An approval process to accept or reject requests. This can range from ad hoc meetings called as scope changes are received to a formal change review board that meets on a regular basis.

·         A communication plan to keep stakeholders informed of the status of requests.

·         A method to incorporate approved changes into the project plan.

The implementation of your scope management plan will be discussed further in Chapter 9, “Project Control.”



You can see why project managers are so interested in making sure they’ve established the scope of the project as best as they can before any work starts. Generally speaking, if you’ve done due diligence and tightly defined the scope of the project, with the exception of very minor changes, most new requests for changes on an IT project should be considered for “Version 2” of the product and included in a brand new project after the first one concludes.

The Work Breakdown Structure (WBS)

The final element of scope planning is the work breakdown structure (WBS), where the project team starts decomposing the project deliverables. Decomposition is the process of breaking down the high-level deliverables into smaller, manageable components from which you can do time estimates, resource assignments, and cost estimates. The WBS is a deliverables-oriented hierarchy that defines all of the project work. Each level has more detail than the previous level.

A WBS is one of the fundamental building blocks of project planning. It will be used as an input to numerous other planning processes. It is the basis for estimating activity duration, assigning resources to activities, estimating work effort, and creating a budget. Because the WBS is a graphical representation, it can be a better vehicle for communicating the project scope than the charter or scope statement. It also contains more detail to further clarify the magnitude of the project deliverables.

The WBS acts to put boundaries around the project. Any work not defined in the WBS is considered outside the scope of the project. A WBS is a tool that can be used to keep customers, team members, and stakeholders focused on what is included in the project scope.

Like a blueprint used to build a building, the WBS is the document that will be used to build your project’s product.

It is important that the project team devote adequate time to develop the WBS. Development of the WBS should focus on all aspects of the project and all impacted areas of the business.

The team may go through several iterations to complete the WBS. Once the team concurs that the WBS is complete, review sessions are scheduled with the client, the sponsor, and key stakeholders to examine and approve the WBS.

Organizing the WBS

The quality of your WBS depends on having the right players involved in the development. Provide adequate notice when you schedule a WBS session. Involve as many project team members or functional representatives as possible. Project team members may not be named at this point, but you’ll probably have a good idea of the various groups or departments that will be involved based on the list of project objectives and deliverables. Work with functional managers or if necessary your sponsor to get representation from each group. A WBS is not something that should be developed in a vacuum. A WBS developed in isolation by the project manager frequently misses key components of the project. It is also more difficult to get buy in on something people had no input on.

A WBS is typically created using either a tree structure diagram or an outline form. A tree structure is the best method to use with a project team. The structure can be created on a white board or easel paper using sticky notes to write the tasks. This allows for tasks to be moved around as you work though the process. Figure 3.1 is an example of a template that can be used to create a WBS.

Figure 3.1: WBS Template

The space you reserve to conduct the WBS development needs to be adequate to allow all participants to see the work in progress. You need to encourage brainstorming. You can always remove or move activities as you work through the process or when you do subsequent reviews. Make sure that all of the participants have reviewed all previous documentation like the charter and scope statement. Have copies of these documents available as reference. They will be your starting point for creating the WBS as well as a reference if there are questions.

Decomposing Major Deliverables

Decomposition, the breaking down of the project deliverables into smaller components, can be a challenge. Let’s take a closer look at this tree diagram and how to work your way through the creation of a meaningful WBS.

The highest level of the WBS tree diagram encompasses the entire project. This level is referred to as level 1. The next level, level 2, relates to the high-level project deliverables defined in your scope statement. This level usually takes the form of listing the deliverables themselves. We have also seen this level show the phases of the project life cycle, the departments involved in the project, or a geographical focus. There is not one correct way to create a WBS, but the method you choose must be a logical way to break things down for your particular project.

Take for instance a simple home improvement project such as painting a porch. Figure 3.2 shows a few of the project deliverables for painting the porch. You’ll notice that level 1 is the porch-painting project itself, and level 2 demonstrates the deliverables needed to paint the porch.

Figure 3.2: Starting a WBS

Project Planning Using the Tree Structure

You can begin brainstorming a WBS by utilizing the tree diagram and a bunch of sticky notes on a white board.

Recently we had to move 2,000 users from various places around the city into one centralized location—a brand new 11-story building. Each of these groups of users had a different function in life, with different managers and move timelines. Imagine the complexity of making sure that you move all the users’ computers into this new building at different times and making sure that everything works. Now imagine that you’re trying to figure out all the obstacles and tasks even before the building is complete—you’re trying to get an advance feel for what’s involved.

Our project managers started this effort by getting various stakeholders into a room and then, as ideas were voiced, writing them down on sticky notes and pasting them to a white board. Another person began to arrange the notes into some sort of logical order. One stakeholder, for example, might cry out “Make sure all monitors work!” while another would say “We need our email to work when we come in on Monday.” Each of these sticky notes had something to do with powering up the machine and validating that it was connected to the network.

In time, as we fleshed out various components of the project, the white board looked just like a tree with yellow leaves all over it!


As Figure 3.2 illustrates, you should always work through level 2 before moving down to the next level of decomposition. This method will help you make sure you encompass all of the project goals.

Each subsequent level should be a breakdown of the previous level. In our porch-painting example, we have taken Prepare Porch and decomposed it as shown in Figure 3.3.

Figure 3.3: Decomposing a Major Deliverable

The process continues until a task does not need to be subdivided again. You need to get to a level of detail that generates manageable activities, but do not go down to a level of detail that you cannot track and control. PMI’s A Guide to the PMBOK refers to the lowest level of the WBS as a work package. The work package is just how far down you need to go to decompose the deliverables.

Guidelines for Creating a WBS

Getting started creating a WBS can sometimes seem overwhelming. we’ve found that a lot of people who struggle with this process are actually taking on more work than they should. Once you start breaking down your deliverables into activities, there is a temptation to immediately put the activities in order (called sequencing the activities) or estimate the length of an activity so you can just get people started on the work. Unfortunately, this type of behavior usually leads to a situation where key deliverables are missed or task sequences are incorrect because many tasks were not defined. The clock is ticking and people are working hard, but not necessarily on the right things, because time was not taken to create a thorough WBS. Although there is no one “right” way to complete a WBS, there are some tips on pitfalls you can avoid to help you be more successful. Here are some guidelines that we find helpful to review with project teams before diving into a WBS session.

Recruit knowledgeable as well as available resources.  Do not try to complete the WBS yourself in the interest of saving time. If you are not an expert on the deliverables, you will miss key elements. You also want the team members to do the work so that they buy into what has been created. Involving knowledgeable team members in the creation of a WBS is far more effective at communicating what the project is all about than handing someone a completed WBS. If there are team members who will be involved in the project but who cannot participate in the session, make arrangements to get input from a representative at a separate session. Ideally, you want everyone in the same room, but if that is not possible make sure you get the input in some other fashion.

Work though all items at level 2 before you go down to the next level.  You should be confident that the entire work of the project is represented at the high level. If you are completing the WBS as a team exercise, you will need to control the tendency the team may have to start decomposition immediately once a deliverable has been put up on the board. This is a natural inclination, once people see a deliverable, to start thinking of what it will encompass. As a project manager, you need to take control of the situation and remind the team to not decompose anything until all of the high-level deliverables have been identified. Otherwise you may end up putting tasks under a deliverable that are not really a part of that deliverable or worse yet miss a key component of the project. Keep referring the team back to the scope statement until everyone is confident that your high-level deliverables are covered. Then you can start decomposing.

Each item in a lower level is a component of the level above.  Completion of all of the items in the lower level should mean completion of the higher level. As a checkpoint, you should always review the items at the lower level and ask the team if completion of those items will result in the task at the next higher level. If the answer to this question is no, than you have not identified all of the lower level tasks.

List all activities and continue to break them down to component parts.  Make sure you get to a level where the team feels comfortable that resources can be assigned and estimates can be completed. Sequencing, assigning resources, and estimating are all separate activities that you will complete after the WBS is complete. We have seen many teams waste time doing separate tasks such as sequencing the activities while creating the WBS. These teams managed to break down the activities, but at the same time they got hung up with the sequence, which is not the goal of the WBS.

Do not create a To Do list.  You should not decompose activities any further than to a level where they can be easily assigned, estimated, and produce a meaningful deliverable. Since the WBS will become the foundation for the project schedule, do not break down beyond a level that you can control. If you create a series of very short sequential tasks, you are expected to manage all of those tasks.

Let’s take a look at the Purchase Materials deliverable for our porch project. Under Purchase Materials you could have just listed all the items you need to buy: sandpaper, sealer, paint, brushes, etc. But if you included your shopping list in your WBS, you would not have actually listed the activities that make the purchase complete. The items that you need to purchase to complete the porch project are only one of the activities associated with “Purchase Materials.” Your shopping list is referenced on the WBS by the activity “Make a List,” as shown in the completed Porch Project WBS in Figure 3.4.

Figure 3.4: Porch Project WBS

Use the appropriate number of levels for each leg.  Each major objective will have a different level of decomposition to get to the point where you can do estimating and resource scheduling.

It is not uncommon for one leg to have three levels and another to have seven levels. You should be concerned about getting to a manageable activity, not on balancing the WBS. If you try to force an even number of levels across all deliverables, you will end up with some legs that are not broken down in adequate detail and others that end up listing all the steps to complete a simple task.

Create a numeric identifier for each item on the WBS.  This is very similar to the format used for a numeric outline. Start at the left of the WBS and work across. Your major deliverables are 1.0, 2.0, 3.0, etc. As you move down a level, increment the second number. The level under deliverable 1.0 is labeled 1.1,1.2,1.3,1.4, etc. Figure 3.5 shows numeric identifiers added to the WBS we created earlier for the porch project.

Figure 3.5: WBS with Numeric Identifiers

Benefits of the WBS

The WBS is often listed as one of the most important components of a successful project. As you will see in later chapters, the WBS is an input to numerous project management processes. In our experience as a project managers, we have also found it invaluable in many other ways.

The WBS is an excellent tool for team building and team communication. With a graphic representation of the major project deliverables and the underlying activities, team members can see the project big picture and how their portion fits in. The direct link between a given activity and a major project deliverable can also help clarify the impact of an individual team member. As new resources are added to the project, the WBS can be used to bring these new team members up to speed.

A good WBS can be turned into a template for future projects. Software development projects frequently have a similar life cycle, and what was done on a previous project can be used as a starting point for a new project. This allows the team to take an existing structure and customize it to fit the new project. This is also an excellent way for teams to look at areas of the project they may not have thought about on their own.

The picture of the project scope the WBS provides is an excellent tool for communicating with clients and stakeholders. People do not always comprehend the magnitude of a project until they see the diagram of the project objectives and the activities required to reach those objectives. It also is an excellent tool to use when discussing staffing requirements or budgets. It clearly shows what work is included in the project. If something is not covered in the project objectives and supporting activities, it is not part of the project.

A detailed WBS will not only prevent critical work from being overlooked, it will also help control change. If the project team has a clear picture of the project objectives and the map to reach these objectives, they are less likely to go down a path unrelated to the project scope. We do not mean to imply that a WBS will prevent change; there are always changes during the project life cycle. But a WBS will clarify that a request is a change and not part of the original project scope


جمعه 31 فروردین‌ماه سال 1386

Chapter 3: ScopePlanning


  • 1.5 Given a scope definition scenario, demonstrate awareness of the need to secure written confirmation of customer expectations in key areas.

  • 1.6 Given a project initiation document (a project charter or contract), including a confirmed high-level scope definition and project justification, demonstrate the ability to identify and define key elements.

  • 1.7 Given a project initiation document (a project charter or contract), including the client’s highest priority between quality, time, and budget, estimate a number of elements.

  • 1.9 Given a proposed scope definition and based on the scope components, assess the feasibility of the project and the viability of a given project component against a predetermined list of constraints.

  • 1.10 Recognize and explain the need to obtain formal approval (sign-off) by the project sponsor(s) and confirm other relevant management support to consume organizational resources as the project scope statement is being developed.

  • 1.11 Given an incomplete project scope definition, complete or rewrite the definition to (1) reflect all necessary scope components or (2) explicitly state which is included in the project and which is not.

  • 1.12 Identify possible elements of a final project scope definition and the circumstances in which they would be appropriate.

  • 1.14 Recognize the need to obtain consensus of stakeholders and to obtain buy in from the team to proceed to the planning stage of the project given a high-level estimate of scope, schedule, budget, and resources.

  • 2.6 Given a project description/overview and a list of the project business and technical requirements, perform key tasks to ensure project success.

  • 2.7 Describe the goals of a useful project requirements review with the client (e.g., verify mutual understanding of client’s product delivery, product performance, and budget requirements, etc.) and describe when it is important to have such reviews.

  • 2.8 Given the client’s approved project requirements and the input of stakeholders, decompose these requirements into business and functional requirements while maintaining trace ability within strict configuration control.

  • 2.9 Given a project planning scenario, demonstrate an understanding of and the ability to develop a phase-oriented WBS with high detail for an early phase and with low detail for later phases.

  • 2.10 Given a scenario involving tasks, resources (fixed or variable), and dependencies for a multiphase IT project, demonstrate knowledge of the standards for creating a workable WBS.

  • 2.11 Recognize and explain the need to obtain consensus and formal approval (sign-off).

Now that we have covered the initiation process and have an approved project charter, it is time to talk about project planning. Planning can be one of the most overlooked areas of project management. Once a project is approved, everyone just wants to run off and start working. As a project manager, you may even find that your organization does not support taking the time to do planning. If you have ever had an executive call you to task for wasting valuable time planning when there is work to be done, you know what we are talking about.

A good understanding of the planning processes will prepare you to communicate within your organization about the benefits of taking time up front to define all aspects of managing a project before the work actually starts. Starting with this chapter and continuing through Chapter 7, “Creating a Comprehensive Project Plan,” we will cover all the aspects of project planning. Our first planning topic is project scope.

Project scope is defined as the size of the work involved to complete the project. As a project manager, you need to be aware of what is included in the project as well as what is excluded. Scope planning will assist you in getting your arms around a project and setting the boundaries for what is included in the project.

You need to define and document three scope components to complete scope planning: the scope statement, scope management plan, and work breakdown structure (WBS). The scope statement provides a common understanding of the project by documenting the project objectives and deliverables. The scope management plan documents the procedures that you will use to manage any proposed changes to the project scope throughout the life of the project. The final component of scope is the work breakdown structure, which breaks the project deliverables down into smaller activities from which you can estimate task durations, assign resources, and estimate costs.


جمعه 31 فروردین‌ماه سال 1386

حفاظت از اطلا‌عات محرمانه در هنگام استفاده از خدمات آنلا‌ین مالی

 روند انتشار کدهای مخرب بسیار نگران کننده‌تر از حالتی است که کاربران معمولی و خانگی اینترنت تصور می‌کنند. با افزایش تعداد افرادی که بطور تفریحی و یا جدی به نفوذ در سیستم‌ها و تخریب آنها مشغولند، تنوع کدهای مخرب با ریسک‌های تخریبی متنوع، به نحو چشمگیری افزایش یافته است. با این وجود به نظر می‌رسد که کاربران اینترنت، به ویژه کاربران خانگی آن، در رابطه با حمله‌های مخرب این کدها نگرانی اندکی دارند و شرایط فعلی، انگیزه مناسبی را برای حفاظت از رایانه‌ها و اطلا‌عات موجود در آنها ایجاد نمی‌کند.

برخلا‌ف عقیده کاربران غیرحرفه‌ای اینترنت، سرقت اطلا‌عات مالی و اعتباری افراد در هنگام استفاده از خدمات بانکی آنلا‌ین، تنها به علت کلا‌هبرداری (فیشینگ) و یا عملکرد جاسوس افزارها نیست بلکه عوامل و شرایط دیگری نیز در این خصوص باید مورد توجه قرار گیرند.

یکی از این عوامل مهم، اعتماد بیش از حد کاربران اینترنت به عدم قرارگرفتن در معرض حملا‌ت مخرب است. بیشتر افراد گمان می‌کنند که امکان حمله هکرها به رایانه و تخریب سیستم آنها توسط کدهای مخرب بسیار اندک است. <واقعا کدام هکر به خود زحمت می‌دهد تا اطلا‌عات بانکی من را که پول کمی در آن وجود دارد، سرقت کند>‌و یا اینکه <هکرها بیشتر به سراغ میلیونرهایی می‌روند که در حساب بانکی‌شان پول‌های فراوانی با ارقام نجومی وجود داشته باشد.>

اما این عقیده‌ای کاملا‌ نادرست است. کاربران باید به خاطر داشته باشند در هنگام اتصال به شبکه اینترنت آنها تنها توسط آدرس‌های ‌IP خود شناسایی می‌شوند و نه خصوصیات شخصی و یا موجودی حساب بانکی. اصولا‌ برای یک هکر و یا خرابکار اینترتی، نفوذ و حمله به رایانه‌ای با آدرس ‌ (مثلا‌ در آمریکا) با ورود غیرمجاز و تخریب رایانه دیگری به آدرس ‌ (در بلژیک) کاملا‌ یکسان است.

اگر در هر کدام از این آدرس‌ها، حساب‌های بانکی وجود داشته باشند که به‌صورت آنلا‌ین و اینترنتی مورد استفاده قرار بگیرد، حتی با وجود کم بودن موجودی، باز هم انگیزه خوبی برای هکرها و خرابکاران اینترنتی است که اطلا‌عات محرمانه مربوط به آن را در اختیار داشته باشند.

کاربران رایانه باید بدانند که بسیاری از مجرمان اینترنتی به پول‌های اندک نیز قانع هستند و برای آنها مقداری اندک همیشه بهتر از هیچ است.

خطرات و ریسک‌های امنیتی مربوط به خریدهای اینترنتی، نقل و انتقال پول و بررسی حساب‌های بانکی بسیار زیاد است اما خوشبختانه راه‌های کنترل و حذف این خطرات نیز (در صورت توجه و عملکرد صحیح کاربران) وجود دارد.

بیشتر کاربران اینترنت برای پیشگیری از ریسک‌های امنیتی در معاملا‌ت اینترنتی، معمولا‌ به نصب و استفاده از برنامه‌های امنیتی با قابلیت ردیابی جاسوس افزارها و تروژان‌ها اکتفا می‌کنند اما متاسفانه آمارهای موجود نشان‌دهنده شرایطی است که از وضعیت مورد تصور کاربران بسیار وخیم‌تر است: خلق و انتشار بیش از هزار گونه مختلف از بدافزارهای رایانه‌ای به صورت روزانه؛ یعنی تقریبا یک بدافزار در هر دقیقه! این بدان معناست که کاربران باید تمام وقت خود را تنها به امن کردن محیط کاری خود اختصاص دهند درحالی‌که هیچ وقتی برای انجام کارهای دیگر ندارند.

برخی از کاربران نیز برای دریافت خدمات آنلا‌ین مالی و اعتباری و یا انجام خریدهای اینترنتی، ابتدا نرم‌افزار امنیتی خود را به‌روز می‌کنند. این حداقل کار صحیح و مناسبی است که انجام می‌شود زیرا دست کم آنها محیط سیستم خود را از وجود کدهای مخرب شناخته و ثبت شده پاکسازی می‌کنند اما تهدید دیگری نیز وجود دارد: خلق و انتشار ویروس‌های بسیار جدیدی که فقط در عرض چند دقیقه در شبکه اینترنت پراکنده می‌شوند و تا لحظه شناسایی، ثبت و تولید کد خنثی کننده آنها، قادر به نقوذ در سیستم و ایجاد حمله‌های مخرب هستند.

باتوجه به تمام شرایط و موارد فوق، توصیه آخر کارشناسان امنیتی به کاربران خدمات بانکی آنلا‌ین، این است که قبل از ورود به وب‌سایت بانک‌ها و موسسات مالی و دریافت خدمات آنلا‌ین از آنها، حتما با استفاده از آخرین نسخه به‌روزرسانی شده یک نرم‌افزار قدرتمند امنیتی، رایانه و محیط سیستم خود را از وجود بدافزارهای فعال پاکسازی کرده و از فناوری حفاظت پیشگیرانه مانند ‌TruPrevent برای ردیابی و خنثی سازی کدهای مخرب بسیار جدید، ناشناخته و سریع‌الا‌نتشار استفاده کنند.

بسته به حجم دیسک‌های سخت مورد استفاده در رایانه‌های فعلی و نیز حجم برنامه‌های مختلف موجود در آنها معمولا‌ زمان بررسی، جست‌وجو و پاکسازی رایانه‌ها ممکن است قدری زمان‌بر و طولا‌نی باشد.

برای رفع این مشکل نیز کاربران رایانه می‌توانند از نرم‌افزار نانو اسکن استفاده کنند. این برنامه با قابلیت‌های پیشرفته و عملکرد سریع خود می‌تواند در مدت زمان بسیار کوتاهی محیط شبکه و سیستم کاربران را برای انجام معاملا‌ت اینترنتی و استفاده از خدمات بانکی آنلا‌ین، امن و نفوذناپذیر کند.


جمعه 31 فروردین‌ماه سال 1386

اطلاعات و فناوری ؛ دو روی سکه جامعه اطلاعاتی

فرنود حسنی

امروزه تولید اطلاعات و دانش در تمام ابعاد علمی، فنی و کاربردی و پراکندن آن با ابزارها و امکانات ارتباطی با هدف به اشتراک گذاری آنها در سطح ملی یا بین المللی، فرآیندی تحول زا و مثبت در عرصه تبادلات اقتصادی، فرهنگی و آموزشی است. فراهم‌شدن امکان دسترسی عمومی به اطلاعات حوزه‌های مختلف موردنیاز مردم و به کارگیری آنها برای توسعه فعالیت‌های اقتصادی و اجتماعی و آموزشی از جمله مزیت‌هایی است که عاید تولیدکنندگان و کاربران اطلاعات می‌شود امروزه تولید اطلاعات و دانش در تمام ابعاد علمی، فنی و کاربردی و پراکندن آن با ابزارها و امکانات ارتباطی با هدف به اشتراک گذاری آنها در سطح ملی یا بین المللی، فرآیندی تحول زا و مثبت در عرصه تبادلات اقتصادی، فرهنگی و آموزشی است. فراهم‌شدن امکان دسترسی عمومی به اطلاعات حوزه‌های مختلف موردنیاز مردم و به کارگیری آنها برای توسعه فعالیت‌های اقتصادی و اجتماعی و آموزشی از جمله مزیت‌هایی است که عاید تولیدکنندگان و کاربران اطلاعات می‌شود.
سحر میرشاهی

مدیر سایت / فارغ التحصیل مهندسی علوم و صنایع غذایی از دانشگاه شهید چمران اهواز

View Profile >
امکان دسترسی آسان‌تر و سریع‌تر به اطلاعات حاصل از نتایج تحقیقات، نظریه‌های علمی، آزمایش‌ها و پژوهش‌ها، بررسی و تجزیه و تحلیل مفاهیم، کاربرد فناوری‌ها برای کسب دانش و کاربرد فناوری‌ها برای تولید و توزیع دانش همه از جمله ویژگی‌هایی است که بشر امروز در ورود به جامعه اطلاعاتی یا به عبارت بهتر جامعه جهانی اطلاعاتی با آنها مواجه است و از آنها بهره‌مند می‌گردد. از این رو هر یک از شهروندان جامعه اطلاعاتی با برخورداری از مواهب دموکراسی اطلاعاتی بوجود آمده در سایه جامعه اطلاعاتی که نتیجه تفکر توسعه بر مبنای دانایی‌محوری است می‌توانند علاوه بر تاثیر پذیرفتن از شرایط حاضر به عنوان عامل و حتی شاخصی تاثیر گذار در اشاعه فرهنگ دانش محوری در جامعه عمل کنند. جامعه اطلاعاتی با توجه و نگاه از بالا به علوم و دانش‌های مختلف فنی، تجربی، انسانی و حتی هنری در صدد است تا از تمام عناصر و نیروهای موجود برای رسیدن به چهارچوب‌های نظری و عملی توسعه دانایی محور استفاده کند. در چنین فضایی است که افراد و جامعه همچون عناصر پیکره یک سیستم مدام در حال داد و ستد خواهند بود و کالایی که در این میان رد و بدل می‌شود، اطلاعات است و در این شرایط جامعه اطلاعاتی به افراد امکان می‌دهد که فراگیری صحیح را بیاموزند و آنها را از نحوه طبقه بندی، بازیابی و به کار گرفتن اطلاعات به گونه‌ای آگاه می‌سازد که برای دیگران نیز امکان آموختن دانش را فراهم کنند.
جامعه اطلاعاتی این توانایی را به افراد می‌دهد تا به صورت مستمر به فراگیری دانش بپردازند زیرا همواره اطلاعات موردنیاز خود را در دسترس دارند و از همین رو آنها می‌توانند در تمام لحظه‌های زندگی از دانش و اطلاعاتی که در اختیار دارند، استفاده نمایند. اطلاعاتی که در زندگی شخصی و کاری افراد می‌تواند راهگشای بسیاری از مسائل باشد و زمینه‌های استفاده از اطلاعات را در امور اقتصادی، آموزشی، علمی، تحقیقاتی و اطلاع رسانی را فراهم کنند.
با این تفاسیر امروزه کارشناسان از اطلاعات به عنوان مهمترین ویژگی جهان مدرن یاد می‌کنند به گونه‌ای که بیشترین توجه سیاستمداران و مدیران کشورها وقف اطلاعاتی شدن زندگی اجتماعی شده است. آنها معتقدند اطلاعات به چنان اهمیتی دست یافته که شایستگی آن را دارد تا به صورت نماد عصر حاضر با آن برخورد شود و به عنوان محور برنامه‌های کلان و کوچک توسعه قرار گیرد.
در بررسی استانداردهای جامعه اطلاعاتی می‌بینیم که الگوهای زندگی عادی و شغلی، اوقات فراغت، نظام آموزشی، اطلاع رسانی و عرصه داد و ستد مشخصا از توسعه و پیشرفت اطلاعات و دانش فنی توزیع و تولید آن متاثر است. کارشناسان این تحولات را نشات گرفته از رشد فزاینده تولید انبوه اطلاعات در طیف گسترده و فراوانی رسانه‌های جمعی که اکثر آنها نیز به صورت الکترونیکی ظهور می‌یابد، می‌دانند.
کارشناسان جامعه اطلاعاتی را جامعه‌ای می‌دانند که در آن ارتباطات، عامل انتقال دهنده واقعی برای ایجاد تغییر و تحول در هر فرد به منظور دستیابی عملی به اطلاعات است و تولید ارزش‌های اطلاعاتی عامل تعیین کننده‌ای در توسعه جامعه است. ‌
توسعه فناوری ارتباطات و اطلاعات و گسترش گرایش جوامع به استفاده از وب و فناوری‌های ارتباطی و اطلاعاتی وب مدار، نگرش‌ها و فرصت‌های نوینی را در فرآیند توسعه جامعه اطلاعاتی فراهم کرده و زمینه مناسبی برای ارتباطات دوسویه میان فرهنگ‌ها و اقتصادها و مراکز علمی دنیا بوجود آورده است. ‌
فناوری اطلاعات و ارتباطات به عنوان بستر همگرایی و تعالی اندیشه‌ها و توانایی‌های دانش نوین الگوها و استانداردهای جامعه اطلاعاتی را با هدف دستیابی به توسعه بر مبنای دانایی با نگرش جهانی ترسیم و به اجرا در خواهد آورد.
از سوی دیگر فناوری اطلاعات و ارتباطات به علت کانون همگرایی دو اصل مهم فرهنگ سازی یعنی محتوای اطلاعاتی و دانشی و ابزارهای اطلاع رسانی و ارتباطی تاثیر مهم و به سزایی در ایجاد تحولات و تغییرات فرهنگی در الگوی دانش مصرفی مردم دارد. از این طریق می‌توان فرآیند دانش سازی و دانش پراکنی را در سطح جامعه مدیریت و کنترل کرد و این دیدگاه را به تمامی امور جامعه تسری بخشید.
مدیریت امور بر پایه دانش در تمامی ساختارهای جامعه می‌تواند نطفه فرآیندی بزرگ‌تر و جامع‌تر را بیافریند، فرایندی که از آن به عنوان توسعه دانایی محور یاد می‌شود و زمینه ساز بهره گیری و استفاده بهینه از مزایای پدیده جهانی شدن است.
تحولات گذار از عصر صنعتی به عصر اطلاعات
از نیمه‌های دوم قرن بیستم به تدریج شاهد افول عمر عصر صنعتی بودیم. هرچند پایان عمر عصر صنعتی بر اساس یک قرارداد و تحت شرایط و توافق خاصی صورت نگرفت و در یک دید واقع بینانه امری تئوریک و نسبی است اما شرایط و رخدادهای اتفاق افتاده در طول چند دهه به صورت زنجیره وار منجر به پایان یافتن عمر این عصر شد.
تحولات پرشتاب علمی ـ تکنولوژی به عنوان موتور محرک تحول جدید مطرح شدند و رشد و تکامل بشر در عصر صنعتی توانمندی لازم را برای ورود به عصر اطلاعات را فراهم کرد. سال‌های آغازین دهه 70 در غرب همراه با آغاز حرکت‌های زیادی برای ایجاد تحول در زمینه اطلاعات و اطلاع رسانی بود. ‌ در سال‌های آغازین دهه 80 گرایش به استفاده از کامپیوترهای کوچک در ادارات و پس از آن خانه‌ها زیاد شد و در نتیجه بسیاری از کارهای جاری تحت تاثیر این تغییر قرار گرفت. از سال 1990 به بعد سیر تحولات در توسعه اشتراک گذاری اطلاعات با ظهور و توسعه شبکه‌های کامپیوتری سرعت بیشتری به خود گرفت و با شکل گیری وب گسترده جهانی تحولی فراتر از حد انتظار را برای جهانیان ایجاد کرد.
در این زمان فعالیت‌ها و فرآیندهای اقتصادی و اطلاع رسانی و آموزشی با استفاده از بسترهای ایجاد شده رنگ و بوی دیگری به خود گرفتند تا از این طریق مردم بتوانند خدمات خود را در ابعاد جهانی ارائه و یا تامین کنند. در آغاز هزاره سوم و با بهره گیری و تلفیق اینترنت و سیستم‌های اطلاعاتی تحول جدیدی ایجاد شد و آن به وجود آمدن سیستم‌های وب مدار بود که ضمن بالابردن راندمان کاری و حذف کاغذ از فرآیندهای ارتباطی و کاری سازمان‌ها به آنها امکان انجام کارهای غیرحضوری را نیز می‌داد. تمام فعالیت‌های انجام شده در جهت توسعه و تسهیل امکان به اشتراک گذاری اطلاعات بوده است و افرادی که به عنوان توسعه دهنده فناوری و یا کاربر آن بوده‌اند خواسته و ناخواسته فعالیت‌های خود را بر مبنای اطلاعات قرار داده‌اند. اطلاعات به تعبیر جالب برخی از کارشناسان کالای قرن بیستم لقب گرفته است و محور تمام برنامه ریزی‌ها و اختراعات و تولیدات فناورانه نیز به شمار می‌رود.
اطلاعات و چالش‌های جهانی
کارشناسان اطلاعات را حاصل تجزیه و تحلیل مجموعه‌ای از داده‌های همگن می‌دانند که در اثر ترکیب با مجموعه‌ای دیگر از اطلاعات تشکیل دهنده دانش خواهند بود.
عصر حاضر با دو پدیده مختلف روبروست: 1- انفجار اطلاعات که حاصل رشد سریع و بی سابقه در کمیت و حجم و تنوع و شکل اطلاعات و انتشارات است و باعث کاهش نیم عمر اطلاعات در جهان شده است. 2- انفجار جمعیت و توسعه نایافتگی حاصل از آن.
کارشناسان معتقدند این دو پدیده از نظر جغرافیایی با یکدیگر نسبت عکس دارند یعنی در جوامعی که اطلاعات به عنوان محور توجه و برنامه‌ریزی درآمده، انفجار جمعیت کمتر بوده و انفجار اطلاعات کاملا محسوس است به گونه‌ای که حتی زندگی روزمره مردمان این گونه کشورها مبتنی بر بهره گیری مناسب از این اطلاعات است. این درحالیست که در کشورهای توسعه نیافته که از معضل رشد بی حد و حصر جمعیت رنج می‌برند، ضعف مشهودی در تولید و توزیع اطلاعات و بهره‌گیری کارآمد از اطلاعات موجود وجود دارد.
نکته‌ای که این روزها باعث اشتباه در دریافت مفهوم کلی و حقیقی اطلاعات می‌شود، محدود کردن اطلاعات در حوزه دانش فناوری اطلاعات است و به نظر می‌رسد که اگر تصویر و جایگاه روشنی از فناوری اطلاعات به دست آوریم می‌توانیم جایگاه اصلی اطلاعات را نیز تعریف و شناسایی کنیم.
با این توضیح می‌توان فناوری اطلاعات را به مثابه منشوری عنوان کرد که اطلاعات علوم مختلف فنی و تجربی و انسانی و هنری می‌توانند در گذر از این منشور ضمن بهینه سازی و توسعه کمی و کیفی موجب افزایش تمرکز بر روی علوم مختلف نیز بشوند.
بررسی‌ها نشان می‌دهند که در جوامع توسعه نیافته که هنوز در گیر و دار عصر کشاورزی و صنعتی هستند و اطلاعات در آنها جایگاه مناسبی نیافته، مشکلات و نقص‌ها و ضعف‌های عمده‌ای نیز از همین محل ناشی و گریبان گیر برنامه ریزان و مسوولان آنها می‌شود.
بنا بر این می‌توان نتیجه گرفت عدم توسعه مناسب کاربری اطلاعات که ترجیحا نیز باید در بستر فناوری‌های اطلاعاتی و ارتباطی صورت گیرد، ارتباط مستقیمی با مشکلات کشورهای توسعه نیافته در مصرف انرژی، محیط زیست، اقتصاد، توسعه سیاسی و فرهنگی - آموزشی و دیگر شاخص‌ها و معیار‌ها دارد.
بدون شک ارتقای جایگاه دانش در جامعه سطح تفکر و نوع عملکرد مردم را در فعالیت‌ها و موضع گیری‌های مختلف اجتماعی تغییر می‌دهد و باعث افزایش کمی و کیفی در نحوه بهره گیری و بهره دهی ایشان به جامعه می‌شود. نکته حائز اهمیت در توجه دولت‌ها به مساله اطلاعات ارتباط مستقیم و اثر گذار اطلاعات در توسعه و تاثیر توسعه در افزایش اطلاعات است. این تاثیر و تاثر می‌تواند در ابعاد گفتمان‌های زیر ساختی توسعه یعنی توسعه اقتصادی، توسعه فرهنگی، توسعه سیاسی و توسعه علمی بروز و ظهور پیدا کند.
شکاف اطلاعاتی و شکاف دیجیتالی
یکی از مهمترین چالش‌هایی که جامعه جهانی این روزها با آن دست به گریبان است تعیین و تفسیر عامل مشکل ساز و معضل ساز توسعه یافتگی در برخی کشورها و عقب ماندگی در برخی دیگر از کشورهاست. به زعم کارشناسان جهان امروز با دو پدیده حاصل از مدرنیته روبروست. یکی شکاف اطلاعاتی و دیگری شکاف دیجیتالی که حاصل اولی فقر اطلاعاتی و حاصل دومی فقر ارتباطی است.
گذشته از نقش انحصارطلبی‌ها و قدرتمندی کشورهای سرمایه دار در بوجود آمدن این دو پدیده چالش‌های مختلفی در پیش روی مردم جهان پیشرفته و جهان توسعه نیافته وجود دارد. به نظر می‌رسد همانگونه که رشد و پیشرفت بشر در دانش‌ها و علوم مختلف موجبات توسعه توانمندی او را در تولید فناوری‌های نو فراهم آورده و همچنین توسعه فناوری‌ها نیز به رشد و توسعه دانش و اطلاعات کمک کرده، ضعف‌ها و مشکلات و نقص‌های موجود در گسترش دانش و اطلاعات نیز با کمبودهای ناشی از عدم رشد مناسب فناورهای ارتباطی ارتباط مستقیم و تنگاتنگی دارد اما اتفاقی که به تازگی در حال تبدیل شدن به یک چالش جدی جهانی است، تلفیق دو پدیده شکاف دیجیتالی و شکاف اطلاعاتی توسط کشورهای پیشرفته و استفاده از بستر‌های اطلاعاتی-دیجیتالی موجود به عنوان اهرم فشار علیه کشورهای ضعیف و توسعه نایافته است.
به عنوان نمونه یکی از بحث‌های چالش برانگیزی که در چند ماهه اخیر مقارن با اجلاس جامعه اطلاعاتی مورد توجه قرار گرفته، موضوع حاکمیت اینترنت به عنوان مهمترین و بزرگترین بستر بین المللی اشتراک‌گذاری اطلاعات است. در این بین آمریکا که خود را سردمدار و محق مدیریت جهانی اینترنت می‌داند با تلاش‌ها و اقدامات و مخالفت‌های بسیاری سعی در اثبات ادعای خود دارد. ‌
اینگونه رفتارها و دیدگاه‌های حاکم بر فضای دنیای اطلاعات زمینه ساز شکل گیری طبقه بندی جدید با ویژگی فقر اطلاعاتی در اثر بروز شکل جدید از برتری طلبی به شکل غلبه الکترونیکی در عرصه جهانی است. بدین ترتیب فصل جدیدی در روند توسعه جامعه اطلاعاتی جهانی در حال شکل‌گیری است که ظاهرا حکایت از تمایل کشورهای توسعه یافته بر استیلای بلامنازع در این عرصه دارد. به گونه‌ای که هم اکنون نیز به صورت آشکار با دو زیرگروه فقرای اطلاعاتی و ثروتمندان اطلاعاتی برمی خوریم.
در اینچنین شرایطی زمانی که جریان اطلاعات در جامعه از تحرک بیشتری برخوردار شود و جامعه جهانی از جریان توزیع آزادانه و منصفانه اطلاعات فاصله بگیرد و اصول و چارچوب‌های دموکراسی دیجیتالی اطلاعاتی در جهان زیر پا گذاشته شود، کشورهایی که از وضعیت اجتماعی و اقتصادی بهتری بهره‌مندند، سریع‌تر از کشورهای ضعیف این اطلاعات را تصاحب می‌کنند و در نتیجه با رشد تمایز اطلاعاتی، تبعیض میان طبقه برتر سیاسی ـ اقتصادی و علمی و اقشار مادون آن رو به فزونی خواهد گذاشت و آن اختلاف و شکاف مابین این دو گروه زمینه‌ساز استفاده نا به جای کشورهای پیشرفته از شرایط موجود به عنوان اهرم فشارهای اقتصادی، سیاسی و علمی خواهد شد.
تاثیرات توسعه ناهمگون فناوری اطلاعات در تعمیق شکاف دیجیتالی
فناوری اطلاعات با حذف موانع و مرزهای جغرافیایی فاصله‌های فیزیکی را از میان برداشته است و از این طریق مسائل و مشکلات بسیاری را حذف کرده است اما در عین حال، این نگرانی و معضل را نیز با خود به ارمغان آورده است که فناوری اطلاعات منجر به جداسازی و ایجاد انفکاک بیشتری در بین اقشار اجتماعی شود و جامعه‌ای را بوجود آورد که به دو بخش <برخوردار> و <غیربرخوردار> از فناوری تقسیم شده است.
در نتیجه، این روند با خطر شکل گیری طبقه بندی‌های تازه‌ای در جهان، نابرابری‌های جدید فرهنگی و علمی همراه باشد. مسائلی مانند کیفیت، دسترسی، برابری و توجیه هزینه در این رابطه قابل طرح هستند. علاوه بر اینکه موضوع دسترسی در ارتباط با طبقات اجتماعی، جنسیت و حرفه طبقه بندی می‌شود، نابرابری‌های منطقه‌ای زیادی در میزان دسترسی به زیرساخت و تجهیزات فناوری وجود دارد. دسترسی به شبکه ارتباطی و اطلاعاتی برای بسیاری از مردم جهان امکان پذیر نیست. آمارها نشان می‌دهند که درحال حاضر تنها یک نفر از هر 20 نفر در دنیا به اینترنت دسترسی دارند و بیشتر آنها نیز در اروپا یا آمریکای شمالی زندگی می‌کنند که فقط پنج جمعیت جهان را تشکیل می‌دهد. این درحالی است که در سراسر آفریقا فقط 14 میلیون خط تلفن یعنی کمتر از شهرهای مانهاتان یا توکیو وجود دارد. با این حساب قریب به 80 درصد جمعیت دنیا هرگز امکان اتصال به اینترنت را نداشته‌اند.
در ایالات متحده که تلویزیون و تلفن در منازل به حد اشباع رسیده است و دسترسی به فناوری اطلاعات در سطح بسیار بالایی است، هنوز تفاوت فاحشی بین کاربران مختلف فناوری اطلاعات در اقشار اجتماعی مختلف به چشم می‌خورد. در سال 1998 حدود 40 درصد خانوارها در ایالات متحده کامپیوتر شخصی داشتند اما فقط 25 درصد خانوارهای سیاه پوست و اسپانیایی تبار دارای کامپیوتر شخصی بودند.
در سال 2000 تقریبا یک سوم جمعیت ایالات متحده در خانه‌های خود از اینترنت استفاده می‌کردند اما این رقم برای اسپانیایی تبارها فقط 16 درصد و برای سیاه پوستان کمتر از 19 درصد بود. در نتیجه طی یک دوره کوتاه بین 1998 و 2000 شکاف دسترسی به اینترنت بین جمعیت سیاه پوست و میانگین ملی از 15 درصد به 18 درصد و برای اسپانیایی تبارها از 14 درصد به 18 درصد افزایش پیدا کرد.
در انگلستان هنوز کامپیوتر شخصی در بیشتر خانوارها نفوذ پیدا نکرده است و حدود دو سوم خانوارها در انگلیس کامپیوتر شخصی ندارند و دسترسی به اینترنت از خانه‌ها فقط برای اقلیتی محدود فراهم است. درحال حاضر نیمی از کسانی که در انگلیس به اینترنت دسترسی دارند از اقشار بسیار بالای جامعه هستند.
به تمام اینها باید وضعیت قاره آفریقا که جایگاه اکثریت کشورهای غیرتوسعه یافته است را اضافه کنیم که زیرساخت فناوری اطلاعات از کمترین میزان گسترش برخوردار است اما در درون آفریقای جنوبی نیز سفیدپوستان دارای تعداد بیشتری تلفن نسبت به رنگین پوستان در منازل خود هستند و از امکانات بیشتری در بهره گیری از اینترنت نسبت به سایرین برخوردارند.
جهان همواره از دو بخش <برخوردار> و <غیر برخوردار> تشکیل شده است. شکاف اجتماعی نوین <شکاف دیجیتال> است. یعنی فاصله بین کسانی که از منافع فناوری نوین بهره‌مند هستند و آنهایی که از آن بی‌بهره‌اند. این اطلاعات و آمار نشان می‌دهند که این موضوع شکاف دیجیتالی به یک چالش جهانی مبدل شده است و برای همین هم لازم است با دیدگاه کلانی برای حل آن اقدام کرد.
شکاف دیجیتال یک واقعیت است. تقریبا 90 درصد کاربران اینترنت در کشورهای توسعه یافته هستند که روی هم رفته 16 درصد جمعیت جهان را تشکیل می‌دهند. آفریقا و کشورهای عربی فقط یک درصد جمع کاربران اینترنت جهان را دارا هستند. این ارقام گویای آن است که بخش بزرگی از جمعیت جهان از پیشرفت‌های فناوری دور مانده است و هنوز در عصر پیش از جامعه اطلاعاتی زندگی می‌کند.
کشورهای درحال توسعه نمی‌توانند این واقعیت را نادیده بگیرند. هیچ گزینه‌ای جز آنکه سطح آموزش جوامع خود را ارتقا دهند، وجود ندارد.
یکی از راه‌های موجود در این امر بهره گیری از فناوری اطلاعات برای جهش به سوی هزاره نوین است. در غیر این صورت، شکاف دیجیتال به رشد خود ادامه خواهد داد هرچند که بسیاری از کشورهای درحال توسعه برای بهره گیری از فناوری‌های دیجیتال کوشش به عمل آورده‌اند ولی کاربرد جدی آن با اهداف آموزشی، هنوز در حد آرمانی دور دست برای آنان باقی مانده است.
حق دسترسی به اطلاعات و انتشار اطلاعات
یکی از مهمترین اصول جامعه اطلاعاتی در ابعاد ملی و بین المللی آن برای تحقق شعار دموکراسی دیجیتالی و اطلاعاتی، دسترسی آزادانه شهروندان دهکده جهانی به اطلاعات و دانش‌های پایه و فنی مورد نیاز است البته این به معنای نقض حقوق معنوی و مادی تولیدکنندگان دانش نیست.
حق دسترسی به اطلاعات عبارت از آگاه سازی، فراهم آوری و تسهیل شرایط برای دستیابی مردم کشورهای مختلف به اطلاعاتی است که در اختیار دولت‌ها قرار دارد. به عبارت دیگر در جامعه اطلاعاتی دولت‌ها مالک اطلاعات نیستند بلکه فقط نقش جمع آوری، توزیع و مدیریت اطلاعات را در جامعه به عهده دارند. مفهوم دموکراسی اطلاعاتی و دیجیتالی در دو واژه اطلاعات و ارتباطات نهفته است. به عبارت بهتر در جامعه‌ای که آزادی بیان وجود داشته باشد، اندیشه‌ها بارورتر و در نتیجه دانش‌ها غنی‌تر می‌شوند و بالعکس در جامعه‌ای که آزادی اندیشه مستولی باشد، افراد همیشه چیزی برای نشر و بیان دانش در اختیار خواهند داشت.
با کمی دقت می‌توان به همپوشانی بسیار ظریف و اعجاب انگیزی که بین نقش متعامل آزادی بیان به عنوان ابزار ارتباطی عناصر فعال در جامعه اطلاعاتی و آزادی اندیشه وجود دارد به عنوان موتور دانش ساز و دانشمند پرور پی برد.
لذا می‌توان دموکراسی را زایچه آزادی بیان و آزادی اندیشه شناخت و از این رو در بررسی جایگاه آزادی بیان و آزادی اندیشه در جامعه اطلاعاتی مبتنی بر فناوری اطلاعات باید اینگونه عنوان کرد که در بستر دنیای شبکه‌ای وب جهان گستر که بزرگترین عرصه تعامل اطلاعاتی و ارتباطی مابین مردم جهان است باید امکان دسترسی به این کتابخانه جهانی اطلاعات و پس از آن حق دستیابی همگانی به اطلاعات این کتابخانه برای تمام مردم جهان یکسان باشد و هیچ دولت و کشوری خود را محق نداند که در دو بعد ارتباطی و اندیشه‌ای حقوق دیجیتالی و اطلاعاتی مردم کشور خود و سایر کشورها را زیر پا بگذارد. ‌
تحریم‌های همه جانبه که شامل تحریم‌های اقتصادی، علمی و فنی است، اخراج سایت‌های یک کشور از سرورها، هک، محدودکردن دسترسی ‌ IP آدرس‌های برخی مناطق جهان جزو ناملایمتی‌ها و مشکلاتی است که برخی کشورها در برابر سایر کشورها ایجاد می‌کنند.

انتهای خبر // روزنا - وب سایت اطلاع رسانی اعتماد ملی//www.roozna.com

به نقل از http://www.roozna.com/Negaresh_site/FullStory/?Id=24069&Title
جمعه 31 فروردین‌ماه سال 1386

مدیریت پروژه

طرح پروژه سندی پویاست که می‌تواند در دوره زندگی پروژه تغییر یابد. و همانند ‌نقشه‌‌، جهت‌گیری ‌پروژه‌ را مشخص‌ می‌کند. تصور کلی بر اینست که طرح ‌پروژه ‌معادل دوره زمانی پروژه ‌است. اما دوره زمانی یکی از ‌مولفه‌های طرح ‌است. طرح ‌پروژه ‌محصول ‌عمده فرایند‌ برنامه‌ریزی کلی پروژه است. لذا همه مستندات برنامه‌ریزی را در بر می‌گیرد. برای مثال، طرح پروژه ‌ساخت ‌یک ساختمان اداری جدید نه تنها شامل مشخصات ساختمان ‌است، بلکه بودجه ‌و زمان‌بندی‌، خطرات، پارامترهای ‌کیفیت، عوامل ‌‌محیطی و غیره ‌را نیز در بر می‌گیرد.

اجزای ‌طرح ‌پروژه ‌عبارتند از:

- خطوط ‌‌راهنما: که گاهی اوقات ‌معیارهای کارآیی ‌نامیده ‌می‌شوند. زیرا کارآیی ‌‌کلی‌ پروژه ‌‌با این معیارها سنجیده ‌می‌شود.

- طرحهای‌ مدیریت‌ خطوط ‌‌راهنما: این ‌طرحها شامل ‌مستندسازی‌ مدیریت ‌واریانسها در پروژه هستند.

- سایر محصولات ‌فرایند برنامه‌ریزی: این ‌محصولات ‌شامل ‌طرحهایی‌ برای مدیریت ‌خطر، کیفیت، تدارکات، استخدام‌ و ارتباطات هستند.


مرحله ‌2: تعریف نقشها و مسئولیت ها

-شناسایی ذینفعان- یعنی کسانیکه که به پروژه ‌یا خروجی آن علاقمندند. شناسایی ‌ذینفعان ‌چالش‌ برانگیز و در پروژه‌های ‌پر خطر و بزرگ ‌دشوار است.


مرحله ‌3: توسعه بیانیه‌ حوزه کار

بیانیه ‌حوزه ‌‌کار از مهمترین ‌اسناد در طرح ‌پروژه ‌است. این بیانیه برای حصول اتفاق نظر با ذینفعان ‌درباره پروژه ‌به ‌کار می‌رود. این ‌سند در دوره ‌زندگی ‌پروژه ‌رشد و تغییر می‌کند. بیانیه‌حوزه‌ کار شامل:

- نیاز کسب ‌و کار و مساله ‌کسب ‌و کار است

- اهداف ‌پروژه‌، به منظور حل ‌مشکلات ‌کسب ‌و کار

- مزایای انجام پروژه

- حوزه ‌‌پروژه


مرحله ‌4: توسعه‌ خطوط‌ راهنمای ‌‌پروژه

خطوط‌ راهنمای ‌حوزه ‌پروژه. به ‌محض ‌اینکه ‌یافته‌های ‌پروژه ‌در بیانیه ‌حوزه‌ پروژه‌ تایید شدند، باید به صورت ساختار تقسیم فعالیت درآیند. در این حالت، خطوط راهنما شامل همه یافته‌های تولید شده در پروژه است و لذا همه کارهای انجام شده را شناسایی می‌کند. این یافته‌ها باید غیر انحصاری باشند. برای مثال، ساخت یک اداره، یافته‌های بسیاری از جمله نحوه ساخت، توصیه‌ها، طرح‌ها و دورنماها را در بر می‌گیرد.

- خطوط راهنمای زمان بندی و هزینه

- شناسایی فعالیت‌های مورد نیاز برای تولید هر یک از یافته‌های شناسایی شده در خطوط راهنمای حوزه پروژه. شرح مبسوط نحوه وابستگی وظایف‌ به ‌عوامل متعدد نظیر تجربه تیم، خطرات پروژه، عدم قطعیت، ابهام مشخصه‌ها، میزان هزینه مورد نیاز و ....

- شناسایی منابع هر فعالیت

- تخمین زمان مورد نیاز برای تکمیل هر فعالیت

- تخمین هزینه هر فعالیت ‌با استفاده از میانگین نرخ ساعات هر منبع.

- بررسی محدودیت‌های منبع یا زمان واقعی مورد نیاز هر منبع

- تعیین فعالیت‌های وابسته و توسعه مسیر بحرانی

- تعیین تقویم زمانی همه فعالیت‌ها به صورت (هفتگی، ماهانه، فصلی، سالانه)، به عبارتی هرفعالیت به چه میزان زمان نیاز دارد و زمان شروع و پایان آن چه هنگام است.

این فرایند یکباره شکل نمی‌گیرد، بلکه‌ در خلال پروژه، برخی یا همه این گام‌ها تکرار خواهند شد.


مرحله 5: ساخت طرح‌های مدیریت خطوط‌ راهنما

به محض اینکه خطوط راهنمای حوزه، زمان بندی و هزینه پروژه را بنا نهادید، طرح‌های مدیریت این خطوط راهنما، ایجاد می‌شوند. معمولا همه طرح‌های مدیریتی شامل فرایند بازنگری و تصویب برای اصلاح خطوط راهنما هستند. معمولا سطوح مختلف تصویب برای انواع مختلف تغییرات لازم است. همه درخواست‌های جدیدحوزه، زمان یا بودجه پروژه‌ را تغییر نمی‌دهند، اما برای مطالعه درخواست‌های جدید و تعیین میزان تاثیرشان بر پروژه، به یک فرایند نیاز داریم.


مرحله 6 : ارتباطات

طرح ارتباطات ‌یکی از جوانب مهم طرح پروژه ‌است. این سند به موارد ذیل اشاره دارد:

- هر فرد در پروژه چه گزارشاتی، در چه فرمتی و با چه رسانه‌ای را درخواست می‌کند.

- اطلاعات پروژه در کجا ذخیره می‌شوند و چه کسی می‌تواند به اطلاعات دسترسی پیدا کند.

- چه پارامترهایی برای حصول اطمینان از کیفیت محصول مورد توجه قرارگرفته‌اند.

- چه تدابیری برای رویارویی با عدم قطعیت‌ها اندیشیده شده است.

به محض اینکه طرح پروژه تکمیل شد،باید محتوای آن به ذینفعان کلیدی ارائه شود.


مراحل بعدی عبارتند از: اجرا و کنترل طرح پروژه.

توسعه یک طرح شفاف پروژه زمان‌بر است. مدیر پروژه شاید بخواهد هرچه سریعتر به مرحله اجرا برسد. اما اگر برای ایجاد یک طرح شفاف پروژه، زمان صرف کند، به آسانی می‌تواند موفقیت پروژه‌ را تضمین کند.


 نویسنده:شهناز پیروزفر

جمعه 31 فروردین‌ماه سال 1386

مدیریت و کنترل پروژه

 اگر نتایج پیش بینی نهایی برای مدیریت، غیر قابل قبول باشند، گامهای پروژه می توانند به سرعت به سوی نیازمندیهای نهایی تغییر یافته، متمایل شوند. دستاورد نهایی، پروژه های نرم افزاری هستند که با در برداستن تعداد بیشتری از تصویرهای نهایی، توان تکمیل را دارند و این در صورتی محقق می شود که مدیر پروژه بازده هزینه حقیقی را، از لحظه شروع پروژه اعلام نماید. 
2. کلیات

بیش از سه دهه است که EV (ارزش بدست آمده ) به عنوان یک تکنیک اثبات شده و تحت استفاده در مدیریت پروژه، جایگاه خود را برجسته نموده و جای خود را در کنار دیگر ابزار ارزشمند باز کرده است. EV در کاربرد رسمی، به عنوان وسیله ای مؤثر برای نظارت و مدیریت ارشد سیستمهای جدید در مراکز دولتی ایالات متحده شناخته شده است. در یک شکل وسیع، ارزش به دست آمده تکنیکی مفید در مدیریت هرنوع پروژه است که پروژه های نرم افزاری یکی از موارد ویژه کاربردی آن است.


3. مقدمه ای بر مفهوم Earned – Value


الف – تاریخچه

ارزش به دست آمده چند دهه است که از سوی دولت ایالات متحده به صورت سختگیرانه ای برای بسیاری از سازمانها، اجبار شده است تا برای استفاده فرمالیزه و استاندارد از آن جدیت نمایند. نسخه رسمی و استاندارد آن از سال 1967 توصیه شده و این هنگامی بود که سازمان دفاع(DOD) ، سی و پنج معیار سیستمهای کنترل هزینه/زمانبندی (C/SCSC) را بر روی همه مراکز صنعتی خصوصی که خواستار شرکت در سیستمهای عمده دولتی آتی که از انواع قراردادهای هزینه/قابل پرداخت و یا مورد رقابت اکثر شرکتها بودند، در راهنمایی منتشر نمود. پس از آن هر موقع که سیستم عمده جدیدی توسط دولت ایالات متحده آمریکا تهبه می شد که ریسک رشد هزینه توسط آن ارگان ثابت می ماند، این 35 معیار باید توسط پیمانکار رعایت می شد.

اثراجبار C/SCSC مستلزم یک نسخه رسمی و استاندارد از مفهوم "ارزش به دست آمده"مدیریت هزینه و زمانبندی پروژه های عمده انتخابی جدید بود. یک قرارداد به ارزش حداقلی(چندین میلیون دلاری) و یک برنامه زمانی حداقلی(بیش از دوازده ماه)، باید قبل ا ز اعمال معیار، معرفی و تشریح می گردید. معیار ارزش بدست آمده، لزوماً در جهت تهیه سیستم اصلی بودند.

مفهوم C/SCSC بطور ناسازگاری برای بیش از 30 سال به کار گرفته شده و به صورت قالب استاندارد مناسبی برای استفاده در سیستمهای عمده دولتی در آمده است. ارگانها و سازمانهای دیگر دولتی در ایالات متحده و کشورهای دیگر همانند استرالیا، کانادا و سوئد، معیار ارزش بدست آمده مشابهی را در مدیریت استفاده از سیستمهای عمده خود اتخاذ کرده اند.

یک ساختار کاربردی مدیریت علمی در استفاده از مفهوم ارزش به دست آمده، توسعه یافته که عمدتاً توسط DOD (سازمان دفاع) و انستیتو صنعتی نیروی هوایی (AFIT) پیشنهادشده است .

در ادامه بحث به تشریح استفاده عملی از مفهوم ارزش به دست آمده خواهیم پرداخت.



ب – مفاهیم مدیریت ارزش بدست آمده


قبل از بحث درباره استفاده از مدیریت ارزش بدست آمده در برنامه ریزی مدیریت ریسک یک پروژه لازم است که بعضی از مفاهیم پایه روش EV تشریح شود. مهمترین نکته کاربردی مدیریت ارزش بدست آمده، درک مفهوم ساختار شکست فعالیت(WBS : Work Breakdown Structure) می باشد.



ب – 1 ) ساختار شکست فعالیت (WBS)


یک WBS، تقسیم بندی با ساختار درختی یک پروژه به عناصر ترکیبی آن است. یک پروژه بصورت سلسله مراتبی به بخشهای سخت افزاری، نرم افزاری و دیگر وظایف کاری مورد نیاز برای تکمیل پروژه شکسته می شود (این بحث، پروژه های نرم افزاری را مد نظر قرار داده است).

WBS، فقط روند تولید محصول را تعریف نمی کند، بلکه وظایف ضروری کار برای تولید محصول تعیین شده را نیز مشخص می نماید. WBS ابزاری برای سازماندهی اجزای محصول و وظایف کار به یک ساختار قابل شناسایی است که بوسیله آن می توان وظایف جزء را برنامه ریزی، زمانبندی و پیگیری کرد.


WBS با یک عنصر واحد در رأس ساختار درختی شروع می شود که آن، عنصر نماینده کل فعالیتهای پروژه است. این به سطح یک WBS نسبت داده می شود؛ سطوح پایین تر به تناسب، سطوح 2، 3 و ... نامگذاری می گردند.


در ضمیمه 1 نمونه استانداردی از یک مثال WBS برای یک پروژه از دسته بندی توسعه نرم افزار نشان داده شده است.

پایین ترین سطوح یا لایه های WBS دارای معنی و مفهوم با اهمیتی هستند؛ برای اینکه هر لایه، یک عنصر گسسته از کار یا وظیفه ای است که در برابر منابع تخصیص یافته، قابلیت انجام داشته و هزینه و زمان مورد نیاز برای انجام آن، قابل سنجش است.



ادامه بحث ساختار شکست فعالیت (WBS) پروژه نرم افزاری؛

مشخصات بسته کاری(Work Package)


هنگامی که این وظایف(وظایف شکسته شده در بخش قبلی) با پایین ترین سطح، زمانبندی شده و به خود هزینه اختصاص می دهند، بهمراه منابع(انسان و مواد) مورد نیاز و مسؤولیت فردی برای تکمیل آن، بسته کاری(Work Package) را تعریف می کنند. تعریف بسته کاری به مدیریت مؤثر ارزش بدست آمده، بستگی حیاتی دارد. یک بسته کاری(Work Package) باید مشخصات زیر را داشته باشد:


1- بسته کاری(Work Package) واحدهای کاری را در سطوحی که کار در آنجا ایفا می شود، نشان می دهد.

2- از بسته های کاری دیگر متمایز باشد.

3- به یک عنصر منفرد سازمانی، قابل تخصیص باشد.

4- در هر بسته کاری، شروع و تاریخهای تکمیل، زمانبندی شده باشند و مسافت نماهای(milestones) موقتی، کاربردی بوده و حاکی از روند تکمیل فیزیکی باشند.

5- بودجه یا مبلغ معینی داشته باشد که با تعابیر و اصطلاحاتی همچون دلار، نفر-ساعت یا واحدهای قابل اندازه گیری دیگر بیان شود.

6- مدت آن، به یک دوره زمانی کوتاه و نسبی محدود باشد یا توسط مسافت نماهای گسسته ارزش، به قسمتهای جزء تقسیم بندی شده تا اندازه گیری عینی کار انجام شده، تسهیل گردد.

7- با اجزای تفصیلی مهندسی، ساخت یا زمانبندی های دیگر یکپارچه و هماهنگ باشد.

شاید بیشترین انتقاد وارد به استفاده از ارزش بدست آمده در مدیریت ریسک، این تصور است که هرکدام از بسته های کاری در اندازه ای محدود شده اند که در یک دوره زمانی کوتاه و نسبی، قابل تکمیل باشند، یا اینکه شامل مسافت نماهایی گسسته ای هستند که می توان در مقابل بازده کاری، اندازه گیری نمود.

در این مقاله، عبارات و اصطلاحات معتبری به صورت مکرر به کار گرفته شده اند و سعی بر آن خواهد بود که در بخشهای بعدی، به طور ساده ای تشریح شوند.




ب – 2 ) توضیح عبارات و اصطلاحات مدیریت EV


در مدیریت ارزش بدست آمده، 3 کمیت معیارها و قالبهای اساسی برای اندازه گیری بازدهی هزینه می باشند؛ این کمیتها از مجموع هزینه های برنامه ریزی شده و واقعی در فازها(مراحل)ی زمانی محاسبه شده و منطبق با هرکدام از پکیج های کاری هستند(از این پس عبارت پکیج کاری به جای بسته کاری به کار برده خواهدشد) که عبارتند از:

1- هزینه بودجه بندی شده برای کار برنامه ریزی شده(BCWS) یا ارزش طراحی شده(یا برنامه ریزی شده)

2- هزینه بودجه بندی شده کار انجام شده(BCWP) یا ارزش بدست آمده

3- هزینه واقعی کار انجام شده(ACWP) یا هزینه واقعی کار تمام شده

 مقادیر بالا که در شکل 2 نشان داده شده اند، به صورت زیر تعریف می شوند:


Budgeted Cost of Work Scheduled )BCWS)

مجموع بودجه های لازم برای کل پکیج های کاری برنامه ریزی شده، جهت اتمام کار در یک دوره زمانی معین.


Budgeted Cost of Work Performed )BCWP)

مجموع بودجه های لازم برای پکیج های کاری تکمیل شده و اجزای کامل شده پکیج های کاری ناتمام.


Actual Cost of Work Performed )ACWP)

هزینه های واقعی صرف شده جهت تکمیل کارهای اجرایی در یک دوره زمانی معین؛ برای مقایسه متعادل، ACWP فقط برای کار انجام شده ثبت می شود تا در برابر کارهایی که BCWP آنها نیز گزارش شده، موجود باشد.

ب – 3 ) عبارات و اصطلاحات تکمیلی مدیریت EV


از سه کمیت توضیح داده شده در قسمت قبلی، می توان بودجه بندی کل برنامه را همچون تعیین کارآیی زمانبندی-هزینه و تدارک هزینه برآورد شده پروژه ای که در حال تکمیل است، مشخص کرد.

پنج عبارت اضافی نیز، جهت ثبت بازده هزینه و زمانبندی و بودجه برنامه، به صورت زیر تعریف می شوند:


Performance Measurement Baseline)PMB)

بیس لاین اندازه گیری کارآیی

مجموع BCWS کل پکیج های کاری برای هر دوره زمانی، که برای کل مدت برنامه محاسبه می شود. PMB طرح بودجه بندی بر مبنای مراحل زمانی(فازهای زمانی) را در برابر بازده محاسبه شده پروژه ارائه می کند.

Budget At Completion )BAC)

بودجه تکمیلی

مجموع کل بودجه های تخصیصی به یک برنامه، علاوه بر PMB؛

معمولاً مبالغی از ذخیره مدیریت کنار گذاشته می شود که جزئی از کل بودجه برنامه بوده و به پکیج های کاری خاصی اختصاص نمی یابد و برای اهداف کنترلی مدیریت ذخیره می شود. BAC، مشتمل بر کل ذخیره های مدیریتی علاوه بر PMB است.


Schedule Variance )SV)

انحراف زمانبندی

این کمیت از تفاوت میان کار زمانبندی شده (BCWS) و کار انجام شده حقیقی با بودجه تعیین شده (BCWP) به دست می آید. انحراف زمانبندی، با ارزش دلار بیان شده و از تفاضل "مقدار کاری که باید در دوره زمانی داده شده، تکمیل شود" و " کاری که واقعاً با همان بودجه تعیین شده به انجام رسیده"، حاصل می گردد.


Cost Variance )CV)

انحراف هزینه

اختلاف میان هزینه برنامه ریزی شده برای کار انجام شده(BCWP) و هزینه واقعی ناشی از انجام کار(ACWP).

CV هم ارزش حقیقی(به واحد دلار) هزینه های بالاسری(overrunning) و هم غیر بالاسری(under running)(در صورت وجود) را نسبت به هزینه برآورد شده اولیه نشان می دهد.


Estimate At Completion)EAC)

برآورد تکمیلی

این کمیت، هزینه های واقعی تحمیلی پروژه تا زمان حال، به اضافه برآوردی از هزینه های کارهای باقیمانده می باشد. در لحظه شروع پروژه BAC و EAC مساوی هستند؛ این تنها ACWP نامساوی با BCWP است که باعث ایجاد عدم تعادل میان EAC و BAC می شود.



ب- 4) کار با EV

ایجاد برنامه جامع پایین به بالا(Bottom-Up)

باید فرایندهای بحرانی را بگونه ای ترکیب کنیم که هم شامل محدوده کاری مشخص زمانبندی و منابع برآوردشده شوند و همچنین یک برنامه یکپارچه پایین به بالا از اجزاء(سلولها) اندازه گیری شده با تشریح کامل، بوجود آید که برنامه های محاسباتی کنترل(Control Account Plans : CAPs) نامیده می شوند. مدیریت پروژه بر مبنای ارزش بدست آمده مطابق CAPهای تفصیلی، اجرا می گردد به طوریکه در نتیجه، طراحی رسمی(Formal) و پایین به بالای پروژه بدست می آید. CAPهای منفرد، یکپارچگی تمامی فرایندهای بحرانی همچون "محدوده کاری"، "برنامه ریزی"، "زمانبندی"، "برآورد و تخمین" و "اجازه اختیار" را بازنمایی می کنند.

اندازه گیری بازده(Performance) در CAPهای تفصیلی جای می گیرد و بازده کل پروژه از مجموع آنها که در CAPهای تفصیلی انعکاس می یابد، بدست می آید. در اصل، هر CAP پروژه یک زیر پروژه از کل پروژه ای است که توسط یک مدیر CAP، "مدیریت"، "اندازه گیری" و "کنترل" می شود.


زمانبندی رسمی CAP ها

هرکدام از CAP های تعریف شده، باید بهمراه یک سیستم زمانبندی رسمی(formal)، برنامه ریزی و زمانبندی شوند.


تخصیص هر CAP به یک واحد اجرایی جهت بازده(کارآیی)

بمنظور حصول بازده، هرکدام از CAPهای تعریف شده باید به یک اجرای کاربردی پایدار، تخصیص یابند. این تخصیص بطور مؤثری، متعهد اجرا در جهت نظارت بر بازدهی و اثربخشی هر CAP می شود.


فراهم کردن یک baseline که CAP ها را خلاصه می کند

باید یک baseline برای اندازه گیری بازده کل پروژه فراهم گردد، بگونه ای که مجموع CAP های تشریح شده را بازنمایی کند.


اندازه گیری بازده در برابر زمانبندی

باید بازده زمانبندی پروژه را در برابر زمانبندی برنامه ریزی شده و اصلی پروژه، بطور متناوب اندازه گیری کنیم.


اندازه گیری اثربخشی هزینه در برابر هزینه های تحمیلی

باید بصورت دوره ای، میزان اثربخشی بازده پروژه را طوری اندازه گیری کنیم که رابطه میان EV اجرایی پروژه و هزینه های تحمیلی جهت دستیابی به EV را مشخص کند.


پیش بینی هزینه های نهایی بر اساس بازده

باید بصورت متناوب، نیازمندیهای هزینه نهایی پروژه را بر اساس بازده آن در برابر برنامه ریزی، پیش بینی نماییم. 


نویسنده:سحر میرشاهی