سواد عمومی فناوری اطلاعات و ارتباطات ( ICT) ، ضرورت ملی

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


نگاهی به مفهوم سواد فناوری اطلاعات و ارتباطات
امروزه بیش از 34 نوع سواد مفید معرفی شده اند ،که سواد علمی با معنای مصطلح آن در نظام آموزشی که در بر گیرنده مفهوم توانایی خواندن و نوشتن است ، تنها یکی از آنها محسوب می شود .دراین باره به عنوان مثال می توان از سواد سیاسی،سواد اقتصادی ، سواد اجتماعی ،سواد رسانه ای و .... نام برد.
سواد ICT از دو منظر اطلاعات و ارتباطات توام با فناوری مرتبط قابل بررسی و تعریف است:
• سواد اطلاعاتی :
اطلاعات را آن چیزی که بتواند در سیستم ذهنی دریافت کننده دگرگونی ایجاد کند و از بی نظمی بکاهد و آن را عبارت
از داده های شکل گرفته و تغییر یافته( به طوری که معنی دار و مفید باشند) می دانند.
اصطلاح سواد اطلاعاتی عموما به عنوان توانایی ارزیابی و سازماندهی اطلاعات به منظور استفاده مطلوب از آنها با ضریب صحت بالا در یک گستره وسیع و متنوع از منابع تعریف شده مطرح می شود .
از دیدگاه وبر و جانسون سواد اطلاعاتی توانایی اتخاذ تدابیر مناسب برای شناسایی اطلاعات مورد نیاز است به گونه ای که دسترسی به آنها به استفاده صحیح ، اخلاقی و مفید در سطح جامعه منجر شود .
به بیانی دیگر سواد اطلاعاتی قابلیتی است که فرد را در ارزیابی انتقادی اطلاعات به دست آمده و استفاده دقیق،موثر و خلاق از آنها به منظور رفع نیازهای اطلاعاتی خویش توانمند می سازد.
• سواد ارتباطات :
از دیدگاه علمای علم ارتباطات، جامعه حاصل برقراری ارتباط بین افراد در سطوح مختلف بوده و ارتباط مبنای شکل گیری یک جامعه می باشد.
تعریف واحدی از ارتباطات که همه را قانع کند وجود ندارد. در 1970، فرانک دنس 126 تعریف انتشار یافته را شناسایی کرد. از نظر برخی معنای آن تبادل متفکرانه دیدگاه ها از طریق یک مکالمه معنادار بین دو انسان می باشد ؛ برخی آن را به پیام ساده ارسال شده، بدون تفکر یا درخواست بازخورد، اطلاق می کنند ، با این تعریف اخیر، می توان گفت ماشین ها و جانوران نیز ارتباط برقرار می کنند.
بنا بر تعبیری سواد ارتباطات را اینگونه می توان تعریف کرد : قابلیتی است که فرد را در ایجاد ، تداوم و تعمیق رابطه با دیگران توانمند می سازد.
با تلفیق دو مفهوم فوق می توان گفت که سواد ICT یا فناوری اطلاعات و ارتباطات قابلیتی است که فرد را در ایجاد، تداوم و تعمیق ارتباط با دیگران به منظور دسترسی ، ارزیابی و استفاده دقیق ، مفید و خلاق از اطلاعات در جهت تامین نیازها ی خویش و دیگران ، توانمند می سازد.
در بیانی دیگر توانایی تفکر در باره اطلاعات و قدرت بازیابی و استفاده ازآن به عنوان یکی از ضروریات زندگی در
قالب ارتباط با دیگران در تعاملی دو سویه و یا چند سویه را می توان سواد فناوری اطلاعات و ارتباطات دانست.
انسان با سواد در عصر حاضر

در عصری که فناوری اطلاعات و ارتباطات تاثیرات و تغییرات شگرف ملموس و غیر ملموس بسیاری را در جوامع و زندگی بشری ایجاد نموده است ، با سواد کسی است که صاحب توانمندی در سه حوزه ذهن – ارتباطات - فن و مهارت بوده و از ویژگیهای زیر برخوردار باشد:
 نیاز به اطلاعات را درک کند و بداند که تصمیم گیری مناسب، مستلزم داشتن اطلاعات صحیح و دقیق است.
 توانایی تشخیص نیاز های اطلاعاتی را داشته باشد.
 بتواند روش های دسترسی به اطلاعات را شناسایی کند.
 بتواند استراتژیهای لازم برای جستجو را تبیین و تدوین نماید.
 توانایی برقراری ، سازماندهی ، کاربرد و تعمیق ارتباط را داشته باشد.
 از مهارت لازم و کافی برای جستجو و در نتیجه دسترسی به اطلاعات بر خوردار باشد.
 توانایی مقایسه ،ارزیابی و نقد منابع را داشته باشد.
 بتواند از اطلاعات به گونه ای خلاق استفاده کند و آنچه را که به دست آورده به نمایش و اشتراک بگذارد.
 همواره در تولید علم مشارکت داشته باشد.
نویسنده:محمود حدادی

E-mail:[e-mail]

منبع:mydocument.ir

Chapter2-5:Summary

Summary

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.

Chapter2-4:Project Charter

Project Charter

The result of the Initiation planning process is the project charter. This document provides formal approval for the project to begin and authorizes the project manager to apply resources to the project. This is a major milestone, as the charter is the first official document of your approved project. All that hard work in the Initiation process has finally paid off.

The person or group approving the project issues the project charter. If your organization has a formal project selection committee, it may define who issues the project charter. This is typically someone in upper management, but this will vary between companies or departments. It may or may not be the project sponsor.

The charter is the project blueprint; similar to the blueprint you develop if you build a new home. The finished product will look a whole lot different, but at least you now have a map to help you get started.

Organizational standards drive the specific format of a project charter and the information it contains. As a project manager, you always want to determine if there is a template or required format to follow. At a minimum, your charter should contain a description of the project, the business need that created the project, and formal approval for the project to begin. If your project was involved in a formal selection process, you will have more data and can develop a project charter that contains the project description, project team information, goals and objectives, high-level business case, and formal approval.

Let’s discuss the components of a charter in more detail.

Real World Scenario—IT Project Descriptions

An IT project description needs to be a quick-read paragraph that encapsulates and describes in a few sentences what the project’s product will do. It documents the key characteristics of the product or service that you’re going to create as well as the work required to deliver the project.

The following are some examples of IT project descriptions:

• IT will create a set of computer programs and databases that will allow the vehicle service department to track all warranty work performed on any given vehicle. The system will be intranet-based and accessible via browser from any computer in the environment. The database will contain fields to house all relevant pieces of information for warranty work performed by the department. Reports will be generated that can be electronically shipped to the vehicle manufacturer for reimbursement. Drop-downs using lookup tables will be provided on the user interface wherever possible to minimize data entry time and incorrect data entry. Consistency checking will be performed on key fields that require double-checking of the data (such as VIN).

• IT will assemble a bar-code system so that two assembly-line employees can scan all parts coming off of the line and enter them into a database tracking system. The system will consist of two PCs connected to the network and the company’s ERP system. The assembly-line technicians will affix a bar code to the item, scan it, then key in pertinent data relative to the item. The data will be subsequently posted to the ERP’s equipment inventory catalog for use by parts persons in the field.

