. .


Career choices




Politics & Policy

Thinking of becoming a project manager? Here are some tips that may help you on your way

Nov 20 - 26, 2000

"Project Management is the application of knowledge, skills, tools, and techniques to project activities in order to meet or exceed stakeholders needs and expectations from a project"—A Guide to the Project Management Body of Knowledge.

While working with IT Consulting firms for the last 15 years, I have had the occasion to manage a vast array of projects. Some of these include setting up an IT training institute, running a Year 2000 'Factory', designing, developing and implementing software for large companies, implementing ERP systems, and off-shore delivery of Y2K ready code. During this time, I have never really spared a thought for the 'formal' definition of what it is I was doing — Project management. I have often thought of listing the essence of what I felt a Project Manager needs to know, in order to successfully manage in a consulting environment. What are they supposed to do? How should they approach their job? What can they expect as project managers? How does one learn the ropes? One would think, that after several years of managing projects of varying complexity, there would be relatively simple answers for such questions. Oddly enough, each time I launch myself into a new project, I find myself re-discovering the answers to these questions. However, over the years, I have learned certain guiding principles, that help me settle into my routine much quicker than it would take a new comer.

These common sense principles are not meant to replace any part of the already established project Management techniques or concepts. To be a successful project manager, one must hold sacred all the good PM practices that exist within the PM body of knowledge. However, sometimes, newcomers may struggle with concepts, principles, tools, techniques and procedures. This article is meant to help newcomers into the PM arena get a quick tour of what they should expect in a Project management role.

• Taking Over a Project

Project briefing: Whenever possible, before you start a project, it is always helpful to ask for a detailed project briefing from the project sponsors or the engagement partners of your Firm. In many instances, especially in larger consulting firms, a lot of ground work may have already been covered by other company specialists, prior to the project reaching the stage where you take over. For instance, pre-proposal studies, bid-meetings, proposal preparation sessions, or maybe related subprojects such as an ongoing Audit or Tax assignment. Knowing such background information helps the Project Manager take important decisions in the long run.

The reason for such briefings is for you to understand the scope and objectives of the project, and also to give you a chance to clarify, first hand, any ambiguities that may exist in your mind. What exactly is this assignment about? What is your role in it? How did the assignment develop and reach this stage? Who were the people involved so far, both from your Firm as well as from the Clients company? This last bit of information is especially important for you, because frequently, at least initially, you may need to refer to these individuals for specific bits of project information that may not have been documented. By documenting such sessions, perhaps even 'informally', I have found that my perception of a projects needs are refined. Writing down, and circulating, what you think is expected of you is a great way of removing all doubts on the role that your Firm expects you to play.

• Know all the players

As the Project manager, you will henceforth be the company's primary source of contact with the client. More likely, you may even be located at the clients site. In any event, you are sure to meet and exchange views with most of the stakeholders of the project. Therefore, it is imperative that you learn as much about these key individuals as you can. Know each one of them, in terms of their role within the client organization, the areas within their influence, the subordinate staff that reports to them, and their superiors to whom they (the key players) report to.

