Wednesday 11 May 2011

Steps to Kick-off a new Project – the Act of using Project Charter

One day, your manager comes to talk to you “I want you to do this project, let’s start!”, then what’s next?
In principle, in order to kick-off a new project, all stakeholders need to be aware of two things. Firstly, you are the Project Manager (PM) and what authorities you have. Secondly, what the project to be executed looks like.

1.       Introduction
In reality, I have seen that some PMs just unconsciously follow what the manager has asked and try to do as much as possible as being considered … it’s starting. As the result, these PMs may meet some difficulties such as:
·         Relating functional managers are not aware of the new project and the assigned PM (sometimes it is the new PM in the organization). So, they may question when receiving requests on human resource, computers, repository etc.
·         The project team members feel uncertain when joining the project because they don’t have enough information on what the project is about.
·         Sometimes, even the manager who assigned the project needs the project information but it’s not ready.
·         Sometimes, client requests progress information, but it is not ready.

Ex 1: Peter has just been assigned to be the PM of one new project although his current title is a Senior Software Engineer. Peter submits the request to the resource manager to ask for project team members and to the IT manager to ask for creating a new SVN repository. After a while, he receives two rejections from these two managers. The common message is that, Peter doesn’t have permission to submit these requests. They’re not aware that he has just been assigned to be the PM for one new project.

Ex 2: One day, client changes the main contact person to work with Peter’s team, who is Ben. He asks Peter many questions about the project such as
“What is the start date and end date of the project?”
“What are the main features of the product to be built?”
“Who in your team can I talk to?”
“Can I have a weekly status meeting?”
Not to spend much time to explain, Peter sends the whole project management plan. However, Ben is not happy with reading a 50- page document of this plan which has a lot of information. There’re many sections which he’s not interested in.

2.       Project Charter
According PMBOK v4, you should officially start/kick-off the project with a Project Charter and in Software Development projects it should contain the following information.

2.1.    Project name and description
This section describes briefly why the product to be built is needed. How it interacts with external environment. If the product is complex, break it down into sub-systems.

2.2.    Project Manager assigned and authority level
Depending on project types, the Project Manager will have different levels of authority. Most of the time, PM will have full authority to control the project. However, in some cases, PM is only in charge of coordinating the work between the project team and client. This level of authority should be made clear at this early phase.
Ex 3: In an ODC typed project, there will be often a PM at client side. Client PM will control the work of the project team. If you are the PM of this kind of project, you will not control schedule and milestones, you will not control the testing plan etc. You need to state clearly your level of authority in the project charter.

Ex 4: In an SCRUM typed project, if you are the SCRUM Master you will be able to commit only what you will deliver per sprint. The overall release plan should be controlled by client or someone external to the project. You need to state clearly your level of authority in the project charter.

2.3.    Product scope and project scope

2.4.    Project objectives
Every organization has different set of parameters to be measured and set as objectives. The common objectives can be considered such as Effort Deviation, Schedule Deviation, Defect Density, Defect Leakage, Productivity etc.

2.5.    Preliminary resource planning
Even all resources are not ready for the project yet, but it should be clear on which types/roles of resource are needed and how many staffs are needed for each types/roles. This session is recommended to have sub-sessions such as team organization chart, project roles and responsibilities and staffing plan.

2.6.    Stakeholders
This section lists out all seen stakeholders at this early phase. Beside the project team, common stakeholders could be relating people at client side, upper managers and functional managers (IT Manager, Resource Manager, QC Manager, Technical Manager, etc.). The information of stakeholders which needs to be gathered includes their name, their contact information, their job title and the most importantly their interest in the project. 

2.7.    Communication
This section describes how the information should be exchanged in the project. Normally, it could include sub-sections as below:
·         Communication channels: which kind of information should be communicated and by whom.
·         Reports & meetings: which reports and meetings are needed.

2.8.    High level milestones
This section lists out major milestones of the project. The deliverables of each milestone should also be described clearly.

2.9.    Initial Risks
Initial risk assessment should also be done at this phase. It is not necessary to have all mitigation/contingency plans for all seen risks. Project team should try to analyze to find the plans as many as possible. Later on, these risks will be managed during the project life cycle.

2.10.Constraint and Assumption
Defining constraints and assumptions at this point is very important for the project success. The project team won’t have much time for clarifying everything before giving commitment. In order to move on, for some unclear scope and requirement, it is wise to just define constraints and assumptions to protect the project from changes in the future.

3.       Steps to kick-off a new project
Once the project charter is completed, it should be announced to relevant stakeholders. Typically, someone external to the project such as Program Manager, Delivery Manager, Delivery Director, etc. should do the announcement as an official authorization for the project to be executed. Stakeholders who should receive the announcement of the project charter are the project team, the client and all relevant functional managers.
As the project charter is distributed to all stakeholders with different interests, the provided information should be kept at a level which is readable and understandable to everyone. Making it too much detailed will not only waste effort of PM but also cause it less interesting to stakeholders.
Moreover, keeping the project charter at high level will help to make sure it will not be absolute later on when the project is planned into more details. 
PM now can organize a project kick-off meeting which involves as many relevant stakeholders as possible. In the meeting, PM can either go through the project charter or prepare another presentation and present it.

4.       Follow up
A good start of the project will promise a good execution and a good result. Via the project charter, every stakeholder will be on the same page and have the same goal to achieve. For some organizations which don’t use the project charter, is it recommended that they should complete actions/sections listed in the project charter as above.
Someone asks to me why they have to duplicate the planning information in the Project Charter and the Project Management Plan. Actually, it is not duplicated at all. It’s about rolling wave planning. We plan something at high level first in the project charter at very early phase. We plan for details via Project Management Plan and it supplementary plans such as Testing Plan, Quality Management Plan etc. after the project is authorized. The project planning is not yet finished after the kick-off.

5.       Conclusion
Gathering the information to kick-off a new project is not an easy task. However, following the standard from PMI, it would be clearer and more organized to do with only three steps:
·         Preparing the Project Charter.
·         Announcing the Project Charter as an authorization.
·         Organizing the kick-off meeting(s).

4 comments:

  1. This comment has been removed by a blog administrator.

    ReplyDelete
  2. Dear ... this is exactly what I've been looking for. Thank for sharing !

    ReplyDelete
  3. This is a good article for anyone wants to get a good head start in kicking off the project. However, I would like to comment on two facts
    1.Is it necessary to have Project Charter for ODC and Agile project? Main purpose of Project charter is to give authority to PM in particular project. And PMs take out almost authority in controlling ODC and Agile projects. I think that large projects seem to be better at this. However, for small projects, it is rarely referred to.
    2.I’m not sure if Scrum Master should join to set commitment on what the team delivers for each sprint.

    ReplyDelete
  4. Firstly, ODC stands for Offshore Development Center which is not a project but an organizational unit. In the ODC, there will be one or many projects.

    I saw the application of "charter" with some different names such as ODC Charter of the ODC, Team Charters for sub-teams in the ODC or even Project Charters for Agile projects (SCRUM/XP/MSF). It is worth to state clearly PM's authorities, what the team will work and so on.

    There should be no right or wrong answer here on whether it is necessary to use "charter" for the ODC and Agile projects even though I would recommend to use it.

    The second question seems to a bit far from the topic of this post. However, it is also an interesting question which I hope there will be another post for it.

    ReplyDelete