Project Description

The project description documents the key characteristics of the product or service that will be created by the project and the work required to deliver the product. The description in the charter will be high level and more detail will be added when you develop the project scope statement, which is discussed in Chapter 3. The project description documents the relationship between the product being created and the business need that drove the project to be requested. This description needs to contain enough detail to be the foundation for the scope planning process that will be the next step.

Project Team

The project charter should formally identify the project manager and his or her authority. Detailing the project manager’s authority in writing early on will prevent misunderstandings or issues down the road. Authority areas to document include personnel management and budget authority.

• Does the project manager have hiring and firing authority over team members?

• Does the project manager have input into the appraisals or salary reviews of team members?

• Is the project manager authorized to spend the project budget?

• Are there any limits on the dollar amount that can be spent without sponsor or other executive approval?

All known project team members can be listed. A charter does not normally list project team members by name, but lists the category of resources required. Job titles such as Business Analyst, Systems Analyst, Programmer, and Tester can be listed. Charters for cross-functional projects should also list known team members from other departments such as a Product Manager, Marketing Communications Manager, Training Developer, or Contract Specialist.

Goals and Objectives

The charter documents the high-level goals and objectives of the project. The project charter is the first communications document to explain what the project is all about.

A charter needs to include a clear statement as to what end result the project will produce and how success will be measured. Goals and objectives must be clear and stated in such a manner that the end result can be measured against the objective. Instead of stating, “Install a fast customer record retrieval system,” a goal should state a measurable outcome like “Retrieve customer records in an average of 5 seconds.”

Working with the client to document quantifiable and measurable goals is key to the project success. It puts the client, the sponsor, key stakeholders, the project manager, and team members on the same page. Fuzzy objectives with no measurement create vastly different perspectives as to what constitutes project success.

Business Case

Approval of the project charter also marks the initial approval for project funding. The amount of funding initially approved for the project is linked to the business case. A business case formally documents components of the project assessment generated by the project selection process. It includes a description of the analysis method and the results.

A business case is typically a stand-alone document that is initially created at a very high level with multiple iterations over the course of the project. Details to the business case are added at various points in the project planning process. Many organizations have business case templates, with some of the sections completed at the time of project selection.

A business case summary in the project charter may include high-level costs, benefits, and payback period estimates.

Costs  All costs estimated at the time of project approval should be listed. These costs include estimates for materials, equipment, and human resources. The estimates in a project charter are very high-level estimates based on costs of similar projects or estimates from experts familiar with the type of work involved.

In a typical IT project, there are both capital and expense costs. Capital costs would include the purchase of new equipment such as servers or workstations. Expense costs include items like salaries, travel, and training.

Benefits  A key benefit is revenue. Revenue is the cash flow generated by providing a billable good or service to an external customer. Not all projects generate revenue, but for those projects that will be sold to external customers, this is a critical component. The early revenue estimates are provided by the marketing organization based on a target price and a forecast of sales.

Revenue is a benefit that can be quantified and measured. A new product may be projected to bring in $2M in revenue during the first year of product launch.

Other benefits, such as increased customer satisfaction, may be more difficult to quantify. Benefits that cannot be easily quantified in dollars are sometimes referred to as soft benefits.

Payback period  The payback period identifies when the project will pay for itself. For a revenue-generating project, this can be a timeline of the project costs compared to project revenue.

There can also be a payback period on a project that does not generate revenue. A new call handling system with menu options may drive efficiencies in a call center operation that will allow the center to grow without adding additional staff. This cost avoidance figure can be used to calculate when the system will pay for itself.

Formal Approval

The project charter should be signed by the executive with the authority to move the process forward. This person could be the project sponsor, the project client, or a representative of the project selection committee. The key is making sure the person signing the charter is at the appropriate level within the company to authorize the project.

This sign-off provides the project manager with the authority to move forward with the work required to complete the project. This approval may be required prior to the release of purchase orders or the formal commitment of functional managers to provide resources to support the project.

Issuing the project charter moves the project from the initiation phase into the planning phase. Regardless of who actually signs the project charter, now is the time to make sure you have buy-in from your stakeholder group. All of the stakeholders need to receive a copy of the charter. It is also a good idea to schedule a meeting to review the charter, review next steps, and answer any questions or concerns. To eliminate any future disagreements regarding the outcome of the meeting, all key points and any decisions made should be documented in a memo sent to all the stakeholders. Issues that are dealt with as soon as they surface are easier to resolve. Ignoring concerns or not keeping stakeholders in the loop can create escalations to higher management and start your project off on the wrong foot. The support of management is critical and the best way to maintain this support is through ongoing communications. Maintaining consensus among stakeholders is a key part of the project manager’s responsibility throughout the life cycle of the project.

IT Chain of Command

When considering the overall project, especially in context of the charter and the associated names of people in that charter who are able to authorize the resources necessary to enact the project, it will be beneficial for you to understand who’s in the IT chain of command so that you know who is capable of doling out this authorization. While most IT shops are somewhat smallish (i.e., just a few members in each specialty group—servers, programming, etc.) these groups can be broken out among various managers who each have their own budget, and who can call the shots for the employees under them. For example, your project might call for a telephony person, who reports to the telecommunications department, of which there are four or five employees and who have a manager over them who is responsible for their day-to-day operations. This person is one who must appear on the charter because he has the ability to authorize the use of the resources you require. Ditto for programmers, who probably come from a different group, with a different manager. You can’t schedule a telecommunications person using the authorization of the programming manager because she doesn’t manage the telecom folks! So it’s prudent to understand the chain of command that’s involved with any given technological project.

The IT chain of command can vary widely depending on the size and spread of the organization you’re working for. Generally speaking, however, there will always be a supervisor or manager of the software development, network operations, server administration, telephony, security, Internet/intranet, architecture, and database teams.

Typically, these supervisors/managers report to a director-level individual or perhaps even the chief technology officer (CTO) or chief information officer (CIO) (the so-called C-band executives) of the company. This, of course, depends on the company’s size. See Figure 2.1 for an example of the IT reporting hierarchy.

Figure 2.1: The IT reporting hierarchy

In Figure 2.1 you’ll see a department called the project management office (PMO). Some (not all) enterprises have realized that many endeavors benefit from a professional project manager overseeing the project—whether the project is technical in nature or not. So the idea of a PMO was formed—a centralized location for all project managers, staffed and managed by project professionals, and capable of taking on any project in the organization.

The Frustrations of Hierarchy

Because the charter speaks to the types of people who will be required to complete the project (note that we may not necessarily know the names of the people at this point in time, but we do know that we need a certain class of individual) understanding the chain of command makes your job easier when it comes to understanding who’s got to sign off on who’s joining the project. You can’t, for example, stipulate that you need a programmer but not list the head of the programming department as one of the persons who must authorize the usage of his or her resources.

Here’s the problem with a chain-of-command hierarchy in a standard IT shop: The director of applications development’s goals may not be the same as the director of operations. Your job as a member of the project management office (PMO) is to try to get these two on the same page with respect to your project—to see that the outcome of this project is of paramount importance and that the two must agree on this. But that’s not always the case. So you wind up doing a lot of resource allocation planning, working with the leaders of each unit in order to come up with convenient windows of time when the people you need are going to be available. You don’t usually have the luxury of a manager telling you “You can have my best programmer for as long as you need him or her!”

