Category: project management

I am not currently managing any distributed teams. However, I used to and we always struggled with effective team meetings. Through trial and error we came up with the agenda below. This was a waterfall project and the agenda reflects that.

Development

• What modules are completed ready for handoff to QA?
• What modules are expected to be completed this week?
• Proposed changes to code already handed off to QA (refactoring, new features, non-QA generated bug fixes, re-organization of repository, etc.)
• Any additional tasks that have been identified
• Current target milestone date(s) – reason for delta (if any)

Test

• What modules has testing been completed?
• What modules are expected to be tested this week?
• Any blocking issues or high priority bugs outstanding?
• Any additional tasks that have been identified
• Current target milestone date(s) – reason for delta (if any)

Current Open Topics From Past Meetings

• First item
• Second item
• etc.

Years ago, I was stuggling to meet all of the committments I had made. When discussing this with my manager, he suggested keeping a log of what I did each day for a couple of weeks to identify items that I could eliminate or postpone (or now that I manage others – delegate). The exercise was useful and got me through the commitments. I then promptly forgot about it. Some time later, I was in a similar situation and started to keep the log. This time, I made it into a habit. Since then, I have kept a simple work log at my last 3 companies.

It is a simple format:

Date      * Description of what I did
Date      * Description of what I did
Date      * Description of what I did

No more than a line for each item. (The details can always be found in my engineering notebooks, wiki entries, source code control comments, bug reports, etc.) At the end of each week, I archive that week’s log and start a new one. I review the prior weeks log when I file my weekly status report. At longer intervals, I will review larger blocks of time.

The work log has helped me numerous times. It is especially useful when I need to answer questions like “when did we do A, B and C?”

I am currently in the process of moving out of my current position. One of the first things I did was review my work logs for the last 12 months and identify

What types of items should my replacement do?

What should be delegated to existing team members?

What items do I need to discuss with my boss about who should take on these duties?

Without these logs, I am sure I would let something slip through the cracks. This is definitely a habit that has been useful and that I will continue.

Over the years, I have seen many forms of status reports used by my team and the teams I have worked on. (I am distinguising these reports from those used for project status. Often, there may be corporate standards or contractual requirements associated with them.) I have settled on the following format which works well in a variety of submittal formats (email, word document, wiki, etc.):

Notes

Highlights

Lowlights

Plans

The notes section is optional. It is used as a reminder of upcoming items or circumstances that the manager should be aware. I have used it to record upcoming vacations, travel plans, customer visits, release dates, milestones, etc. This section often spans multiple reporting periods. The highlights section enumerates those items that went well during the reporting period. These are just bulleted lists – not a lot of text. The lowlights section are those things that did not go as planned. Once again, it is just a list of bullet points. The plans section lists what the individual intends to accomplish in the next reporting period. If this information is captured elsewhere, say in a project plan, then just reference it.

I use these reports in two ways. The first is in my regularly scheduled one-on-one meetings. I review the status report beforehand. (I am opposed to receiving both written and verbal status.) I make notes of those items I need more information on – these are usually the lowlights. I encourage my staff to include items in their reports that they want to discuss with me. The second way I use these are during performance reviews. This is especially useful in countering the “recency effect” – only remembering what has happened in the last 1-2 months. Unfortunately, it is usually the details of the good things I forget, so I review the highlights sections in detail for the last year. I only look for trends in the historical lowlights.

I have used this format consistently over the last 3 years. As an organization, we have tried collecting different information or collecting it in different ways but I keep coming back to this format.

I have been looking at standardizing some document templates for various software artifacts. As I review these things, there are several items that annoy me. As I think about it, I think the difference comes to how the documents are viewed (and in particular whether they are handled in hard copy vs. looking at them online).

Typical documents I see look like this:

Title Page

Revision History

Table of Contents

Bunch of standardized boilerplate text mixed with the content I am interested in

Many times, I need to page through 3-5 pages before I get to the information I am interested in.

Title Page: In a printed document, this may or may not be a nice touch. However, generally, it does not add significant value over just a title, author and update date at the top of the first page of text. Whether to include a title page or not in the printed document is a question of your audience. In an electronic document, this is text and whitespace that must be skipped over to get to the “meat” of the document.

Table of Contents: If I see another 3 page document with a table of contents, I think I will scream… My general rule for printed documents is that a table of contents is useful once the “meat” of the document is over 10 pages. In an electronic document (where I have full text search), I want the table of contents to be hyper linked enabled so I can use it as a navigation tool.

Boilerplate Text or Background Info: In a printed document, it is a matter of preference. In general, I prefer background information on a project to be kept in a separate document that is referred to in the main document. However, this may make using the printed document unwieldy if the reader needs to shuffle between multiple documents. In an electronic document, I want the background information to be a link to the definitive source. It is easy for me to skip over and if it changes, there is only one location that needs to be updated.

Boilerplate text is often seen in document templates. These are usually instructions for how to use the template or perhaps generic text that describes corporate policies or procedures. This text may be useful to a new employee or someone who is using the document for the first time. However, after that initial experience, this is text that most people will skip over and generally ends up wasting space. If instructions are needed or a reference to a procedure needs to be included, make it a reference (or link) to another document.

Revision History: Some documents include a detailed table of every change made by every person ever in the history of the document. While this is valuable information, I consider this document meta-data rather than content of the document itself. I would prefer to see this data stored in the version control or content management system rather in the body of the document. That being said, it is nice to have some version identifier in the document (perhaps in the header or footer) to distinguish between versions.