Know Your Boundaries

In all relationships, not just personal ones, it is essential to know one's own boundaries. You really can't know the boundaries of other people until you cross them and by then... it's too late. In a business relationship it is better by far to write your boundaries down in the contract; make it all known so that both you and the client know what you will and will not do.

Easy. Not so much for the consultant who becomes Project Manager (PM) for the client, using the client's staff for implementation. Larry Richman, in his standard 'Improving Your Project Management Skills' suggest that project objectives must past the Specific, Measurable, Agreed upon, Realistic, Time/Cost limited (SMART) test. Many are the clients who come to us and say, "We want a document management system." when they have never specifically identified what the objectives of such a system are for their organization. It may sound ideal, they want you to tell them what their objectives are; you get to decide how deep and wide the project will go, how long it will last, and what will be needed, but you open yourself up to the accusation that your decisions are self-serving (and enriching). It will happen, at some point, with every client; they will doubt the need for some aspect of a project and someone on staff will suggest that the consultants are bloating the budget to bloat their fees.

Once the client has given you their objective for the project you can define the rest of the SMART test in your contract. The key difference here is that on most projects the PM herself is the one defining the objectives of the project. This is fine for a staff PM; internal audiences will not suspect her of anything, she has nothing to gain from a more expensive or longer project. If you are working as the PM maker sure the sponsoring executive (SE) of the project has defined the project objectivess and, then, have her tell you what she defines as success. Make sure the SE explains, company wide if need be, the objectives of the project and the metrics of success so that staff knows it is the SE, and not you, defining the scope of the project.

Ideally, a consulting PM will simply serve as a liaison between existing teams, coordinating their efforts and measuring their progress. It is more likely that you will have to do more than coordinate existing teams, the client could have done that themselves. Your worth most likely lies in your specific knowledge of the project at hand. Staying with the document management project example, you know what the legal requirements are, you know what the user experience must be like to encourage adoption, you know which products work together etc. Your specialization argues for giving you the authority on questions related to your bailiwick, even when that authority crosses pre-existing reporting relationships or temporarily subordinates them. The SE has to make sure that every member of staff knows that she has given you the authority to make such decisions. Reinforce the point with frequent project meetings where the SE defers to your judgment and where you run the meeting.

An even cleaner way to define the relationship with the client staff is to ask the SE to second specific employees to your management for the duration of their role in the project. This will make the project go faster as a seconded employees should have no other responsibilities than working on the project. If you have to compete for the attention of employees with managers they have to work with long after you are gone, you will not be given priority treatment no matter what directive the SE has given.

Next time: Strategies to manage client employees.