Another similar, only worse, problem arises when the directors of these various units don’t report to the same individual, as shown in Figure 2.2.

Figure 2.2: Business units not associated with the IT hierarchy

Now you’ve got an issue where you not only need to coordinate resources across various managers but also across executive leaders. While the executive might say “Sure, you can use so-and-so!” the manager may not be so wild about the idea. Or vice versa.

Still more confusing is the hierarchy in which the business unit has some IT staff and you also have some IT folks who are going to work on the project. This is similar to the CIO/CTO model shown in Figure 2.2 except that the business unit’s objectives may be quite different than the objectives of executives who are committed to IT. You may well find that you get an initial commitment from the business unit director to use a staff IT person, but that permission is yanked back at the last minute due to other pressing issues. Or you might find that your assigned staff person is a yo-yo, being pulled constantly off of the project in order to put out business unit IT fires.

Unfortunately, there is no really good way to manage such complicated scheduling issues, apart from doing your best to anticipate problems up front and then planning into your project enough leeway to handle such issues. Business unit leaders need to understand that a commitment to an important IT project means that the staff you need are available to you at the time you need them and they cannot be used for other work!

Case Study: Chaptal Wineries Email and Intranet Systems

This case study will follow you through the remainder of the book. It’s designed to be complicated enough to require the use of all of the project management components we talk about, using information from each chapter you read.

You work for a mid-sized winery—Chaptal (named for the process of adding sugar to wine to increase its alcohol level—chaptalization)—in the Sonoma county region of California.

Business has been very, very good! Wine is hot, hot, hot all over the country and your wine maker, Rachel Ranee, has gained in stature and favor throughout the major wine circles.

The owner of the winery, Kim Cox, has decided to set up shop in other interesting parts of the world: Chile, southeastern Australia, and western France. She has established strong partnerships in these areas and is now ready to connect the three sites together into one network so that she can keep track of the daily activities of each new winery. The prospective new wineries are as follows:

France  LaCroix is in the Bordeaux region of France. Chaptal’s partner is Guillaume Fourche, a long-time Bordeaux negociant, one who buys wine from the various smaller wine merchants to blend into interesting cuvees that are then bottled and sold. Kim wants to set up an international distributorship with this man, utilizing Rachel’s wine-making skills to seriously kick up the quality of the wines that LaCroix distributes.

Chile  Metor Sanchez in the Aconcagua Valley has been making wonderful Chilean red wines for several years now. Metor Sanchez is interested in branching out internationally and understands that a partnership such as one through Chaptal would be beneficial for both wineries.

Southeastern Australia  In Adelaide, Australia, a new renegade winery has sprung up. Roo Wines, headed up by a young new upstart wine maker, Jason Jay, holds Kim in a spell with the luscious dark Shiraz wines that they release.

Kim has entered into financial agreements and working partnerships that allow her to own a stake in each of the wine company’s output, while allowing them to retain their original look and feel. The people who work for each entity will ultimately report to Kim, but each endeavor is free to continue doing what it does best. Kim has committed to not creatively interfere.

As the head of IT for Chaptal, you’ve been with the winery since it had one little fileserver on which Kim kept the spreadsheets for the various accounts and Rachel kept track of the residual sugar readings of the grapes.

Today Kim has told you that she wants you to install an email server in each of the other three locations, connecting them so that everyone can quickly communicate with one another. She also wants an intranet site set up so that the new wine releases can be easily pre-released to all sites for comment and approval.

Having just recently passed the CompTIA IT Project+ test, you understand that there are some basic elements you need to capture in this first meeting:

Basic Requirements  You have two requirements that you must fulfill:

1. Set up an email system between the four sites.

2. Set up an intranet.

Stakeholders  Clearly, Kim is the project sponsor, but who will be the stakeholders? In addition to Kim there are three primary stakeholders:

1. Guillaume Fourche

2. Metor Sanchez

3. Jason Jay

But in addition to this list, various staff members will benefit from the new changes. Also, the support entities that assist in the production of the various wines will be stakeholders as well.

Chapter2-3:Project Stakeholders

Project Stakeholders

The refinement of high-level requirements and the project selection process is where you will first interact with a very important group of people: stakeholders. You have probably seen or heard references to project stakeholders. But what exactly is a stakeholder and why is it important to identify all your key stakeholders?

A stakeholder is a person who is either actively involved in the project or is impacted by the project. Stakeholders have something to gain or lose, and you need to meet their expectations. Stakeholders may be interested and involved with the project at different phases.

Some stakeholders may not support your project. A project that creates a major impact on operational procedures may be viewed as a threat. Change can be a frightening proposition. Projects that result in a more efficient business operation may cause a staff reduction. Fear of job loss may cause certain people or organizations to work against a project.

Dealing with your stakeholders is where you will put to use many of the general management skills we discussed in Chapter 1. Individual stakeholders may have very different priorities regarding your project, and you will do a great deal of negotiating with your stakeholder group. Building consensus among a group with diverse viewpoints starts with up-front negotiation during Project Initiation and continues with ongoing communication throughout the life of the project. In Chapter 6 we will discuss Communications Planning in detail, including how you define and implement a communications plan geared to the needs of individual stakeholders.

Set up individual meetings or interviews early on in the project to get to know your stakeholders and understand their perspectives and concerns about the project. These people will not go away, and if you ignore some of your stakeholders, the issues they raise will become more difficult to resolve.

Project Sponsor

The project sponsor is a special type of stakeholder. Although projects have multiple stakeholders, whom we will discuss shortly, there is (or should be) only one project sponsor.

The sponsor is the person who champions the project throughout the organization. The sponsor acts as an advisor to the project manager. The project manager keeps the project sponsor informed of current project status, including conflicts or potential risks. The project sponsor typically has the following accountabilities:

• Provide or obtain financial resources.

• Analyze key stakeholders.

• Negotiate support from key stakeholders.

• Monitor delivery of major milestones.

• Run interference and remove roadblocks.

• Provide political coaching to the project manager.

  Note

  From time to time you might hear a reference to a person called the project champion. The project champion is generally a technical person aligned with the project for the purpose of supporting the project. She is not necessarily one who has a lot of power, but is one who understands the goals of the project and can help you keep the project moving forward.

Other Project Stakeholders

A complete list of stakeholders varies by project and by organization. The larger and more complex your project is, the more stakeholders you will have. Sometimes you will have far more “stakeholders” than you want or need, especially on high-profile projects. I recommend that you define who you think the other stakeholders are on the project and review the list with your project sponsor. He or she is often in a better position to identify what we refer to as “political” stakeholders—influential people in the organization who have expressed a desire to be involved in this project, without a direct or obvious connection. You do not want to ignore these people just because their role is not obvious, and your sponsor can assist you in identifying the needs of these stakeholders.

Some stakeholders are more obvious and much easier to identify. In addition to the project sponsor, the following are generic stakeholders you should find on most projects:

Project manager  We have already talked about the project manager in detail. This is the person responsible for managing the work associated with the project.

