The Project Initiation Phase: How to Start a Project

The purpose of the initiating process is to obtain commitment to start a project. You want the customer or management team, to be able make an informed decision whether to move to the planning process, without spending a lot of money or time.

During the initiating process you identify the problem the project is supposed to solve, and you gather more information to define the project. This information is presented in a document known as the project definition or project summary. In many instances you as project manager, may be assigned with the project after it's been approved.

Writing a problem statement

Every project has a specific goal. The goal of the project is to accomplish something, like solve a problem, or take advantage of an opportunity. This goal drives every decision in the project, so you want to make sure you accurately describe the underlying problem or opportunity. You do this by putting together a document called a problem statement.

A problem statement clearly defines the problem that you are attempting to solve, or the opportunity you are attempting to take advantage of. It doesn't have to be a long winded affair. If you spell out what the problem is in one sentence, all the better.

Defining a problem can be a challenge, because people often jump straight to solutions. Solutions describe the end result of a project, not the beginning motivation. For example end results would be, we need a new building, or we need to increase sales. These are not problem statement, but solutions. One way to backtrack from a proposed solution to the original problem is to ask why. Why do we need a new building? Why do we need to increase sales? Don’t be afraid to ask why, more than once and then probed for more detail as the story unfolds. You can use the answers to get to the bottom of the problem and start uncovering more specific objectives for the project.

The problem statements would be, we don't have enough space for projected growth, or we’re losing sales to our competitors. Write the problem statement for the project you’re working on. Keep it simple. Make sure you are not writing a solution statement. Don’t be afraid to ask why and other questions until you have a clear and simple statement that defines the underlying reason for your project.

Defining project goals and objectives

Now that the problem has been defined, we need to describe what the project is supposed to achieve. We do this by defining a project goal.

A project goal is the high-level target that states the end result that the project will achieve. The goal should be a simple statement, and easy for everyone to understand. That way you can use it to get buy in, and guide the team to a successful conclusion.

Objectives further define the goal, by flushing out specific details. Identifying objectives is important, because they help define the scope, your approach, and the success criteria you have to meet.

Below are several criteria of objectives:

• Business objectives are often strategies or tactics that support your organization’s goals. For example reduce the return rates on orders.

• Financial objectives are all about money. Your organization might require that projects deliver a 15% return on the money invested in the project.

• Quality objectives specify how good results must be. For instance, if your project is supposed to increase customer satisfaction, you might want to increase the number of customer satisfaction ratings.

• Technical objectives. For example you might want to use tough machines that can withstand harsh environments

• Performance objectives is a catch all objectives . For instance your project might need to finish by a specific date, such as your company's product release date.

In writing your document objectives, your objective statement should be:

• Specific.

Specific objectives are clear. So there is no misunderstanding about what you're supposed to achieve. For example host an event that reaches 80% of our customers, and costs no more than $80,000. Vague objectives are bad, because you probably won't get where you want. Be specific when you write your objectives.

• Measurable

Measurable objectives eliminate any question as to whether or not they have been achieved. For instance you can use ratings from surveys to measure customer satisfaction.

• Realistic

Realistic objective spell out what you can do with the resources available. Setting challenging objectives can motivate people but your team might give up if they think the objectives are impossible.

• Time bound

Time related objectives identify when they can be achieved. For example a new product might need to be available in stores before the end of the year. For time related objectives set a clear target date.

Choosing a strategy

Once you know the goal and objectives for the project, you're likely to find that there's more than one possible strategy from which to choose. We will examine how you can evaluate alternative strategies, and select the right solution.

• Create a brainstorming group.

Assemble a small group of people familiar with the project to brainstorm strategies. The brainstorming group should read the problem statement, the goal as well as the objectives, and then begin generating possible strategies. This should be a free flow of ideas. The point is, to get as many ideas written down as possible, before you begin criticising or evaluating strategies.

• Use a decision matrix to compare your options

