Project Initiation Activities
Key activities necessary for successful development of a Project Charter and initiation of a project:
Assign A Project Champion/Leader: Every aspect of a project requires someone to guide it. Initiation, and specifically development of the Project Charter, is no exception.
This project champion (who may or may not be the eventual Project Manager) is responsible for defining the project purpose, establishing the Critical Success Factors, gathering strategic and background information.
His role is to determining high-level planning data and developing estimated budgets and schedules for the life of the project. He will coordinate resources and activities to complete the necessary activities in order to develop the Project Charter & any other materials required for project approval.
Since it generally takes more than one person to fully develop a Project Charter, a team of individuals may also be required to do the research, generate the estimates and perform other work that may be necessary. This team may not carry over to actual conduct of the project.
Identify A Sponsor: The Sponsor is the individual, generally an executive, who is responsible for the strategic direction and financial support of a project.
A Sponsor should have the authority to define project goals, secure resources, and resolve organizational and priority conflicts.
It has been shown, but may not be generally recognized, that lack of project sponsorship can be a major contributor to project failure.
Conversely, an appropriately place and fully engaged Sponsor can bring a difficult project to successful conclusion.
Assumptions that a formal Sponsor is not needed (or for political reasons can be avoided) are misplaced.
Steering committees are no substitute.
A powerful but uninvolved Sponsor is no help.
Even big-budget and highly visible projects require a formal Sponsor.
The Sponsor’s responsibilities are many:
– Champion the project from initiation to completion
– Participate in the development and selling of the project business case
– Present overall vision and business objectives for the project
– Assist in determining final funding and project direction
– Serve as executive liaison to key Persons (e.g., Senior Management, department directors and managers)
– Support the Project Team.
Define the Business Need/Opportunity: The statement of need/opportunity should explain, in business terms, how the proposed project will address specific needs or opportunities.
Typically, satisfaction of a need or opportunity will provide specific benefit to the organization, e.g.:
– Keep an existing service or operation in good working order
– Improve the efficiency or effectiveness of a service
– Provide a new service as mandated by external authority
– Obtain access to needed information that is not currently available
– Reduce the cost of operations
– Generate more revenue
– Gain a strategic advantage
The discussion of the need/opportunity should be stated in business terms and should provide an understanding of:
– Origin of the need, or how the opportunity was recognized
– The magnitude of the need/opportunity
– Contributing factors, such as increased workload, loss of staff, fiscal constraints, change in market conditions, introduction of new technology, etc.
– Results of an alternatives analysis, i.e. relative merits of alternative approaches
– The cost of taking no action
This information allows an organization to determine how much of its resources (money, people’s time) to put into the project.
The decision can be made based on how well the project should meet the business need or take advantage of the opportunity.
Identify Business Objectives and Benefits: Every project is an investment of time, money or both. We conduct projects so that the organization can meet its strategic objectives.
More specifically, projects help the organization reach business objectives that are directly related to the organization’s business strategy.
Business objectives define the results that must be achieved for a proposed solution to effectively respond to the need/opportunity, i.e. the business objectives are the immediate reason for investing in the project.
Objectives also serve as the “success factors” against which the organization can measure how well the proposed solution addresses the business need or opportunity.
Each business objective should be:
– Related to the problem/opportunity statement
– Stated in business language
– SMART (i.e. Specific, Measurable, Attainable, Results Oriented and Time Limited)
Having established the business objectives, determine the benefits. For example, determine whether the proposed solution will reduce or avoid costs, enhance revenues, improve timeliness or service quality, etc.
If possible, quantify operational improvements by translating them into reduced costs.
For example, a business objective might be to “Reduce the average amount of overtime worked by 100 hours per month, thereby saving X per year while still meeting terms of the Service Level Agreement.
Attain this result within 6 months.”
Objectives can also identify:
– Business process improvement opportunities
– Opportunities to improve the organization’s reputation or name recognition
Define Overall Scope: Provide a concise, measurable statement of what the project will accomplish (in scope), and, where appropriate, what it will not try to accomplish (out of scope). There are two kinds of Scope: Product Scope and Project Scope.
– Product Scope is a description of the product or service that would be produced as an outcome of the project.
– Project Scope is a statement of the work required to create and implement the product or service as well as the work required to manage the project.
Project scope is documented at a high level in the Project Charter. It should include a discussion of the proposed solution and the business processes that will be used with the solution, as well as a description of their characteristics. Also describe the general approach that will be taken to produce the proposed solution, and how the work will be planned and managed.
The Scope section of a Project Charter is generally written at a fairly high level. Nonetheless, the level of detail in this section must be sufficient to provide a basis for detailed scope and solution development in the Scope Statement, developed in the Planning phase.
If Scope in the Charter is done well, Scope as developed in the Scope Statement will more completely describe the product of the project without substantially increasing the estimate of work required to create it.
If it is not possible to establish boundaries on scope during project Initiation, then there must at least be some decision made about how to handle changes to scope later in the project.
Define Project Objectives: Project Objectives are the specific goals of the project. Project objectives, if properly defined and met, will lead directly to accomplishment of the Business Objectives.
While Business Objectives relate to the goals and objectives of the organization, Project Objectives relate specifically to the immediate goals of the project.
For example, the project goal “implement a new time tracking system” has no value in and of itself. That goal only brings value to the organization when it leads to accomplishment of the Business objective (e.g. “Reduce costs and improve productivity through improved resource management”).
Project objectives are used to establish project performance goals – planned levels of accomplishment stated as measurable objectives that can be compared to actual results.
Performance measures should be derived for each goal. These measures can be quantified to see if the project is meeting its objectives.
Note that it may not be possible to determine that the project actually provided the intended business value until sometime (days, months or even years) after project Close. By this time the project team will no longer exist.
For this reason, it is essential that the organization carefully define at the start of every project how it will measure those impacts and who will be responsible for doing this and reporting on it.
Organizations must conduct these measures if they are ever to know if their investments in project work have actually paid off.
Project objectives can be described in two ways:
– Hard Objectives – Relate to the time, cost and operational objectives (Scope) of the product or service. Was the project on time? Within budget? Did it deliver its full Scope?
– Soft Objectives – Relate more to how the objectives are achieved. These may include attitude, behavior, expectations and communications.
Is the Customer happy?
Project team proud of its work?
Management proud of the project team?
Focus on the full set of project objectives, hard and soft, can lead to a more complete project success. Focus only on hard objectives can lead to a situation where the project is delivered on time and within budget, but the customer never used the product.
As with Business objectives, Project objectives are defined best if they are SMART (i.e. Specific, Measurable, Attainable, Results Oriented and Time Limited).
Project objectives fully define success for the given project. They are communicated in the Project Charter so that all Stakeholders understand what project success will be.
Identify Project Constraints and Assumptions: All projects have constraints, and these need to be defined from the outset.
Projects have resource limits in terms of people, money, time, and equipment. While these may be adjusted up or down, they are considered fixed resources by the Project Manager.
These constraints form the basis for managing the project. Similarly, certain criteria relevant to a project are assumed to be essential.
For instance, it is assumed that the organization will have the foresight to make the necessary budget appropriations to fund its projects.
Project assumptions need to be defined before any project activities take place so that time is not wasted on conceptualizing and initiating a project that has no basis for funding, or inadequate personnel to carry it out.
Include a description of the major assumptions and constraints on which this project is based in the Project Charter.
Ensure Alignment with Strategic Direction and Architecture: It is important that an organization only engage in projects that effectively support its business strategy.
To ensure that this is true, the organization’s business strategy needs to be visible and understood by everyone involved in project selection and prioritization.
Using the organization’s business strategy and strategic objectives as a baseline during project initiation will save time and effort later.
Many organizations have made effective use of Project Portfolio Management as a key process in project selection and oversight. This works best when IT’s business partners are an integral part of the process.
Review the alignment of the proposed project with supporting documents such as:
– Organizational wide strategic plan
– Department strategic plan
– Organizational wide enterprise architecture
– Department architecture
– Organizational wide applications portfolio
– Department applications portfolio
– Organizational wide architecture (software and/or hardware)
– Current business and technical environment
– Organizational mandates.
Identify and Engage Key Stakeholders: Stakeholders are individuals and organizations that have a vested interest in the success or failure of the project.
During Initiation, Stakeholders assist the project team to define, clarify, drive, change and contribute to the definition of scope and, ultimately, to the success of the project.
To ensure project success, the project team needs to identify key Stakeholders early in the project. It is essential to determine their needs and expectations, and to manage and influence those expectations over the course of the project.
Stakeholders who are not sympathetic to the goals of the project must be either made into supporters or at least brought to a place of neutrality.
If the project will have an impact on the business processes, work habits or culture of the organization, steps should be taken during Initiation to prepare for the process of Organizational Change Management.
Identify Key Potential Risks: Projects are full of uncertainty. As such, it is advisable to perform and document an initial risk assessment to identify, quantify and establish contingencies and mitigation strategies for high-level risk events that could adversely affect the outcome of the project.
A risk is usually regarded as any unplanned factor that may potentially interfere with successful completion of the project. A risk is not an issue.
An issue is something you face now; a risk is the recognition that a problem might occur. By recognizing potential problems, the project team can plan in advance on how to deal with these factors.
It is also possible to look at a positive side of risk. A risk may be seen as a potentially useful outcome that occurs because of some unplanned event. In this case, the project team can attempt to maximize the potential of these positive risk event should they occur.
An understanding of Risk is essential in the Project Portfolio Management Process. A project with excellent potential for ROI may be turned down if the risks are so high that the ROI might never be realized. Use the Risk Assessment for Project Charter tool to assess risk.
Determine Cost/Benefit and Schedule Estimates: Projects are often only one part of a larger product lifecycle.
For example, when a new Accounting system is put into place it is understood that the system will require maintenance and occasional upgrades over its lifetime, will involve operational costs, and at some point in the future will be replaced with yet another Accounting system.
Therefore the true cost of the product includes both implementation and ongoing operational and maintenance costs.
When comparing alternative approaches during project Initiation, it is useful to compare product lifecycle costs rather than just project implementation costs.
This may help the organization identify the alternative that truly provides the greatest value over its lifetime.
Cost / Benefit: For the project Charter, estimate the one-time development / acquisition / implementation costs (including contracted staff, hardware, middleware, licenses, leases, etc.), and then separately total the costs that will follow the project:
– One-time upgrades
– Ongoing operations
Next, determine the anticipated benefits of the project including tangible and intangible operational benefits, cost savings, cost avoidance and other benefits.
Use these estimates of cost and benefit to determine the anticipated cost savings / revenue enhancement / other benefit that will result from the project.
With respect to the project itself, it may be necessary to explain how the project will be funded. This process varies greatly from one organization to the next, but it is fairly common to provide a description of funds required by fiscal year, by funding organization, and by phase of project.
If the project is to be funded from multiple sources, indicate the percentage from each source. Also indicate whether funds have been budgeted for this purpose. If this project will require funding beyond that already provided to the organization, supply the necessary details.
It is also useful to determine in advance who (which funding source) will underwrite continuing costs once the project is completed. It is not uncommon for a business unit to be unaware of the “true” cost of their proposed initiative.
Schedule: The Initiation phase of most projects is a time of great uncertainty. While there may be general agreement on the scope of the project, specifics of implementation may not be available.
For this reason, it may not be possible to provide anything more than a high level schedule, and even then only with fairly large confidence limits (e.g. +/- 30% or more).
If this is the case, it is important for the project team to make this clear in the project Charter.
With that in mind, it is nonetheless necessary in most cases to identify at least the high-level tasks of the project and then guestimate a schedule.
For example, tasks could include the typical steps of the project life-cycle (e.g. gather requirements, create specifications, develop a test plan), along with tasks specific to the project at hand (e.g. procurement, conversion, training for end-users, training for technical staff, post-implementation support, etc.).
Schedule information can include the duration of critical tasks, major management decision points (e.g. go / no go decisions) and milestones.
Milestones should be products or major events that may be readily identified as completed or not completed on a specified due date.
Most projects are done in phases (e.g. Initiation, Planning, etc.). Define the phases in the schedule and make clear the tangible output of each phase. If project phases are not planned, be very clear why this is so.
When planning for staged project implementation (e.g. implement a new general ledger first, then purchase and roll out accounts payable and payroll modules in subsequent stages), use only as many stages as provide improved management control over the program as a whole. There should be identifiable deliverables and success criteria for each stage.
Many late or over-budget projects deemed “failures” are actually only estimating failures. This can happen when estimates based on inadequate data (usually the case during Initiation) are then taken by management as “final”.
One useful strategy is to re-estimate at the start of each major project phase when more information is available and confidence in the estimates is better. Cost and time tracking are not as useful when there is not much confidence in cost and time estimates.
This is true because when an estimate is expected to be 35 percent off, variances from it seem a minor concern. Management insistence that unreasonable cost and time targets be met only results in a dispirited project team, unhappy customers and another “project failure”.
Project Charter: The Project Charter is a business proposal. It is a statement by the group who develops it that they have a great idea that will help the organization and here is how we will do it, what it will cost and how long it will take to do.
If the project Sponsor and all parties who will be involved in the project (e.g. peer business groups, Information Technology staff, Financial Officer, Technical Security Officer) accept it, the Project Charter is presented to upper management (or a group appointed by them) for review and approval.
Project Charters can appear in many forms depending on the size, complexity, importance and level of risk of the project. Indeed, how an organization defines “project” will determine if there is any written Project Charter at all. Any work that takes more than 40 hours is considered a project.
– For small, less complex, less critical projects, a single page Project Definition is sufficient.
– Somewhat larger but not complex projects require a Project Charter Lite
– More costly, more complex, and critical (high impact) projects require a formal Project Charter along with supporting documents (e.g. Risk Assessment, Cost Estimator, Cost/Benefit Analysis).
Specific documentation and approval requirements are detailed in the Project Sizing and Approvals document. This document details:
– Types of projects and distinguishing criteria (e.g. cost, hours of labor required)
– Documents required approval steps and other information for each size of project.
If the project is approved by management’s Project Selection Team, the Initiation Phase is ended and Planning begins. During Planning, the project team, along with additional staff, will begin the work of creating the Scope Statement and other project planning documents.