From an organization perspective, after getting a decent project manager or scrum master, you need to have a place to share everything about the project. I personally don’t care if you use IBM Quickr, Microsoft Sharepoint, Confluence Wiki, or eProject. You just need to get a place to share the following:
- Documents that are deliverables
- Mockups and screenshots
- Comments on deliverables
- tasks and timelines
- Defined standards on what you will do in the project
- List of contact information for who works on the projects
- Key roles in the project
- Key information like testing usernames and passwords
- urls to all the environments
- etc.
What to Do
So yes, this seems kind of dumb but I do have a typical structure of things I like to include in a specific project. It’s not perfect but it’s worked for me in the past. It’s basically a way to track the who, the where, the what etc.
Again, you can poke holes in almost any taxonomy but you will want to have locations for key information and it will change according to what methodology you use. You can expect it to be different with Scrum projects vs RUP projects. The bottom line remains, create a place to share key information and use it. Don’t fall into the trap of resorting to email as your main communication device. You lose versions of deliverables. You lose comments and key decisions. When your project team doesn’t go to the source of truth and instead goes to email, you lose valuable time as everyone looks for key information.
Who Should Use Your Collab Tool
I’m a huge fan of transparency. I know many project managers or project teams that would rather create a line of separation. At times this is necessary. Most of the time however, you need to have everyone on the same page and trusting each other. I’ve found that when you have business users, project managers, consultants, contractors, developers, etc all seeing everything as it is created; you get a certain cohesion. You are all in this together. I’m even a fan of putting out incomplete documents in a work area. You may be afraid that the business will misinterpret the draft document but I’ve found that since they know you are working on it, they provide constructive feedback.
That said, sometimes you need to have a secure area to discuss or share information that’s not quite ready for publishing. That’s OK. Feel free to create a sub-section and secure it to whoever needs to see it. But don’t make that your main working area. In the long run, transparency provides a far more efficient working environment than the distrust lack of communication breeds.
Other Ideas
I had one project use a wiki as the project deliverable. Instead of putting everything in a series of Word Documents and Excel Spreadsheets, this team created wikis with pages and sub-pages matching key sections. This was great because:
- It fostered the transparency I love. Everyone sees the content as it’s created.
- It’s really easy to capture comments and decisions. Those comments and decisions remain
- Version control works well with this approach. Most wikis will automatically save the previous version
- It’s also easier to consume the content. Web pages are easier to read than a series of documents
- It’s easier to find the content. Tag a wiki page and you’ve made it easier to find than a section inside of a document
I believe this to be a superior way to approach those parts of your project that are still document based. I also realize that this means the entire project team and the business must buy into it. Most people have some serious concerns so I don’t this approach used very often. I wish I did see it used more.
Add to your list ProjExec for Quickr – Social Project Management a.k.a the “Facebook” of project teams voted Best in Show at LS 2011. Robust project management tools + Facebook-style activity stream w/microblogging called the Project Wall accessible from Quickr place, Notes client side bar or mobile devices/tablets.
If you like transparency, this is as good as it gets.