Project team members  These are the experts who will be performing the work associated with the project. Depending on your organizational structure, these people may report directly to the project manager, matrix report to the project manager, or simply be provided by another department. Project team members may be assigned to the project either full-time or part-time. Most projects have a combination of dedicated and part-time resources. If you have part-time resources, you need to understand the other obligations of these team members to make sure they are not being over allocated.

Your project team may include only people from other IT groups, or it may include other departments such procurement, legal, public relations, marketing, sales, and customer service.

Functional managers  If your resources are supplied by another organization, the functional managers who assign those resources are critical stakeholders. Normally multiple projects compete for the same resource pool. You need to establish a good relationship with your functional managers. Documented agreements on the amount of time a resource will be available to the project as well as the deliverables the resource is accountable for will prevent future misunderstandings. You should obtain up-front agreement as to your input in such areas as appraisal, salary increase, and bonus opportunity.

The functional manager is the decision maker in these areas. If you approach functional managers with these questions up front, there will be much greater clarity as to your role and your authority.

Customer/Client  The customer is the recipient of the product or service created by the project. In some organizations this stakeholder may also be referred to as the client. A customer is often a group or an organization rather than a single person. A customer can be internal to the company, as would be the case if you were on a project to install a server system for the sales organization. An example of external customers is the people who purchase a new feature.

End user  The term end user denotes the person who directly uses the product produced by the project. This term is often seen in IT projects to distinguish between the organization purchasing the output of the project and the group who will use it on a daily basis. As an example, the sales department may be viewed as the customer for an online order entry system, while the frontline sales consultants are the end users of this system.

End users may participate at some level in requirements review or functional testing of the product.

As you can see from even this generic list, your stakeholders represent a wide range of functional areas and very diverse wants and needs relative to your project. To keep track of everyone, you may want to develop a stakeholder matrix.

Who Are Your IT Project Stakeholders?

Typically your IT stakeholders will come from the corporate business unit(s) requesting the project. Because IT touches virtually every facet of an organization’s business, it’s very likely that as time goes on you’ll encounter a variety of projects from all or a combination of the business units that your particular IT shop supports. You’re likely to encounter three classes of IT projects that will affect specific groups of stakeholders: single business unit projects, multiple business unit projects, or enterprise projects. Let’s talk about each of these in more detail.

Single Business Unit Project

In a single business unit project, you might be approached by a representative from, say, marketing or sales, for example, to help design and build a system that meets a specific business requirement.

Often in such situations you’re presented with a system that the business unit is currently using but is not satisfied with. In a lot of cases, business unit stakeholders have already done some research into what they want and have some recommendations to offer for COTS applications that they think will meet their needs. As a project manager you should scrutinize the software very carefully because it may not meet the scalability requirements that larger shops have. Additionally, if the software being put forward is from another firm that wrote a custom application but is willing to “loan their code” you need to be doubly careful to make sure that the application being considered is solid, reliable, and, most important, supportable by your IT shop.

In some cases, the business unit has no idea about any other software applications that are available to meet a business objective or solve a business problem and they’re coming to you to formulate a project that fulfills the goal. You’re afforded much more leeway in a situation such as this. Generally speaking, COTS applications are so plentiful today that you will probably be successful finding a fairly close match to what the business unit is asking for. However, some instances may require that a new software application be written to custom specifications. It is up to you as the project manager wearing a systems analysis hat (or vice versa) to make the best educated decision about the proper approach to the solution.

Multiple Business Unit Project

Sometimes two or more business units can make use of a system in order to meet business objectives or solve a business problem. Document imaging and management systems (DMS) are an example of this. In a multiple business unit project, you might be approached by two or more business units that have determined that they collectively have enough capital funding to “go in together” on a DMS that they can all use.

Now your task has gotten more difficult because you have a variety of stakeholders involved, all with different agendas, but similar interests. Gaining consensus in such stakeholder environments will be the most important item of the day.

Additionally, you’ll be forced to understand each business unit’s logical flows in order to make collective sense out of the system that you design and build. One business unit, for example, may not require quality control procedures for incoming documents, for example, because they’re already quality checked by the sender due to some regulation or another. But another participating business unit does have a quality control step that they need to continue to maintain. Solving for such stakeholder irregularities makes for interesting project management issues.

Enterprise Project

Another interesting project is one that impacts the entire enterprise. What we mean by the word enterprise is the complete array of business units—everyone in the company or division is affected.

You may not be aware of it, but you’ve probably been a part of or at least interacted in some way with an enterprise project. Two distinct examples come to mind: your organization’s email system and its corporate intranet. All persons interact with each of these enterprise systems, and yet at most probably one group of IT people is involved with each respective system’s maintenance.

Real World Scenario—The Shared DMS

Marvin works as an IT specialist for a business unit in a company. His business unit managers have voiced a need for a DMS in order to scan in old documents and archive them in some DMS software. Any new documents will be electronically submitted and automatically populated into the DMS software.

Another business unit with similar needs has gotten wind of the project and approached Marvin’s managers. Together the managers of both business units have agreed to partner to procure and implement the new system. The other business unit does not have an IT department, so they’ll be relying on Marvin to assist with their implementation. They will be assisting by providing some funding for the project.

Marvin is not the owner of the datacenter, where the new DMS servers will be housed. This function is handled by the central IT shop (called “Ops”) responsible for enterprise operations. He will manage the software on the servers, but Ops will be responsible for maintaining the server hardware and the database on the system.

In this case Marvin has a very complex stakeholder environment. Ops and the other business unit are both stakeholders in the efforts that Marvin’s business unit is making. Success or failure can be had at the hand of any of these stakeholders. If, for example, the second business unit drops their funding, then the project is in jeopardy. If Ops cannot or will not manage the server, the primary business unit will have to find some other workaround, potentially resulting in increased project costs or duration or both. Ops must rely on Marvin’s training in the new DMS software in order to make sure that users can reliably utilize the system.

Enterprise projects bring interesting stakeholder issues. Who are your stakeholders in enterprise systems? Generally, everyone will use the system. So you have to look at representatives from each group as your key stakeholders, or conversely, at certain select groups as the primary stakeholder for the system. For example, when considering a new email system, your corporate records manager; that is, the person or group responsible for setting down document retention policies, will be a very important stakeholder in any decisions you make about the retention of email items. In a new corporate intranet project, all users will be stakeholders, but most likely the content providers for each business unit will be the key stakeholder for the project.

IT Project Team Members

The IT project team has several stakeholders in various positions. The IT project team is different than a team you’re assembling for a construction project. Construction workers work within their own areas of expertise (a plumber doesn’t necessarily care, or have to care, what the electrician is doing, for example). But in an IT team, you have individuals who have specialized in their respective areas of IT and who may well have a clue, perhaps a substantial one, about the other team member’s functions. A software developer has to be fairly database savvy, for example, because he or she will be working extensively with writing data taken from user input screens to a database somewhere. Database administrators (DBAs) must be extremely knowledgeable about the things software developers do, plus they need to understand how servers work and also how users connect to databases across the network wire. Server administrators must understand that their servers are there to support business functions—that the underlying network operating system (NOS) isn’t the sum total of what the server’s about. And woven through it all are systems analysts, business analysts, business subject matter experts, and others who are participating together to bring in the project’s deliverables.

