Managing client-oriented technical projects is a many-faceted challenge. Several groups of talented individuals come together to conceive, design, test, and implement complex systems which will improve the business of a client without changing how they do business. That’s the plan at any rate. And that’s what account representatives sell to clients. As a result expectations will be high. This document is geared to individuals charged with the responsibility of managing a technical project to completion.
by Michael Nanfito
Originally published in June of 1996 for librarians with little or no project management experience yet charged with developing and leading technology projects. Some of this might still be useful to folks. . .
Bridge Information Services
- Quick Overview
- Project Library
- Team Rosters
- Technology Inventory
- Client Relations
- Team Building
- Managing Change
The Project Manager (PM) must understand the goals of the client, the nature of the project services they have purchased, develop a plan appropriate to those goals, and bring the appropriate forces to bear in executing the solution which best suits these needs. In order to fulfill these expectations and bring the project to completion, the Project Manager will be teacher-guru-slave driver-guide.
Managing a project is not a sequential or linear set of events. You will be juggling half a dozen things at once all the time. As a result, any description of a technical project which is described in linear terms is not a true representation of the techniques and procedures which will actually be employed. Nevertheless, such a linear representation is forced upon us given the convention of language.
BEFORE YOU DO ANYTHING ELSE: Read the Contract. Know what your company has promised the client, what the timeframe is and everything else the contract stipulates. If the contract has not been signed yet, insist that you’re in the loop on contract negotiations and progress. Request copies of preliminary contracts. Request copies of old contracts. If your company maintains a boilerplate version of a contract, request a copy and read it now.
There are many things you’ll be doing simultaneously. Here’s an overview of some things you will address, although not necessarily in this sequence:
- Project Library
- Team Rosters
- Technology Inventory
- Client Relations
- Team Building
- Managing Change
Scan this list and start making lists of your own. Rule #1 in project management: write everything down that you know. Then write your questions down about what you don’t know. You must get in the habit of documenting plans, projections, problems, questions. The better you document as you go the happier you and everyone around you will be. This may seem tedious now, but you’ll thank yourself later.
It seems straightforward and common sense but it’s surprising how often we forget to do the little things that make our lives easier. You should always maintain a rotating checklist of questions and needs.
Make lists of all the things you know you need to do, based on your early readings of the Request for Proposal (RFP), the contract, and any conversation with account reps and the client. Every phase should generate new questions and needs. Devise checklists and schedules that reflect each phase of the project. Your lists should be inclusive yet general. You are managing others who are doing the actual work, thus your checklists will not need to be exhaustive. You are charged with overseeing the project. Don’t get bogged down in detail that you will not be implementing. Understand the processes of the project, who is responsible for what, and generate lists, schedules, and timelines which reflect your vision. Step One: Write down everything you know about the project. Step Two: Write down questions which you have or anticipate. Do your own Management Needs assessment: what do you need to do or know to get the job done?
- Identify the problem
- Identify initial solutions to the problem
- Identify talent and resources to complete the solution
- Describe the process
- Describe the documentation
- Schedule the process
- Schedule the documentation
Write everything down. Continuously update these lists as the project takes shape and the needs change. Correlate your lists with the various process phases of the Project:
- Solution Acceptance
You will build a Project Library consisting of several documents. You may not write every document listed below, but you will end up with a large body of documentation. It is far better to plan the library now, order it, and let the binders fill up based on that plan, rather than trying to sort out pages of documents, flow charts and Visio schematics in the middle of the project. Think through the project early on and come to a conclusion as to which documents you’ll write. These documents need not be novel-length in size. In fact, there are two tendencies to avoid in documentation: there is either none at all, or far too much. In each case no one reads any documentation, either because it doesn’t exist, or because the sheer volume dissuades them.
The Project Manager will not actually write each of the documents listed below. Identify the most appropriate resource on your staff based on skill sets and activities with the project and notify them early on of their assignments. Make it clear what they are assigned to write and how that document fits into the overall schedule. Make it clear when you expect to see the drafts and final copy of the documents.
Problem Specification.The first order of business is to write the Problem Specification. Describe the requirements of the project based on the RFP, the Contract and any conversation with account reps and client team members. NOTE: The Problem Specification should describe the problems and needs of the project as they are understood, and avoid describing the solutions to the problem — that will be accomplished in the Design Specification.
Design Specification.Following completion of the Problem Specification you will write the Design Specification. This document illustrates in detail the solutions to the project problems as they are outlined in initial documentation.
Test Specifications.You will write Test Specifications for Integration Test, System Test, and Acceptance Test. Identify specifically what you are testing for, and create test scripts, checklists, sample test data, and test plans.
Technical Notes.Describe specific technical aspects of the project not directly related to the design solution. Include hardware and software inventory and specifications; site licenses needed and purchased; vendor names, contacts and phone numbers; and contractor names and contacts.
Coding Specification.Once you have described the solution in narrative and diagrammatic form, begin detailing the design. Include schematics, software engineering process and sample code.
Change Orders.Any time the client, one of your staff, or a contractor describes or requests process which deviates from the Design Specification you must document that event. Even if the change is not to be implemented, make a brief note that the change to the specification came up. In those cases where changes are accepted, note who originated the change, note observations on how the change will impact the overall progress of the project, and distribute your observations to the client and appropriate staff, as well as your superiors. Approved changes which significantly alter the Design Specification should require contract negotiations prior to implementation.
Test Documents.Document all test results. Note what works and what does not. Distribute your findings to the client and appropriate staff as well as your superiors.
Status Reports.You will engage in scheduled reviews of the project, per your Project Timeline. Document the reviews and distribute these to the client, appropriate staff and your superiors.
Communications Log.Possibly the most important piece of documentation: document all communication between you, your staff, and the client. Maintain a log for all modes of communication you engage in, per your Communication plan (see below). Having decided on the protocols (FAX, E-mail, Memo, phone, meetings) and parameters (daily, weekly, etc.) of your client interactions start binders now that will contain copies of all communications between you and the client. Maintain a binder in which you keep copies of each FAX (or E-mail, etc) you send, as well as those you receive.
Establish rosters of all team members including: the consultant (you and your team), all contractors you utilize, and the client’s talent.
Document the roles of everyone involved, including consultant, contractor and client resources Identify skill sets and responsibilities of everyone on the list Generate tabled rosters and distribute these to your team Meet at regularly scheduled times to review responsibilities and other issues
Communicate roles and responsibilities to the client and make sure they’re understood and signed off on. If any of your work or contractual obligations rely on information, data, files, or other copy to be received from the client, make certain that understand what you need and when you need it. If there are daily, weekly, monthly or other scheduled receipt of copy, write this information down and insert it into your project timeline with appropriate names attached. Give a copy to the client.
One of the first activities you will engage in is settling on how and when you will communicate with the client. Work with the client as soon as the contract is signed and your interaction with them begins, deciding how often you will be in communication and what mode that communication will take. Make a list of parameters: FAX, phone, E-mail, memo, etc.
Take the time to identify a communication schedule. The nature of the project and culture of the client will help decide this. Define the most appropriate communications protocols, i.e., phone, FAX, E-mail, memo, etc. and sign off on it. Identify the most appropriate communication schedule and which team members will be included in regularly scheduled meetings, whether conference calls, face to face, etc. Get signoff on each of these from the client, document your Communications Plan, and distribute it to all involved. Effective communication is the only way to minimize and eliminate confusion and the resulting lost time.
Identify project communication protocols and parameters for the Communications Plan.
- How do you work best? E-mail, telephone, FAX, memo?
- How does the client work? Identify the organization’s culture.
- How often will you report? Daily at a specific time? Weekly?
- Who will be in scheduled meetings? (Client, PM, analysts, engineers, etc.)
- Document communication schedule, i.e., daily, weekly, monthly meetings etc.
- Distribute this to the client and appropriate staff.
- Identify the process and the schedule as well as the players.
- Maintain a communications log: FAX, email, and memo.
- Document all communication.
Inventory all of the technology proposed to the client. Identify appropriate talent to implement the technical solutions based on RFP, Proposal, Problem Specification and Design Specification. Don’t rely on who seems available. Fight for the right people to be on your team.
- Identify custom programming and estimate availability
- Communicate this to the client
- Identify commercial software and vendors
- Identify hardware needs and estimate availability and order times
- Identify any proprietary software and issues
- Identify technical skill sets needed
- Identify resources on staff to complete the technical solutions
- Communicate your technical needs early and often to your superior and the account rep
- Fight for the right people to be on your team
The Project Manager will work with account representatives to maintain a positive relationship with the client. Depending on the culture of your organization, and that of the client, the degree to which you will interact with the client will vary. Your account representative may assume a prominent role in client relations, or may feel comfortable delegating that responsibility to you. Identify this role early in the project. Don’t assume the account rep will handle all relations with the client. Be proactive and labor early on to define this role and ensure the client is comfortable with the situation.
Whether you are assigned a prominent role in client relations or not, communicate the primacy of the client to your staff. Moderate the tendency of staff to perceive the client as a pain. They are the paying customer after all and come first.
Projects often assume an identity of their own. There is a tendency for staff to feel and work as though the project emerged from inside the company and to forget that a separate corporate entity has requested the work be done. The fact that the consultant has sold their services to a paying client often gets lost in the enthusiasm of the project staff. Manage that enthusiasm, keep it focused on the goals of the client.
You are managing a skilled and creative group of individuals. It is imperative that the group move forward as a team. You need to moderate and manage the natural enthusiasm of your staff. There is little time for “artistry” in a technical project. The team must work together and avoid too much individuality, while, at the same time you are encouraging creative problem solving behavior. This is a difficult balance. Some simple guidelines include:
- Communicate roles effectively
- Make sure everyone is aware of and understands everyone else’s role
- Keep a team roster
- Decide on, and maintain, regularly scheduled team meetings (without over doing it)
- Encourage creative approach to problem solving
- Ensure that everyone understands the ultimate goal of the project
- Solicit feedback regularly: find out if the team’s view of the project matches your own
Depending on your personal style, the culture of your organization, and the makeup of your team, how familiar you are with the team will vary. One thing you must keep in mind however, you are no longer a team member alone, you are the coach. You have the responsibility of keeping the team focused. In general, you will not have the luxury of familiarity with team members in the way that they will have and you used to. You must encourage comraderie while maintaining some degree of distance. The reason is simple, as mentioned above the Project Manager will be teacher-guru-slave driver-guide. You must operate at several levels at once. The time will come when you will crack the whip and that will require some separation from the team. New managers especially discover some difficulty in achieving this balance, particularly if they are promoted from within the organization. You may now be managing people you used to work with. This is often a difficult situation. Communicate these frustrations to your superior.
Projects have a natural tendency to self-destruct. Competing centripetal energies fragment the direction and thus the integrity of the project. This is amplified in client-oriented technical projects. Know now that your project management is mirrored, to some extent, client-side. They have their own ideas. They have been thinking about and planning for this project a lot longer than you have. Theyare going to contribute, to some extent, to the project. The Project Manager must play host to the client and at the same time control their tendency to get involved. Understand and accept that change will occur and that some changes will be beneficial.
Competing energies from the client, external contractors, and internal staff often result in new ideas and directions not described in the Design Specification. Focus is lost and teams lose sight of the target. Make sure everyone understands the goals even as they shift, and ensure that everyone’s activities are geared to satisfying the solutions to the problem as laid out in the Design Specification and Problem Specification documents. The iterative nature of programming projects ensures that change will occur.
Acknowledge proposed changes, investigate these, and come to a conclusion whether they are urgent or not. If so, call in appropriate staff to analyze and make recommendations. Where changes are approved, first evaluate the impact, document this, and then negotiate a contractual change. Make sure the client is aware of and understands all implications and impacts before you negotiate the change and then schedule and implement the change.
- Review proposed changes
- Analyze and make recommendations
- Decide whether change is urgent or not
- Evaluate impact to project
- Negotiate contract change with the client
- Schedule the change
- Implement the change
The PM provides the compass and the map to the project, the direction to the goal agreed to by all. The Project Manager must anticipate changes to the plan as well as the tendency towards fragmentation.
Recognize that it is not the client’s responsibility to anticipate or understand problems that will arise. That’s why they hired you. In fact, the client will be a source of some problems. Anticipate that.
- Communicate your project needs clearly and regularly to your superiors and the account rep.
- Get signoff on your procedures from the client and your superiors.
- Demand support and commitment from your own company.
You are the compass and map: Where are you going? How will you get there? Who is going with you? and Who will help?