Thoughts on Collaboration in Project Management
By Anders Heie
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.
Anders Heie has 17 years of broad experience in the wireless industry, small mobile device domain, and enterprise application space. He’s been focusing for the last 3 years on architecting, developing, distributing and selling an enterprise application worldwide. He runs his own blog, Thoughts on Project Management and Software Architecture.