Following is a list of the kinds of people you might expect to join you on any given IT project team, depending on the deliverables you’re trying to produce:

Software developers  Software developers are often called on to work on IT projects. This category of team member may also include folks who specialize in writing programs that run on application servers such as JBOSS, Microsoft BizTalk, or BEA WebLogic; user-interface developers; firmware coders who write software that works inside hardware devices; database stored procedure developers; and Internet/intranet developers and specialized module developers (for things such as printer and communications modules).

Server administrators  These team members are responsible for bringing up the servers (whether Intel-, mid- or mainframe-based) that will house your project.

Database administrators (DBAs)  DBAs are responsible for creating the database schema (structure) and associated requirements, plus planning out the backup and recovery methodologies for the data. DBA work includes the concept of reducing the table structures to their lowest operable form, a process called normalization.

Internetworking specialists  Internetworking specialists are the folks who handle the routers, switches, LAN cabling, and WAN connections.

Telephony specialists  The people who manage the company’s telephone equipment and operations are telephony specialists. It’s amazing how many systems today interoperate with telephony. Think of a telephone-based menu system, called Interactive Voice Response (IVR), realizing that a software developer had to write that code that intercepts the incoming call, provides a menuing system for the user to pick from, then routes the call back out to the appropriate party. The IVR software runs on a server but is connected to the telephony backbone.

Systems analysts  Systems analysts (SAs) are people trained and skilled in IT subjects, but who operate at the functional level of taking the system requirements and boiling them down to a system design specification that the system developers can use to build the project. SAs today use very cool software such as the offerings from Rational that help them quickly and accurately model the system from business flows.

Business analysts  Often one and the same as the system analyst, business analysts (BAs) are able to work at the high level of the business unit in order to understand their needs but are also able to interface with the IT folks to help them understand what it is the business unit really wants. BAs can be IT-savvy folks who come from the business unit, or business-savvy people who are in the IT shop.

System architects  System architects have a very technical level of knowledge about systems and are able to draft out the “blueprint” of the proposed system. Sometimes the system analyst can be the architect; other times, a developer or perhaps even the project manager is in charge of architecture. However, in larger systems, it is not unusual for project managers to use the assistance of an actual system architect.

Budget analyst  Especially in very large projects, a budget analyst is required to keep track of the project’s budget and associated expenses.

Security analyst  The security analyst is a new, yet indispensable character on most systems project teams. The security analyst is the person who makes sure that all security aspects are ironed out. Security is a unique specialty and really requires, especially in mid- to large-sized projects, someone who has a firm background and understanding of the subject.

Technical writers  In larger projects a technical writer is put in charge of writing all of the documentation (with the exception of the comments directly entered into the code) for the project. This includes training documents as well as user manuals, help-desk “cheat sheets” and other documentation.

All of these people must be able to understand technical jargon and acronyms, and be able to fully function and get along with one another. It’s important that these people feel a sense of freedom to be able to question something that’s being done and to work closely with one another in making sure that the right decisions are being made going forward. There is little room for superstars or “Lone Rangers” (those who prefer to work alone and not associated with project teams) in efforts such as these. The project team must consist of a group of people who understand the project’s goals and who come together with a cohesive purpose. Otherwise chaos will occur.

Additionally, people on project teams must be great self-starters, able to work on their tasks with little guidance apart from the system design specification. System project teams are usually not a good place for a beginner to start out because you need folks who have some basis of experience for what they’re being asked to create.

As the project manager of a technical project team you must realize that you’ll be working with a wide variety of personality types and you’ll have to somehow manage the psychology of process accordingly. While you need to have a firm grasp on all of the technological ramifications of the deliverables being created, you must also understand team dynamics and how humans interact with one another in high-stress settings. You should be prepared to handle grievances, to mediate arguments, to gather around a whiteboard and draw out a logical function so all stakeholders understand it, to communicate in one person’s lingo what the other person is trying to say, and so forth. Clear, concise and adequate communications are essential in IT project management.

Real World Scenario—Matching the Project Charter to the Project Team

By writing a good quality project description, you’ll probably have a fairly clear idea of exactly the kinds of people you’ll need on your team before you even start assembling the team. Take, for example, the project description in the sidebar, “IT Project Descriptions”:

“IT will create a set of computer programs and databases that will allow the vehicle service department to track all warranty work performed on any given vehicle. The system will be intranet-based and accessible via browser from any computer in the environment. The database will contain fields to house all relevant pieces of information for warranty work performed by the department. Reports will be generated that can be electronically shipped to the vehicle manufacturer for reimbursement. Drop-downs using lookup tables will be provided on the user interface wherever possible to minimize data entry time and incorrect data entry. Consistency checking will be performed on key fields that require double-checking of the data (such as VIN).”

Clearly you can tell from this short description that you’re probably going to need at least one web programmer. You don’t know yet whether you’ll opt for Java, C#, or some other Internet programming language—that’s not important just yet. You also know that you’re going to need at least one DBA because there are databases to be created. You’ll doubtless need the assistance of a server administrator to assist you in placing the databases and software that you’ll develop. You’ll also need a good BA to help you understand the business processes and translate them into the computer programs.

As you drill into the project a little more, you’ll discover how many of each you need, but for now you’ve at least identified the relevant technology people.

Stakeholder Matrix

If you have a large project with multiple stakeholders, it may be appropriate to create a stakeholder matrix to help you keep track of everyone. A stakeholder matrix should include a list of the stakeholders with the following information on each one:

• Role on the project

• Needs from the project

• Involvement on the project

• Level of influence over the project

This matrix can be a useful tool to review during project execution, as conflicts arise. It can help the project manager understand and deal with various behaviors. It is of particular value if your project has some of the political stakeholders I mentioned earlier.

Since project stakeholders can move on and off the project at different times, it is very important that the project manager reviews the project charter and the project plan as stakeholders become involved in the project.

Chapter2-2:Project Selection

Project Selection

We received a project request and defined and documented the high-level requirements, so it must be time to actually start working on the project—right? A little wishful thinking perhaps, because our project still needs to be approved. The good news is that it is time to move on to the final hurdle to get our project authorized: project selection.

Multiple projects compete for limited budget dollars and human resources. No organization we are familiar with has ever been in a position to complete all the requests for projects that it receives. The organization evaluates project requests to determine which projects will be approved to receive funding and resources. In some instances the client is the sole approver, but often approval is required at a cross-functional or executive level.

An organization can use a number of techniques to select new projects. You need to understand the basic concepts of these techniques, so that you understand how the project selection process works and are prepared to present the appropriate data for your project.

Selection Techniques

Project selection is used to determine which proposed projects are approved to move forward. It usually includes the allocation of high-level funding. Project selection may take place using formal documented guidelines, or it may be informal, requiring only the approval of a certain level of management.

Typically, a high-level board or committee will do project selection. This committee may be cross-functional in nature and accountable for corporatewide project selection, or selection can be done on a departmental basis. A committee at the corporate level is composed of representatives from all corporate departments such as IT, sales, marketing, networking, and customer service. In other companies, an internal IT committee may review and select all IT projects.

Complex projects, especially those involving new technology or a major business process change, may be required to undergo an additional step called a feasibility study prior to review by the project selection committee. This is a more detailed look at the request than what is normally required at initiation. All aspects of the request, including profitability, marketability, risks, and alternatives will be evaluated, typically by people not associated with the project request.

