Efficient Project Execution (An Idea)

Problems:

Project Organization: In most software companies, the project information such as requirements, designs, tasks, discussions, etc is scattered in various documents (word, PowerPoint, spreadsheets, wiki pages, blog, mail, chat, etc).

1. It's hard to track a project's progress with this disconnected information model, even if they use wiki to create documents they are usually lost in the wiki pages jungle. Any discussions occurred about a project via emails, chat, meetings are lost unless somebody collects and organizes them manually.
2. It's hard to trace project requirements, designs, tasks, people, milestones, bugs, etc with the information model.
3. It's hard to learn lessons from previous projects using the disconnected information model.

Project Status:Usually managers conduct daily or weekly meetings to get status from developers working on a project. Status meetings are expensive. For example, work on a project is halted for about 30 minutes prior to the meeting + time spent in the meeting + 30 minutes after the meeting, this time is per person.

Project managers or developers should be able to answer questions like

• How much time is being spent on what tasks?
• Is there heavy context switching going on between unrelated projects or tasks?
• What percentage of a project's work is completed?
• What are the chances of not completing a project on time?
• What tasks (supporting customers, supporting old code, etc) are slowing down the current project?

Time Tracking:Usually developers record time they spent on a requirement after a task is completed, rather than continuously recording time, so that it is useful to find out information about context switching between projects or tasks. For example, to calculate amount of time spent on bugs on the previous release versus time spent on a new project or task.

A typical developer's day may be as follows

• 9:00AM :Start requirement 1
• 10:00AM:Stop previous task, disturbed by a team mate to discuss something.
• 10:45AM :Start requirement 1
• 12:00PM :Stop previous task
• 1:00PM :Attend status meeting
• 1:45PM :Start requirement 1
• 3:00PM :Stop previous task, check email and respond.
• 3:30PM :Start Requirement 1
• 5:00PM :Stop previous task
  

The typical time tracking works by recording time taken to finish a task, in the above case it is 5Hrs spent on "requirement 1". The time tracking tool lost the critical information about context switching for example, in the above scenario first interruption (highlighted) resulted in 45 minutes lose.

Solution:

We could have an enterprise web application (web2.0) that allows interconnection of projects, requirements, designs, tasks, milestones, bugs, people, blog entries, etc.

Here's the laundry list of features of a typical product.

• Create projects.
• Add people to projects with various roles.
• Create individual requirements (could be as a wiki page).
• Allow project members to create various types of tasks for each requirement. The standard tasks could be requirements analysis, design, implementation, test and documentation tasks.
• Assign requirements/tasks to team members.
• Create milestones by grouping either requirements or tasks.
• Associate tasks to requirements.
• Associate bugs to requirements.
• Associate part of a project to another project to create a dependency.
• Allow discussions between two or more members about some requirement to happen from within a requirement wiki page, so that information is recorded and associated to a requirement appropriately.
• Allow time tracking per team member as well as for the whole project team. The time tracking would provide information about context switching, amount of time spent on various projects, etc.

Existing Products:
There are number of products that are available already, for example, basecamp from 37signals.com, it offers disconnected todo lists and time tracking per requirement basis not continuous time tracking. There are also standalone time tracking tools that detect time spent on IDE, browser, etc and they are not integrated into any project either.

Conclusion:

I think that there is an opportunity for a enterprise product (web 2.0) that is one stop shop for

• organizing project information (projects, requirements, tasks, time, people, milestones, bugs, etc).
• tracking time.
• enabling efficient collaboration such as Instant Messaging from within a requirement page, etc.
• Integrate bug tracking system, wikis, IM, email, blogs, etc.