Software without anger: managing vendor relationship
/Isn’t that a great title for an article about software development? If you’ve ever been involved in a software development project this would ring bells! And if you have not been, but you are thinking of starting a software company or working with a vendor to make a software you should definitely learn about this. Because want it or not, anger will come. You’d be very lucky if it’s only once in a while that people are angry, it could easily be that the whole project is a series of angry exchanges!
FEAR NOT.
This is a problem that can easily be managed (if not completely avoided) if you take some simple steps. So here goes our strategies for anger managed software project. I want to split these strategies up in separate articles, one about managing anger between you and the outside software development partner, one about strategies to use to manage anger when your developers are in house and the last one about strategies to manage your own anger (remember, you are sometimes one of those angry people)!
Today’s article is about strategies for managing software projects that are outsourced to custom software development company like us.
Expect and accept anger as normal in software development.
In any endeavor where there is a lot of unknowns and yet the risks and cost of getting things wrong are big anger is natural. Anger is actually sometimes good sign in software projects - it shows people involved in the process are emotionally attached to what they are doing and they care enough to voice things out. It is the negative aspects of anger like the blame game, shutting off channels of communications, creating bias, etc. that are destructive that you have to be worried about. If you expect and accept the fact that there will be anger, you can take steps to reduce it, manage it or channel its energy to a creative force.
Know that software development is a fluid process.
The top thing you need to understand when you are managing anger or designing a process to reduce it, is that software development is inherently a fluid process. You just can’t have it structured as precision engineering process (e.g. like a building a bridge) where everything is thought out and can be measured. Every step of the software development process involves reviewing what you initially thought needed to be done and changing it. Remember why Agile process is so successful - “embrace change”. So all your contracts, documents, dev cycles, demos, monitoring, analysis of work should have the possibility of change taken into account. For example your software development contracts with the vendor should have clauses to cover situation where there are changes. Timeline and delivery milestones should have padding for inevitable change. The list goes on.
Scope, scope and scope.
The full software will probably do a lot of things one day (maybe even change the world) but for the small block of time that you are working on, or the immediate delivery you are waiting for will only be for a small section of those things. So you’ll need to first identify clearly what you want to achieve, define and document those features and then communicate that to the developers. You are scoping the limits of a delivery. If you do that clearly, right up front and stick to it (as much as possible without harming your business) you’ll get rid of most of the destructive anger in a software project.
Have regular scheduled meetings.
As the software is being built offsite by a team that is not always in touch with you regularly things can easily go in the wrong direction. It’s essential to have regular meetings at short intervals. That makes it easy to find errors early, give feedback early and get the development back on track faster. Bunching up a lot of development work to be reviewed in one go is a recipe for disaster and fights. It is counter productive and actually wastes much more of your time than the time you thought you were saving but not doing regular meetings. How regular? Depends on the nature of the project, but I will say the meetings should never be more than weeks apart.
Create an environment of trust and collaboration.
For a software project that is outsourced this is a really big one, and most of the responsibility fall on you as you are the ultimate customer as much as the software team is concerned. You set the tone of the collaboration. If you set it so that it’s always combative then you’ll have your vendor always trying to be defensive. They will hide things from you, be less proactive, less likely to point out errors on your part. Set the tone from the start that you have trust and that the project is a collaboration. That will make way for conversations that addresses issues with reason rather than emotion or subterfuge.
Always celebrate victories.
Make deliveries and reaching milestones a big thing. Treat your team to a party, give them some symbolic gifts (even a congratulatory email goes a long way). This celebration renews the relationship, gives it the time to rest and prepare for the next cycle. And most importantly this celebration makes it easy for people to forget bad feelings and make them move on with renewed energy. It is like the restart button on a game gone wrong!
That’s all for today, wait a bit for my other one about keeping your in house development process happy. By the way this article was my chance once again to use old black and white pics stolen from the web particularly of the three stooges. We used to have this as a tradition for all our articles some years ago!