Project Selection Criteria

A project selection committee uses a set of criteria to evaluate and select proposed projects. The selection method needs to be applied consistently across all projects to assure the company is making the best decision in terms of strategic fit as well as the best use of limited resources. The exact criteria varies, but selection methods usually involve a combination of decision models and expert judgment.

Decision Models

A decision model is a formal method of project selection that helps managers make the best use of limited budgets and human resources. Requests for projects can span a large spectrum of needs, and it can be difficult to determine a priority without a means of comparison. Is an online order entry application for the sales team more important than the addition of online help for the customer support team? To the impacted departments, each project is probably viewed as a number one priority. The problem is there may not be adequate budget or staffing to complete both requests, and a decision must be made to approve one request and deny the other. Unless you can make an “apples to apples” comparison of the two requests, the decision will be very subjective. A decision model uses a fixed set of criteria agreed on by the project selection committee to evaluate the project requests. By using the same model to evaluate each project request, the selection committee has a common ground on which to compare the projects and make the most objective decision. You can use a variety of decision models, and they range from a basic ranking matrix to elaborate mathematical models.

There are two primary categories of decision models: benefit measurement methods and constrained optimization models.

Benefit Measurement Methods

Benefit measurement methods provide a means to compare the benefits obtained from project requests by evaluating them using the same criteria. Benefit measurement methods are the most commonly used of the two categories of decision models. Three common benefit measurement methods are cost-benefit analysis, scoring model, and economic model.

A cost-benefit analysis calculates the cost, projected savings, and projected revenue of a project. This model is a good choice if the project selection decision is based on how quickly the project investment will be recouped from either decreased expenses or increased revenue. The weakness of using just a cost-benefit analysis is that it does not account for other important factors like strategic value. The project that pays for itself in the shortest time is not necessarily the project that is most critical to the organization.

A scoring model has a predefined list of criteria against which each project is rated. Each criterion is given both a scoring range and weighting factor. The weighting factor accounts for the difference in importance of the various criteria. Scoring models can include financial data, as well as items such as market value, organizational expertise to complete the project, innovation, and fit with corporate culture. Scoring models have a combination of objective and subjective criteria. The final score for an individual project request is obtained by calculating the rating and weighting factor of each criteria. Some companies have a minimum standard for the scoring model. If this minimum standard is not obtained, the project will be eliminated from the selection process. A benefit of the scoring model is that you can place a heavier weight on a criterion that is of more importance. Using a high weighting factor for innovation may produce an outcome where a project with a two-year time frame to pay back the cost of the project may be selected over a project that will recoup all costs in six months. The weakness of a scoring model is that the ranking it produces is only as valuable as the criteria and weighting system the ranking is based on. The development of a good scoring model is a complex process that requires a lot of interdepartmental input at the executive level.

An economic model is a series of financial calculations that provide data on the overall financials of the project. A whole book can be dedicated to financial evaluation, so we will give you a brief overview of some of the common terms you may encounter when using an economic model: discounted cash flow, net present value, and internal rate of return.

Discounted Cash Flow (DCF)  Discounted cash flow (DCF) compares cash inflows and outflows over the life of the investment. It uses the concept of opportunity cost in discounting the cash flows. There are several measurement methods associated with DCF.

Net Present Value (NPV)  Net present value (NPV) is the discounted value of future cash flows associated with a business activity. NPV measures increase in wealth and assumes that cash inflows are re-invested as capital. It is a measure of marginal return.

Internal Rate of Return (IRR)  Internal rate of return measures the rate of return earned on money committed to a capital investment. IRR states the profitability of an investment as an average percent over the life of the investment.

Constrained Optimization Models

Constrained optimization models are mathematical models, some of which are very complex and require specially trained resources. They are typically used in very complex projects and require a detailed understanding of statistics and other mathematical concepts. Further discussion of these models is beyond the scope of this book.

Expert Judgment

Expertise may be sought regarding the requested product. A project sponsor, key stakeholders, other departments, consultants, or industry groups can provide this expertise.

Expert judgment can be used in conjunction with one of the decision models. We have frequently seen a combination of decision models and expert judgment used if the top project request rankings obtained from a decision model are very close to each other.

Companies with an informal project selection process may use only expert judgment to make project selection decisions. Although using only expert judgment can simplify the data required to complete project selection, there are dangers in relying on this one technique. It is not likely that the project selection committee members will all be authorities on each of the proposed projects. Without access to comparative data, a project approval decision may be made based solely on who has the best slide presentation or who is the best salesperson.

Political influence can also be part of the expert judgment. An executive with a great deal of influence may convince the selection committee to approve a particular project.

Chapter2-1:Receiving a Project Request

Initiation is the formal authorization of a project and is the only process in the Initiation process group.

Before you can initiate a project, you need to have a request. A number of events can drive a new project request. These requests fall into one of the following categories:

• New product development to meet a market demand

• Internal business need, such as a new invoice system

• External customer request

• New technology

• Legal requirement

• Social need, such as infrastructure in a developing country

The manner in which a project request is received can vary widely in different organizations. Requests may come from inside your corporation or from external customers. Your IT organization may have business analysts who are assigned to work with various departments and proactively document departmental requests. The company may have regular interdepartmental meetings to discuss future IT projects. The person from another department making a request for an IT project is often referred to as the client or the customer. We have found that some organizations use the term customer only to refer to people external to the company, while others use customer to refer to the source of either internal or external requests. You need to be aware if there is any distinction in those terms at your company. A customer (either internal or external) may take a project request directly to your VP or CIO.

Regardless of who initiates a request or the event that triggers a request, the organization must review the request and make a decision on a course of action. Even though an initial request may not be detailed, you need to get enough information to adequately evaluate the request. As project manager, you need to meet with the requestor to clarify and further define the request, identify the functional and technical requirements, and document the high-level requirements.

High-Level Requirements

To clarify any project request, you need to develop what the Guide to the PMBOK refers to as a product description . In IT projects, a product description is often referred to as high-level requirements .

The high-level requirements explain the major characteristics of the product and describe the relationship between the business need and the product requested. In order to develop high-level requirements, you need to understand the problem or business need that generated the project request, and the functions you are providing or supporting.

Before you jump into completing your high-level requirements, you need to make sure the problem or need that generated the project request is clearly defined and understood. If the problem is unclear, the solution may be off target. You also need to understand the different categories of requirements and the importance of obtaining both functional requirements and technical requirements.

Defining the Problem

Have you ever been on a project where people are working furiously to meet a deadline, but no one appears to know why the work is being done? Then halfway through the project everything changes or worse yet, the whole thing gets canceled? If this sounds familiar, it may be that a solution was being developed without clarifying the problem. A project can get off to a bad start if the project manager does not take the time to clearly define the problem or need generating the project request.

The customer request may be nebulous and loosely worded. Your job as project manager is to figure out what the customer really means. You need to investigate the customer request and communicate your understanding of the request. This may result in the creation of a project concept document, which represents your first attempt at restating the customer request to demonstrate understanding of the project.

