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.
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.
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.
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.
|
|
Tip |
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. |
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.
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 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.
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.
|
|
Note |
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.
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.
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.
|
|
Note |
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.
· 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.
|
|
|
|
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.
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.”
|
|
Tip |
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 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.
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.
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.
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.
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.
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.
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
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
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.
برخلاف عقیده کاربران غیرحرفهای اینترنت، سرقت اطلاعات مالی و اعتباری افراد در هنگام استفاده از خدمات بانکی آنلاین، تنها به علت کلاهبرداری (فیشینگ) و یا عملکرد جاسوس افزارها نیست بلکه عوامل و شرایط دیگری نیز در این خصوص باید مورد توجه قرار گیرند.
یکی از این عوامل مهم، اعتماد بیش از حد کاربران اینترنت به عدم قرارگرفتن در معرض حملات مخرب است. بیشتر افراد گمان میکنند که امکان حمله هکرها به رایانه و تخریب سیستم آنها توسط کدهای مخرب بسیار اندک است. <واقعا کدام هکر به خود زحمت میدهد تا اطلاعات بانکی من را که پول کمی در آن وجود دارد، سرقت کند>و یا اینکه <هکرها بیشتر به سراغ میلیونرهایی میروند که در حساب بانکیشان پولهای فراوانی با ارقام نجومی وجود داشته باشد.>
اما این عقیدهای کاملا نادرست است. کاربران باید به خاطر داشته باشند در هنگام اتصال به شبکه اینترنت آنها تنها توسط آدرسهای IP خود شناسایی میشوند و نه خصوصیات شخصی و یا موجودی حساب بانکی. اصولا برای یک هکر و یا خرابکار اینترتی، نفوذ و حمله به رایانهای با آدرس 12.34.56.78 (مثلا در آمریکا) با ورود غیرمجاز و تخریب رایانه دیگری به آدرس 87.65.43.21 (در بلژیک) کاملا یکسان است.
اگر در هر کدام از این آدرسها، حسابهای بانکی وجود داشته باشند که بهصورت آنلاین و اینترنتی مورد استفاده قرار بگیرد، حتی با وجود کم بودن موجودی، باز هم انگیزه خوبی برای هکرها و خرابکاران اینترنتی است که اطلاعات محرمانه مربوط به آن را در اختیار داشته باشند.
کاربران رایانه باید بدانند که بسیاری از مجرمان اینترنتی به پولهای اندک نیز قانع هستند و برای آنها مقداری اندک همیشه بهتر از هیچ است.
خطرات و ریسکهای امنیتی مربوط به خریدهای اینترنتی، نقل و انتقال پول و بررسی حسابهای بانکی بسیار زیاد است اما خوشبختانه راههای کنترل و حذف این خطرات نیز (در صورت توجه و عملکرد صحیح کاربران) وجود دارد.
بیشتر کاربران اینترنت برای پیشگیری از ریسکهای امنیتی در معاملات اینترنتی، معمولا به نصب و استفاده از برنامههای امنیتی با قابلیت ردیابی جاسوس افزارها و تروژانها اکتفا میکنند اما متاسفانه آمارهای موجود نشاندهنده شرایطی است که از وضعیت مورد تصور کاربران بسیار وخیمتر است: خلق و انتشار بیش از هزار گونه مختلف از بدافزارهای رایانهای به صورت روزانه؛ یعنی تقریبا یک بدافزار در هر دقیقه! این بدان معناست که کاربران باید تمام وقت خود را تنها به امن کردن محیط کاری خود اختصاص دهند درحالیکه هیچ وقتی برای انجام کارهای دیگر ندارند.
برخی از کاربران نیز برای دریافت خدمات آنلاین مالی و اعتباری و یا انجام خریدهای اینترنتی، ابتدا نرمافزار امنیتی خود را بهروز میکنند. این حداقل کار صحیح و مناسبی است که انجام میشود زیرا دست کم آنها محیط سیستم خود را از وجود کدهای مخرب شناخته و ثبت شده پاکسازی میکنند اما تهدید دیگری نیز وجود دارد: خلق و انتشار ویروسهای بسیار جدیدی که فقط در عرض چند دقیقه در شبکه اینترنت پراکنده میشوند و تا لحظه شناسایی، ثبت و تولید کد خنثی کننده آنها، قادر به نقوذ در سیستم و ایجاد حملههای مخرب هستند.
باتوجه به تمام شرایط و موارد فوق، توصیه آخر کارشناسان امنیتی به کاربران خدمات بانکی آنلاین، این است که قبل از ورود به وبسایت بانکها و موسسات مالی و دریافت خدمات آنلاین از آنها، حتما با استفاده از آخرین نسخه بهروزرسانی شده یک نرمافزار قدرتمند امنیتی، رایانه و محیط سیستم خود را از وجود بدافزارهای فعال پاکسازی کرده و از فناوری حفاظت پیشگیرانه مانند TruPrevent برای ردیابی و خنثی سازی کدهای مخرب بسیار جدید، ناشناخته و سریعالانتشار استفاده کنند.
بسته به حجم دیسکهای سخت مورد استفاده در رایانههای فعلی و نیز حجم برنامههای مختلف موجود در آنها معمولا زمان بررسی، جستوجو و پاکسازی رایانهها ممکن است قدری زمانبر و طولانی باشد.
برای رفع این مشکل نیز کاربران رایانه میتوانند از نرمافزار نانو اسکن استفاده کنند. این برنامه با قابلیتهای پیشرفته و عملکرد سریع خود میتواند در مدت زمان بسیار کوتاهی محیط شبکه و سیستم کاربران را برای انجام معاملات اینترنتی و استفاده از خدمات بانکی آنلاین، امن و نفوذناپذیر کند.
طرح پروژه سندی پویاست که میتواند در دوره زندگی پروژه تغییر یابد. و همانند نقشه، جهتگیری پروژه را مشخص میکند. تصور کلی بر اینست که طرح پروژه معادل دوره زمانی پروژه است. اما دوره زمانی یکی از مولفههای طرح است. طرح پروژه محصول عمده فرایند برنامهریزی کلی پروژه است. لذا همه مستندات برنامهریزی را در بر میگیرد. برای مثال، طرح پروژه ساخت یک ساختمان اداری جدید نه تنها شامل مشخصات ساختمان است، بلکه بودجه و زمانبندی، خطرات، پارامترهای کیفیت، عوامل محیطی و غیره را نیز در بر میگیرد.
اجزای طرح پروژه عبارتند از:
- خطوط راهنما: که گاهی اوقات معیارهای کارآیی نامیده میشوند. زیرا کارآیی کلی پروژه با این معیارها سنجیده میشود.
- طرحهای مدیریت خطوط راهنما: این طرحها شامل مستندسازی مدیریت واریانسها در پروژه هستند.
- سایر محصولات فرایند برنامهریزی: این محصولات شامل طرحهایی برای مدیریت خطر، کیفیت، تدارکات، استخدام و ارتباطات هستند.
مرحله 2: تعریف نقشها و مسئولیت ها
-شناسایی ذینفعان- یعنی کسانیکه که به پروژه یا خروجی آن علاقمندند. شناسایی ذینفعان چالش برانگیز و در پروژههای پر خطر و بزرگ دشوار است.
مرحله 3: توسعه بیانیه حوزه کار
بیانیه حوزه کار از مهمترین اسناد در طرح پروژه است. این بیانیه برای حصول اتفاق نظر با ذینفعان درباره پروژه به کار میرود. این سند در دوره زندگی پروژه رشد و تغییر میکند. بیانیهحوزه کار شامل:
- نیاز کسب و کار و مساله کسب و کار است
- اهداف پروژه، به منظور حل مشکلات کسب و کار
- مزایای انجام پروژه
- حوزه پروژه
مرحله 4: توسعه خطوط راهنمای پروژه
خطوط راهنمای حوزه پروژه. به محض اینکه یافتههای پروژه در بیانیه حوزه پروژه تایید شدند، باید به صورت ساختار تقسیم فعالیت درآیند. در این حالت، خطوط راهنما شامل همه یافتههای تولید شده در پروژه است و لذا همه کارهای انجام شده را شناسایی میکند. این یافتهها باید غیر انحصاری باشند. برای مثال، ساخت یک اداره، یافتههای بسیاری از جمله نحوه ساخت، توصیهها، طرحها و دورنماها را در بر میگیرد.
- خطوط راهنمای زمان بندی و هزینه
- شناسایی فعالیتهای مورد نیاز برای تولید هر یک از یافتههای شناسایی شده در خطوط راهنمای حوزه پروژه. شرح مبسوط نحوه وابستگی وظایف به عوامل متعدد نظیر تجربه تیم، خطرات پروژه، عدم قطعیت، ابهام مشخصهها، میزان هزینه مورد نیاز و ....
- شناسایی منابع هر فعالیت
- تخمین زمان مورد نیاز برای تکمیل هر فعالیت
- تخمین هزینه هر فعالیت با استفاده از میانگین نرخ ساعات هر منبع.
- بررسی محدودیتهای منبع یا زمان واقعی مورد نیاز هر منبع
- تعیین فعالیتهای وابسته و توسعه مسیر بحرانی
- تعیین تقویم زمانی همه فعالیتها به صورت (هفتگی، ماهانه، فصلی، سالانه)، به عبارتی هرفعالیت به چه میزان زمان نیاز دارد و زمان شروع و پایان آن چه هنگام است.
این فرایند یکباره شکل نمیگیرد، بلکه در خلال پروژه، برخی یا همه این گامها تکرار خواهند شد.
مرحله 5: ساخت طرحهای مدیریت خطوط راهنما
به محض اینکه خطوط راهنمای حوزه، زمان بندی و هزینه پروژه را بنا نهادید، طرحهای مدیریت این خطوط راهنما، ایجاد میشوند. معمولا همه طرحهای مدیریتی شامل فرایند بازنگری و تصویب برای اصلاح خطوط راهنما هستند. معمولا سطوح مختلف تصویب برای انواع مختلف تغییرات لازم است. همه درخواستهای جدیدحوزه، زمان یا بودجه پروژه را تغییر نمیدهند، اما برای مطالعه درخواستهای جدید و تعیین میزان تاثیرشان بر پروژه، به یک فرایند نیاز داریم.
مرحله 6 : ارتباطات
طرح ارتباطات یکی از جوانب مهم طرح پروژه است. این سند به موارد ذیل اشاره دارد:
- هر فرد در پروژه چه گزارشاتی، در چه فرمتی و با چه رسانهای را درخواست میکند.
- اطلاعات پروژه در کجا ذخیره میشوند و چه کسی میتواند به اطلاعات دسترسی پیدا کند.
- چه پارامترهایی برای حصول اطمینان از کیفیت محصول مورد توجه قرارگرفتهاند.
- چه تدابیری برای رویارویی با عدم قطعیتها اندیشیده شده است.
به محض اینکه طرح پروژه تکمیل شد،باید محتوای آن به ذینفعان کلیدی ارائه شود.
مراحل بعدی عبارتند از: اجرا و کنترل طرح پروژه.
توسعه یک طرح شفاف پروژه زمانبر است. مدیر پروژه شاید بخواهد هرچه سریعتر به مرحله اجرا برسد. اما اگر برای ایجاد یک طرح شفاف پروژه، زمان صرف کند، به آسانی میتواند موفقیت پروژه را تضمین کند.
http://www.industryinfobase.ir/cofarsi/cofarsi/science/Article.asp?Id=ARQ1685#ARQ1685
نویسنده:شهناز پیروزفر
منبع:mydocument.ir
اگر نتایج پیش بینی نهایی برای مدیریت، غیر قابل قبول باشند، گامهای پروژه می توانند به سرعت به سوی نیازمندیهای نهایی تغییر یافته، متمایل شوند. دستاورد نهایی، پروژه های نرم افزاری هستند که با در برداستن تعداد بیشتری از تصویرهای نهایی، توان تکمیل را دارند و این در صورتی محقق می شود که مدیر پروژه بازده هزینه حقیقی را، از لحظه شروع پروژه اعلام نماید.
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 را مشخص کند.
پیش بینی هزینه های نهایی بر اساس بازده
باید بصورت متناوب، نیازمندیهای هزینه نهایی پروژه را بر اساس بازده آن در برابر برنامه ریزی، پیش بینی نماییم.
http://www.industryinfobase.ir/cofarsi/cofarsi/science/Article.asp?Id=ARY5259#ARY5259
نویسنده:
منبع:mydocument.ir
فناوری اطلاعات و ارتباطات ، گستره نفوذ و تاثیرگذاری
درگذشته تمدن هایی که در بستری ارتباطی شکل گرفته بودند و دارای امکانات و پوشش ارتباطی توانمند تر و وسیع تر بوده اند ، سرزمین های وسیع تری را در گستره نفوذ خود قرار داده و در پناه این شیوه خردمندانه و بدون نیاز به جنگ و کشور گشایی که همواره نتایج نا مطلوبی در بر داشته و دارند، منابع متنوعی را در اختیار گرفته و توسعه ای پایدار داشته اند .
ساکنین مناطق تحت سلطه این تمدن ها در حوزه های مختلفی از قبیل زبان ، دین ، هنر ، دانش ، ارزش های اخلاقی و اجتماعی ، اقتصاد ، قوانین و اصول حکومت به مشابهت ها و اشتراکات زیادی دست یافته بودند که آنها را تا مرز ایثار در کنار هم متحد کرده بوده است که به عنوان مثال می توان به تمدن ایران باستان اشاره داشت.
امروزه یکی از پیامدهای مهم و قابل توجه توسعه فناوری نوین اطلاعات و ارتباطات شکل گیری فضای جدیدی در بستر اینترنت است که به تعبیر برخی می رود تا عصری با عنوان عصر مجازی را خلق کند.
این فضا ی مجازی در جای جای شئونات فردی و اجتماعی (آموزش و پرورش در تمام سطوح ،تجارت و اقتصاد، سیاست، فرهنگ و هنر ، دین و اخلاق و ...) وارد شده و این ورود، صرف نظر از میمون و مبارک بودن یا نبودن آن در حال تکامل و توسعه است و به تعبیری چشم اندازی از شکل گیری یک ویا بهتر بگوییم چند تمدن جدید را به نمایش می گذارد و قوانین حاکم بر آن نیز در همین فضا تعریف می شود.
ساکنان نواحی مرزی این قلمرو – کاربران جدید- به مرور در این فضا حل می شوند و جوامع الکترونیکی جدیدی بنا می شوند جوامعی که در نهایت سلامت به تولید و توسعه علم می پردازند یا جوامعی که در گنداب ضد ارزش ها غوطه می خورند.
شکاف دیجیتالی
آنچه که امروزه از آن به عنوان شکاف دیجیتالی یاد می شود در واقع معضلی سیاسی – اجتماعی است که بر فاصله بین جوامع ( مبتنی برسلامت معنوی ، مادی و رفاه اجتماعی) دلالت دارد که این خود محصول تفاوت سطح و مهم تر از آن چگونگی بهره جویی جوامع از فناوری اطلاعات و ارتباطات است.
در این حرکت رو به جلو، جوامعی می توانند با حفظ استقلال خود به سوی غایت سعادت گام بردارند که حضوری هوشمندانه و قدرتمند داشته باشند.
نگاهی به مفهوم سواد فناوری اطلاعات و ارتباطات
امروزه بیش از 34 نوع سواد مفید معرفی شده اند ،که سواد علمی با معنای مصطلح آن در نظام آموزشی که در بر گیرنده مفهوم توانایی خواندن و نوشتن است ، تنها یکی از آنها محسوب می شود .دراین باره به عنوان مثال می توان از سواد سیاسی،سواد اقتصادی ، سواد اجتماعی ،سواد رسانه ای و .... نام برد.
سواد ICT از دو منظر اطلاعات و ارتباطات توام با فناوری مرتبط قابل بررسی و تعریف است:
• سواد اطلاعاتی :
اطلاعات را آن چیزی که بتواند در سیستم ذهنی دریافت کننده دگرگونی ایجاد کند و از بی نظمی بکاهد و آن را عبارت
از داده های شکل گرفته و تغییر یافته( به طوری که معنی دار و مفید باشند) می دانند.
اصطلاح سواد اطلاعاتی عموما به عنوان توانایی ارزیابی و سازماندهی اطلاعات به منظور استفاده مطلوب از آنها با ضریب صحت بالا در یک گستره وسیع و متنوع از منابع تعریف شده مطرح می شود .
از دیدگاه وبر و جانسون سواد اطلاعاتی توانایی اتخاذ تدابیر مناسب برای شناسایی اطلاعات مورد نیاز است به گونه ای که دسترسی به آنها به استفاده صحیح ، اخلاقی و مفید در سطح جامعه منجر شود .
به بیانی دیگر سواد اطلاعاتی قابلیتی است که فرد را در ارزیابی انتقادی اطلاعات به دست آمده و استفاده دقیق،موثر و خلاق از آنها به منظور رفع نیازهای اطلاعاتی خویش توانمند می سازد.
• سواد ارتباطات :
از دیدگاه علمای علم ارتباطات، جامعه حاصل برقراری ارتباط بین افراد در سطوح مختلف بوده و ارتباط مبنای شکل گیری یک جامعه می باشد.
تعریف واحدی از ارتباطات که همه را قانع کند وجود ندارد. در 1970، فرانک دنس 126 تعریف انتشار یافته را شناسایی کرد. از نظر برخی معنای آن تبادل متفکرانه دیدگاه ها از طریق یک مکالمه معنادار بین دو انسان می باشد ؛ برخی آن را به پیام ساده ارسال شده، بدون تفکر یا درخواست بازخورد، اطلاق می کنند ، با این تعریف اخیر، می توان گفت ماشین ها و جانوران نیز ارتباط برقرار می کنند.
بنا بر تعبیری سواد ارتباطات را اینگونه می توان تعریف کرد : قابلیتی است که فرد را در ایجاد ، تداوم و تعمیق رابطه با دیگران توانمند می سازد.
با تلفیق دو مفهوم فوق می توان گفت که سواد ICT یا فناوری اطلاعات و ارتباطات قابلیتی است که فرد را در ایجاد، تداوم و تعمیق ارتباط با دیگران به منظور دسترسی ، ارزیابی و استفاده دقیق ، مفید و خلاق از اطلاعات در جهت تامین نیازها ی خویش و دیگران ، توانمند می سازد.
در بیانی دیگر توانایی تفکر در باره اطلاعات و قدرت بازیابی و استفاده ازآن به عنوان یکی از ضروریات زندگی در
قالب ارتباط با دیگران در تعاملی دو سویه و یا چند سویه را می توان سواد فناوری اطلاعات و ارتباطات دانست.
انسان با سواد در عصر حاضر
در عصری که فناوری اطلاعات و ارتباطات تاثیرات و تغییرات شگرف ملموس و غیر ملموس بسیاری را در جوامع و زندگی بشری ایجاد نموده است ، با سواد کسی است که صاحب توانمندی در سه حوزه ذهن – ارتباطات - فن و مهارت بوده و از ویژگیهای زیر برخوردار باشد:
نیاز به اطلاعات را درک کند و بداند که تصمیم گیری مناسب، مستلزم داشتن اطلاعات صحیح و دقیق است.
توانایی تشخیص نیاز های اطلاعاتی را داشته باشد.
بتواند روش های دسترسی به اطلاعات را شناسایی کند.
بتواند استراتژیهای لازم برای جستجو را تبیین و تدوین نماید.
توانایی برقراری ، سازماندهی ، کاربرد و تعمیق ارتباط را داشته باشد.
از مهارت لازم و کافی برای جستجو و در نتیجه دسترسی به اطلاعات بر خوردار باشد.
توانایی مقایسه ،ارزیابی و نقد منابع را داشته باشد.
بتواند از اطلاعات به گونه ای خلاق استفاده کند و آنچه را که به دست آورده به نمایش و اشتراک بگذارد.
همواره در تولید علم مشارکت داشته باشد.
نویسنده:
E-mail:mhaddadi@roshd.ir
منبع:mydocument.ir
Initiation is the formal authorization for the project to move forward. It starts with the identification of a problem, a business need, or a requirement that in turn sparks a project request. Events that trigger a project request are market demand, internal business need, legal requirement, new technology, external customer request, technological change, and social need.
The initial project request needs to be clarified to create high-level requirements, or the product description. High-level requirements and associated cost estimates are presented during a project selection process. This stage may be formal or informal, and may be done on a corporate basis or departmentally.
Project selection techniques involve the use of decision models, such as a cost-benefit analysis and expert judgment, to allocate limited resources to the most critical projects.
Project stakeholders are people who are involved in the project or people who will be impacted by the result of the project. Some project stakeholders you will likely encounter, besides yourself as the project manager, include team members, functional managers, customers (both internal and external), and end users. A project sponsor is a stakeholder who will promote the project and is available to mentor the project team as applicable.
The output from the Initiation process is the project charter. This contains the signature of the person or persons who have the authority to move the project forward. This document will be the basis for more detailed project planning. It should contain the project description, information on the project team, measurable objectives, and a high-level business case.