Project Initiation

by

You need to start strong to end strong. Project Initiation brings together or creates key, foundational documents and processes to define the project and enable initially interested parties to gain concurrence for it from the standpoints of the business and technical concerns. During the initiation stage you’ll also determine the project sponsor and stakeholders who will be responsible for on-going project governance. By performing several criticalProject Initiation steps, you’ll ensure a successful project start-up and you’ll have a solid head start to achieving the project objectives. On the other hand, not performing these critical steps and omitting critical documentation will virtually assure that your project is bound for failure. So, start strong to end strong.

The aim of Project Initiation is to gather the initial resources who will be required for initial planning and collate all the key documents to outline the project.With the right people and information at hand, initial stakeholders can make initial decisions regarding sponsorship, project governance, and business groundrules. At a high level that all sounds straight forward, but there are essential steps that need to be well-defined and followed in order to obtain a successful project start-up and fulfill the project objectives.

A project commences due to a business change. For example, a new visa fee system commenced in Abu Dhabi on 1st August, 2014, after being sanctioned by the federal cabinet. The new system involves fees being increased for different types of visas and new multiple entry visas being introduced for medical tourists, students, and business visitors.

In order to introduce a new visa system, the government identified all the visas which are currently being offered to citizens of different nations and evaluated the visas which needed changing prior to deciding how they could modify the system. A high level strategic view was taken to determine the viability of the project. Afterwards, other considerations such as budget, ROI calculations, and sign-off by the president to commence the project were also carried out uniformly.

Develop the Project Charter

Developing a charter is the birth of a project. It is prepared by the Project Sponsor, with or without the assistance of the Project Manager. The aim of the project charter is to develop a clear statement of the key goals, principles, and driving motive in order to provide a foundation for the direction of the project. There needs to be a well-stated and fully understood basis for the project—a clear statement of the problem, the target solution, and a strategy for achieving that solution—so that everyone involved in the project, including all stakeholders, maintains a clear vision of its scope and goals throughout its lifecycle.

The project charter is one of the most effective tools the project manager and sponsor have to ensure the effectiveness of an implementation effort. A project can only be developed and implemented correctly if the focus remains constant.This, in fact, is the main goal of the project charter. A fully-developed project charter, accepted by all stakeholders, will prevent unnecessary changes to the project’s scope and objectives. Without this solid foundation, during the lifecycle of the project changes can be very time consuming and expensive, and can even completely derail the project from its initial objectives, causing project failure and the wasteof time and money.

A good project charter is a daily reference point for dealing with any disputes or confusion, utilizing new ideas as they occur, preventing ‘scope creep’, evaluating progress, and ensuring that all interested parties (in case new members are brought into the project after inception) are aware of the project’s intended goals.

Elements of a Good Project Charter

1.   Requirements that meet the stakeholders expectations, needs and wants
2.   Business needs with a high-level project description
3.   Project Justification
4.   Assigned Project Manager
5.   Milestone Schedule
6.   Stakeholders roles And Responsibilities
7.   Functional Organizations and Participations
8.   Assumptions
9.   Constraints
10.   Business Case Justifying The project
11.   Summary Budget

Contrary to popular belief, most project charters are not lengthy and incomprehensible, but brief and to the point, and they tend to outline or have bulleted lists of the major design. There should be one when the project commences and another after the project has finished. This project charter should contain the goal statements from the planning phases and a well-structured detail of the end product.

Tools and Techniques

While Project Management has a history virtually as long as human existence—is it possible to imagine the building of the Acropolis without a plan?—Project Management as a science and formal field of study has only existed since the 1950’s. Today there are several codified project management methodologies, each of which have strengths and weaknesses and are relatively better or worse for different types of projects. For example, a software development project for a new and untried concept will necessarily use a different methodology than will a project to build a cargo ship. But whether the project team uses Agile, Scrum, Waterfall, RUP, Prince, or any of several other choices, each has been developed from millions of man-hours of experience by people who are expert in their field. The discipline of a methodology and the constraints one has to work within in order to implement a project with that methodology should not be reason to ignore the experience and knowledge embedded in its design.

Regardless of the specifics of how each methodology implements the processes and documents of the initiation stage, each has its own way of implementing a project and then controlling changes as it progresses. Again, these change processes are based on the combined experience of countless people who have experienced both project success and failure. The lessons learned and codified in the project methodology should not be lightly ignored.

Building the Business Case

A business case document is a formal, well written argument with the aim of convincing the decisionmakers to approve the project and fund its execution. If there is any question of feasibility—technical, financial, business climate, etc.—the business case will address these questions and build a case for the project’s adoption. The challenges of the project as well as its benefits should be clearly outlined so that decision makers can make an informed decision before project execution begins. The goal of the business case document is to obtain approval from key stakeholders for the capital and expense dollars required. The decision makers should know from the business case exactly why this project is better than a competing project and deserves the enterprise’s scarce resources.

The creation of a business case document is normally the last of several key stages that are completed prior to presenting the project for approval. While the project charter stated the need for the project’s purpose, its end goal, the business case presents the detailed analyses from all aspects of the business—financial, marketing, technical, and others—that executive decision makers need to determine this project’s merits relative to other possible projects. When the project is approved and in the execution phase, change requests will inevitably arise. The Project Charter and the Business Case are then reviewed and appropriate analyses made on the effect to the project of the requested changes so that decision makers can approve or reject them based on solid business data.

Because the development of a solid Business Case development can be time-consuming, Executive decision makers will require that it be built on hard, verifiable data, usable for sound decision-making. Not only should the business case show with cold, rational facts and figures why the project should be funded and why human resources should be dedicated to it, but the downside to the business if the project is rejected.

