Project Management Central

Please login or join to subscribe to this thread

Topics: New Practitioners
Need your feedback about creation of a Team Charter
Network:28



Hi there,

I would like to formalize some of the implicit ground rules we have on my team of developers.

To summarize, I have thought about the following sections :

-----------------
"performance report"
sending the weekly performance report each monday

"leave management"
sending an email to the team when booking leaves
and scheduling a handing over meeting

"quality of code"
following the code standards
using the provided code templates when creating a new sql table
using the provided control checklist when applying a script on production
-----------------

What are your thought about it ? Is this the correct document for this kind of information ?

Do you have any examples or template to complete it ?

What is your experience about using such a document ?

How did you introduce it to your team (so that it gets buy-in) ?

Thanks for your advices !

Alexandre
Sort By:
Page: 1 2 next>
Network:954



Hi Alex,

Did you come up with these ground rules all by yourself? You may want to get some input from members of your team. This will give them a sense of ownership and engender commitment to obeying these laid down ground rules.

It is possible that you some other person in your team has some experience from other projects as to what behaviors or methods of work create better functionality for the desired results. You can get the buy-in of your team by creating these ground rules with them. Ask questions and agree with them on what should be done when these rules are breached, while you create this document.

You may also want to be more specific with each of the rules, e.g, for the weekly performance report, you want to add a specific time (9:00 AM) on Monday or say, before the end of work on Monday.

This document may be circulated through emails or posted up somewhere in the working environment where they are constantly reminded of what to and what not to do.

Best of luck.
Network:308



The more you can involve your team in the process of developing the rules, the more likely they will be to follow them. Make sure they understand the reasoning behind the rules and how they will help projects run more smoothly and make it easier to function as a team.
Network:307



That type of detail is not something I would typically see in a charter. A charter normally describes the purpose, business case, scope including constraints, stakeholders, risks, high level budget, and perhaps some other essential items to establish and approve the project ground rules.

I could see high level standards like "project will follow ISO 9001 standards" level of detail. Reporting frequency becomes problematic because if your communication plan changes, it requires a charter approval. Standard operating procedure like how you schedule your vacations is not something I would ever expect to see in a charter.
...
1 reply by Stanley Oranika
May 16, 2019 6:45 PM
Stanley Oranika
...
Actually, Keith, I think he's referring to a team charter which is quite different from a project charter.
Network:1520



Keith -

Alexandre is referring to a team (not project) charter.

I'd agree with Pamela that coming up with the working agreements for the team should be done by the team - your role is to facilitate the identification of those.

In general, a team charter looks at how we will interact with one another vs. specific standards for deliverables. Those should either be defined in the acceptance criteria for the deliverables, by your organization's standards, or in the quality management plan.

Kiron
Network:954



May 16, 2019 5:45 PM
Replying to Keith Novak
...
That type of detail is not something I would typically see in a charter. A charter normally describes the purpose, business case, scope including constraints, stakeholders, risks, high level budget, and perhaps some other essential items to establish and approve the project ground rules.

I could see high level standards like "project will follow ISO 9001 standards" level of detail. Reporting frequency becomes problematic because if your communication plan changes, it requires a charter approval. Standard operating procedure like how you schedule your vacations is not something I would ever expect to see in a charter.
Actually, Keith, I think he's referring to a team charter which is quite different from a project charter.
Network:100193



Those are what we usually refer to Rules of Engagement. Put a couple of them on the wall then have the team brainstorm for more.
Network:28



Thanks for all your feedback !

That helps me a lot.

Yes indeed, I'm referring to the team charter, not the project charter.

I agree there must be some involvement on the team, and also that there must be some explanation about why these rules are set.

@Stanley Oranika : these rules have been set along the way when we saw problems arising. For example, I am not the admin on the tool where the team book their leaves, and sometimes, some employees will warn they are on vacation just one day before, or in the worst case, not at all. This is why the rule for "leaves" has been set.

@Stéphane : good idea for the brainstorming thing !

Alexandre
Network:3295



You could create a Terms of Reference for your department or just a set of working norms that you put up as a poster. A team charter is another term for it, but as long as it works for you, then it doesn't need to "fit" into a standard corporate template.
Network:954



Adressing your last question, (“How do you introduce it to your team so that it gets buy-in?”);- Some team charter document formats include an area at the bottom of the page for signatures of team members
Network:407



I am setting up Team charter for my Team too. I plan to share Rules of engagements aka Basic set of expectations from everyone while working in Project in Project Documentation Database. So, everyone can refer to it anytime. I missed the part of taking inputs from team for buy-in & will do it on Monday itself :(
Page: 1 2 next>  

Please login or join to reply

Content ID:
ADVERTISEMENTS

If we do not succeed, then we run the risk of failure.

- Dan Quayle

ADVERTISEMENT

Sponsors