Many small developers hit a wall of pain when they start growing out of their one-team-one-game-no-limits shoes. In particular if they sign a deal with a big publisher…suddenly time, money and quality and a whole pantheon of buzz words starts flying about and rocks are overturned and closets are emptied out for everyone to see. Expectations are high and the developer finds that “it will be great, just trust us” doesn’t fly any more…
The publisher, or even new management, will not trust the word of the developer even if they have a great track record because they inevitably want so much more and because they inevitably introduce another level of hierarchy with new accountability and new pathways for blame. If you, as a representative of the publisher, are trusted with $$$ to get a title developed and shipped by a developer then you will want to cover your own back and if you don’t understand, or don’t see, the inner workings of said developer then you will become intrusive. This is human nature and this is why the developer has to come up with something other than “it will be all right, trust us”….
Equally you, as the publisher, have to understand that unless you can articulate exactly what it is you want (in which case you will kill any creativity on the developers part) you will *not* get exactly what you thought you were getting.
What a dilemma…
Now, agile development methods can help here because they put so much emphasis on measuring progress by working product and not documents (unless of course that’s what you are producing…) or promises; if it doesn’t run “on the box” it isn’t done, simple. Importantly these processes also rely on the concept of product owners; the people who are the representatives of the customer on earth (the Voice of the Customer.)
To make it work, you as a stakeholder really have to act like one. Dropping in once in a while and leaving (un)helpful comments about making something more blue or less dull is not going to get you your AAA seller (nor is it going to get you any respect.) You have to become part of the RACI chart (Accountable, in fact) in the eyes of the developer and You Must Take This Very Seriously.
If you can get a developer to agree and buy in to this arrangement of you-the-stakeholder across the board (that is: for the whole team, from the bottom up, everywhere and always) then you are in a good place. Key here is for the whole team because it doesn’t do much good if only the developer’s management team buys in and understands it while the rest of the team soldiers on as before. You will not get what you agree on, you will be frustrated and angry with the developer, their management team will loose kudos and respect with you and their teams and it will all go Horribly Wrong. Trust me…I’ve been there.
So, when you first meet and greet and sign dotted lines you must be 100% clear on Who Does What. Are you here to pay them money and let them get on with it or are you here to pay them for something specific that you want? Do not ignore this distinction! Ask probing questions (it’s better to have a bit of hard time early than later when it might be too late to change anything) and don’t accept fluffy answers. Make sure they (and you) understand their place in this great play.
Schwartz’ “Group Effectiveness Model” is a good place to start; it is a model (google it) that categorizes the different forces that interact to make a team effective. Effectiveness doesn’t necessarily mean “creates lots of stuff cheap”, it means that the team works together effectively and that communication and roles are clear in everybody’s mind.
Again, unless you are going to just hover in and out of the developer’s view occasionally and otherwise leave them to their own devices, you all have to understand each others places and interfaces relative to each other.
You must do this early on and you must catch any deviation or eroding of this.
Remember, you are part of the team…..
