Simple Project Management with FlexLists

Everybody probably has had his share of problems with managing projects executed by a remote development team. A key factor is good communication. Offcourse you can write long detailed reports with the exact specifications and then hope for the best. You can use expensive collaboration tools nobody actually uses or you can keep things simple.

We have succesfully managed several projects using a very simple approach. The main idea is that specifications are based on the needs of the developers and are never set in stone. To achieve this we set up a simple FlexList with the folowing fields:

• Description (for a short identification of the feature)
  
• Details
  
• Priority (with four possible priority values)
  
• Status (Free text)
  
• Notes (More free text)

To get started you specify every feature rather globally. Don't spend to much time on it, because you don't have a good idea of where the project is heading anyway. Get the developers started on the high priority tasks. Now the important thing is to have a bit of discipline and keep all communication in the FlexList. So no questions by e-mail, mesenger or telephone. The developers can raise questions by writing them in the Notes field and setting the status to e.g. 'Question'. The only thing you need to do is regularly check the list for status changes. (or use the RSS feed to track it) You can then alter descriptions, answer questions or test delivered tasks.

The advantage of this approach is that all knowledge, doubts, questions and bugs are in one place, everyone can easily reference to the list and find what decisions have been made. Because the list is so simple everybody can directly understand and use it, without the need to learn complex bugtracking tools. Furthermore you could tune it to your needs by adding deadlines, hour registration, assignment and more. You can even profit from the time difference because you can easily update the list while they are not at work, so the developers can have all questions answered before the new day even begins.

Just keep in mind that specifications are just a way to communicate, the really important thing is to stimulate developers to ask questions, think about the features and the implementation. A polished report will make it much harder to discuss and change the specifications to the current demands of users, developers and your customer.

Start managing my project now!

RSS