Once you have a significant number of strategies written down, you will need to begin evaluating those ideas. You can use a decision matrix to compare your options. First, the group should ask, how well does this strategy satisfy the project objectives? One way to quickly shorten the list of contenders is to check whether a strategy satisfies all the must have objectives. If a strategy doesn't satisfy one of your must haves, you don’t have to fill out the rest of the values for that strategy.

• Rate the performance for each objectives

1. For the strategies that pass that first hurdle, rate the performance for each objectives. If some objectives are more important than others, you can increase their rating. The strategy with the highest overall rating is most likely your winner.

2. Then, the group should ask, is this strategy feasible? Strategies that use new technology or unproven methods might not work. If feasibility could be an issue, a feasibility study can explore whether this strategy will work without committing too much time or money.

3. Ask, are the risks of this strategy acceptable? You won’t know all the risks at this stage of a project, but you can perform an initial risk analysis to see whether any risks are so significant, and likely that you don't want to proceed.

4. Ask, does this strategy fit the culture of the organization. Trying to force a strategy that doesn't fit with the culture is a losing battle. You won’t get the commitment you need from management or team members.

Remember the strategy you choose has to satisfy most, if not all of the project objectives. Once you select a solution from the alternative strategies the details of your project will start falling into place.

Gathering requirements

The goal, objectives and solution for a project identify what you're trying to achieve and the general approach for getting there.

Requirements provide the details of what the outcome must look like. They are the specific needs of the project. Gathering requirements is important because if you missed true requirements the customer won't be satisfied with the project results. On the other hand if you include requirements that are not really necessary the project will probably take longer and cost you more than it should.

Gathering requirements can be challenging. Sometimes customers know what they want and sometimes they don't. Customers and stakeholders often mix wish list items with true requirements.

Another hazard is people who aren't stakeholders, often append the requirements onto your to-do list. As the project manager, you have to distinguish true requirements.

There are several techniques for gathering requirements. Each technique has its pros and cons. the best choice of technique depends on your project.

• Re-use existing requirements from project done in the past if your project is similar To do this you'll need documentation from that project. Determine whether some features have become obsolete or new ones have cropped up

• Build a prototype. A prototype is usually a quick and rough model that your customers used to test out an idea. A prototype is great if your customers aren't quite sure what they want.

• Business process modelling and use cases are examples of methodologies for gathering requirements about processes and systems. You may have to train people on the methodology first, or hire people experienced with the tools.

• If your project involves several groups you can hold requirements meetings with representatives from each group to discuss their requirements for the project. These meetings not only help identify requirements but offer the advantage that you may also obtain buy in from the departments that attend. You might want hold separate meetings for different audiences, such as the business team in the IT department.

• You might have one group attend to listen to what other groups need. If you're working on a project to revamp how people work, you can work with the end users directly. One approach is to conduct observations, in other words watch what people do in their day-to-day activities. To make sure you get the requirements right break them up and review them with the workers.

• You can also interview people. It’s a good idea to put together specific questions for the first round of interviews, that way you ask everyone the same questions and don't leave anything out. A second round of interviews can help clarify and refine the requirements.

With your goal in mind, l document your requirements by writing detailed statements of what must be accomplished in a project to satisfy the objectives

Understanding deliverables and success criteria

Deliverables are what people expect to get when a project is done. Deliverables are the products or services that are delivered.

Deliverables can be tangible like a building, software or a new employee. Other times deliverables are more abstract, like a new service. During the planning process, deliverables help you define the project scope, which basically means what is and isn't included in the project.

Once your project gets underway, deliverables then help you measure progress. Breakdowns what the deliverables for your project are.

1. Begin with the end deliverables, which is goods or services that your project delivers at the end of the project.

2. Document your intermediate deliverables. These are items or services that are delivered during the course the project. Keep in mind that the customer doesn't necessarily receive intermediate deliverables.

3. Whenever possible try to define deliverables that can be accomplished in the timeframe between status reports. That way you can evaluate progress based on the deliverables completed since the last report.

4. If a deliverable is too big, breakup your deliverables into manageable pieces.

So now that you have defined your deliverables, how do you know that the deliverables you receive are what you wanted? You need some way to measure them.

