At my previous job with a large telecommunications company, I was constantly involved with projects of all sizes. In some, I was a mere pion, in others I was the manager. In most cases, including my own, a project more or less went through the same steps:
- A Manager is assigned to develop a new feature.
- Manager talks to a few developers to get input, then sits by himself to write the plan.
- Project Plan is reviewed with a few select others, and eventually accepted
- A group meeting is called, where the plan is 'revealed' to the entire team.
- More changes to the plan, as the team starts working
- After a few weeks, updating the plan becomes hard. There are so many changes, it is not kept updated.
- A top level manager asks for an update. This most likely happens friday afternoon, and is needed by monday morning for an executive meeting. The reason for this is a bit unclear to me.
- Manager frantically mails everyone for an update, calls India sunday night, updates the project, and monday morning sends the new plan to the top level manager.
- (At this point, there is a 50% chance the executive meeting is delayed, but that is beyond this post)
- Go back to bullet 5.
- Someday the project ends. At this point it is probably running late. Very often, projects are canceled very late, because their delay was not visible to anyone.
- The plan is created once, and then not maintained. What a waste of time.
- Team members do not give input, and can rarely influence the plan once it is created.
- Feedback is manual, using meetings or emails.
- Team members cannot see what is happening with the plan. Late or on time (or even early)?
As the years went by, I was not the only one to notice this trend of what we came to call "Static Burst Project Management." Static in this sense means that once the project is created, that's it. Burst in the sense that updates only happen when someone request them.
Since we used Microsoft Project at the time, this was really all we could do, unless we spent a huge amount of money on a Microsoft Project Server. Some teams started using the Project Server, but most gave up after a while. It was too complicated to install, and the team still needed Microsoft Project in order to make changes. While this is a great tool for project management, it lacks a bit in simplicity, and few wrong edits can seriously wreck havoc on a project plan.
Having mulled over this problem for a few years, two friends of mine and I finally decided to start our own company to solve this problem of collaboration. Our goal was not to create a new project management tool, but instead to enable collaboration using Microsoft Project files. We wanted to build on top of its success, and enable existing users a tool to collaborate on their existing projects. We also wanted to create a tool that was focused on the team members themselves, rather than the manager.
After 2 years of hard work, evenings, weekends (and lots of coffee), we finished version 1.0 of LiveProject on January 2nd 2007. Our company was called KaDonk (Funny story, maybe another time).
At that time, we had been beta-testing LiveProject for 8 months. Thanks to our excellent beta-testers and project managers, we had gotten a huge amount of feedback that went straight into the project. We use LiveProject ourselves every day, and we all know that if we were still working for a large company, this is the tool we would use.
On this blog, I will attempt to capture my thoughts on Project Management, and maybe a few anecdotes on starting a new Software Company in San Diego.
Posts
