Thoughts on Collaboration

I have for some time now thought about the concept of Collaboration in regards to Project Management. While I worked for my old company, I had the "joy" of managing small projects. In all honesty, I am probably not a very good project manager. At the time I was not an expert in Microsoft Project (Can you ever truly be?), and I tended to fall into the "Static Burst Project Management" category. Once, I think I accidentally turned on baselines, and by the time I realized it, my project file was around 100Mb, and I was unable to even open it, much less mail it to others.

My team was called Archimedes, and consisted of 5 senior Software Architects, which I had hand-picked from throughout the organization. These guys were absolutely brilliant, and I soon realized that for me to sit and create a project plan, or update it, without the help of them all would be crazy. I ran the team for about a year (Before an organization change disintegrated us), and I had quickly realized that to get the absolutely maximum result from these people, I had to give them the maximum amount of empowerment and impact that I could.

As a consequence, I regularly told them things I was not supposed to. For instance, at one point our executive management team told me about a new feature and thus architectural change that was coming down the pipeline 6 months later. For reasons I don't quite fathom, this was to be secret (There are way too many things that are secret in organizations). About 10 minutes later I had my team in a meeting room, closed the doors, and told them what was happening. I told them not to tell anyone, but that they each should consider how we could support this new feature, its impact, and so forth. By the time we received an official go-ahead, we already knew what to do, how to do it, and which teams would be impacted. My guys felt very important, and they all contributed to a great solution. This is just how it worked. I felt I could trust these guys with any task and they would figure it out (In fact I did, and they did).

Thus, while creating a project plan, it struck me how insane it was that I could not continuously pick the brains of my team. I could of course call meetings every week, and ask for email updates, but what a pain. I wanted a way to keep my project up-to-date at all times, ready for the popular request from management: "Could you give us a quick update..." I also wanted my team to be able to see pending changes from other members, and so be able to react, even when I was traveling or out of town.

It started to dawn on me that I had 5 of the brightest guys in the company, and no efficient way to capture their many years of knowledge while planning.

Another truism about project plans I had realized is that they are all subject to continuous changes. Requirement changes, tests can introduce new bugs, marketing conditions changes. The one static thing about a Project Plan is that it will change. I needed a tool that would allow the team to be aware of these changes, react on them, edit existing tasks, and even add new tasks. And this needed to happen live, as soon as a change occurred. Not because the projects were all that urgent, but because there seemed to be no reason to make it slower than live.

At the company, we also had a UI team, consisting of around 30 people. Imagine the gargantuan improvement on project plans that could be achieved if every member of a team could view changes at any time. See the project status at any time, and comment and collaborate in a dynamic environment. The more I discussed this with others, the more convinced I became that this is the way to do project management.

Instead of alienating team members by pushing a plan on them, I wanted to share a plan, and encourage feedback. Who better than the team would realize the a task was missing, a duration wrong, or a dependency wrong. After all, the team had to do the work - they were the experts.

Thus, after years participating in projects, running projects, seeing project after project fall behind schedule, I have devised the following recommendations/thoughts about Project Collaboration:

• Share plans, at all times, as soon as a change is known, with everyone. Hide nothing.
• Allow team members to provide feedback. Challenge if necessary, but encourage feedback.
• A team that participates in planning feel empowered. Empowered people work harder and better than non-empowered people.
  
• Anyone who has estimated their own tasks will work hard to meet their own deadlines.
  
• If a plan falls behind schedule, the team will work together to pick up the slack if they feel ownership for the plan
• An up-to-date plan makes you sleep better at night (Literally).
• With empowerment comes responsibility. With responsibility comes resolve. With resolve comes results.
• Be honest when something goes wrong. Ask for advice.
  
• Never, ever, unless there are legal reasons, hide information from your team. Use their brains to help find a solution, and they will jump at the chance to help their manager, and the entire team.
  

To me, Project Management is all about empowerment, sharing, and allowing people to feel responsible and be accountable for their own work. Granted, some people will not work well like that, and your style may have to be adapted to individuals. My own experience in Scandinavia, and in the US tells me that most people will perform miracles when allowed to provide significant, relevant input.

Features for LiveProject Version 2.0

As we have finished version 1.x of LiveProject, we are reviewing our roadmap for version 2.0. We have a lot of features planned, as we collected the more advanced ideas over the past year while focusing on getting version 1.0 out.

If you have any requests or ideas, we would love to hear about them. Send a mail to

suggestions@kadonk.com with your input.

The start of KaDonk and LiveProject

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:

1. A Manager is assigned to develop a new feature.
2. Manager talks to a few developers to get input, then sits by himself to write the plan.
3. Project Plan is reviewed with a few select others, and eventually accepted
4. A group meeting is called, where the plan is 'revealed' to the entire team.
5. More changes to the plan, as the team starts working
6. After a few weeks, updating the plan becomes hard. There are so many changes, it is not kept updated.
   
7. 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.
8. 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.
1. (At this point, there is a 50% chance the executive meeting is delayed, but that is beyond this post)
9. Go back to bullet 5.
10. 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.
    

While it is certainly possible to "squeak by" using this method (or lack thereof) it certainly is not the best way to work. A few problems comes immediately to mind:

• 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)?

Or put simply, in one all-encompassing word: There is no collaboration !

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.