Problems also arise when project requests are proposed in the form of a solution. It is not uncommon, especially in the IT world, for clients to come to you with a very specific request. A client has already identified the solution required to satisfy the request. You may be thinking that is great news, because there is no need to tie up your calendar with a lot of meetings. The problem is, your client may not be asking for the right solution. As a project manager, you need to make sure that the problem has been identified before the solution is proposed.

Let’s say that you get a request for a new billing system, which would be a pretty major undertaking. The first thing you should do is meet with the person making the request to get more information. Why does she need a new billing system? What functionality is the current billing system not providing? What business need or opportunity does she believe this new system will solve? These kinds of questions will help you to understand what is behind the new billing system request. If your client is concerned about the number of customer calls related to general billing questions, the best solution might not be a new billing system, but rather a clearer explanation of the charges or a bill insert explaining each line item on the bill. If she is interested in a new look and feel for the bill, you may be dealing with requirements that range from reformatting the current bill data to using a different paper to print bills. Numerous business needs may cause your client to want a “new billing system,” but many of them may have nothing to do with developing an entirely new application. That is why a good project manager asks questions to uncover what is behind a request. Lack of up-front clarification and problem definition has been the downfall of numerous IT projects. Do not assume that a customer-requested solution is always the best solution until you understand the business need. Clearly defining the problem up front will give you and the client a better starting point for identifying the functional and technical requirements.

Requirement Categories

Once you have a clear idea of the problem behind your client’s request, you must also understand what the client’s requirements/objectives/expectations for the project outcome are. You need to identify three types of requirements: functional, business, and technical requirements.

Functional Requirements

Remember from Chapter 1 that a project produces a unique product. Functional requirements define what the product of the project will do. Functional requirements focus on how the end user will interact with the product. The requirements for a client whose business need is a new bill format are going to be very different than the requirements of a client who wants to introduce a new product or feature. This why it is so important to have the problem defined before you start looking at specific requirements. Knowing the problem will assist you in asking the right questions to identify the client requirements. For a new bill format, you need to know how the client wants the bill to appear. What are the categories of charges and credits? For a new product or feature, you will need very different data. Will this be a one-time fee or a recurring rate or both? If there is a monthly fee, is it a fixed rate or does it vary by usage? Are there discount periods? Is there a contract period or a penalty for breaking the contract?

Applications being used internally are an area where you should use extra caution in defining the requirements. Your client may assume things will work in a certain fashion without explicitly stating that assumption as a requirement. Let’s use a new order entry system for sales consultants as our example. Your client has told you that the system needs to display product availability, generate sales reports, and include a help feature. Although these may sound like good requirements, they are missing some critical data. What drives the product availability? How will the sales reports be generated? What information is included in the help feature? By asking these questions you come up with the following requirements:

• The system will display product availability by wire center.

• The user can generate sales reports online in real time.

• Each product will include a help feature that provides detailed information on the cost, benefits, and usage of the product.

Although functional requirements can be stated in more general terms than technical requirements, as a project manager, you must ask questions to drive out ambiguity. If your client requirement states that a new sales system must be easy for the sales consultants to use, do you know what that means? If the answer is no, you do not have a clear requirement, and you need to define what “easy to use” means to the client. It could be the flow of the screens, built-in help, or other criteria. The client needs to clarify the meaning so the requirement defines the functionality that will make the system easy to use. If you are not sure whether you have a clearly defined requirement, ask yourself how you would create a test scenario to validate the requirement. If there is no way to validate that the requirement has been met, you need to get more data.

Business Requirements

An organization’s business requirements are the big picture results of fulfilling a project. Business results can be anything from a planned increased revenue to a decrease in overall spending. They can even mean that an organization plans to downsize as a result of a project’s outcome.

Technical Requirements

Technical requirements , also known as non-functional requirements, are the product characteristics that are needed so that the product can perform the functional requirements. You can think of technical requirements as the things that happen behind the scenes to meet the client’s request.

There are many categories of technical requirements, and the need to include a specific type varies based on the product being developed. Some of the more common technical requirements include usability requirements, maintainability requirements, legal requirements, performance requirements, operational requirements, and security requirements.

If you work in a regulated industry, make sure you address the question of whether any specific government- or industry-related regulations impact the design or delivery of your product. Regulatory noncompliance is a serious offense and correcting infractions can be both time consuming and costly.

Industry or corporate standards may also impact your technical requirements if you are developing an application with interfaces to existing systems. The application interface may require a specific programming language or methodology. These restrictions need to be documented in the requirements, as they may impact activity duration or cost estimates that are completed in later planning processes.

Examples of technical requirements for an IT project are:

• System response time can be no greater than 5 seconds.

• The system must be available Monday through Saturday from 7 AM to 7 PM.

• The system must run on both PCs and Macs.

Your client may be more prepared to discuss the functional requirements than the technical requirements. You need to be prepared with a list of standard questions. For a new customer service application you can ask for data such as the number of concurrent users, hours of operation, hardware platform, peak busy times, and other elements of the product that could impact the design and development of the new system. If your company has a requirements template or checklist, use it in your meetings with the client group.

Real World Scenario—Assessing the Impact of Regulations and Requirements

Projects often have legislative, regulatory, or other third-party restrictions imposed upon their processes or outputs. For example, suppose that you are managing a project that will create a new IT system for a funds management company, one that’s in the business of managing individual stock portfolios. You can imagine that this company is heavily regulated by the Securities and Exchange Commission (SEC) and that your new system, in turn, will encounter several regulatory guidelines that you must follow. Especially pertinent will be the security aspect of your new system. You must be able to assure the SEC and your shareholders that the system is hack-proof.

It’s important that a project manager be able to not only recognize the need to investigate specific industry regulations and requirements, but also to communicate this need and its associated impact on the project scope and project plan to the stakeholders. Here are a few examples of the many external considerations you need to account for:

Legal and regulatory conditions  Know the statutes covering the type of activity your deliverable involves. If you collect information about customers, are you complying with privacy laws? Do you know which types of encryption can be exported legally? Also, you may face government reporting and documentation requirements or public disclosure rules.

Licensing terms  Suppose that part of your project requires that developers write some code according to a Microsoft application programming interface (API). You need to be well aware of the licensing ramifications associated with using a Microsoft API. Trademark, copyright, and intellectual property issues all enter into this category.

Industry standards  Your project may utilize various interfaces between systems. Is there some standard that governs such things? For example, Microsoft uses the Web-Based Enterprise Management (WBEM) standards to move management data from one place to another. You will need to find out how your new system can use the Windows Management Instrumentation (WMI) interface to provide support for a heterogeneous system that you’re developing. Theoretically, you would need to determine what, if any, specific methodologies or approved coding practices should be used in the implementation of your project.

Considerations such as these will help you refine the scope of the project, thus producing a more accurate project timeline.

Vendor Bids

Occasionally, project initiation depends on the receipt of bids from outside vendors. This situation occurs if the project request involves a new technology that requires outside expertise or if it is known up front that the project timeline cannot be completed internally.

If your project or a key component of your project is going to be completed outside your organization, you may be involved in writing or providing input for a Request For Proposal (RFP) . An RFP is a document that is sent out to of vendors requesting them to provide a proposal on providing a product or service.

Once a vendor is selected, a statement of work (SOW) is completed. The SOW is a description of what product or service the vendor will provide under the terms of the contract agreed to with the selected vendor.

