Wednesday, May 7, 2008

How to Write a Project Charter

What is a Project Charter?
The project charter, sometimes also called a Project Overview Statement (POS), is the signed document that formally defines and authorizes a project. Reaching an agreement on the nature of a new project, including its scope, objectives, and constraints can be a difficult but healthy process for a group of key stakeholders in a corporate environment. For that reason, a project proposal should be written and approved before the project charter is established.

Why Do You Need a Charter?
Without a project charter, the goals of the project will be ambiguous and often understood incorrectly by the key stakeholders, each having a different point of interest in the project. The result is a project beset with conflicting priorities, role confusion, and in many cases, as failed project.

What Every Project Charter Should Include
While charters are to written for each specific project, they should contain at least the following aspects:
1. Project Authorization.
A brief written statement should identify the authorized project by name and/or number.
2. Project Manager Authorization.
The name of the project manager, including a description of his/her responsibilities should be clearly identified.
3. Key Stakeholders.
All key stakeholders identified in the project proposal, those who can positively or negatively influence the success or failure of a project, must be identified. Their functions and roles must also be defined clearly to avoid role confusion. List all stakeholders, their roles, and how they will contribute to the project.
4. Project Goal(s).
Having a clear, agreed-upon, goal statement is vital to the success of the project. The goal statement in the project charter must be identical to the goal established in the approved project proposal. The goal must be:
• Specific
• Measurable
• Achievable
• Relevant to the corporate strategy
• Time-lined
5. Project Priorities.
A list of the project priorities (time, cost, scope, etc.) must be included and delineated in the order importance. These priorities should remain constant throughout the project whenever possible. The importance of conveying project priorities to the project manager cannot be stressed enough.
6. Scope Statement.
A scope statement that describes the major activities of the project in such a way that it will be absolutely clear if extra work is added later on. Sometimes it is best to also include what is not in the scope of the project. The scope statement in the project charter must reflect the approved scope described in the project proposal, and may further expand on its details. If a scope statement is not included in the project charter, it must be developed as part of the project scope planning efforts.
7. Product Requirements.
Either marketing personnel, or a customer will identify the product requirements--what the product is expected to do, and how it must perform. Requirements at this stage are embryonic and will be defined during the project planning processes. Remember, most customers don’t know what they want until they know what you can provide, so initial product requirements are often “soft.” Product requirements must be consistent with those in the approved project proposal, and are sometimes included in a document called a, “Marketing Requirements Document (MRD).”
8. Project Assumptions.
Any and all assumptions related to this project must be clearly described. This may include the availability of specific resources, information, funding, and project personnel skills.
9. Project Constraints & Boundaries.
Any constraints or boundaries placed on this project must be clearly described. This might include budget/funding limits, time constraints, regulations, or quality standards that must be met.
10. Initial Project Risks.
Any identifiable obstacles and risks (threats) that might prevent the successful attainment of the project goals must be considered. Each risk must be analyzed, quantified, and prioritized as much as possible with the information available at this stage of a new project. Risk responses, including mitigations, risk sharing, risk avoidance, and risk tolerances should be described in this portion of the project proposal. The risks identified in the project charter must be identical to those in the project proposal, but may contain additional detailed risk management information.
11. List of Deliverables.
The project charter should include a list of deliverables produced by the project and submitted to a customer, or a production manager for acceptance. There can be both intermediate and end deliverables.
12. Cost Estimates.
Any cost estimates that were developed and approved in the project proposal must be reflected in the project charter. These might also contain the following aspects:
• How fixed is the budget?
• Why was it set at ($$$)?
• How far over the budget or how late can we be and still be successful?
• Do we know have enough to produce a reliable estimate?
13. Schedule Estimates.
Any project duration estimates that were developed and approved in the project proposal must also be reflected in the project charter. These might also contain the following aspects:
• How was the project deadline arrived at?
• Why does the project need to be finished by (date)?
• Do we know have enough information to produce a reliable estimate?
14. Integrated Change Control.
The project charter must also define how changes to the project charter, or the approved project management plan, will be managed. Processes such as configuration management, or software release centers must be described in detail, including who has the authority to accept of reject these changes.
15. Success Criteria.
In addition to the project goals it is also important to determine the success criteria of a project. Not all projects finish exactly on time, within budget, or with all initial scope completed, but this does not mean that a project has failed. Aggressive, but doable success criteria will ensure having a motivated project team.