Success criteria are definitions of success. Some are easier to figure out like signed vendor contracts, or the certificate of occupancy for a building. Other criteria are not so easy and can be subjective. Therefore to be effective, rate success criteria that are clear and quantifiable.

Identifying assumptions and understanding risks

It's important that you protect your project plan by identifying assumptions and risks early on.

What is assumption?

An assumption is something that someone takes to be true without confirming it. Different people can make different assumptions and if those assumptions aren't brought into the open someone will end up disappointed. Assumptions can be tricky, because people often don't realise they are assuming something. The key is to get assumptions out in the open, that way you can make sure everyone is aligned. Think about uncovering unspoken assumptions as you work through every step of the project plan. Ask questions about what people expect, what they envision when they think about the project. Don’t be shy about asking more than once.

Uncovering unspoken assumptions is almost like being a detective. You ask again and again to see if the story changes. First, ask people to describe the results they expect from the project. Ask them to describe project success. This helps identify objectives that may have been unspoken. If the list you end up with, outstrips the budget or resources you have available, you can negotiate with the team to rate it in.

What is risk?

A risk is a situation or event with some probability of occurring that might negatively affect your project. Risks are events that may or may not rise, but will cause problems if they do occur. Early on a project spent some time identifying risks that could affect the project. Mainly so the management team can make an educated decision about whether or not to invest in the project. If you identify numerous risks and several are quite worrisome it might be better to forego the project for another one.

See Related Articles in Project Risk Management:

• Project Risk Management: Creating a Risk Plan

• Project Risk Management: Identifying Project Risks

• Project Risk Management: Analyzing Project Risks

• Project Risk Management: Responding to Project Risks

• Project Risk Management: Monitoring and Controlling Project Risks

Document assumptions and risks as you flush out what you project is about. That way the customer of the management team can consider all the pros and cons of the project before they decide whether give it an approval to proceed the planning

Creating a scope statement

After you document requirements and deliverables create a scope statement so that what the project is going to do is crystal clear. The project’s scope actually describes the boundaries of the project, that is what is included in the scope of the project, and just as important what isn't included. A scope statement helps you evaluate whether a project is doing what it should -no more and no less- and whether the budget in other aspects make it worthwhile.

The scope statement covers the work and deliverables for which the team is responsible. Your scope statement can also include an out of scope section that indicate work that is not the responsibility of the team.

The out of scope section is a good place to document assumptions about what is outside the boundaries of your project. The scope statement also helps to prevent scope creep, an uncontrolled changes or continuous growth in a project's scope

See related article: Preventing Scope Creep

Customers and team members alike might come up with, this one will thing to add to the project, but those little things add up and before you know it the scope has expanded beyond your budget, beyond your resources, and past the due date.

With a clear scope statement you know what's within scope. If someone wants to add something you can discuss the impact to decide whether or not it makes sense. Because scope statement defines the boundaries of a project at a high level, you will also need a change management process to control the smaller change request that come in.

Sometimes members of your team end up expanding the scope without you knowing about it. Perhaps a programmer adds a feature that she sure the customer would want, even if it isn't in the requirements.

When you assemble your project team emphasized the importance of the scope and the project objectives. Revisit your objectives and deliverables and use them to write a scope statement that identifies what is and is not within the scope of your project. Then review your assumptions and if necessary add items to what is within scope or out of scope for your project.

Identifying stakeholders

The term stakeholder means someone who has a stake in the outcome of project. This includes the customer, the departments affected by the project, and even the people who work on project tasks. Sometimes it can be challenging to determine who the stakeholders are for your project.

Identifying Major Stakeholders Role:

• The Project Customer

The project customer is the person or group who has a problem to solve. The project customer brings three crucial things to a project.

1. They fund the project.

2. They have a lot to say about what the project will do.

3. They approve deliverables from start to finish.

• The Project Sponsors

Sponsors are people who want to see the project succeeds and have enough formal authority to help make that happen. Like an executive who believes in the project. The sponsor can help prioritize objectives, talk to stakeholders who are not being supportive and suggest improvements to the plan.

