The Project Set Up Phase

 

Figure 23: The Project Set Up Phase

Purpose

Every successful project begins with a thoroughly planned and implemented Set Up phase. The objectives of the Project Set Up Phase include:

  1. Establishing the Project Governance Structure.

  2. Officially authorizing the start of the project.

  3. Communicating the project launch.

Establishing the Project Governance Structure

Unfortunately, the term “governance” often conjures images of bureaucratic processes and protocols. This is not the intent or purpose in the case of project governance.

In the context of project management, governance defines the management framework within which project decisions are made. A robust governance structure clarifies:

Authority: Who has the power to make decisions and within what tolerance levels;

Accountability: Who is accountable for the success of the project? With no clear accountability for project success, there is no one moving agendas to resolve project issues.

Governance structures can take many forms. In its simplest form, a governance structure comprised of a single individual – the Project Sponsor – might be sufficient. In this scenario, the responsibility of the Project Sponsor would be to:

  • Ensure organizational commitment and accountability for the project;

  • Decide on proposed project changes (scope, budget, calendar or others) that extend beyond the project manager’s agreed tolerances;

  • Oversee the project, providing resources, direction and insight as necessary;

  • Monitor the ongoing viability of the project, making decisions to terminate the project if necessary;

  • Support and advise the Project Manager on the management of the project, especially on issues that extend beyond the span of control of a project manager.

  • Advocate for necessary organizational support and resources for the project; and

  • Ensure that the organization “owns” the process and results of the project.

And yet, while a governance structure comprised of a single sponsor might be simple, it often fails to represent the multiple perspectives of development projects.

We all know, however, that development projects are seldom simple. The project team must manage agendas with multiple stakeholders, including (but not limited to) the project donor, the implementing organization(s), the beneficiary communities, and project suppliers. In these complex contexts, a single project sponsor will not provide the support the project team requires to succeed. Instead, a more effective governance structure would be a project board which includes representatives from multiple stakeholders involved in the project.

There is no single, definitive norm for establishing project boards. However, the following guidance provides insights into how they can be structured and managed:

Size

There is no standard size for project boards. At minimum, there should be two people and it is common to find boards comprised of three, four or five representatives. As mentioned previously, smaller group size facilitates efficient collaboration and decision-making. However, it is often helpful to expand the size of the Board when stakeholder management is complex. For example, if there are multiple donors, multiple beneficiaries groups, or multiple organizations working on the same project

Composition

Board members should represent the following distinct knowledge/ management/ experience perspectives:

  • An Executive perspective - assessing whether the project is providing value as a whole, and providing the funding and resources necessary to obtain that value. There is only one representative with Executive Perspective on the Board.

  • A Senior User perspective - establishing that the project is meeting the needs of the people who will be directly working with the project's outputs. There can be more than one representative with Senior User Perspective on the Board. Another alternative would be to establish a “senior user group” for the project, which in turn identifies a single representative on the board to represent the opinions of all group members.

  • A Senior Supplier perspective - providing confidence that the project's outputs (from which value will be derived) can be achieved with available resources, and at the required level of quality. There can be more than one representative with Senior Supplier Perspective on the Board. Another alternative would be to establish a “senior supplier group” for the project, which in turn identifies a single representative on the board to represent the opinions of all group members.

Each board member perspective reflects a different dimension of the project in terms of resources provided to the project; understanding of organizational, user, and developer needs (for decision-making on ongoing project viability); and weighing project results. Each has its own assessment of what "success" means - and all perspectives when taken together define project success.

Responsibilities

Collectively, the Project Board owns the project and its responsibilities include:

  • Decide on proposed project changes (scope, budget, calendar or others) that extend beyond the project manager’s agreed tolerances;

  • Oversee the project, providing resources, direction and insight as necessary;

  • Monitor the ongoing viability of the project, making decisions to terminate the project if necessary;

  • Represent the interest of the perspective they represent;

  • Support and advise the Project Manager on the management of the project, especially on issues that extend beyond the span of control of a project manager; and

  • Advocate for necessary support and resources for the project.

 

Meetings

It is recommended that Project Boards conduct regularly scheduled meetings where the agenda is set by the Project Manager in cooperation with the Executive Perspective representative. Important items on the agenda include the review of the Risks Log and Issue Log to be discussed later. In addition, a Project Board meeting is also necessary at all decision gates.

