managementHere is a very simple management framework, which we have used in our teams for the last two years. We came to it experimentally, trying to merge some Agile principles, PMBOK ideas, and common sense. Our experience so far is positive, even though the proposed rules of work are not really about project management, but more about keeping an eye on the situation and making sure it’s not falling apart. This is the best most modern teams can afford anyway.
Each group has a Team Coordinator (TC), who is usually not the most knowledgeable expert, but someone with good organizational skills and strong self-discipline. TC is responsible for four cornerstone elements of our management framework: 1) Plan, 2) Monday Reports, 3) Weekly Calls, and 4) Demos.
Plan
Our Plan is a very simple text document visible for everybody in the team, usually in Google Docs, and editable by the TC only. It is a primitive version of a Work Breakdown Structure (WBS) married with a Gantt Chart, where each line is a tangible artifact, like a file, a document, a software module, a PDF report, and so on. Tasks are not welcome in the Plan, only artifacts. An example:
- Requirements v1 [Jeff+Bill, 25-Aug, 80%]
- Dataset with 500+ files [Anna+Jeff, 3-Sep, 100%]
- XYZ module deployed [John+Jeff, 14-Sep, 50%]
- Database redesign [Bill+Mary, 27-Sep, 20%]
- ABC package released [Jeff+Mary, 1-Oct, 0%]
- Report on data analysis [Jeff+Anna, 5-Oct, 10%]
Each artifact has 1) an owner and 2) a reviewer. In the first artifact “Requirements v1” the owner is Jeff and the reviewer is Bill. Jeff will make sure the requirements are delivered, and Bill will check them and confirm. The owners may not necessarily be primary contributors to their artifacts, but they are responsible for keeping the delivery status under control. Simply put, when an artifact is delivered on time, we reward the owner; when the delivery is missed, we also blame (I know, most of you don’t like this word) the owner.
Each artifact has a planned delivery date. The dates may change as often as necessary, but at any moment of time the Plan has to have dates defined for all artifacts. The list is reverse sorted by dates.
Each artifact has a subjectively measured status of completion, like “80%” for the first artifact above. The TC collects this information from reviewers, not owners.
No more than three artifacts may be owned by one person and no more than four may be reviewed. Thus, anyone is allowed to keep no more than seven artifacts under control.
Monday Reports
Each Monday morning, the TC sends a report by email to all team sponsors: a plain-text email without any attachments or fancy formatting. All stakeholders, including all team members, are CC-ed too. An example:
From: Team Coordinator
To: Big Boss
CC: Programmer #1, Programmer #2, Friend #1, etc.
Subject: WEEK13 Dataset, Requirements, XYZ
Hi all,
Last week achievements:
- Added 100 new files to the Dataset [100%]
- Fixed the deployment of XYZ [50%]
- Refined the requirements [80%]
Next week plans:
- To publish ABC package draft
- To review first draft of the report
Risks:
- The server is weak, we may fail the delivery
of the dataset, report milestone will be missed.
Bye.
The subject of the email starts with the WEEK13, where 13 is the number of the previous calendar week in the current year. By the way, there are 52 weeks in almost every year. The WEEK part makes report emails easily searchable in the inbox. There is also a comma-separated list of the most important topics of the report, to give the reader a quick impression about the results being reported.
Each achievement of the last week starts with a verb or a past tense, like “fixed,” “added,” “refined” etc. After the verb the artifact is mentioned, which we contributed to. At the end of each line there is a progress status, subjectively measured by the author of the report. There should be no more than seven achievement points, no matter how big the team is nor how detailed the Plan. The report must not tell the full story, but only highlight what’s most important.
Wherever possible, each achievement item must be supplemented with a link leading to a pull request, or a file, or a document. There has to be something traceable and verifiable: the readers of the report must be able to find all necessary details for each item without asking its owner or the author of the report.
Each task for a new week starts with a verb in the infinitive form, like “to publish” or “to review” and then, of course, the artifact is mentioned. There should be no more than seven tasks in the list.
Each risk, in Cause-Risk-Effect format, is an opportunity for the reporter to protect the team: the more people knew about risks, the harder it will be to blame the team for failures, which are inevitable.
Weekly Calls
Every week at the same time and day, we make a 30-minute Zoom status call: everybody participates. We look at the Plan and discuss whether our work is still on track. We ask each other:
- Will all artifacts delivered mean success?
- Did we break down the scope correctly?
- What did we miss in our Plan?
- Are all owners committed to the their dates and scopes?
- Are there any risks overlooked?
We don’t use status calls for reporting. This is what we have Monday Reports for.
All decisions we make at status calls we call Meeting Minutes and send by email to everybody (or post in our Telegram group chat).
Demos
Almost every week we ask some artifact owner to demonstrate his or her results at a one-hour “demo” Zoom call. Usually it happens when the delivery date is approaching and an owner is ready to show something complete. However, demo calls are also very useful to collect opinions when an artifact is still in progress.
It’s the responsibility of a TC to make regular demo calls weekly, inviting owners of the most important artifacts.
All status calls and demo calls are recorded and posted into a private list on YouTube, where all team members can watch them later.
