Project Management has grown from a 'learning -by-doing' art to almost an academic discipline with a number of professional certifications. This shift reflects the importance of project managers in almost every sector in the economy and the increasing complexity and ambition of projects taken up by firms in a globalized world. Almost every investment that a firm makes today is into a project or more frequently into a programme (a logical portfolio of projects each contributing to an overall goal for the firm). It is no surprise then that the project management literature has ballooned in recent years in the form of books, manuals, toolkits, handbooks, videos, podcasts etc. This is in addition to the usual blogosphere and discussion groups on the Internet. So why another blog post on project management?
First, I want to share some of my experiences in the application of project management techniques to real world situations where projects will go wrong, especially if the project involves systems and actors whose motivations and capacities are questionable. Having gone through some of the project management literature doing the rounds these days, I fear that at least some of us would probably think of the project manager as someone with an ice cool temperament calmly issuing instructions and updating tools like risk registers. Nothing can be further from the realities of the projects where goals exist on paper but transform themselves into something else, where several clients on the same project with different expectations and motives have to be managed, where milestones are not achieved but payments come through, where milestones are achieved but payments do not come through and a host of other such situations that do not match the typical textbook description of what should be going on in a project.
My view is that the current literature on project management is not dynamic enough to handle real world complexities in large scale projects across geographies for large clients where there are multiple actors both on the client side and the project implementation agency side. In such cases, it is not enough for the project manager to record risks and update standard scope, time and cost schedules - she has to be tactically and strategically agile, revising targets downwards in some cases to increase scope on some other aspects in such a way so as to always keep ahead of client expectations and at the same time control them. Cost is not a holy grail either - the project manager must understand quickly when there is acceptable scope creep (there always is), how to compromise on certain cost escalations but gain added fee-paying opportunities from the client without bringing in changes to contract.
Second, project management is being affected as we speak by information technology that is challenging traditional concepts much highlighted in the literature. Loosely termed as "Project Management 2.0", this wave refers to a variety of collaborative IT tools and applications used by project managers to decentralize implementation, improvise strategies and share information much faster across and up and down multiple teams. With the rise of cloud computing systems, collaboration is going to be a fact of life for project managers at some time. This already puts top-down management models - with clean organisational pyramids on both the client and consultant sides - in danger.
Finally, I have a fair number of years of experience working and managing projects across sectors, clients, locations, countries, across teams of various nationalities, cultural and personal traits. I do not claim to be the grandmaster of project management with decades of experience but I believe I should be able to share something that would be interesting and valuable to the readers of this blog.
I will try to be as honest as possible in what I convey through this blog. I speak of clients not necessarily in a way that reflects the 'customer is always right' cliche. In fact, readers may find that my attitude towards clients tends to border on disrespectful. I accept this charge and will explain why I adopt such a position through the posts to come. Not all clients are knowledgeable, motivated to achieve the same goals that the project intends to achieve and willing to work with the project manager through thick and thin. On the flip side, not every project manager is entitled to a clean chit just because she has a certification and some years of experience. Project managers are often lazy, pretentious, incompetent and, worse, irresponsible - uncaring about what the real needs of the client are, the real goals of the project are and prone to treating every project as just another day in office. I highlight warning signals, traps and mistakes made on both sides to undermine one another in a project.
As a summary of my subsequent posts, I highlight some key facts and observations.
In government projects in developing countries, the project is usually driven by a 'big man' (Principal Secretary or equivalent in a British style bureaucracy and it's almost always men). Pro: much faster to drive through changes if you're a consultant without having to go through several useless meetings with officials who are ignorant/uninterested and with committees, standing committees, empowered committees, working groups, task force etc. Con: if the big man goes (transferred/retired/deputed/dies) then the project can quickly fall apart. The big man's successor almost always doesn't have the same motivation/interest in the project. One of the biggest causes of failure of eGovernance projects for instance is the frequent loss of project champions in developing country governments.
The 'big man' is rarely knowledgeable technically. If knowledgeable, the big man will expect consultant/project manager (PM) to absorb his or her biases/prejudices/preferences and incorporate it into scope. This is especially important to assess if the PM is coming into a downstream component of a project where other consultants/contractors have worked on upstream components or, in the case of IT projects, legacy systems that need to be integrated (difficult) or scrapped (easier). E.g. You, the current PM, may have replaced an earlier PM who was the favourite of the current 'big man'. (The replacement was done by the 'big man's' predecessor.)
Big man or not, in case of projects requiring 'hand-offs' of interim or final outputs across departments/ ministries, usual turf fighting will happen particularly between second tier and middle rank officials. One way of finding out which agencies are more powerful is to figure who gets the largest share of budgets, loans or programme grants. Smaller fish can be ignored more or less by PM. In such a situation, PM often has to report/coordinate across several 'clients'. As usual, there will be some who are for/against/non-committal towards the project. Some will be corrupt, most will be lazy - although to be fair, this may be the right option if you do not get any recognition or performance incentives for going out of routine work as is always the case in a bureaucracy).
Most books/manuals talk about the importance of a Project Charter or Scope Statement before work starts on a project. In practice, this is a luxury. Once tendering ends and the clock starts ticking, clients in government will wonder why you are wasting so much time creating yet another document on scope ("but the RFP already has your Terms of Reference, what is left to discuss?"). In many cases, the PM enters the scene to execute something that is part of a Project Charter created by another consultant earlier.
If pressed for time, quick solution would be to create a table based on the RFP which should have 3 columns - To be Done / Not to be Done / Undecided or Unknown. Regularly update this document and share with client and hope for clarity. Accept that there will be certain scope creep or late decisions as project progresses that will need improvisation.
The longer the project, the more the variation between actual scope and what was written on the RFP. The more the number of people with an opinion on client side, the more the variation between actual scope and terms of reference in RFP.
Saying 'No' to scope changes that you think are inappropriate/damaging/misinformed/stupid is rarely possible particularly if the client happens to be the biggest buyer of your services. This is very often the case with large scale government projects where the PM is contracted either individually or as part of a consulting team. In other words, if the PM and the organisation are in a seller-buyer situation, it's difficult to disagree with the client beyond a point. Of course, the dynamics differ when the PM represents a party/firm which has a relationship of equals with the parent organisation in the project, either in terms of investment or sharing of risk. Cultural variables specific to the project also matter e.g. it is difficult to manage scope changes in a setting where the government official enjoys and expects to be in the driving seat all the time and does not care much for a democratic process.
In the duration of a long project, some milestones will change/appear/disappear. PM has to accept this into planning.
In any discussion on scope, the PM should remember that the technically optimum solution is not necessarily the one preferred by the client. The client will pay more importance to politics (internal/external to organisation), to reducing his own work sometimes and to creating opportunities for him to move up the organization or (rarely) to monopolise a process to extract favours later on. It is important for PM to be pragmatic and not get into 'Analysis Paralysis' where she is trying to come up with a better analysis to refute a client's option or to push her own option. Effort is better spent on securing agreement on an admittedly inefficient option from key stakeholders, executing it and getting paid.
Even if scope creep is inevitable, it is useful to periodically take out a dusty copy of the original contract containing Terms of Reference if only to check for alarming or nonsensical deviations that are going to occur. This may also be useful if client-side stakeholders want a change that is fundamentally disrupting the scope. (Waving the original contract and pointing out the implications of such a big change in scope often deters government officers from pushing things. Government officials rarely want their own signatures next to a big change in a project document.)
Cost is the element, sometimes the only element, of the scope-cost-time triangle that will be watched most closely by the client. This has its pros and cons. On the negative side, scope creep and demands from the client to deliver 'more' will not change the cost of services agreed to in the contract (it's a rare government client who will want to go through the paperwork and approvals necessary to initiate change in the cost clauses of an existing contract based on a competitive tender). For the PM, this obviously means that at the same cost (and same remuneration/revenue from the project) she would be expected to deliver more.
But if cost is such a holy cow, this can be used by the PM to control the other two points of the triangle. For instance, the most effective way to deter a client to propose a scope change is to show how this would require him to spend more on procurement. This strategy works very well when such decisions are taken by a committee. In particular, if the PM puts this down in the form of a written note to the committee, it is virtually guaranteed that the committee will back down from a scope expansion. This approach doesn't however work well on changes that affect the timeline. For long term government projects in developing economies, time is often not a very important variable anyway.
Cost from buy side = Revenue from sell side: the PM should focus on regular billing and collections from client especially in a long term project where Time and Material (T&M) billing comes into play. This is important apart from the obvious reasons. When collections stop, the PM's firm will tend to stop supporting his calls for more/better resources and infrastructure in a fire-fighting situation. From the firm's point of view, a project that doesn't earn money is not worth diverting resources to. In such cases, the PM is left alone to manage as best as he can. Regular collections enables the PM to command instant attention from higher-ups within his own firm. If the PM heads a large on-site team, word of any disruption in collections will spread quickly and sap the morale of the team.
On the other side, if the client gets used to a situation where the PM and her team keeps working without timely collections, it is an invitation to more scope creep and in general - trouble. If the client is regularly paying fees to the client, it also means attention is being paid to the project (not always certain in public sector/government projects) and is an indicator of the urgency to execute. One way to deal with this is to 'go slow' on pending work and keep mentioning the issue of overdue payments at every possible opportunity. This is no guarantee however that bills will be cleared. In large government projects, it is important for the PM to maintain good relationships with the official who actually signs the cheque. Doing favours such as arranging a chauffeured taxi for his son's trip to some other city for an examination may be most useful in certain siuations.
Time is often the least important variable in long term, complex government sector projects (exception: disaster relief or any project in the emergency category). The PM can use this to advantage by negotiating more time for any scope changes pushed by the client. In financial terms strictly, this would be inefficient, but it is advisable from two points of view. First, it gives her time to finish what is promised and sustain a good relationship and second, it creates more opportunities for the PM to create opportunities so that the client is 'locked-in' to her services for this or any other related project.
In any case, external variables (cabinet reshuffle, elections, budgets, sudden transfers) can all impact timelines and will be beyond the PM's control.
In short, given fixed costs, an increase in scope should be accompanied by an increase in time. If costs and time are fixed while scope increases, it means trouble for the PM.
After some time, clients tend to lose interest in project component level details. As long the PM can show minimum deviation from overall start/end dates, it is possible to 'hide away' small increases in time at various levels of activity so as to buy a fairly large chunk of time.
PROJECT MANAGER'S ROLE
Conventional PM schools of thought often lead to the impression that the PM should be immersed only in project steering. This assumes that there is a core project management staff supporting the PM which is directing several execution teams. In practice, this is frequently not the case - the PM also doubles as a strong member of the project execution team. This is particularly true of large scale government projects where the PM is one out of several members of an implementation team. What does this mean? The PM must be able to switch back and forth from executing a specific part of the deliverable (micro) to a bird's eye view (macro). This puts considerable pressure on the time available for pure play PM activities.
It is also the PM's job to integrate the deliverables produced by a multi-specialist team into a coherent whole that is understandable to the client. (Technically smart work that the client doesn't understand is not a deliverable.) This work is time consuming and requires skill and the PM must factor this into her work schedule. If the project has a number of interim deliverables, this will increase the workload of the PM to a point where often PM activities will have to be given a back seat and the focus is on meeting the deadlines. E.g. an integration of an As-Is assessment report written by multiple team members, each concentrating on one area, say, business requirements, infrastructure, network, data design, information security etc.
The demands on the PM's time means that hundreds of smartly designed MIS templates out there can't be used by a PM for lack of time and bandwidth. Most of these tools are well thought out but require diligent and accurate data updates by the PM to be of any use. It is important for the PM to use simple tools and techniques that pose minimum costs of keeping them up to date. So the PM should track a few key project dimensions using simple MIS and keep others in his mind or delegate someone else to track them. This is better than trying to formally map every possible aspect of a project into a tool/template.
PM 2.0 tools act as a 'force multiplier' for the PM in this regard. By using collaborative PM tools, it is possible to decentralise data collection and tracking away from the PM so that she has more time to steer and integrate deliverables.
There is one more aspect of PM that is usually overlooked by PM literature. This is one of internal HRM - the PM must also manage a large project execution team especially if it is on-site. E.g. sorting out workplace issues, distributing 'fly-back' days equitably to all team members, keeping track of effort, reimbursements, team logistics, troubleshooting, support services vendor management (vehicles, communications, accommodation) etc. This can easily become a full time job and is another big reason why the PM must ration the time available for project steering activities. The longer the project is, the more these tasks can eat into project steering time. (Tempers and morale of on-site team members usually start to fluctuate with long periods away from home.) Again, the PM is lucky if she is supported by a logistics manager on the team who looks after these aspects exclusively.
The 'perfectly staffed' project implementation team is a myth. The PM has to work with the resources made available to him by his firm or by the client. She will have to manage this by highlighting the stronger members and hiding the weaker members (who may or may not be replaceable by firm/client).
The best possible resources obtainable by a PM from her firm is at the beginning of a project. This should be factored into the PM's plans. After some time, the firm will loose interest, competing verticals within the firm will attempt to poach your best resources and on-site resources will start getting restless. A strong start with the best possible team often compensates for a time when the team is playing with bench players and work is not proceeding as quickly as it should.
A good way to quickly buy some time is to submit a proposal to a client-side committee. In government especially, this will cause the proposal to be shuffled back and forth between the committee members, each of whom will not want to be seen as the decision maker. This approach doesn't work so well in the private sector. On the other hand, if the PM wants to drive through a proposal quickly, then it is foolish to submit it to a committee. The PM should manoeuvre to ensure that the proposal is cleared by one person even before it reaches a shape and size requiring a committee meeting.
If the PM is writing a RFP for the client for further procurement necessary for project execution, following the textbook and maintaining a strict distance from bidders is not a good approach. Before the RFP is written, the PM almost always develops a Detailed Project Report (DPR) which provides a budget estimate and justification for that estimate (as well as a justification as to why procurement is necessary). Keeping in touch with bidders means that the PM is well informed about market costs and can provide reliable estimates. It is embarrassing for the PM to see that bids submitted far exceed or fall short of her estimate. In several cases, this leads to loss of credibility and work opportunities with that client. Keeping in touch also means that the PM is aware of what services the key players in the market can provide. This is handy while developing the scope of work for the RFP. At the end of the day the PM should develop a RFP that attracts a fair number of bids at prices that are close to the DPR estimate. In government especially, a cancelled tender is a source of irritation to everyone and the PM will not score any points with the client.
Finally, when things go haywire and the PM has very little control over a project that has gone horribly wrong, just focus on doing what is necessary to maintain billing and collections (or to minimize penalties) and do not ask too many questions.