Project management, unlike development in some ways, is not so much a skill as it is an art. Each project must be managed differently because of the various personalities, skills and requirements needed to complete it. This should seem obvious but, to many project managers, it is not. I learned this as a result of a project that I participated in recently – but not as the project manager in this case.

And I’ll add a caveat here – this is the second version of this particular post. I do not normally go through several revisions of my blog posts but it was necessary here as my first version was more an indictment of the project I was on rather than an impartial view of the failures that occurred and thoughts on how to make it better. Complaining about things may make people feel better in the short run but it does not help to provide long-term solutions to ensure the problems do not occur on the next project. One additional caveat is to point out that the experiences listed here on a fairly small project, only a half-dozen personnel and a timeframe of a few months (within a large organization, trust me, that is a fairly quick turnaround).

Perhaps the one key to any successful project is to have only a single project manager. This may seem a fairly obvious point but it is something that was hammered home on the aforementioned project. Indeed, after further reflection, this has not been uncommon in my experience though typically multiple project managers each handle various aspects of a given project, so it would be more like sub-project managers to a larger overall project. But the underlying point is that there should only ever be a single project manager at the top-most level and the delineation between that manager and any others should be very clear from the outset.

The next key is constant and open communication bewteen the project manager and all members of the project team. I will admit that this is a major issue for me and I work very hard to ensure that everyone has not just the information they need to do their piece of a project but also a view of the bigger picture. This serves two goals: they know exactly what they need to do but also gives them a piece of ownership of the larger project as a whole. It also helps to foster greater teamwork and accountability. When (not if, because the reality is that it will always happen) there is a problem within the project, if the team is already communicating, those problems can be addressed more quickly with fewer cascading issues as a result. For example, a problem on the part of one member of the team can be addressed by another if brought out into the open or a delay by one member can be addressed so that it does not cascade to the rest of the project. For projects with tight deadlines, a failure to communicate can prove disastrous.

Finally, there should only ever be a single source for the data needed for the project. Again, this should be fairly obvious but it is amazing how often failures can be traced back to this issue. There should only ever be one master project plan that the team uses to manage progress. And, if the project is a data-driven project, then all of the data should be in a single repository and not necessarily managed across a variety of applications or segmented by team/member. It does not matter if the plan is done in Project, Excel or some other project management software so long as everyone is operating off of the same plan. Correspondingly, any updates to the plan and/or data should be distributed to the entire team, even if the updates may not necessarily be applicable to all of the team. The purpose behind this (in much the same vein as the communication issue discussed above) is to ensure that nothing is missed and to allow everyone the opportunity for input that may actually help the project.