What to Do If You Have No Project Charter?
If you as a project manager have no written project charter you should write one and then submit it to your sponsor, and the other key stakeholders, for review, revision, and written approval. It is critical that all project charters be in writing and signed by the appropriate stakeholders.

Monday, May 5, 2008

The Role of the Project Coordinator

Most project managers find that they when they complete the planning of a project they become inundated in the following execution phase. This is primarily because of the need for overall project coordination, routine schedule management, integrated change control, and project status tracking. In most cases, there is more work than can be accomplished by the project manager, even when working overtime. For this reason, many corporations are realizing the need for a project coordinator, also called a project expediter.

Project Coordination
Project teams often require coordination of activities, resources, equipment, and information. To satisfy this need the project coordinator functions in their primary role. Any coordination issues which cannot be resolved are elevated to the project manager.

The Coordinator and Project Schedule Management
It is the project coordinator who is to be the expert on the project schedule software. If project managers attempt to fulfill this role they will discover that it is so time consuming that if diverts their focus from the overall management of the project. In many cases they often find themselves having to “relearn” the intricacies of the software. To alleviate this dilemma, a project coordinator assumes the role of working with project team members to develop the initial project schedule, making certain that all project schedule conflicts are resolved, and then updating it routinely. When schedule compression techniques, such as lead-lag exploitation, fast-tracking, or critical path crashing become necessary, it is the project coordinator who works with project members to develop the trade-off data required by the project manager for making such decisions.

The Coordinator and Project Status Reviews
While some project managers prefer to have each team leader present the status of the recent work, many insist on having the project coordinator present the status since they will be unbiased. As a result, true project problems will be surfaced in the project status review meetings. It will then be up to the project manager, and the “problem owner” to work out a corrective action plan. The project coordinator follows up on the approved corrective action plan.

The Coordinator and Change Control Management
The task of presenting, reviewing, and tracking approved changes to the project management plan can also be very time consuming. Some larger companies adopt the practice of using a “configuration manager” to accomplish the necessary coordination of all proposed and finalized changes, however, many combine this role with that of a project coordinator. The coordinator would ensure that all necessary information has been gathered by the change initiator prior to presenting it to the change-control board, monitoring the review, and following up on all approved changes including the dissemination of any revised project documents.

The Coordinator and Project Procurement
When projects involve either contract or subcontract administration, the project coordinator works to ensure project schedule integration with either the customer, or the subcontractor. Generally, the coordinator also tracks subcontractor schedules to identify problem areas.

The Dilemma
Since most corporations do not appreciate the need for supplying a project coordinator to the project as a support to the project manager, many project managers find themselves in the dilemma of becoming overwhelmed by the functions described above. George Heywood and Thomas Allen, in his PM Network Article, "Project Controls, How Much is Enough," posits that about 2% to 5% of the total project budget must be allocated to project coordination in order to prevent this dilemma.

Thursday, July 19, 2007

The Ethical Shift in American Business

Over the past few years we have seen a significant shift in business ethics. For some managers it is deemed acceptable to "bend the legal rules" as long as it ultimately benefits the company. This ethical system, often called teleological ethics, is being embraced by many managers and executive today when placed under pressure to be competitive in the business world.
Others hold to a more traditional form of ethics called deontological ethics where the right thing is done no matter what the consequences are---even if it means getting fired.
So how does a project manager choose the right ethical system when faced with pressures from executive managers to do whatever it takes to benefit the company?

Monday, January 22, 2007

What's Your Great Project Challenge?

Many of my project management students have indicated that most of their project crises can be traced back to the project’s initial definition. Others believe that most of their project problems stem from poor risk management, role confusion, and scope management. From your experience, what one single underlying cause has created the most difficult challenge in your projects? mdt

Building Successful Project Teams