Knowing the chain-of-command and the environment within which the stakeholder operates, gives the Project Manager a greater degree of maneuverability and leverage when it comes to close quarter interaction with clients staff. You will know who has what information, and who is more reliable in the information that he or she supplies. Frequently, in order to get the job done, you may even have to use this knowledge to play the 'name dropping' game: "By the way, as part of our study, I will be meeting Mr. Hanley at Finance. Does he has any interaction with you?..." (You know fully well that Hanley probably writes up your subject's Performance Reviews!)

• What each players interests and expectations are

Knowing what the interest of each stakeholder is, in your project, will help you relate uniquely to that stakeholder, when it comes to reviewing project status and communicating deliverables. For example, the Warehouse Manager, whose primary aim is to eliminate the manual Stock Cards, and reduce Cycle Counting time to 1 day, will need a different level of interaction than, say, the CEO of the company, whose primary concerns may be investors perception of the ongoing project.

Knowing what each player expects from your project will help you tailor your stakeholders buy in 'pitch' for your project. The level of cooperation you may expect from each stakeholder and their domains, will increase proportionately to his or her (the stakeholders) perceptions of how well you are addressing their particular interests. As a successful project manager, it is up to you to sell your project uniquely to each beneficiary. And knowing what they want from you is the first step in a successful 'sale'.

•What your Firms objectives are

Just like the Clients CEO and Warehouse Manager have varying expectations from your projects, it is not uncommon for senior executives and Partners in large Consulting firms to have different interests in one project. A Systems Development project, though primarily the IT Partners 'baby', may also hold parallel interest to the Audit Partner, who sees the possibility of getting an IT Controls Review assignment, or a Computer Audit assignment during the next financial year. The MC Partner may see your project as an opportunity to follow up with an assignment to develop or review a Standards, Policies and Procedures Guideline manual for the client.

Such initiatives may occur before, after or in tandem with your own project. As the Project manager, you owe it to your firm to act as the on-site sales-person for auxiliary services. However, you can only do so if you are clear about your Firms policies and long term interests, as far as the client is concerned. Many Firms may not wish to compete with existing Auditors or Management Consultants of the client. In such cases, it would not be prudent for you, as the IT Project manager, to try and sell such services to the client.

• Organizing your Team

• Who are your team members

Frequently, project teams are determined not by choice but by other ongoing engagements, and staff availability. Most Consulting houses that I have worked with assemble engagement teams based on their current inventory of personnel, and the skill sets required for the project. In many cases, we have inducted outside resources to staff a project team. As Project Manager, it is absolutely essential for you to be fully conversant with each of your team members background and capabilities. What are their basic qualifications? What assignments have they been on previously? What special skills do they have? What are their strengths and weaknesses with regards to the current project? This last piece of information is especially relevant when you will be assigning Team Roles and responsibilities. A brilliant Programmer may be better suited for a System Testing role than a good Analyst, who may fit well in your system study and fact finding team.

• Discuss project team Roles and rotate them, if possible

Once a project commences in earnest, there will be a number of roles that will need to be performed by each team member. Technical work, such as developing specifications, designing network architecture and identifying communications requirements are relatively easily assigned. Such roles are usually assigned to team members having the necessary qualifications or experience. However, to effectively run a project, especially if the team is large, and based at a Field Office off-site from your Home Office, you will need to staff other roles too. Who is responsible for collecting and summarizing project Time Sheets? Who will maintain project documentation such as Memos, Letters etc.? Who will formalize and circulate discussion notes, agendas and minutes? Whom do team members submit their reimbursable claims to? Who will follow up collections and subsequent disbursement of such claims? Who will be responsible for maintaining Staff logs and leave records? Who is responsible for consolidation and Home Office reporting?

If your project is of a relatively longer duration, say 8 to 10 months or more, it is always nice to discuss these roles with the team and make appropriate assignments, before the project commences. Because these roles are additional to the standard role that a team member may play, it is important that they understand the importance of such auxiliary duties. Each team member should be briefed on the expectations of his or her role, and how it adds value to the overall project. It is also a good idea to rotate the roles, especially for lengthy projects. This is not only important in terms of change, but also serves as a source of personal development for team members.

•Project Team briefings

Communication, between you and your team, is the essence to a successful project. Prior to project kick-off meet individually, and as a group, with the team, and make sure that everyone is clear of what needs to be done. If you have a collection of people who have never worked together as a team, one of your first responsibilities as Project Manager is to build harmony between these individuals. Don't hesitate to explain even the most minor details, if required. I have seen disasters on projects, just because the term 'documentation' was not clearly understood by all team members.

As a Project manager, you may not be available all the time to clarify points of ambiguity, or to provide input when and where it is needed. Therefore, it is essential that you build a team structure that is independent of you. The Project Team briefings are the best place to discuss and communicate your Project Team hierarchy. Who is your second-in-command? Who are your Team Leaders? Who has what authority and what responsibilities? On several occasions, while I was away from my Project Offices and reporting at my Home Office, I have had occasion to thank myself for defining a clear hierarchy for the Project Team. Clarifications are sought randomly by Client executives, or the Client CEO requires an out of schedule status report. In your absence, someone in your team has to be identified to handle such issues.

• Project Accounting

Usually, the Home Office will have well defined project accounting guidelines, and will be keeping track of when to invoice, and how much. But you, as Project manager, have a parallel responsibility of making sure that your project's accounting is on track. In all probability, you were primarily responsible for developing billing schedules and agreeing installments thereof. But merely passing these schedules to Accounting, does not absolve the Project manager from his responsibilities. To be fair, invoices must reflect value delivered to the Client. As such, the PM is the best person to decide on the value delivered. Be very sure to keep track of out of pocket expenditure. Most consulting Firms have these included as separately billable items. Sometimes, especially in longer duration assignments, these can silently creep up to a significant percent of the total project value. Smaller consulting Firms can't afford to overlook such items. Knowing what is chargeable and what is not, is also essential to avoiding Client flack in the long run.

During the course of the project, tasks slip, scheduled deliverables take more effort to complete, unforeseen delays may occur. It is the Project manager's job to make sure that these delays are accurately reflected in client invoicing. It is my experience that the greatest points of tension, between your Firm and the Client, will arise if the Client is invoiced for deliverables that have not yet been delivered. And if you do not advise Accounting to hold the invoice, you are opening yourself to needless flack from the Client. On a number of occasions, especially in smaller consulting firms, invoices are not raised even though they are due. Additionally, out of pocket expenditure is not properly accounted for by the Project manager, and therefore is a source of loss for the Firm.

• Accounting for Project Time

One of the most powerful tools that you will have at your disposal, for keeping tabs on your Project, is the staff Time Sheet. Most Consulting firms have their own variations of the TS. However, it is my experience that the TS is only as effective as the people filling them make it. During your Project Team briefings, one of the most important items of discussion must be the Time Sheet and its associated coding conventions. If your team is properly briefed on what each element in the Time Sheet stands for, and how it is interpreted for the purpose of Project monitoring, chances are that you will have a very effective and reliable source of Project statistics streaming from the TS.

If you have a disparate group of people working together for the first time, you can't imagine how many variants of the Time Sheet you will receive. Productive Time, Idle Time, Practice Development, Professional Development, Team Meetings, Client Meetings, all of these need to be clearly explained to the Team, without allowing each one the freedom to interpret their own versions of the terms. Only with consistent recording and reporting will you be able to stay on top of your project at all times. Other items, with regards to the TS, that you may consider discussing are:

•Frequencies of recording and submission

•Codes to be used for various Tasks

•Formats and columns to be completed by various functional teams

•Level of automation required by your Home Office or other teams, such as a spreadsheet or a FoxPro or MS Access module

•Approval process, before consolidation takes place

•Preparing the Project plan

Before you start any work on the project, please consider developing a detailed project plan. Frequently, and this happens all too often, so watch out, you are under pressure to commence the assignment so that the client (or your own boss) can report project initiation. Don't! The moment you mobilize your team and start any project activity without a clear plan, you are doomed to get sucked into an black hole. Instead, spend quality time and develop a comprehensive plan, taking your team into confidence on the various tasks that they need to perform. Where an activity is Client related, or based on inputs to be provided by Client staff, make sure these are communicated to the Client without any ambiguity. Do not sign off on the plan, unless you get Client sign off on the tasks for which Client resources are required. A project, based on a plan that does not have hand-shake from the client, is doomed to fail.

As Project manager, you will be held accountable for the overall success or failure of the project. Therefore, if Client resources are not forthcoming, in the required quality and quantity, make sure that your boss and executives at the Client are aware of this. The temptation is to have your own staff take on additional work, in the interest of getting the ball rolling as soon as possible. Don't! You will have enough problems trying to produce deliverables with your own staff, to have to worry about staffing a client task with your own resources. Most projects are costed, based on a reasonable input from Client staff. Even if you have to put in additional resources, make sure these are documented, quantified, and brought to the notice of the engagement Partners and Client Executives. Whether your Firm decides to bill for such additional input is a separate issue.

• Managing day to day activities

• Insist On Regular Status Reporting

Build a formal status reporting system. This is especially useful when you are responsible for a number of projects simultaneously, as is often the case in large consulting Firms. It does not have to be very complex, or cover each and every aspect of the days activity. For larger, multiple site projects, which have tasks taking place in several locations or cities, I find a daily exceptions reporting system very useful. A Team Leader or an Assistant Project Manager, based at the client site, faxes or emails me a pre-designed template of Hot Buttons at his or her site. For me, the Daily Status Report is not meant to be a tell-all document. It is essentially a tool through which I am informed of major events, issues and concerns at each location. What is important here is that you, as the Project Manager, must decide the Hot Buttons on which you want status reported. These usually follow the 20:80 rule that is well known in Inventory management circles. Keep a tight watch on the more critical 20% of your project tasks, and the remaining 80% will more or less take care of themselves.

• Give feedback to your team

I remember the days when I was a team Leader on a project, religiously reporting to my superiors. I'd spend hours consolidating status reports, Time Sheets and other project information, but never got much feedback from 'up there'. I know how frustrating it can be not to receive feedback from the Boss. If you want to maintain a high degree of team morale, take time to give the occasional feedback to the troops. Feedback serves two purposes. Firstly, it is a definite morale booster to your subordinates. But more importantly, it is only through your feedback that the team can maintain or correct its bearings. With your experience, you will probably be the first one to spot a truck coming down the highway, long before the more in-experienced team members are run over. Too often the team is engaged in close quarter combat, and is unable to see the bigger picture. You, as Project manager, must read the signs and constantly steer the project in the right direction.

Again, feedback need not be lengthy or too elaborate. Simple suggestions such as "Matt, consider putting Sue and Tom on the documentation team to help speed up things there". Or "Jill, why don't you consider calling the hardware vendor to see if they can help us out with this problem?" will help the team dig themselves out of a potentially damaging situation.

• Work out Escalation procedures

To help manage your project smoothly, it is always advisable to have well defined escalation procedures in place. Whenever there is an issue, frequently team members feel that it is a poor reflection on their abilities if they turn to others for help. This is wrong! If an issue is not resolved within a reasonable period of time, you must have procedures in place whereby the problem comes to the next higher level within your project hierarchy. For example if you, as the Project Manager, are unable to convince the Client to release your firm's outstanding invoices, perhaps its time for your senior, maybe at the Partner level, to have a word with someone higher up in the Client organization.

Escalation should also be put into place where feedback or inputs from Client staff is required. For example, if you have circulated a questionnaire to an Inventory Clerk, and you do not receive his input within a stipulated time frame, your project team should have clear guidelines as to whom next to approach. Perhaps the Clerk' s Supervisor or his Manager? With well-defined escalation in place, you will find that there is less time spent waiting for events to occur while you sit and do nothing. Instead, no response will automatically trigger a subsequent event to occur, thus, moving the project closer to completion.

• Monitor the Project plan

Most of the stakeholders in your project are either too busy with their own problems, or are not really interested in micro-managing the project. They rely on you, the Project manager, to do this for them. Spend quality time in updating and monitoring your project plans. It will pay you great dividends in the long run. Watch for delayed tasks. Spot slippage in critical tasks. Look to see whether budgeted resources are being used as plan, or whether they were over or under budgeted. Sometimes, in lengthier projects, Consultant and Client staff form a special 'bond', which prompts the consultant team member to 'do that extra bit' for his client. This in itself is not bad, but if it gets out of hand, it could lead to significant delays. The one 'off line program' for a special user could soon lead to a whole 'module' of off-line programs. Monitoring progress, and studying Time Sheets can help curb such incidences. Always make a point to discuss significant deviations with team members, and make adjustments only after taking the team into confidence.

Whenever you revise a plan, always maintain a history of your previous estimates, and frequently use previous versions of the plan to compare later versions. You will be amazed at how these plans evolve over time. There is a lot that the Project Manager can learn from his past plans. These are invaluable inputs for future project planning.

• Hold Regular Team Meetings

I have found that meeting frequently with the whole team sometimes generates synergies that are needed to break a particular project deadlock. Use regular briefings with the team to bring all members up to date on progress, as well as to discuss issues or concerns that you may have. Don't just focus on problems. Review positive developments as well. A task completed ahead of schedule. A revision to the project plan that will enable you to save five days of project time. Decide a format for such meetings, otherwise they tend to lose direction. I have found the following agenda extremely helpful in such working sessions:

•Tasks Completed / achievements since we last met

•Tasks delayed so far

•Issues and concerns outstanding

•Problems resolved since we last met

•Our plan, till we meet next

•Any changes to the overall plan, roles or responsibilities, team structure

• Have Regular Client meetings

Communicating with the Client is as important as communication between you and your team. It is important for the client to be kept informed of every aspect of the project status. For projects extending beyond 6 months, depending on the nature of complexity, I'd say a fortnightly meeting with weekly status reports is prudent. Where there is a fixed fee contract, with specific Consultant time commitments, I have found that providing Project-To-Date consultant man-hour usage statistics to the client is a very useful way to getting greater client participation. The client knows exactly where and how, the consultant man-hours that he is paying for have been utilized. If deliverables are not nearer to completion because of his own staff's shortcomings, he will ensure that his team puts in more effort. And if there is any disagreement over time spent, these can be clarified immediately, during frequent meetings.

These sessions with the client should also be used as a forum to highlight lack of client input, delays in tasks that are client responsibility, or any other matters that could significantly impact your project time line. Be sure to document each meeting, and have copies circulated to all participants as Minutes. Make these Minutes form a permanent part of the Project Files. Work to an Agenda. Ensure that Agendas are circulated well in advance, and include items of interest to both your team as well as the Clients. Rotate the secretarial role between your project team and the client's team. And above all, summarize major points and make sure your Engagement Partner is kept informed.

• Documenting project events

One of the most important tasks that you, as a Project manager, will need to do is corresponding — both internally and externally. For large and lengthy assignments, this can be a very daunting task, sometimes taking up to 25-30 per cent of your workday, if not more. Large projects, especially where there may be other Practices within your Firm involved, or other Co-consultants or joint-consulting Firms participating, need special attention, where documenting events is concerned. In projects like these, it is very easy for the other teams responsibilities to be confused with your own. For example, at times, Systems Developers, Systems Integrators, System Implementers and System Vendors work so closely together, that the Client looses track of whose responsibility is what. It is in situations like these that finger pointing is often resorted to. Each time an issue is discussed, project boundaries re-drawn, or responsibilities allocated, you must make it a point to document and circulate the decision. Several months later, if you ever get caught in a crossfire of finger pointing, it is precisely these correspondences that may save the day. There is another school of thought on this, but I really believe that 'there is no such thing as too much documentation' when it comes to managing a complex project.

• Project Close Out

• Get sign off on deliverables

Each time you deliver something to the Client, make sure you document your delivery with either a Memo or a formal Engagement letter. Whether it is completing a mile stone task, delivering a report or installing a piece of software, always communicate in writing. Another important thing is to make sure that you get acceptance of your deliverables. The Client could either expressly communicate acceptance, or if such acknowledgements are not received, your letter must indicate implied acceptance. So, if you do not receive feedback from the Client within 30 days, say, you will assume that they have tested your software and found it acceptable. This puts pressure on the Client to be proactive while reviewing your deliverables, which in turn brings your project nearer to closure.

• Keep an eye out for trouble

Be especially careful in your reviews, towards the fag end of a project. The nearer project completion dates approach, the more alert you need to be. By now, your team members as well as the Clients are probably exhausted and eager to wrap things up. In many consulting Firms, team members may have already been reassigned to other projects, to which they are anxious to get to — what a change ! Because of that special 'bonding' with Consultant staff, a Client team member may also be inclined to give 'provisional' acceptance to a deliverable that may not have been up to the mark. An incomplete report, or a partially completed housekeeping software routine could come back and haunt you, when you are comfortably placed at another project.

Although such errors and omissions are nothing to be paranoid about, you must exercise due diligence in ensuring as complete a close out as possible. Go over your project check list, and make sure you have reasonably acceptable Client acceptance letters for all your deliverables. Where a particular deliverable has only a provisional acceptance, take time to review the deliverable with the team, to ensure that no major skeletons are lurking in the background. Go over your Project Files, and give special attention to issues or concerns that the Client may have raised. Now, while you still have your team in place, is the best time to uncover and tie up loose ends. You may spend a few extra days doing it now, but once the team has disbursed to other projects, it may take you several weeks to achieve acceptable closure.