Please login or join to subscribe to this thread
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.
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.
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.
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.
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.
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 !
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.
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
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 :(
Please login or join to reply