Project Initiation is the first process in the life of a project. We've already addressed the initial question, "Is it a project?" So this phase serves as the official project kickoff.
The project Initiation phase acknowledges that the project should begin or that the next phase of a project already in progress should begin. For example, prior to the handoff from the Planning phase to the Executing phase, the Initiation phase is revisited to determine whether the handoff should occur.
The first phase in the project life cycle, where project requests are generated and approved or denied. The project charter is produced in this phase, the project manager is appointed, and the organization recognizes that the project should begin.
There aren't any formal rules for project Initiation other than the publication of the project charter, which we'll cover in a later section of this chapter. Generally what occurs during this process is that a project is proposed due to a need or demand. A selection committee, or perhaps the senior director or manager, reviews the project request and its accompanying details and then makes a decision whether to undertake the project. Following a "go" decision, the project charter is created and approved, resources are committed, and a project manager is assigned.
The following graphic illustrates how the Initiation process works. Needs or demands create requests for projects, and that in turn kicks off the Initiation phase of the project. The output of this phase is the project charter. The project charter then becomes an input into the Planning process, which is the next phase in the project life cycle.
How Projects Come About
The VP of Sales strolls into your boss's office one day and asks for a little assistance. Ms. VP is interested in purchasing a system that will help her staff profile potential customers. The sales department has satellite offices over a six-state region, and each of these offices needs access to the system. Since this is an IT system, and you work in the IT department, Ms. VP thinks it's a good idea to let your department run with the project.
Your boss was mightily impressed with the last project you successfully completed and decides you'd be the perfect candidate for this project. It will stretch your skills and give you even more experience in the project management arena. You jump at the opportunity.
You know that this is a project: There are definite beginning and end dates, it's unique, and it's temporary in nature. Even though Ms. VP is planning to purchase this system from a vendor, the implementation of the system is a project that will require the participation of members from both the sales department and the IT department. This new system will interface with existing systems the IT department manages currently.
This project came about as the result of a business need. Ms. VP would like to increase sales for the organization, and she thinks this new tool will help her sales team accomplish that goal. Organizations are always looking for new ways of generating business. It seems that some of the most common business concerns today include operating more efficiently, saving time or money, and serving customers with higher levels of excellence than their competitors. These are some of the reasons behind new project requests. Now we'll look at all the categories of needs and demands that generate projects.
Project Generators—Needs and Demands
There are six needs or demands that drive almost all projects. Understanding why a project came about will sometimes help you clarify the goals and scope of the project. For example, if you understand that a project is being driven by a legal requirement, you'll know that the project is required to be completed according to specific conditions and that there are certain aspects of this project that cannot be compromised. The new law may require certain specifications, and those specifications become the requirements for the project. Below is a brief description of the categories of needs and demands that bring about projects.
Business need:The customer-profiling project that this section opened with came about because of a business need. This organization would like to increase sales by examining its customer base and allowing sales team members to use the information to improve the number of "yes" responses they get. Business needs (such as improving efficiency, reducing costs, and utilizing resources efficiently) are very common reasons for new project requests.
Market demand:The needs of the marketplace can drive new project requests because of changes in the economy, changes in the supply and demand cycles, and so on. As an example, the auto industry may initiate a new project to design and create cars that run on a combination of electricity and gasoline because of a decrease in the supply of oil.
Customer request:Customer requests can generate any number of new projects. Keep in mind that customer requests can come from internal customers or from customers that are external to the company. If you're looking at it from the perspective of the vendor, the customer-profiling project given in the opening of this section is an example of a customer-driven project. Your organization, the customer, has purchased a profiling system from the vendor. Your organization has some specific requirements that must be met regarding this system prior to installation. From the vendor's viewpoint, you are the customer and the purchase and customization of this product to suit your own organization's purposes (a customer request) are what are driving this project.
Legal requirement:Projects driven by legal requirements come about for as many reasons as there are laws on the books. Perhaps Congress passes a new law requiring warning labels to be placed on certain electrical appliances cautioning users of potential hazards. Producing the labels and attaching them to the appliances, when none were required previously, is an example of a project driven by a legal requirement.
Technological advance: We live in an age of technological advances that seemingly take place almost overnight. Things never dreamed of just a generation ago, such as talking on a wireless phone from almost any location, are taken for granted today. Perhaps you work for a telecommunications organization that provides wireless services. Technological advances in the software available for the handheld devices generate a project to create and introduce a new line of services for business customers that takes advantage of the new software capabilities and generates more profits for the organization.
Social need: Projects driven by social needs may include things like designing and presenting public awareness campaigns about the prevention of infectious disease or creating educational programs for underprivileged children. Social needs can be driven by concerned customers or concerned citizens. Perhaps the organization's customers put pressure on the company to develop new methods of testing that reduce environmental hazards or protect water supplies in the countries where the company operates.
Note:Determining the need or demand that's driving the project will help you define the project goals.
Whatever the reason for the project, whether it be a business need or customer request, most organizations require some process by which projects are submitted, reviewed, and selected. In the case of new legal requirements, for instance, your organization may have no choice in the matter since the law requires that the project be undertaken and completed. This is usually the exception, however, as most organizations have a formal process for project selection. We'll examine the project request and selection process next.
Let's go back to the beginning of the customer-profiling project that was requested by the VP of Sales. Projects in this organization go through a two-step process before they become projects. First, the project is submitted to a review committee on a project request form, or a project concept document, similar to the one shown below.
project concept document
Outlines the objectives and high-level goals of the project. Used in the selection process to determine whether the project should be approved or denied.
On the first page of the project concept document you can record general information about the project, including the project objectives and overview, so that review committee members can make decisions regarding whether to actually commence working on the project and where it should fall in priority with the other project work of the organization. The review and prioritization is the second step of the process and occurs prior to actually beginning the work of the project.
The project concept document is the first template that we'll talk about in the project Initiation process. You may want to make changes to this template to suit your organization's needs. Keep in mind that the information provided here should be high-level only. Detailed descriptions and objectives will be required later in the project charter and scope statement. This document should not go over two pages, so don't let the requestor get too carried away with the amount of information on this form since you don't know yet whether the selection committee is going to approve the project. The concept document should contain enough information to make a go/no-go decision but should not detail every requirement of the project. You'll be creating other documents during the Planning process that will give the details of the project, including deliverables, requirements, and so forth. The project concept document form should contain these basic elements:
The second or last page of the concept document has two sections. One is for the project manager—or perhaps a functional manager if a project manager has not yet been assigned—to fill out. This section should include high-level planning estimates. This will give the review committee an idea of how long the project is going to take to complete. It should also include a list of the other business areas in the organization that will be impacted if the project proceeds.
The last section of this page is for the review committee. This section has an area that indicates that the review committee has reviewed the request, the date reviewed, and whether the project has been accepted or denied. Providing an area for signatures is a good idea as well.
This is the first document you will file in your project notebook. It's an official project document that can be shared with anyone who asks. You'll reference this document when preparing the project charter. That occurs after the project has been officially approved by the review committee.
Selecting and Prioritizing Projects
Project selection is the next step in the process. But many organizations do not have a formal selection process. Rather, the CIO, or some other senior executive, merely says, "do it," and you have a project on your hands. That's not really the best way to select or prioritize projects. If your organization does not have a formal method for project selection, consider adopting the techniques outlined in this section. You'll likely have more success with the projects you do undertake, and your organization will benefit by weeding out the unprofitable or potentially unsuccessful projects before they even start.
The first task is to establish a selection committee. Review committees or steering committees are formed to review the project concept documents and decide, based on a myriad of criteria, which projects should go forward. Selection criteria can be as simple as someone in the top ranks of the company saying that the project will be done to complex scoring models with multiple criteria to determine which projects are chosen. We'll look at a few of these methods shortly.
Most projects are subject to some type of financial review as well. Organizations are in business to make a profit, unless of course they're a nonprofit organization or a government agency. If they're in business to make money, they're going to be concerned about choosing projects with the greatest potential for revenue. Nonprofits and government agencies aren't concerned with making profits, but they are concerned about getting the greatest utilization out of their operating funds as possible. That means they want to select projects that provide the most benefit for the least cost. Not altogether different from their profit-making partners, their motivation to use resources to their fullest extent possible while receiving the greatest return possible is the same. Let's look at the first category of selection criteria that organizations might use to choose their projects.
Profit and nonprofit companies alike have limited resources and limited amounts of time. As such, they're interested in knowing whether if they invest the time and resources to produce the product of the project, it will be a good investment. Financial calculations can tell you whether the project is likely to produce a good return on your investment. In other words, are you going to get more out of it over the life of the project (or the product the project is going to produce) than you put into it? Financial calculations are also used as selection criteria when comparing and deciding among several projects.
The most common financial methods used as selection criteria include paybackperiod, cash-flow techniques, cost-benefit analysis, and internal rate of return. Below is a brief explanation of each of these techniques. It's beyond the scope of this book to go into the detailed formulas behind each of these calculations. If you're interested in sitting for the PMP exam or the CompTIA IT Project+ exam, you'll need to know these formulas, so I recommend picking up a copy of the PMP: Project Management Professional Study Guide or some other text that explains these formulas.
The amount of time it takes to recoup the original investment.
The payback period is simply the amount of time it takes for the project to pay itself back. The payback period compares the total project costs to the revenue generated as a result of the project and calculates how long it will take for revenues to pay back, or equal, the initial investment. When comparing one project to another of similar size and scope, typically the project with the shortest payback period is chosen.
Discounted cash flow
This goes back to the old saying that time is money. The discounted cash flow technique takes into account the time value of money to determine whether the potential revenue stream for the project is worth more than what it costs to produce the product or service of the project. The idea is straightforward. Money in your hand today is worth more than money you might receive tomorrow. Since you have access to the money today, you could invest it and make a profit, put it in the bank and draw interest, start a small business, and so on. Therefore, money you may receive tomorrow needs to be related to what it's worth today.
discounted cash flow
A financial calculation used to determine the project's worth or profitability in today's value. Used as a selection criteria technique when choosing among competing projects.
Discounted cash flow takes into consideration all of the potential future revenue streams related to today's dollar. As an example, $1,000 two years from now given a 7 percent interest rate per year is worth $1,145 (rounded up) today. This technique is used to compare projects of similar size and scope; typically, you'd select the project with the highest return on investment. If you were choosing between this project with a value of $1,145 and one with a value of $1,023, you'd choose the $1,145 project since it has the higher return value.
Cost-benefit analysis:Cost-benefit analysis compares the costs to produce the product or service of the project to the financial benefits gained from doing so. You should consider all costs when analyzing the cost benefits, including the costs to produce the product, costs to market the product, and ongoing support costs. This is a simple decision tool. If the costs are lower than the expected return, the project will receive a go recommendation.
Internal rate of return Internal rate of return (IRR) is a very complex calculation that is best determined using a financial calculator. IRR calculates the rate you'd have to apply to the present value of the expected cash inflows (in other words, what the cash inflows are worth in today's dollars) to make the cash inflows equal the original investment. Generally speaking, the higher the IRR, the more profitable the project. IRR assumes cash inflows are reinvested at the IRR value.
internal rate of return (IRR)
The discount rate when the present value of the cash inflows, or the value of the investment in today's dollar, equals the original investment. Used as a selection criteria technique when choosing among competing projects.
It works like this. Say your initial investment is $10,000. Further, let's say the value of the future cash inflows in today's dollars equals $12,000. IRR calculates the discount rate you'd have to apply to the $12,000 to make it equal the initial investment of $10,000. (As I said previously, this is most easily determined using a financial calculator.) Internal rate of return, like the other techniques, compares projects of similar size and scope. Projects with the highest IRR are the projects that should be chosen. For example, Project A produces an IRR of 5 percent while Project B has an IRR of 6 percent. In this case, if the project size and scope are similar, Project B should be chosen.
Financial calculations are an easy way to tell the selection committee whether the project is going to be profitable, and they provide a basis to choose among projects. Some organizations set specific standards for the financial goals of a project. For example, the organization may automatically reject projects with an IRR of less than 5 percent. Or perhaps all projects must have payback periods of less than 18 months. If you're proposing a project that has an IRR of 3 percent, you know that it will not receive approval as soon as you do the calculation.
Financial calculations are one method used to select projects and usually carry the most weight. Other methods of selecting projects include scoring techniques based on a series of questions or models that score company goals or project goals against criteria determined by the selection or review committee. Combining scoring methods with financial calculations gives you a very clear picture of which projects to choose. However, neither of these methods is an indicator of project success. You can have great financial numbers and high selection scores but still experience project failure. Good project planning will help you avert potential obstacles as will good follow-through and taking proper corrective actions at the right time. But we're getting ahead of ourselves.
Tip:High scores during the project selection process do not ensure project success. Project success comes about by following standardized, methodical project management processes.
Scoring models can take on many forms, including questionnaires, checklists, and complex models where weights are combined with scores. The table below shows an example of a simple weighted questionnaire.
Table selection Questionnaire
In this example, the review committee members examine the various criteria against the project concept document and assign scores on a scale of 1–5 where 5 is the best score. The scores are totaled and then used to make a final determination regarding the project. The organization may have predetermined rules for project selection, such as one that says all projects with scores lower than 18 are automatically rejected.
Another example is shown below, which is a simplified weighted selection-scoring model. This table shows the same criteria as above but the criteria have been assigned weights according to the goals of the company or as defined by the selection committee.
Table Weighted selection-scoring model
The first column in this chart shows the weight the selection committee has assigned to each of the selection factors. The first entry determines whether the project will adequately address the problem or issue stated in the business justification section of the project concept document. Points in this case are assigned a value of 0–100. The first factor was given 90 points. The weight for this factor is 25 percent, making the final score 22.50 (90 points × 0.25). Each factor is assigned points, and the total score is calculated by adding all the scores together. Finally, all the forms are collected and all selection committee scores are added together for a final overall score for the project.
Selection can take several forms. Perhaps the selection committee feels that one of the factors is so important, say the customer satisfaction factor, that scores lower than 20 are an automatic rejection. Along the same lines, another method might look at total score. All projects with scores that fall below a certain number are automatically rejected. If the committee is choosing between projects of similar size and scope, projects with the highest score will be chosen.
Selection methods can also be used to prioritize projects. Financial calculations and scores can be used to rank projects in the order of most profitable, highest return, or greatest potential for market penetration, for instance.
Every organization has powerful members who seem to get what they want when they want it. There's some dynamic at work here that no one can explain, but if this particular person says, "I want Project A," Project A gets done (unless it is wildly out of the realm of possibility). While your selection committee may use several methods, or combinations of methods, to select projects, don't underestimate the political pull of some managers to get projects approved without much fanfare—maybe even without the approval of the selection committee.
Other Selection Criteria
Scores and financial impacts might be a big part of the picture, but there are other factors that should be taken into consideration when selecting projects as well. In fact, some of the things we'll talk about here could easily be added to a weighted scoring model and rated for selection purposes.
One of the issues that should be addressed regarding all projects concerns choosing projects that are in line with the organization's strategic plans and goals. In some cases, this might seem obvious. For example, say you work for a pharmaceutical company and someone proposes a project to research and develop a new allergy medication for hay fever sufferers. Since researching and marketing new drugs is the company's bread and butter, it's a no-brainer that this project will at least make it to the selection committee for review. Other reasons may exist that could kill the project in the selection stage, but it is fundamentally in keeping with the company's strategic plans.
Now let's suppose you work for a small pharmaceutical company whose focus is researching and developing medications for particular blood diseases. If the hay fever project were proposed to this selection committee…well, the person who proposed it would probably get a little visit from their manager to remind them of what the company focus really is. Chances are this project proposal would never make it to the selection committee because it wouldn't be in keeping with the organization's strategic plans.
Project requestors should be conscious of the overall strategic mission of the company prior to submitting a project proposal. Selection committees might use adherence to strategic plans as one of the criteria in their project selection models as well.
Risks and Impacts
Another area that concerns most organizations is risks and impacts. Risk comes in many forms, but what concerns the selection committee at this stage is risk to the company—be it financial risk, bad publicity, potential product flops and the like, or project risk, such as the potential failure to complete the project or incompatibility with their customers' business practices. A project that puts the company at risk financially will more than likely not be selected. But keep in mind that organizations have risk-tolerance levels just like you and I do. What may seem risky to one company may not be considered high risk at all to another. Be aware of the risk and impacts to the company and the risk-tolerance levels of the organization when submitting projects for selection. We'll cover risk much more in depth in Chapter , "Assessing Risk."
Constraints limit the actions of the project team. Organizations may have pre-established guidelines (constraints) for project work estimates, budgets, and resource commitments. For example, perhaps the organization will not take on any project work internally with completion estimates longer than one year. The same type of restrictions may apply to budgets in that no projects in excess of certain dollar amounts will be approved, or there might be pre-established limits on the number of internal resources allowed for project work. Be aware of constraints that might kill the project before it's even started.
Other constraints may include things such as priority conflicts with other projects already in progress, actions or outcomes that would violate laws, regulations, or company policies, and lack of skills in the technologies needed to create the product of the project.
Note:Not all projects should be worked. Timing issues, constraints, political events, and a variety of other reasons may prevent a "go" decision from the selection committee.
Lack of support from upper management or the project sponsor is another huge red flag. While this may not kill the project up front, it's something you'll want to watch for right from the beginning. Lack of support or commitment tells you right away that you're going to run into problems later on in the project. If you aren't getting much support for the project at this early stage, opt out if at all possible.
Some projects are much more complicated than the organization feels comfortable undertaking. However, the project has such merit that the selection committee doesn't want to just toss it out—in other words, the project sounds good on the surface but more information is needed before a go/no-go decision is made. In these types of situations, a feasibility study might be requested. The feasibility study is sometimes conducted prior to the selection committee review process in anticipation of their concerns, or it can come about as a result of a selection committee recommendation.
A preliminary study that examines the profitability of the project, the soundness or feasibility of the product of the project, the marketability of the product or service, alternative solutions, and the business demands that generated the request.
The purpose of the study is to find out more of the project details, including digging deeper into the business need or demand that brought about the project, and to propose alternative solutions. A feasibility study is generally needed when projects are complex in nature, are larger than the normal projects the organization ordinarily undertakes, require large sums of money to complete, or seek to do something brand new that the organization has never attempted before. Feasibility studies look at things like the viability of the product of the project, the technical issues surrounding the project or product of the project, and the reliability and feasibility of the technology or product proposed.
Feasibility studies should not be conducted by the same people who will make up the final project team. The reason is that project team members may already have formed opinions or have built-in biases toward the study outcome and will sway the results to line up with their biases. I know you would never do this, but you should watch for strong biases among the feasibility team members. If you see personal opinions starting to influence the study outcomes, voice those concerns so that the project gets a fair shake and the results and findings are accurately reported to the selection committee.
Tip:Eliminate bias in the feasibility study by choosing different people to conduct the study than those who are going to work on the project itself.
Some organizations hire outside consultants to conduct their feasibility studies. This is a great way to eliminate personal opinions from influencing the results of the study. Keep in mind, however, that if you hire a consultant to perform the feasibility study, you should not use that same consultant, or their company, to work on the project. Consultants will approach your project having their product or services in mind as the end result of the study (there are those personal biases again) if they know they're going to work on the final project.
The completion and approval of the feasibility study marks the beginning of the Planning process. Before we jump into Planning, though, we have a few more areas to cover in the Initiation process.
Meeting the Stakeholders
Stakeholders are people or organizations who have a vested interest in your project. You as the project manager are one of the stakeholders in the project. The majority of this book is about your role on the project, but, simply put, you're the one responsible for getting the project completed to the satisfaction of the customer on time, on budget, and within the quality constraints. Some of the other primary stakeholders you'll find on most projects are the project sponsor, functional managers, the customer, the project team, and suppliers or contractors who are critical to the completion of the project.
Stakeholders come from all areas of the organization and can include folks outside the organization as well. If your project involves producing products or services that are potentially hazardous, for example, or your industry has specific regulations it must follow, you'll need to include industry or government representatives on your stakeholder list also. Let's look at the role of the project sponsor first, and then we'll explore the responsibilities of some of the other stakeholders you'll have on your project.
Working with the Project Sponsor
We know that projects come about as a result of a need or demand. But someone has to propose the project and describe the results the project is intended to produce. Someone has to win the support of management and convince them to support this project and dedicate time and resources to it until the project is completed. That person is the project sponsor
An executive within the organization who champions the project.
The project sponsor rallies support from the upper ranks and generates a lot of fanfare. The project sponsor finds supporters who'll pledge their involvement and resources and who understand the importance of the project. Finally, support is gained, the project is approved, and the hands-on work is passed off to you, the project manager. The project sponsor doesn't go away at this point but instead becomes a partner with you during the project lifecycle.
The project sponsor usually has the most involvement in the Initiation and Planning phases of the project. This person introduces the project, publishes the project charter, and serves as an advisor to the project manager throughout the project. The Executing and Controlling stages don't require as much involvement on the part of the sponsor except when problems arise. By this point in the project, if everything is going according to plan, meeting with the sponsor and keeping him updated on progress may be the extent of the sponsor's involvement until the celebration phase of the Closing process.
The project sponsor is your best friend, and you'll be doing yourself a favor by treating him as such. This is the person who will go to bat for the team when things aren't going well. This executive will steer you through the inevitable roadblocks that will arise during the course of the project and assist you in getting more resources or put pressure on suppliers to perform if needed.
Tip:The project sponsor is your partner throughout the project and shares responsibility with you for a successful outcome.
The project sponsor will oversee all the project documents you produce and may assist you with the development of the scope and planning documents in particular. A project sponsor typically has the authority to make decisions and to settle disputes. If a problem cannot be resolved any other way, the project sponsor is the one who makes the final call.
In exchange for the support and trail-blazing on the part of the project sponsor, your responsibility as the project manager is to keep the sponsor informed. Don't wait even a minute to inform the sponsor of potential problems or issues. The project sponsor should be the first to hear about project issues or conflicts and should never hear about these things second-hand. Since the sponsor is generally an executive who has the authority to settle disputes and make decisions, don't hesitate to bring problems and issues to his attention to get matters resolved quickly. The sponsor has a vested interest in the success of the project and will work with you, not against you, to help resolve the problems.
Documenting Stakeholder Roles and Responsibilities
Each stakeholder has a different role in the project, and you'll want to clearly understand and document those roles. This will reduce confusion and serve as a reference for the project team when questions come up later in the project about who does what. This information should be filed in your project notebook so it becomes part of the project documentation. When the information is written down, it assures that everyone on the project understands what their role is. And there's no danger of forgetting the information since you've written it down. Remember Einstein's rule—you don't have to memorize things you write down or can look up. If you haven't gotten used to the idea of documenting yet, you will by the time you get to the end of this book. Documenting is going to become your second best friend after the project sponsor.
Try to keep the list of stakeholders to a reasonable number. For example, one representative from the supplier's company might be all you need to list. But you will want to include all the functional managers who will contribute deliverables or provide the services of their department to the project.
Some of these stakeholders will serve on a project oversight or steering committee that's charged with overseeing the management of the project. Not all stakeholders will serve on this committee. You should meet with the project sponsor, who chairs the oversight committee, to decide which stakeholders should be included in the steering committee. The purpose of this committee is to make decisions outside the realm of the project manager's day-to-day issues and to assure that the organization's resources are being applied correctly to meet the project goals and objectives. Remember that if controversy or conflicts arise among the steering committee members, the project sponsor has the final say in all decisions and has the authority to override the decisions of the steering committee if needed.
Make a list of stakeholders (include their names on your chart) and their responsibilities, similar to the example shown in below table, and include this in your project notebook.
Table Stakefolder roles and responsibilities
Your stakeholder list should be more specific than the one shown in this example. I've outlined the generic responsibilities of each of these groups of stakeholders, but you'll want to list their actual responsibility in the project. For example, maybe one of the functional managers on your project will be responsible for installing a new piece of hardware. List that under the responsibility section of your chart. Keep in mind that you aren't going to know everything that's required of the stakeholders at this point, but what you do know should be noted. You'll have an opportunity later to update this chart and to provide additional documentation on responsibilities in the Planning process.
Competing Needs of Stakeholders
Since stakeholders come from various areas of the organization, they have competing needs and interests. This means that one stakeholder's concerns are focused on the aspects of the project that impact their department, information technology as an example, and that another stakeholder has completely different concerns. As the project manager, you'll have to balance these needs and concerns and use those communication skills we talked about in previous topic, "Developing Project Management Skills," to keep everyone informed and working together cooperatively.
Warning:Stakeholders are not always in favor of your project. Get to know the stakeholders and open the lines of communication with them as early as possible. Stakeholders are influential people, and negative comments regarding your project can take hold quickly, generating a lack of cooperation or a lack of commitment from stakeholders and functional managers you're relying on to help the project succeed.
Stakeholders have a lot of other responsibilities on their plate besides this project that will occupy their time and attention. And unfortunately, sometimes not all stakeholders are supporters of the project. They may not agree with the project, they may not like the project sponsor, they may think their own projects have much more merit than this project, and they may have other higher priorities and don't want to be bothered with project duties. There are dozens of reasons why a stakeholder may not be behind the project. Your job is to get to know the stakeholders and establish an open, trusting environment as soon as possible. If you make the extra effort to get to know the stakeholders and understand their issues and concerns, they're much less likely to cause problems later on. If they feel you are really trying to incorporate and address their concerns and you treat them with respect, they'll likely reciprocate. Get to know your stakeholders and the business processes they oversee, because this will help you make decisions later on regarding the scheduling of activities and resource requirements in the Planning phase.
Project Management Related Tutorials
|Business Analyst Tutorial||Strategic Planning for Project Management Tutorial|
|Software Development Lifecycle (SDLC) Tutorial|
Project Management Related Interview Questions
|Business Analyst Interview Questions||Strategic Planning for Project Management Interview Questions|
|Network Monitoring Interview Questions||Software Development Lifecycle (SDLC) Interview Questions|
|Business process outsourcing (BPO) Interview Questions||Project Manager Interview Questions|
|PMP Interview Questions|
Project Management Tutorial
Building The Foundation
Developing Project Management Skills
Initiating The Project
Defining The Project Goals
Breaking Down The Project Activities
Planning And Acquiring Resources
Developing The Project Plan
Executing The Project
Controlling The Project Outcome
Closing The Books
All rights reserved © 2018 Wisdom IT Services India Pvt. Ltd
Wisdomjobs.com is one of the best job search sites in India.