One area of confusion that sometimes arises is whether the Project Board acts as a simple democracy wherein each board member has an equal voice when voting on major decisions. It is important to recognize that not all voices on the project board hold equal authority on all decisions. If, for example, there is a need to request a budget increase or a calendar extension for the project, it could be that all members of the Project Board are consulted but ultimate authority for the decision resides exclusively with a single board member (most likely in this example, the Executive perspective) or a small group of board members. Remember that the decision-making effectiveness of a group can be thought of as being inversely proportional to its size. Not only can large groups fail to make timely decisions, the quality of decisions can be impacted by the challenges of managing the group.

Officially Authorizing the Start of the Project

If a project has been following the decision gate model, a number of go/no-go decisions will have already have been made before entering the Project Set Up Phase – for example, when the concept paper was developed, when a statement of interest was presented, or when a project proposal was reviewed and approved. During the Project Set Up Phase it is important to ensure that the project is formally authorized by the project governing body (whether it is comprised of a project sponsor or a project board).

This approval should be documented through the development of a project charter, a document that provides a high-level description of the project and which is signed by the project governing body. The contents of the Project Charter can vary, but usually includes statements regarding the:

  • Project Purpose – including a statement of the need the project will address.

  • Project Deliverables – articulating the scope of the project, including the project goal, outcomes, and major outputs.

  • High-level Project Estimates – including a high-level statement of:

    • The project activities;

    • The project schedule;

    • The project budget; and

    • A preliminary list of the roles and skills required to perform the necessary work.

  • Project Risks – identifying potential problems/risks that the project might encounter.

  • Project Tolerances – articulating project tolerances regarding project deliverables, schedule, cost and risk.

  • Project Change Control – establishing an exception handling process for when the project exceeds a tolerance in any of these areas.

Once developed and signed, it is important that it not be put on a shelf and forgotten. The project charter is an extremely useful document that can be used to accomplish the following objectives:

  • To officially authorize the start of project activities and the use of resources for project implementation;

  • To ensure that there is shared understanding of the project parameters among key project stakeholders and sponsors (both internally and externally);

  • To document a shared commitment to the objectives of the project and the resources/activities required for project success.

Furthermore, the project charter should be considered a living document. If the project governing body approves major changes to the project (scope, budget, calendar or otherwise), the project charter should be updated and signed to reflect the new project parameters.

In summary, the Project Charter serves as the project manager’s ally, and in the absence of a project charter document, the project team runs the risk that:

  • The project team will begin to expend time, money, materials, staff and organizational capital in executing a project that lacks commitment and support from key decision-makers (donors, implementing partners, decision-makers internal to the agency);

  • Key stakeholders do not share a common understanding of the project (scope, budget, schedule, benefits, and risks).

Communicating the Project Launch

One of the principle objectives of the Project Set Up Phase is to communicate the launch of the project activities to the many stakeholders who have interests in the intervention. These stakeholders might include the beneficiary communities, NGOs working in the intervention area, representatives of government ministries, the general public and many more.

There are multiple communications tools that can be used to announce the project launch to the community of stakeholders. However, regardless of the mechanism employed, the purpose of the project launch communications activities remains unchanged:

  • To formally acknowledge the beginning of project;

  • To ensure that key stakeholders have a consistent understanding of the project;

  • To introduce stakeholders to the project.

In many ways, the signed project charter is an ideal document, in which to officially communicate the launch of the project to the broad project audience. Because of its brief, concise format, the project charter is especially good for communicating the high-level parameters of the project. As a result, this document will frequently be very handy when dealing with some people who have short memories, unintentionally or otherwise. Sharing the project charter with the larger community of stakeholders is not only an effective communication practice, but is also a way to promote transparency and accountability in the project.

If, however, there are reasons that the project team prefers not to share all elements of the project charter with the larger community of stakeholders, other options for communications mechanisms exist. If there is sensitive information, it can be included in an amended version of the project charter that can be shared with the general public. Furthermore, articles in newspapers, press conferences, field visits, meetings, and launch party events can also be used to communicate with the larger community. The messages for these communications can vary, depending on the audience and their connection to the project. It is important, however, that at least the high-level parameters of the project be shared with stakeholders before project implementation begins.

You don't have permission to view or post comments.