It is common for the relationship between development and management to be tenuous. Both are like good fighters circling each other, testing for weaknesses. The moment that a weakness is found: whammo! And it’s usually the developers that are down for the count.
As a developer the way that I typically win the fight with management is by effectively managing their expectations. When a project starts out, I set very clear expectations on an initial deliverable. This is not what most would consider to be a milestone. This is something typically much smaller. It is this piece of documentation or it is showing them that few buttons and fields working on a web page. Now here’s the important part: I meet that expectation. After the first expectation is met, another is set, and, guess what?, I meet that expectation too. This goes on again and again and again. Within a few weeks management has become more amicable when it comes to negoitating terms.
(What’s ironic, for me at lesat, is this is what I believe that XP is trying to promote with its tight involvement with the clients and its short development cycles. Unforunately for me, I had to develop this methodology on my own over the years.)
For those that may have missed it, let me emphasize again what is going on. By setting expectations and by consistenty meeting those expectations, the tenuous relationship between management and
development becomes more amicable. Effectively, development builds and earns managements trust. Only through this earned trust can development begins to dictate its own terms. (I call this “Managing the Managers”.)
A quick illustration: when developers and management first meet, there is no trust between them. Management tends to be the dominant force since it tends percieves development to be “working for” management. As a developer how can I say “well, we think that your time estimates are off by a factor of ‘n'” without any proven trust or track recond? You must also factor in the fact that the management team may have been bitten in the past by developers so there’s already an uphill battle. (Yes, it may be that management has been bitten as a result of their own mis- or over-management.) Only after consistently and continually setting and meeting expectations and by establishing a degree of trust is it much more palatable to go to management and say “We believe that the timelines you have established are invalid. This new timeline is what we believe is more realistic. We can back up this estimate with the fact that we have defined timelines in the past and have consistently met them.”
You may have also noticed by now that this stream of small deliverables shows management clear progress. There’s no confusion as to the state of the project. This does wonders for reducing management’s anxieties.
A few tricks that I use to gain trust faster (I hope that there are no managers around and I hope that people will understand my intentions and not misconstrue them):
- It is possible to placate management by delivering some of their “dream” ideas early in the project. If you have a manager that likes purple hippos, then put some purple hippos on the web page. If you have some manager that really wants something that you know is dumb, just add it. (Remember: we’re talking about small deliverables. We’re not talking about adding that new e-commerce functionality that they’ve wanted!) This will go a long way to gaining their favor. Loosen up the relationship early if you can and as necessary.
- Work a little harder on the first deliverables and pad the time a bit more so that on just a few of them you deliver early. It’s just a cheap and dirty way to quickly provide the perception that the development team is trustworthy. This will certainly help with a very icy relationship.
- I hesitate to mention this trick because I know it will be misconstrued by some, but a few of these deliverables can be orthogonal to the actual development efforts if there is a tactical situation that can be exploited. If there is a particularly icy relationship that needs to be warmed up quickly and if there is an opportunity to make a quick win then weigh the risks and try it as
necessary. I’ll leave it at that.
I now need to stress that this does add quite a bit of management overhead on the part of the development team. Accurately defining small deliverables and ensuring that these deliverables are met while ensuring that the deliverables are in line with the goal of finishing the project can be quite taxing on the development lead. It can consume quite a lot of their time.
I also need to stress that it’s very easy to “fall from glory” in the early phases of a project by missing a single expectation. One item that I cannot emphasize enough to teams is clear and early communication about a missed deliverable. Telling management that you’re going to miss a deliverable that is expected either the same day or the day before does nothing to paint you in a good light. It simply shows them what they already believe: that you have no ability to effectively plan and anticipate problems. If you know that you’re going to miss a deliverable then tell them! Just don’t say: “Hey Bob! We’re going to miss the deliverable” and leave it at that. Say: “Hey Bob! We’re going to miss the deliverable for these reasons, here’s when we’re going to deliver on the deliverable [or, alternatively, here’s the items that we’re going to deliver], and here’s what we’re going to do next time to not miss the deliverable.”
Finally, you must continue to manage the relationship even after it has become amicable. I have seen a few projects where the developers have achieved a decent relationship by following what I’ve outlined here and then they stopped setting and meeting expectations. The relationship can quickly return to its original state. Management is very much about “what have you done for me today”. If there’s no “today” to frame some request then you quickly fall out of favor.