Kicking Off a Project

Lead Advocacy Group: Program Management

An Envision Track contains deliverables, checkpoints, and activities to consider at the beginning of a project. However, it is extremely likely that a whole bunch of preEnvisioning Track activities and approvals are needed to be able to kick off a project.

The following sections briefly highlight some common activities that enable a project to be kicked off. This assumes that a business case justifying the need for a project has already been assembled for business sponsors to review and approve. Hopefully, operations and support teams have also been involved in project proposal activities to make sure that they are ready, willing, and capable of assuming operations and maintenance of a solution.

Defining a Project Charter (Deliverable)

At its essence, a project charter is a founding agreement between the sponsoring organization(s), solution delivery organization(s), and key stakeholders as to the who, what, when, where, why, and how rationale for undertaking a project. It contains the motivation, authorization, and justification for commissioning a project. It establishes the driving and defining elements of a project. It contains a high-level summary of the intent and purpose of a project. As much as is known, it provides the agreed-to scope, goals, objectives, time frame, approaches, risks, and deliverables of a project. It establishes the foundation of how a project and the team will be structured and managed. It identifies project sponsors and participating organizations, and maps out their roles and responsibilities. Other basic elements of a project charter include these:

• Business needs and drivers

• Desired timelines

• High-level requirements

• Assumptions and constraints

• Success criteria

Once a project is kicked off, a project charter is a useful historical document that provides an overview of the initial project rationale, drivers, and motivators.

Handling Kickoff Logistics

A little-recognized key to a successful project kickoff is to make sure some basic logistics have been taken care of prior to the kickoff, such as the following:

• Suitable and equipped area in which the team can work

• User accounts with appropriate rights on the systems and tools needed for a project

• Unfettered access to all facilities associated with solution delivery

• Orientation guide for on-boarding team members

• Team collaboration site (e.g., Microsoft SharePoint) to store project collateral and governance templates (e.g., status report template)

Kickoff logistics are implicitly assumed to be handled properly, but it is quite obvious and disruptive if they are notmuch like the "dissatisfier" category of requirements described in Chapter 8, "MSF Plan Track: Planning a Solution." A good kickoff enables a team to focus on their work rather than spending time preparing to work.

Establishing a Deliverable Acceptance Procedure

A key to making sure a solution meets the needs and expectations of the stakeholders is to make sure the deliverables do as well. To help instrument this, a team should establish a deliverable acceptance procedure that is consistent with the deliverable life cycle discussed in Chapter 6, "Establishing a Solution Delivery Life Cycle." This procedure can be as agile or as rigorous as needed. Regardless, the procedure consists of the following steps:

1.	Submit deliverable The deliverable is submitted to the appropriate stakeholders for review and, hopefully, approval.
2.	Review deliverable The review period should be planned into the scheduleallowing sufficient time for the stakeholders to review the deliverable.
3.	Accept or reject deliverable To have a record of the acceptance, the team should provide a completed deliverable acceptance form to the appropriate stakeholder(s) for signature. Should the deliverable be rejected, the form should be returned with the reasons why it was rejected.
4.	Refine deliverable Most likely, stakeholders will not reject a deliverable but will send it back for further refinement. Given the likelihood that most deliverables will need some refinement upon their first submittal, time to perform this step should also be reasonably planned into the schedule. Unless the deliverable was conditionally accepted (i.e., accepted pending refinements that do not need to be re-reviewed), the deliverable needs to be resubmitted after being refined.

It is expected that the team shares mature versions of the deliverables with appropriate stakeholders to solicit stakeholder feedback along the way. If done correctly, this deliverable acceptance process should be a non-event because the team already has a high degree of confidence that the deliverable meets stakeholder needs and expectations.

It is important to establish which stakeholders need to approve each deliverable and which stakeholders are provided the deliverable for informational purposes only. For technical deliverables, it is good practice to have the appropriate architect sign off on the deliverable before submitting it for business approval.