A mutually agreed working structure

Establish a clear, strong, clean working relationship that allows you as manager and the contractors to reach a mutually agreed-to working structure. Ideally, the impetus in achieving this out to be on both you as a manager and the contractor.
Be well,
Dwika-ExecuTrain



"How can people be so dumb? I thought I was hiring professionals."
by: Steven Cerri

Here's the situation.

A current coaching client called me (before he was a client) in a state of severe upset. He is managing a relatively large software development project for a web portal and, in an effort to contain costs, he has contracted out much of the work. He has tapped several of the contracting portals such as enlace, oDesk, Outsource Solutions, and he has hired, what he thought, was a good team of programmers and designers. He gave them his requests and then sat back and expected results.

In some cases he got very good results. Some of his contractors delivered top-notch work. Others delivered not-so-great results. But in all cases, my client used his preferred management style. He would reach out to the contractors via email, or IM and expect to know what the status of his project was. In nearly every case their work style didn't match his management style. What do I mean by that?

In some cases, my client would email his contractors requesting information about the status of their projects. My client expected to hear back within a couple of hours. That's how he would have responded if he'd been pinged by his customer. Actually, one contractor didn't get back to him until a week later! And in several other cases his requests for status weren't answered until several days had passed.

In one case, the contractor delivered "buggy" code. When my client complained that it seemed that it wasn't tested properly, the contractor responded that regression testing was not included in his bid.

In another case, the contractor modified a portion of the web portal that was outside the scope of his work but because it was necessary to make his module function, he did it anyway. But he didn't inform my client of the changes and the whole portal went down.

After these events and many others, my soon to be client called at a loss for what to do to bring this project under control. He just didn't know what to do. He made statements like:

* I can't believe these people are so irresponsible. They write code and they don't even test it.

* I can't believe these people won't answer my emails or IMs in a timely manner. These people disappear for a week at a time.

* I've got contractors who won't bid on a task for a fixed price. They tell me it will cost as much as it will cost. I can't tell my customer that. I can't manage a project with "It will cost what it will cost!"

* Some of these people are really good technically, but I can't work with them.


That's the set-up. Now I'll tell you what happened.

The question I always ask is: "What do you want?"

While this might seem like a self-evident question it took my client considerable time to answer it. Because, for most technical managers who have a strong engineering/technical background, the answer is filled with contradictions and impossibilities.

At first his answers to this question were as follows:

* I want the best technical people.

* I want them to manage themselves. I don't have the time to manage them closely or to micromanage them.

* I want to communicate with my contractors the way I want to communicate with them and I don't want to chase them down.

* I want them to think and work like me.

Now my client wanted the above conditions within reasonable limits. He understood the impact of time differences on work and communication schedules, but he wanted the above conditions subject to reasonable impact due to distance.

Now you might look at his list and say, "That seems reasonable to me. I'm paying these people for their work. If they want to get paid they had better deliver. And I want to manage them the way I want to manage them."

Well, unfortunately, it doesn't work that way.


My suggested approach.

Over the course of several coaching sessions I helped my client take a very different approach to managing his contractors and things have turned around. He is now receiving the communications and results he always wanted.

Here is what I suggested and what my client did.

First, my client's attitude had to change, as follows:

* Whoever said that your contractors have to work like you do?

* Whoever said that your contractors have to think like you do?

* Whoever said that your contractors have to be willing to bid fixed-price?

* Whoever said that your contractors have to respond to your emails and IMs within two or three hours?

* Whoever said that your contractors can't "disappear" for a week at a time without "asking your permission"?

The fundamental issue for my client was that he had expectations that he didn't communicate to his contractors, and then when the contractors didn't live up to them, he got upset. Well who's responsibility is that; the contractor or my client?

I'll state it differently. When a contractor doesn't deliver on an unexpressed expectation of the manager, who is responsible? We can even generalize this more. When a direct report doesn't deliver on an unexpressed expectation of the manager, who is responsible?

As far as I'm concerned, in most cases, the responsibility for missed and/or unexpressed expectations is the responsibility of the manager.

As obvious as this statement seems, the challenge comes about because most technical managers and most engineers are loath to express their expectations. They don't like to tell people what they want. They consider other engineers to be professionals. They wouldn't want to be told what to deliver and they think that other engineers feel the same way. Therefore, they avoid those important, clarifying discussions that make all the difference in the world between success and failure. The goal is to express exactly what you expect in all facets of the project.

It doesn't have to look like micromanagement if it's done properly. In fact, I don't think micromanagement ever has to appear if the conversations that structure the project are conducted correctly.

What we did.

My client began to implement a series of conversations and processes that I suggested.

The conversations were used to establish common expectations and common ground. The conversations allowed my client and his contractors to come to agreement regarding philosophy, attitude, processes, requirements, and deliverables.

New and much more demanding processes were implemented. Documents defining requirements were implemented. Documents defining changes to design, requirements, functionality, and/or code were implemented. New processes were implemented so that reviews took place on a regularly scheduled basis.

My client had a habit of "dictating" to his contractors and then getting upset with them when they didn't meet his expectations. Now with these conversations and processes in place, he began asking his contractors for their suggestions. They became committed to the overall projects' success, not just to the success of their tasks.

Finally, he understood that having the very best programmers who won't communicate with him or provide visibility into their progress was not a good fit for him. In fact, he decided he'd rather hire a good programmer who works with him the way he likes, than a great programmer who wants to work "his own way". This, of course, matches what is often said about technical employees, "We hire engineers for their technical expertise, and fire them for their lack of fit".


The Bottom Line.

My client has been implementing the changes I suggested, some of which are laid out in this Ezine/Newsletter. And his project is turning around. He's bringing his projects and contractors under control. He's able to predict cost and schedule much more accurately now. And he is developing relationships with engineers, programmers, and designers that he has never meet in person, such that they are working together much more smoothly.

Working with contractors all over the world is a new requirement for managers and it's here to stay. It's not about fancy tracking software, although it can help. It's not about having the best and brightest on your team, although that may be useful in certain circumstances.

The key is knowing how to establish a clear, strong, clean working relationship that allows the manager and the contractors to reach a mutually agreed-to working structure. Ideally, the impetus in achieving this out to be on both the manager and the contractor. However, the reality is, in most cases, the responsibility for success on a contractor-developed-project, rests with the technical manager.


What would you have done?

Email me with your suggestions. I'm very interested in your thoughts.


Good luck and be well,

Steven