Sources of data for the business case can come from anywhere: financial sources within the business or from outside, analyses of the competitive environment, or case studies from previous projects may be relevant. Privately acquired or publicly available industry analyses can be useful for some types of projects, as can historical data combined with forecasts and demographic studies.

All information that might be required to evaluate the worth of the project is relevant for the Business Case. This document cannot be taken lightly. It is not only a means to project approval, but oftentimes to continuation of the project as other priorities continuously arise and try to take attention of the business leaders.

Identify Stakeholders

Project stakeholders are individuals, groups, or organizations who may affect, be affected by, or perceive themselves to be affected by the project. During the initiation phase of the project the organizing team will identify the obvious stakeholders, some or all of whom may be invited to take part in early project planning. After the project manager is identified, it becomes his or her responsibility to continue identifying stakeholders, a process that continues virtually throughout the entire project lifecycle.

Identifying Stakeholders is the process of identifying the people, groups, or organizations that could impact or be impacted by a decision, activity, or outcome of the project. Then, with the stakeholders, the project manager will analyze and document relevant information regarding their interests, involvement, interdependencies, influence, thepotential impact on project success, and the impact of the project on the person’s or group’s operations. Stakeholder dependencies can easily affect the project schedule and scope.

The key benefit of this process is that it allows the project manager to identify the appropriate focus for each stakeholder or group of stakeholders and ensure that the project does not reach the implementation phase and be suddenly surprised by an interdependency that wasn’t planned for. Obviously, identifying all stakeholders as early as possible is critical for project success.

Tools and Techniques

In essence, the tools and techniques one decides to use for any project should be of value not only to the particular project but for all similar future projects. Along with being easily understandable, the tools and techniques should also be easily communicated to the project team and its stakeholders. Whether it’s the creation of the project charter, stakeholder analysis, change management, or any other part of the project management process, the tools that are used should be reusable throughout the lifecycle of a particular project and, ideally, for other similar projects. The need to deviate from repeatable, standardized processes should always be examined carefully.

Project Meetings

As much as a project manager tries to reduce group meetings, there is not a practicing project manager who can say that the benefit of meeting with the project team on a regular basis is not a valuable use of time. However, with project teams scattered around the globe, team meetings may not be face-to-face, and may not even include the entire project team. But when the core team knows that they will have the opportunity to discuss issues in real time on a regular basis with other team members, it reduces the flurry of emails and misunderstandings that may be common otherwise and which inevitably slow down project progress.

Regularly scheduled team meetings should not be for the purpose of updating status—the project manager or scheduler can get this information without using the valuable time of all other team members. The team meeting is to identify issues that are impeding or might impede the successful execution of the project. And very importantly, the meeting should always follow an agenda. The meeting should never last longer than necessary and except in rare, emergency cases, should not be used to work issues. Time is better spent identifying issues, adding specificity to the issue so all team members understand exactly what is at stake, and assigning appropriate subject matter experts within the team to resolve it. If outside personnel are required, then the people or organizations should be identified and a specific person assigned during the meeting to be responsible for the issue’s resolution. Whenever possible, a target date for issue resolution should be assigned. When not possible, the person responsible for the issue should provide a date when the date for issue resolution will be provided.

Lest one think that team meetings are all about problems, this is also the venue for announcing team accomplishments and giving congratulations to specific people when warranted. In fact, positive recognition and encouragement are just as important as issue and problem definition, if not more so to the health and success of a project. The team meeting is the perfect opportunity to share good news.

Business Case Study

The Abu Dhabi Government has supported the initiation of the Abu Dhabi Systems and Information Centre (ADSIC) to implement the No Objection Certificate Program for Utilities and Infrastructure in Abu Dhabi (NOC). A joint partnership framework commenced with ADSIC, The GPC Group in adopting and addressing the project strategic and implementation by merging local expertise with global practices.

In 2011, the business engagement was initiated with the Master Planning phase. In early 2013, the three-stage-program implementation commenced and was planned in partnership with the municipalities and 19 stakeholder entities to streamline NOC operations and operating procedures between all the stakeholders. The aim of the exercise was to improve the efficiency of permits and approvals procedures and processes by adopting a Vision of the NOC Program. This program ensures “An investor friendly government and society proactively encouraging and facilitating sustainable and resilient community development opportunities in Abu Dhabi”.

The NOC Program initiation was triggered by the fast pace of urban development in Abu Dhabi. Every year it fueled an average of 15,000 permits and approvals transactions. Approximately 100,000 No-Objection-Certificate (NOC) transactions were occurring every year by public, private and government entities.  Each transaction endured the processing complexities of the system. This resulted in excess resources and was very time consuming.Most of all, it was very costly. The primary objectives of the program were to protect valuable infrastructure assets, improve customer satisfaction, enhance integrated government business processes, and increase the viability of the overall investment environment.

The ultimate goal was to implement the NOC Program through the use of the optimum project management methodology. Therefore a multilayered operations approach wasagreed to in the implementation phase. The success of involving stakeholders throughout the implementation stages has resulted in the NOC program community expansion into several sections such astransport, municipal, utilities, oil & gas, and many more.

It is important to note that the integration and support from the leadership were among the critical success factors of the NOC Program. But just as important as their participation, was that they, and all stakeholders, were brought into the project planning at an early stage and were integral in its implementation. With the concurrence of all stakeholders in the project methodology and their invaluable help in the creation of the project charter and business case, the project manager and team were able to concentrate on execution of the plan without extraneous noise that may have resulted from incomplete planning.

The project ended strong because it started strong.

by