Last week, I blogged about how to start a wiki on your blog. One of the great things about wiki was to run a entire project using a wiki, however a wiki is limited in functionality and a lack of any concrete structure makes wiki unacceptable for certain projects.
If you’re looking to run a full project management suite that lets you look at task, tasklist and milestones. Manage time and resources, provide 1-page updates for stakeholders. You’re in luck because that’s what I’m doing here today. However, before we proceed to the how-to-install, I thought it’s best if we revisit why you’d need a web-based tool for project management and how it can help overcome the 4 major pitfalls of the traditional method of managing project plans via MS Project and emails.
Let’s look at the traditional project management models that most software projects are familiar with. In the ‘traditional’ model, a typical project manager would use tools like Microsoft Excel or Microsoft Project to draft out a project plan that usually comes in the form of a Gnatt chart. Each line item in the Gantt chart is a task list, which can then be broken further down into task.
In project management a task is an activity that needs to be accomplished within a defined period of time. An assignment is a task under the responsibility of an assignee which should have a start and end date defined.
On top of these there are project milestones, letting the project and external stakeholders know how far along the project is, and whether the project is on schedule. A milestone is sort of a high level work package that the project needs to get done.
Within the framework of project management, a milestone is the end of a stage that marks the completion of a work package or phase, typically marked by a high level event such as completion, endorsement or signing of a deliverable, document or a high level review meeting.
In general we see the lowest level of the project plan as task, and atomic unit that is either done or not done. At this level it’s uncommon to have it 10% or 20% down. A task is atomic and has only 2 states, Done and Not Done.
Higher up the ladder we have task list,which is a collection of task. If a tasklist has 10 task, 5 of which are done, the task list is 50% done.
Even higher up we have a milestone, which is (usually) a collection of tasklist.
Now let’s look at a real-life project example.
So in terms of lower to higher level
Task – > Atomic, done or not done.
Tasklist -> Collection of Task
Milestone – >Usually a collection of task list, used for reporting the current status of the project.
Now that we’ve got that out of the way. Let’s say we have a project manager named Jerry, and Jerry has just completed his project plan in Microsoft Project. He then shares that project plan out to the CEO of the company, and the project team. The project team has 2 developers, 1 architect, 1 tester and 1 Business Analyst.
So the Project gets and approval, and finally it gets started, and so far things are going according to plan. Everyday the project team has a meeting where the project manager goes through each tasklist (and task) on the project plan to make sure everything is in order. Each member is in the meeting, even though sometimes they could have no outstanding task for the day (or even the whole week).
Suddenly an unexpected incident occurs, the project plan is missing a key task. For example, let’s say one of the key components of the application has an expired license and developers can develop till the license is renewed. This causes 2 big problems:
a) The timeline has to be shifted back, by the amount of time it takes to renew the license.
b) The project plan now has to be include this new tasklist (let’s say there are 5 task in this tasklist).
What usually happens now is the project plan is then updated, and then shared with the project team again, we now have a new version of the project plan. This project plan would then have to be sent (usually via email) again to the developers to reflect this new change, the CEO will also have to receive a new copy.
Then when the team meetings occur (sometimes virtually via teleconference), people start referencing emails by timeline. “So this is the project plan I sent out yesterday at 4.15pm”, and there is a VERY real possibility that you can have the entire project team referencing different versions of the document while the team meeting goes on.
Then the unthinkable happens, and they discover a business requirement can’t be met unless the project re-designs the application. Jerry thinks this particular business requirement is nice to have, and decides to take forgo meeting the requirement for the sake of the project timeline. However, this results in a long series of emails between him and the Business Analyst. The business analyst then ropes in a developer into the email thread halfway, the developer then consults the architect in a private email (forwarded from the source), the architect then goes back to the project manager, and says it was a misunderstanding that that we’ll be able to meet the requirement after all. To late though because the BA has already informed the business the requirement can’t be met and the CEO is furious. It’s a classic case where the emails fly about without any purpose and direction, because the email has already branched out into so many different branches, no one is sure what’s it about anymore.
Finally, some project members (and even the project manager), could be on multiple projects. This means multiple excel spreadsheets or MS Project documents to take care of. A single repository is rarely ever used, and a lot of times even the project managers suffers from project fatigue. The project manager is finding it hard to keep up with keeping 3 different copies of project plans for 3 different projects.
The Gantt chart project plan, usually list out the task in the order of which they have to be done (due dates). That’s perfect for a project manager, but difficult for a project member since my specific task could be drowned out by others and I can’t really find what exactly I’m suppose to do without some filtering. In summary the usual project checklist is designed for project managers and not project members.
What you’ve just seen is an outline of 4 different problems, when the project manager uses just emails and local files to cordinate a project.
Problem 1: Data redundancy means that many different versions of the project plan are flying about, and only the project manager has the latest version. Project members can’t modify the data, because then they need to send the updated plan to the project manager to updates it on his masterlist. This means twice the work for every update.
Solution: Store the data online in a central repository. This means that people view a link to the latest version, rather than reference their emails. It means that everytime someone views it online, they’re viewing the latest version. Proper permissions mean that project members can update the status on the fly without having to go through the project manager.
Problem 2: Lost in emails. Emails were cutting edge 3 generations ago. Now it causes more confusion than anything. It doesn’t surprise project members anymore to come into the office after a one day vacation to see 20 emails with the same title populating their inbox. Some people choose the latest email and scroll down, but that only works if the email didn’t have branches, where emails with the same title are floated around but the content and people in the email are different.
Solution: Message boards, forums or wikis can help resolve this conflict. Once again, instead of pushing email out to folks to brainstorm solutions, a wiki acts as a central repository of information. Where the information is up to date and everyone in the project has access to the latest discussion. Side discussions can still take place, but overall the project will always have an ‘official’ stand with a wiki, and the best part is the discussion would be naturally documented. So things like ‘why didn’t we do this’ can be answered easily with a search.
Problem: One Project Limit. You can (in theory) run multiple projects with one MS project document, but that is of the assumption that the project members are the same. A project an it’s resources usually have a many-to-many relationship, meaning a project can have multiple members and a project member can be on multiple projects. This means that each project member needs to reference different project plans to get a high level view of their own workload. It also means that resource managers (typical in consulting firms) don’t get to see the task of their resources.
Solution 3: Central system for all projects. This means that all project plans are stored on a central system. The central system then is able to analyze the data and provide a break down the information and provide a full task list of all task for a project member across multiple projects. This means that the central system will have a full view of all projects currently running (and past projects as well) and cordinate the resources. This also allows companies to view their project-based employees and better gauge demand planning should new projects start to roll in. It also (in theory) allows other project team members to search a database of task to figure out ‘Has anyone done this before?’ and get the answer.
Problem: Project high-level view, versus Project-members detailed view. A project manager usually use tools that provide high level view of the project, and leave team members to their own devices to keep track of their own deliverables. Team members rarely use project plans as their too high-level and includes every deliverable. A project team member is usually only interested in ‘What am I suppose to do?’.
Solution 4: Filtering by project member. A system should be in place to allow project members to screen through all task and filter to:
1) Task that they are personally responsible for
2) Task that are dependant on their own task
3) Task that their own task are dependant on.
Once again, this can be done via MS project or excel, but not without including redundancy.
So obviously since we discussed the problems, there has to be a solution. There is, a web-based project management tool. One that:
Stores Data Online in a central repository (files/folders/emails..etc)
Provides message boards/discussion forums/wikis for important discussion between team members.
Provides a central systems for all projects currently run by the company. Or at least be able to support multiple projects.
Be able to filter through task/tasklist/milstones and provided data relevant to user only as well as high level view.
The best part is there is more than one. In fact there are as many as 30 different FREE web-based project management tools that you can host on your website free of charge. These tools are usually opensource as well.
So what are they?
Currently I’m reviewing 4.
Project Pier – A PHP based web project management tool that has all the bells and whistles.
Collabtive – A PHP based web project management tool that ALSO has all the bells and whistles. (similar to project pier).
dotproject – A PHP based web project management tool, that misses some of the bells and whistles but has a 1-click install on dreamhost.
Teambox – A Ruby on Rails based web project management tool, has everything including the kitchen sink as well as a subscription based service for those wishing to transfer all support for teambox to a fully qualified teams.
Other notable mentions:
ClockingIT – Looks great, but I’ve got no time to get the code and install it. Does have some good screen shots and might be worth a shot.
Once I’m able to write a review I’ll post it up here.
Until then, if you’re really impatient, my favorite based on first impressions would be Collabtive. Installing it is similar to installing wordpress. So no worries there. Teambox seems to be the most functional, but installing a ruby on rails app will take some acquisition of skills.