There’s nothing worse than being on a team when no one trusts anyone else. Such situations lead to gamesmanship and a lot of watching what you say because you don’t want your own words to bounce back in your face.

TEAM DEVELOPMENT IS A MUST TODAY
One of America’s greatest strengths has always been its manufacturing ability, yet more and more work today seems to be departing for Southeast Asia and the Far East.

Today, companies are under tremendous pressure to rapidly introduce new products into the marketplace because existing product life cycles are becoming shorter. In an attempt to reduce the time it takes to get a new product on the market, many American companies are adopting techniques such as concurrent engineering, also called simultaneous engineering. They no longer have the luxury of performing work in series.

Concurrent engineering is not without potential risks, the largest one being the cost of rework. The most effective method today for minimizing risks, while at the same time performing work in parallel, is project management.

Project management, in turn, depends heavily on the use of project teams where authority is passed down to the product development level. Decision making and problem solving is expedited when effective project teams are empowered. Yet many project teams seem to struggle and are often ineffective. Why? The answer lies with the ability of the project manager to establish, develop, and nurture a team. Simply “assigning” a group of individuals to work together does not make a team.

EIGHT ELEMENTS OF A HEALTHY PROJECT TEAM
The question is often asked, “how would I recognize an effective, healthy project team if I saw one?” While the definition of an effective team can be debated for days, it stands that a team must have at least the following proven eight elements in order to function effectively and efficiently.


1 - SUPPORT FROM THE SUPERIOR
Is there is good general satisfaction among subordinates with the way they are being treated by their superior? Do subordinates feel the superior is constructive and fair in helping them? Are subordinates are able to work out problems with the superior and feel he/she supports them with higher management?
2 - ENCOURAGEMENT OF INITIATIVE
Do the actions of the superior demonstrate that he/she believes the subordinates will act in a mature, self-controlling, responsible manner?
3 - INFLUENCE WITH THE SUPERIOR
Is the superior willing to share power rather than hold it tightly? Is the superior responsive to influence from those below who should properly be able to communicate effectively to the superior? Do they feel they can be open and aboveboard in communicating about problems to the superior?
4 - MUTUAL SUPPORT WITHIN THE GROUP
Do the subordinates have high confidence and trust in the superior and each other? Is there is good teamwork and helpfulness within the group? Are problems tackled with joint action? Are alternatives explored openly?
5 - HIGH STANDARDS OF ACCOMPLISHMENT
Are overall objectives clear, and accepted as appropriate by the group members? Do high standards prevail for efficiency and output and for effectiveness as an organization? Are decisions based on sound data and effective use of problem-solving processes? Are needed systems developed and supported?
6 - RECOGNITION
Does the subordinate feel that if he/she does a good job, it will be recognized and rewarded?
7 - JOB IMPORTANCE
Does the subordinate feel the job assigned to him/her is important to the overall group objectives, and ultimately to the company?
8 - OPPORTUNITY FOR ADVANCEMENT
Does the employee see good opportunities to advance in the organization if the job is performed well.

DEVELOPING NEW TEAMS
The development of a new team begins with recognizing the anxiety that usually comes when a new team is formed. It’s normal and predictable. However, unless dealt with at the outset, it can be a serious barrier. Here are three actions a prudent manager can take to put these anxieties to rest.
First, sit down with each team member, individually, and review the project objectives, who is involved and why, the importance of the project to the overall organization and why their part is vital. Explain the work being assigned to the other members and show how it is evenly distributed. Point out the recognition given to those who do a good job. Second, provide honest and accurate feedback to each team member as they work into their new team role. This feedback should be provided more frequently at the beginning. Third, ask for feedback from individual team members. Find out how they feel about their role as a team member. Ask for their suggestions in making the team more efficient. Recognize and reward good ideas!

SUMMARY
  • Effective teams are made by managers who are committed to an on-going development and nurturing process. The “delegate and run” method rarely works.
  • Team effectiveness profiles, using the eight elements described in this article, should be measured every six months and any resulting weak areas must be addressed. Team measurement models can be found at: www.projectmgt.com.
  • There is no greater reward for a manager than to work with a team that is effective, cohesive, and successful in bringing about greater company capabilities and profits.