. .

Corporate Profiles

Career choices



Corporate Profiles

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

Nov 13 - 19, 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.