There are many projects which follow the old phrase: “we don’t know where to go but we try to get there sooner”.
Ever got in the situation that your boss complained about the project costs after he reassigned two of your key people to other tasks? Your architect just show up at the status meeting every two weeks instead of working half time in the project? Team members unaware about their roles in the project?
The project agreement is a simple way to align all involved parties of a project: project manager, team members and your boss 🙂 But don’t missunderstand the project agreement with the customer contract or an internal paper describing the goal of the project. The agreement is a summary of all related information which define the project from the very beginning till the end.
Before you kickoff a project you should write down the agreements on which the project is based on in a single document and not afterwards. There are plenty of them, e.g:
- internal and external project organization
- project roles of the team members
- escalation and change request process and organization
- timeline of the project
- relevant documentation
- quality asurance process like interval of status meetings
- budget in terms of working time or financial aspects
- payment milestones
- development coding convention
- version controll process and tools
- bug tracking
After you wrote the project agreement make it public to all involved parties and ensure that everybody understands the document. I think the rest is simple to understand thereafter.
There will be more details in one of the next blogs.
In my last post I wrote about why status meetings and meeting minutes are important. The following checklist is a simple questionnaire to help you to focus in your discussion.
One big mistake in many status meetings I’ve seen was that everybody was taking about several things in parallel. Raising problems and questions in such a way that you can’t summarize it in written form. There is one good indicator to point out this situation: when the discussion last longer than 5 minutes and you are still not able to write a single sentence in your meeting minute or ticket system.
In that case stop the discussion and start with the following checklist. I promise that you will get immediate input for your minutes. In most cases you get decisions and several todos after such a lengthy discussion.
Here they are:
- First ask the participants to formulate 1 short sentence which describes the topic best. This is a good starting point for the name of the task.
- What happened until now?
- What should happen in the future?
- Are there alternative solutions?
- What happens when this issue is not solved or nobody takes care about it?
- Impact on other tasks, milestones, budget, delivery of the project?
- Known risks?
For internal status meetings only:
- Is the customer informed about the topic?
- Must the customer be informed? If yes in which way, e.g.
- By phone and phone protocol
- Traceable in written form like customer status meeting minute
- Has the topic legal aspects to consider?
One of the never ending stories in business is about how to record the ongoing and results of status meetings. Status meetings have a fixed set of conditions, like
- reoccurring very often
- the agenda is the status of the project
- team members and customers are the participants
- many todos to follow up (ticket system)
- may have legal aspects when it comes to troubles later
Nevertheless I’ve seen many projects which neglect to write records of status meetings or don’t hold regular status meetings at all. I think a regular status meeting which follows simple rules helps to avoid 80% of the typical errors which occur in project, e.g. unclear production date, forgotten payment milestones or contractual penalty’s.
There are simple rules to follow which ensure that the status meeting is
- meaningful – everybody clearly understands what should be done next
- straight forward – don’t waste your lifetime
- foolproof – don’t let your project suffer from mistakes you can avoid
The following simple rules result from 10 years practice in project business. They don’t claim to cover every situation but are a minimum every status meeting should obey. Here they are:
- Nominate one person who will write the meeting minutes
- Write the record during the meeting together with the participants! Ask the participants if you are unsure what to write.
- Don’t write down just the conservation but identify the topics. One discussion may raise several decisions or todos.
- Every time a discussion about something does not result in dedicated decisions or todos interrupt the discussion and demand to run through the meeting minute checklist! Never allow lengthly discussions which don’t result in written decisions or todos. Give them 5 minutes.
- Separate the infos & decisions of a status meeting from the todos! Write the infos and decisions of the meeting in the meeting minutes but manage the todos as tickets in a ticket system. To make it clear: don’t write todos in the meeting minutes manage them in the ticket system or will get a mess.
- List the infos and decisions of the meeting in chronological order. Every entry must provide the following attributes: a running number, description (title&summary), type (info or decision) and responsible (who decided that entry).
- I recommend to begin the running number anew from #1 with every status meeting (relative numbering). To refer to a decision you need the date of the status meeting and the running number.
- List the discussed trouble ticket numbers in the status meeting record. Even just a simple list of ticket numbers ensures you understand later what were your focus at the meeting
- If you want to make it perfect, create for every “decision” afterwards a separate tickets in your ticketsystem (e.g. Jira supports that kind of ticket types). This makes it on the long run easier to list all your decisions and verify whether you made already certain decisions.
Remember that even it is widely unpopular to concentrate on meeting minutes they are a key element for successful projects.