• Functional or Line Manager

Functional managers run departments and are accountable for achieving their department’s goals. They also managed the people in their departments, were the very same people you need for your project.

• Team Members

While they are assigned to your project their jobs depends on their assignment and on how well they perform.

Now that you identified your stakeholders, how do you work with them effectively?

• Know what motivates you stakeholders and how they are connected to your project. You can store information in a stakeholder analysis document start by including the Department, business unit, or a company the stakeholder belongs to.

• Determine who the stakeholder listens to, that can help if you need to explore ways to deal with an issue with the stakeholder.

• Identify the project objectives that the stakeholder cares about and their priority. That way you know who to talk to if an issue comes up with an objective.

• Document the stakeholder’s contribution to the project. So you know what to expect from him or who to turn to for things you need.

Remember stakeholders are crucial to the success of your project

See related Article: Managing Project Stakeholders

Obtaining approval

Now the project is defined, you need to get approval from stakeholders to proceed the planning. Obtaining approval is important because you need commitment from project stakeholders to make a project a success.

Once you have the initial project summary, you might think about getting approval by mailing or emailing a packet to stakeholders and asking them to sign on the dotted line. I do not recommend you do this. The problem with that approach is that people don't read through the packet. They might sign their names, but if they find something they disagree with later, their commitment disappears and you’re back where you started.

A face-to-face sign off meeting is more effective. Schedule a meeting specifically for obtaining approval. The agenda for the meeting is straightforward.

1. Review the project summary that you put together to make sure that the stakeholders agree with it. If any issues comes up, deal with them right then and there, or if the issues are big enough you might have to reschedule the signoff and go back to rework the documents.

2. Once everyone agrees, ask them all to sign a signature page to indicate their approval. If you can’t get everyone in the same room, a video conference or a conference call works too. Ask people in other locations to transmit their signatures.

Signing a project summary isn't like signing a legal document. You probably never going to come back to your stakeholders and say but you signed this. What is important is that the stakeholders understand what the project is about and buy in to it.

Writing a project charter

Now the project is approved the final step of the initiating process is writing a project charter.

Project managers don't have the kind of authority that managers in a structured organization do. Project manager’s authority last as long as the projects they manage and apply only to those projects.

For that reason it's important that people understand what a project manager is authorized to do. A project charter is the vehicle for doing that. Typically your project sponsor publishes the project charter to formally announce the project, and to communicate the responsibilities and authority that you have as the assign project manager.

The typical project charter includes the following items:

• The name of the project

• The purpose of the project. A one sentence summary of the goal and objectives will do

• The name of the project manager

• The project manager’s responsibilities, including a brief description of the work the project manager does.

• The extent of the project manager’s authority and the specific work the project manager has authority to perform, such as requesting resources or signing contracts.

• A formal declaration of the sponsor's support for the project. Think of this declaration as the power of attorney given to the project manager by the sponsor or customer.

When the project charter is ready to go, the project sponsor distributes it to everyone affected by or in some way involved in the project. Unlike the project approval meeting the publication of the charter can be via email or the preferred method in your organization.

Once you have approval to start planning the project and your authority as a project manager is common knowledge you're ready to begin the planning process.

You can also check the following articles:

• Exploring Project Management

• The Project Initiation Phase: How to Start a Project

• The Project Planning Phase: How to Plan for the Project

• Building a Project Schedule

• Project Monitoring and Controlling: How to Run the Project

• The Project Closing Phase: The Project Conclusion

There are many sources of information to learn more about Project management. Here are some books I recommend:

• Successful Project Management: Applying Best Practices, Proven Methods, and Real-World Techniques with Microsoft Project by Bonnie Biafore

• Project Planning and Control by James P. Lewis

• Making Things Happen by Scott Berkun

• Fast Forward MBA in Project Management

• 101 Project Management Problems and How to Solve Them: Practical Advice for Handling Real-World Project Challenges by Tom Kendrick.

#ProjectManagement