The use of an outside vendor involves unique considerations that would not apply to an internally developed project. The contract is a legal document that needs to be taken into consideration as you move forward to complete the project scope and the overall project plan.

RFPs, SOWs, and contracts are part of Procurement Planning, which will be covered in more detail in Chapter 6, “Additional Planning Processes.”

Documenting the Requirements

Once you have clarified what problem your client is trying to solve and defined the functional, business, and technical requirements, you are ready to start documenting the requirements and complete the product description.

The high-level requirements document is part of the formal request for project approval. It is also the basis for defining the project scope, estimating the cost of the project, identifying the resources required, and developing the schedule. The high-level requirements should contain the following information:

Problem Statement:

What issue or problem generated this request?

What is the specific business need that the client wants to address?

Objectives:

How do you define project success?

What is the end result?

What are the deliverables leading to the end result?

What are the goals?

How are the goals measured?

Strategic Value:

How does this product fit the strategic vision of the corporation?

Is there a link to other proposed or ongoing projects?

Requirements:

What work functions are required?

Are there interfaces to existing systems?

What are the performance criteria?

What are the support requirements?

Timing:

When does the customer need the project completed?

Are there market windows involved?

Are there significant business expenses to be incurred if the project is not complete?

Is there an impact to corporate revenue if the project is delayed?

Historical Data:

Have there been similar projects in the past?

Were they successful?

Can pieces of previous projects be reused for this project?

Clearly defined high-level requirements with measurable objectives and good supporting data regarding strategic value, timing, and relevant historical information on similar projects is critical to project approval as well as ongoing communications regarding the project.

Decomposing Requirements

Objective 2.8 of the CompTIA exam specifications talks about the ability to decompose , or break down, the initial project requirements, as approved by the stakeholders and passed down to the project manager into functional, business, and technical requirements. This means you take the requirements initially given to you and try to boil out the different facets that will make these requirements come about. Then you make a determination as to whether the requirement is functional, business, or technical in nature. Additionally, “maintaining trace ability within strict configuration control”, as alluded to in the objective, means that you’re careful to make sure that the requirements you’ve decomposed continue to match the type of requirement you noted in the first place and you do not allow the requirement to morph into something else. Let’s try an example:

Stakeholder Requirement:  Users throughout the company’s fifty-three campuses will be able to connect to a centralized database system via browser in order to manage sales and inventory information . You and the stakeholders have agreed upon this high-level requirement and you are now ready to decompose this complex requirement into its baser elements.

Decomposition  To decompose the stakeholder requirement, we’ll pick out the main elements and determine the types of requirements these entail.

• Fifty-three campuses  This element of the stakeholder requirement is a business requirement because the company has fifty-three campuses and you’re required to have all of them connect to a central database.

• Centralized database  This element is a technical requirement. You’ll use a single centrally located database for all transaction activity.

• Via browser  This is a functional requirement. The stipulation is that all users will use a browser to connect to the system. (A very right and proper standard and requirement in today’s complex network topographies, we might add.)

• In order to manage sales and inventory information  This is also a functional requirement. You might confuse this as a business requirement, but in actuality you’re saying here that the users are functionally going to do something with the system—they’re going to manage sales and inventory information.

Noting these elements, it is now within your obligation to make sure as you go forward and boil the requirements down even further into the tasks, dependencies, milestones, and resources required, and that you do not violate the spirit of each of these requirements. If, for example, a business unit came to you and said: “We don’t want to connect to a centralized system because our network connection is very slow. This will just serve to slow it down further!” You might be tempted to raise a huge red flag and say “Wait a minute!” But in reality, this business unit has pointed out a fundamental issue that has to be examined for factualness and rectified if true. It does not alter the initial high-level requirement that started the project in the first place.

Note

A number of the elements described in this table will also be included in your scope statement, which will be discussed in Chapter 3, “Scope Planning.”

Chapter 2: ProjectInitiation

THE COMPTIA IT PROJECT+ EXAM TOPICS COVERED IN THIS CHAPTER INCLUDE:

• 1.1 Given a vague or poorly worded customer request or business need, determine the appropriate course of action in order to handle various business- and project-related issues.

• 1.2 Given a set of criteria that outlines an enterprise's minimal requirements for a project charter, together with stakeholder input, synthesize a project charter.

• 1.3 Identify strategies for building consensus among project stakeholders. Select an appropriate course of action involving negotiation or interviewing strategies, meetings, memos, etc.

• 1.4 Recognize and explain the need to obtain formal approval (sign-off) by the project sponsor(s) and confirm other relevant management support to consume organization resources as the project charter is refined and expanded.

• 1.8 Given a project charter or contract including a statement of work (SOW) recognize and explain the need to investigate specific industry regulation requirements and contractual/legal considerations for their impact on the project scope definition and project plan.

• 1.13 Recognize and explain the need to build management buy in and approval into the structure of the project, and describe strategies for doing so.

• 1.15 Recognize the need to conduct a review meeting as the project transitions from the initiation phase to the planning phase. The review should include an assessment of key items.

• 2.7 Describe the goals of 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 functional, business, and technical requirements while maintaining trace ability within strict configuration control.

The Initiation process group is the first of the five process groups that PMI lays out in the Guide to the PMBOK. Initiation covers the receipt of a request through the authorization to start a project. This process can be formal or informal, depending on the organization.

Initiation includes reviewing a customer request with the client to refine and clarify measurable deliverables and to develop a high-level requirements document.

A project selection process or criteria may be used to determine project approval. In this chapter we will discuss the most common methods used for project selection: cost-benefit analysis, scoring models, financial analysis, and expert judgment.

You will learn about project stakeholders: the people with a vested interest in the outcome of the project, including one of the most important stakeholders: the project sponsor.

The end result of the Initiation process is a project charter and the formal assignment of a project manager.

This chapter marks the start of an ongoing IT case study that will be used to demonstrate the application of these process groups.

تولید در دنیای جدید

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

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

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

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

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

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

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

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

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

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

بنابر گزارش‌ سال 94 بانک‌ جهانی‌ با عنوان‌ آزادسازی‌ مبادلات‌ در بخش‌ خدمات‌ بین‌المللی، تقریباً تمام‌ اقتصادهای‌ آزاد که‌ عهده‌دار صادرات‌ عمده سرمایه‌های‌ خدماتی‌ هستند، جهت‌گیری‌ سرمایه‌گذاری‌ مستقیم‌ خارجی‌ خود را به‌ سوی‌ بخش‌ خدمات‌ تنظیم‌ کرده‌اند. از این‌ رو از اهمیت‌ تولید صنعتی‌ برای‌ این‌ کشورها هم‌ چنان‌ کاسته‌ خواهد شد.

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

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

تعدادی از کارشناسان اقتصادی نیز معتقدند در این بازار جهانی، سرمایه‌گذاری‌ بر منابع‌ انسانی‌ می‌تواند، جایگزینی‌ برای‌ رهایی‌ از نگرانی‌های‌ ناشی‌ از هوس‌های‌ گذرای‌ بازار کالاها و مصونیت‌ در برابر تهدید دایمی‌ مازاد تولید در بازارها باشد.

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

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

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

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

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

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