Project RACI

RACI matrix describes the participation by various roles in completing tasks or deliverables for a project or a process. A Project Manager should always create a RACI matrix for a project and share it with the team at the project kick-off. This helps in clarifying the expectations of the entire project team, including project manager and thus mitigates the risk of 'lack of ownership'. The project manager should take time to educate those who are not familiar with a RACI matrix. Also, team members are added during the course of the project as well as new roles are defined for the existing team members. In these instances the project manager should again clarify how those individuals/roles fit into the RACI matrix. Thus creating and sharing RACI is not a one time activity, but may need to be used as a means of communication multiple times during the course of the project
The projects where this tool has been used and well understood by the project team, there have been fewer gotchas in terms of 'who does what and why'. Project manager can harvest the benefits of this tool throughout the project

Great project plans do not assure accurate project status reports

Often times it is seen that a project starts with a good project plan created using Microsoft Project. After all, it’s a project management best practice to have a project plan. It’s a misnomer though that if we have a good project plan, the plan will show accurate status of the project at all times. So, if a senior management needs to know about the status of a project at a high-level, the project plan can provide that information.

It has been observed, on multiple occasions that as the project activities start happening, the updates to a project plan starts to fall behind. Some tasks are updated with % complete, however, actual start and finish dates are not updated. If the project manager is has not set his team’s expectations about requiring an update about progress of their respective tasks from them, he may get updates from some but not all. Thus the project plan update is incomplete and inaccurate. Also, if a project is 50% complete, doesn’t always mean that the remaining 50% will take twice the time already expended.

Creating and maintaining a project plan requires discipline. The project manager should set aside time each week to make those updates. Otherwise, the updates are often not made at all or made in an ad-hoc manner. The updates should include % complete and updates to actual start and finish date fields. In case the finish date is likely to be pushed out, the project manager should make that update.

knowledge harvesting is so hard!

Typically, documentation which is one of the means of harvesting knowledge on a project gets the least importance as the project nears completion. When any project starts, every project manager lays emphasis on knowledge harvesting and yet its importance diminishes as time goes by. Why does that happen?
One of the reasons is that people believe that documentation needs to be done at the end. As the project nears completion so much has transpired and documentation during the course of the project is in emails, in post-it notes, and people's brains that it is impossible to convert that into documentation that is coherent and meaningful. As a result, even if sufficient time is allocated at the end of the project to complete documentation, the documentation that is created is incomplete, lacks context (why certain things were done) and becomes merely an academic exercise
The consequence of incomplete and insufficient documentation is that the product or service created as a result of the project is not easily maintainable thereby increasing the total cost of ownership (TCO).
Project manager can take some simple steps to circumvent this problem:
1) Take bite-sized-documentation approach - document things as they happen without having to re-write. Provide a control mechanism to measure whether this approach is working and that the documentation is leverageable.
2) Do not take a one-size-fits-all approach - depending on type of project and its duration, different types of documentation may be necessary. Being pragmatic will ensure good documentation and team members will be more willing to complete documentation
3) Always use a central repository to store documentation - sharepoint, project wiki, etc. are good options. This eliminates the need to have to bring it all together towards the end of the project

It cannot happen on my project....

How often have you heard this on a project "if we had just taken care of this little thing, our project would have succeeded." In my experience, both as project manager and a team member, on some projects I have noticed that trivial issues bog down the progress. Although it may seem like a case of hindsight being 20:20, I feel that those issues can be prevented with some common sense preventive (pro-active) actions. Here is one such example:

On a business critical project where the organization did not have any prior experience implementing new software, a common sense approach should have been to have the software vendor accountable for implementation. However, when few initial milestones (provided by software vendor) were missed, it was assumed that the end date will be met through super-human efforts. This was a folly that resulted in additional milestones being missed and as expected dented confidence of end-user community in the project itself. At this point, project sponsor challenged the project management group (including the software vendor leadership) to re-baseline the project and build a closed-loop control mechanism to always keep the project on-track. The control mechanism (comprising of exception reports, clear metrics definition, etc.) should alert senior management in case of abnormal situations.

Although a simple example of a project being led by some smart project managers and yet, these issues were observed. Sometimes smart project managers are afflicted by the bug ‘it cannot happen on my project’ that breeds complacency and hence undesirable results.