The Perils of Consulting: Project Management

Today we start a series of posts on the perils of project management as consultants and how clients and consultants can avoid some of the potholes on the road to project implementation.

CONSULTING vs CONTRACTING
Let us use an analogy from another industry: Architects and Builders. Although many architectural practices are moving toward integrated management, most still operate essentially as consultants to their clients who then take the ideas the architect has sold them to builders who work directly for the client. The builders are the contractors, they will actually perform the work to complete the project. The architects stay on hand, of course, to offer solutions to technological problems or to clarify their design ideas.

Now take any project a business needs to complete, they can use their own staff to design and execute the project, or they can hire consultants to research and design the project (especially when the project is outside the expertise of the firm itself) while their staff performs the actual work, or they can hire the consultant to implement the plan. We find that this is the first place a consultant and a client can have a clash of expectations. As a consultant one's role is fairly clear: Advise the client. However, once you cross over into the active daily management of the project or performance of the component work one has become a contractor. In the building trades this is usually not a problem as contractors use their own or sub-contracted employees, they typically do not oversee or direct the client's employees though frequent collaboration may be necessary for logistical reasons. If a consultancy is hired to manage a project for an internal business project where in the line of authority does the consultant/manager lie?

Managing a client's employees for them is bound to lead to resentment, confusion and conflict. Such employees will be confused, even with the best guidelines, about the priorities of their job and the authority of the consultant. They may well resent the imposition of a new manager they have never worked for and who will be gone post-implementation. Still, having management authority over the client's employees is better than not having it, while still being the manager of the project. If the consultant is tasked with project management without the authority to direct individuals or even departments the consultant will have a difficult time getting their work done over the other priorities and relationships that shape work flow in the client firm. This can (and for us has) led to some nasty confrontations with entire departments that were angry (not at us per se) that an outsider was attempting to direct their work.

It is obviously much better to clearly establish what it is one wants, both as a client and as a consultant. Does the consultant want to reap the financial benefits of project implementation or do the design work and hand it off? Does the client want a start to finish consultant cum contractor to work alongside its employees or in a self contained unit?

Next time we will talk about defining the role of the consultant and if work that requires internal authority is required, how to segment the scope of the work to minimize clashes with existing client employee priorities and expectations.