As we have seen in our previous newsletter, a project is a temporary structure aiming at creating a new, unique product, service or result.
Unlike processes that may be active in an organization for many years and reach a certain level of maturity, each project is a fresh start.
> For the Project Manager’s point of view, this means that the management of the project is also a new need that needs to be addressed.
> Every project is something new but this does not mean that one cannot build on past experience or utilize best practices that have worked in the past.
> Every work (and life experience) is useful as long as it adds to the skills set of the user and improves his or her ability to work better the next time.
There are many resources from which best practices and guidance can be drawn. The International Project Management Association (IPMA), founded in Europe in 1967 and the Project Management Institute (PMI) was formed in the USA in 1969, publish guidelines and offer support to project managers around the globe.
Various project management approaches, methodologies and best practices are available world-wide. The most commonly methodology used, at the time, is PRINCE2. Our intention is not to reproduce or repeat these methodologies but rather to elaborate on some aspects of project management sometimes missed.
A project exists for a reason. It therefore has, among its other stakeholders, a client.
> If it is a strategy-level project expected to push the organization towards its vision, then the client is probably top level management.
> If the project is an implementation-level one, its client will be a department or a group of users or even the entire workforce of the organization.
> In case our organization's mission demands the execution of projects as a (routine) core process, then the client will be an external customer, who shall pay either for the project itself or for the product of the project.
It is thus imperative that the client perceives the value that the project has to offer throughout the duration of the project.
> It is sometimes the case, that while initially there was a consensus as to what the project outcomes would be and their perceived value was relatively stable, in the course of the projects and in light of unforeseen events, obstacles and new challenges, the project is transformed to something other than the original.
> If this is the case, it has to be confirmed that the client continues to recognize the value to be offered by the project.
> On the other hand, the Project Manager must ensure that the project team have not unilaterally decided to make changes that will affect the end result.
> Proposed changes and their reasoning should be communicated to all affected parties and agreement should be reached.
> In the opposite case, any work done by the project team for the project may be pointless and could result in misunderstandings and disputes.
Another problem that may present itself is the cultural and/or personality clash between team members.
> No methodology can prepare the project manager for this. If cultural/personality conflicts are strong in the team, the project may fall apart as cooperation will collapse.
> The best remedy in this case is prevention.
The team members must be selected based on both their expertise and skills but also on their ability to work together. If there are personality incompatibilities, strong rivalries, hidden agendas or even diverging strong beliefs, then it’s better to sacrifice expertise for the benefit of the team fit. If it did not get prevented after all, then the only option may be to change one or more team member(s) early to save everyone the unnecessary pressure.
A typical example is the case of appointing a team with many strong "leadership" personalities or without any one and/or by not including a good planner or a finisher and so on! By running a simple Belbin test, one can prevent an unbalanced team composition and most desirably achieve a well-balanced team!
No matter in how many different manners you depict it, the Achilles heel of most projects is the time schedule.
> Even though the Project Manager may be determined to stick to the deadlines, it is not always up to him or her. Meeting the deadlines depends on the team’s collective effort, other departments’ or people’s input, products or services from contractors and so on.
> It is imperative that the Project Manager communicates the importance of meeting the deadlines to all affected parties as well as the adverse effects of delays. It is, however, even more important that he or she talks the talk and walks the walk by completing his/her reviews and/or delivering his/her approvals and/or instructions on time and replying to queries promptly so that the team is not delayed on his/ her account.
> Further, the Project Manager must account for the review/approval time necessary for all deliverables (not only by him/herself but also by any higher authority, such a Steering Committee or the Customer) when the time schedule is formed and for the possibility that each deliverable may need a couple of iterations before it reaches an acceptable status.
Do remember:
These are but a few Project Management tips that no matter what the methodology followed is, tend to show up and put the project into peril. The best teacher in project management is experience; and good Project Managers are usually those who have had their fingers burnt in the past and have formulated a self-defence based methodology!
